linux-kernel - Re: [xen] double fault: 0000 [#1] PREEMPT SMP DEBUG

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131008080625.GA25034@n2100.arm.linux.org.uk>
Date:	Tue, 8 Oct 2013 09:06:25 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Fengguang Wu <fengguang.wu@...el.com>,
	David Airlie <airlied@...ux.ie>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	xen-devel@...ts.xenproject.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [xen] double fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC

On Tue, Oct 08, 2013 at 10:14:52AM +0800, Fengguang Wu wrote:
> [    2.785188] kobject: 'drm' (ffff880006dae048): kobject_release, parent ffff880000189648 (delayed)
> [    2.787362] kobject: 'drm' (ffff880006dafe00): kobject_release, parent           (null) (delayed)
> [    2.789674] [drm] radeon kernel modesetting enabled.
> [    2.791798] [drm:drm_proc_init] *ERROR* Cannot create /proc/dri/0
> [    2.793280] [drm:drm_get_minor] *ERROR* DRM: Failed to initialize /proc/dri.
> [    2.795591] kobject: 'controlD64' (ffff880006dc3820): kobject_release, parent           (null) (delayed)
> [    2.797988] cirrus: probe of 0000:00:02.0 failed with error -1
> [    2.799675] usbcore: registered new interface driver udl
> [    2.802167] parport_pc 00:04: reported by Plug and Play ACPI
> [    2.803818] parport0: PC-style at 0x378, irq 7 [PCSPP(,...)]
> [    2.806035] kobject: 'parport_pc.956' (ffff880006dc3820): kobject_release, parent           (null) (delayed)

Look very carefully at the above addresses of the controlD64 object and
the parport_pc.956 object.  They're both the same - and the first hasn't
been run yet.  It's a double addition because the culpret is not parport_pc,
but is controlD64 instead.

And here we have it:

int drm_put_minor(struct drm_minor **minor_p)
{
...
        drm_sysfs_device_remove(minor);
...
        kfree(minor);
}

void drm_sysfs_device_remove(struct drm_minor *minor)
{
        if (minor->kdev.parent)
                device_unregister(&minor->kdev);
        minor->kdev.parent = NULL;
}

I think David Arlie also needs a quiet talking to about how to use the
device model:

int drm_sysfs_device_add(struct drm_minor *minor)
{
        minor->kdev.release = drm_sysfs_device_release;
...
        err = device_register(&minor->kdev);
}

static void drm_sysfs_device_release(struct device *dev)
{
        memset(dev, 0, sizeof(struct device));
        return;
}

Since when has that been acceptable in a release function?
--
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/