[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130903204442.GA22222@redhat.com>
Date: Tue, 3 Sep 2013 16:44:42 -0400
From: Dave Jones <davej@...hat.com>
To: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc: rmk+kernel@....linux.org.uk, gregkh@...uxfoundation.org
Subject: Re: kobject: delayed kobject release: help find buggy drivers
On Tue, Sep 03, 2013 at 06:59:24PM +0000, Linux Kernel wrote:
> Gitweb: http://git.kernel.org/linus/;a=commit;h=c817a67ecba7c3c2aaa104796d78f160af60920d
> Commit: c817a67ecba7c3c2aaa104796d78f160af60920d
> Parent: 7c42721fe0c58a848849b43ff558cf2fb86aa35a
> Author: Russell King <rmk+kernel@....linux.org.uk>
> AuthorDate: Thu Jun 27 15:06:14 2013 +0100
> Committer: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> CommitDate: Thu Jul 25 15:39:04 2013 -0700
>
> kobject: delayed kobject release: help find buggy drivers
>
> Implement debugging for kobject release functions. kobjects are
> reference counted, so the drop of the last reference to them is not
> predictable. However, the common case is for the last reference to be
> the kobject's removal from a subsystem, which results in the release
> function being immediately called.
>
> This can hide subtle bugs, which can occur when another thread holds a
> reference to the kobject at the same time that a kobject is removed.
> This results in the release method being delayed.
>
> In order to make these kinds of problems more visible, the following
> patch implements a delayed release; this has the effect that the
> release function will be out of order with respect to the removal of
> the kobject in the same manner that it would be if a reference was
> being held.
>
> This provides us with an easy way to allow driver writers to debug
> their drivers and fix otherwise hidden problems.
>
> Signed-off-by: Russell King <rmk+kernel@....linux.org.uk>
> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
With this enabled, I get a bunch of scrolling oopses immediately after
exiting the bootloader. It happens so early I can't even capture them
over usb-serial, or earlyprintk=dbgp.
And for whatever reason, the printk path while oopsing ignores boot_delay parameter,
so I can't even use that.
any ideas ?
Dave
--
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/
Powered by blists - more mailing lists