linux-kernel - Re: [tps_init] BUG: unable to handle kernel paging request at 484970c9

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 25 Aug 2013 10:17:00 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Fengguang Wu <fengguang.wu@...el.com>,
	linux-kernel@...r.kernel.org, Samuel Ortiz <sameo@...ux.intel.com>,
	Ben Dooks <ben@...tec.co.uk>,
	Wolfram Sang <w.sang@...gutronix.de>
Subject: Re: [tps_init] BUG: unable to handle kernel paging request at
	484970c9

On Sat, Aug 24, 2013 at 09:09:39PM -0700, Greg Kroah-Hartman wrote:
> Same as before, are you unloading and loading modules?  We have a fix
> for modules that cause problems when unloading with the config option
> above enabled.  But that shouldn't be this issue.

What seems to be is going on here is that something creates a kobject,
which gets exported into sysfs, then removed and then immediately
recreated.

It appears that sysfs entries are deleted in the cleanup function:

static void kobject_cleanup(struct kobject *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",
                         kobject_name(kobj), kobj);
                kobject_del(kobj);
        }

which is now delayed.  I don't think this is specifically a problem of
my patch - I think my patch is revealing a problem here.

Let's take it from the point of view of a struct device.  Lets say that
a device with name "foo" gets created.  This creates a sysfs directory
entry called "foo".  Various things take a reference on the device.

You then unregister that struct device because it's been removed.  As
all the references haven't yet been released, it means that the sysfs
directory persists.  Now, if the device is recreated with the same
name, sysfs complains that the directory exists.

In this case, it's not a struct device, but a device driver itself:

        /* some boards have startup glitches */
        while (tries--) {
                status = i2c_add_driver(&tps65010_driver);
                if (the_tps)
                        break;
                i2c_del_driver(&tps65010_driver);
                if (!tries) {
                        printk(KERN_ERR "%s: no chip?\n", DRIVER_NAME);
                        return -ENODEV;
                }
                pr_debug("%s: re-probe ...\n", DRIVER_NAME);
                msleep(10);
        }

Notice how the (i2c) driver is registered and removed multiple times.
If something can independently grab a reference to the kobject associated
with that driver, then it can cause the sysfs directory to persist longer
than the re-probe, which will cause sysfs to complain.

I don't think moving the sysfs directory cleanup (via kobject_del()) before
the delayed release fixes the fundamental problem here, because that just
covers up what happens if a reference is held.

Commit 0f4dafc05 (Kobject: auto-cleanup on final unref) introduced the
kobject_del() into the cleanup function.

Any thoughts?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/