linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: Brendan Higgins <brendanhiggins@google.com>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	hdegoede@redhat.com,
	"rafael.j.wysocki" <rafael.j.wysocki@intel.com>,
	Naresh Kamboju <naresh.kamboju@linaro.org>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:KERNEL SELFTEST FRAMEWORK" 
	<linux-kselftest@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Shuah Khan <shuah@kernel.org>,
	Anders Roxell <anders.roxell@linaro.org>,
	lkft-triage@lists.linaro.org,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>
Subject: Re: BUG: kernel NULL pointer dereference, address: 00 - ida_free+0x76/0x140
Date: Fri, 6 Mar 2020 14:05:25 +0200	[thread overview]
Message-ID: <20200306120525.GC68079@kuha.fi.intel.com> (raw)
In-Reply-To: <20200305223350.GA2852@mara.localdomain>

On Fri, Mar 06, 2020 at 12:33:50AM +0200, Sakari Ailus wrote:
> Hi Brendan,
> 
> On Thu, Mar 05, 2020 at 11:51:20AM -0800, Brendan Higgins wrote:
> > On Thu, Mar 5, 2020 at 11:40 AM Brendan Higgins
> > <brendanhiggins@google.com> wrote:
> > >
> > > On Thu, Mar 5, 2020 at 11:18 AM Andy Shevchenko
> > > <andy.shevchenko@gmail.com> wrote:
> > > >
> > > > +Cc: Sakari
> > > >
> > > > On Thu, Mar 5, 2020 at 6:00 PM Naresh Kamboju <naresh.kamboju@linaro.org> wrote:
> > > > >
> > > > > Regression reported on Linux next 5.6.0-rc4-next-20200305 on x86_64,
> > > > > i386, arm and arm64. The steps to reproduce is running kselftests lib
> > > > > printf.sh test case.
> > > > > Which is doing modprobe operations.
> > > > >
> > > > > BTW, there are few RCU warnings from the boot log.
> > > > > Please refer below link for more details.
> > > > >
> > > > > Steps reproduce by using kselftests,
> > > > >
> > > > >           - lsmod || true
> > > > >           - cd /opt/kselftests/default-in-kernel/lib/
> > > > >           - export PATH=/opt/kselftests/default-in-kernel/kselftest:$PATH
> > > > >           - ./printf.sh || true
> > > > >           - ./bitmap.sh || true
> > > > >           - ./prime_numbers.sh || true
> > > > >           - ./strscpy.sh || true
> > > > >
> > > > > x86_64 kernel BUG dump.
> > > > > + ./printf.sh
> > >
> > > Oops, I am wondering if I broke this with my change "Revert "software
> > > node: Simplify software_node_release() function"":
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d1c19322388d6935b534b494a2c223dd089e30dd
> > >
> > > I am still investigating, will update later.
> > 
> > Okay, yeah, I am pretty sure I caused the breakage. I got an email
> > from kernel test robot a couple days ago that I didn't see:
> > 
> > https://lists.01.org/hyperkitty/list/lkp@lists.01.org/thread/N3ZN5XH7HK24JVEJ5WSQD2SK6YCDRILR/
> > 
> > It shows the same breakage after applying this change.
> > 
> > I am still investigating how my change broke it, nevertheless.
> 
> As nodes in the tree are being removed, the code before the patch that
> "simplified" the software_node_release() function accessed the node's parent
> in its release function.
> 
> And if CONFIG_DEBUG_KOBJECT_RELEASE is defined, the release functions are no
> longer necessarily called in order, leading to referencing released memory.
> Oops!
> 
> So Heikki's patch actually fixed a bug. :-)

Well, I think it just hid the problem. It looks like the core
(lib/kobject.c) allows the parent kobject to be released before the
last child kobject is released. To be honest, that does not sound
right to me...

I think we can workaround this problem by taking reference to the
parent when the child is added, and then releasing it when the child
is released, and in that way be guaranteed that the parent will not
disappear before the child is fully released, but that still does not
feel right. It feels more like the core is not doing it's job to me.
The parent just should not be released before its children.

Either I'm wrong about that, and we still should take the reference on
the parent, or we revert my patch like Brendan proposed and then fix
the core with something like this (warning, I did not even try to
compile that):

diff --git a/lib/kobject.c b/lib/kobject.c
index 83198cb37d8d..ec5774992337 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -680,6 +680,12 @@ static void kobject_cleanup(struct kobject *kobj)
                kobject_uevent(kobj, KOBJ_REMOVE);
        }

+       if (t && t->release) {
+               pr_debug("kobject: '%s' (%p): calling ktype release\n",
+                        kobject_name(kobj), kobj);
+               t->release(kobj);
+       }
+
        /* remove from sysfs if the caller did not do it */
        if (kobj->state_in_sysfs) {
                pr_debug("kobject: '%s' (%p): auto cleanup kobject_del\n",
@@ -687,12 +693,6 @@ static void kobject_cleanup(struct kobject *kobj)
                kobject_del(kobj);
        }

-       if (t && t->release) {
-               pr_debug("kobject: '%s' (%p): calling ktype release\n",
-                        kobject_name(kobj), kobj);
-               t->release(kobj);
-       }
-
        /* free name if we allocated it */
        if (name) {
                pr_debug("kobject: '%s': free name\n", name);


thanks,

-- 
heikki

  reply	other threads:[~2020-03-06 12:05 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05 15:57 BUG: kernel NULL pointer dereference, address: 00 - ida_free+0x76/0x140 Naresh Kamboju
2020-03-05 19:18 ` Andy Shevchenko
2020-03-05 19:40   ` Brendan Higgins
2020-03-05 19:51     ` Brendan Higgins
2020-03-05 22:33       ` Sakari Ailus
2020-03-06 12:05         ` Heikki Krogerus [this message]
2020-03-09 20:35           ` Brendan Higgins
2020-03-09 21:43             ` Brendan Higgins
2020-03-10 11:18               ` Heikki Krogerus
2020-03-10 20:46                 ` Brendan Higgins
2020-03-10 20:46                   ` Brendan Higgins
2020-04-07  9:25                   ` Naresh Kamboju
2020-04-07 20:56                     ` Brendan Higgins
2020-04-13 19:10                       ` Naresh Kamboju
2020-04-14  8:15                       ` Heikki Krogerus
2020-04-14 19:18                         ` Brendan Higgins
2020-04-14 19:27                           ` Brendan Higgins
2020-04-14 21:06                             ` Brendan Higgins
2020-04-14 20:44                           ` Brendan Higgins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200306120525.GC68079@kuha.fi.intel.com \
    --to=heikki.krogerus@linux.intel.com \
    --cc=anders.roxell@linaro.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=brendanhiggins@google.com \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=lkft-triage@lists.linaro.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).