linux-kernel - Re: Oops/Warning report for the week of September 10th, 2008

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: <48C91BE4.7000602@linux.intel.com>
Date:	Thu, 11 Sep 2008 06:23:48 -0700
From:	Arjan van de Ven <arjan@...ux.intel.com>
To:	Greg KH <gregkh@...e.de>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Theodore Ts'o <tytso@....edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Oops/Warning report for the week of September 10th, 2008

Greg KH wrote:
> On Wed, Sep 10, 2008 at 12:16:48PM -0700, Arjan van de Ven wrote:
>> Rank 2: sysfs_add_one (warning)
>> 	Reported 215 times (3751 total reports)
>> 	Duplicate sysfs registration; mostly in USB audio
>> 	This warning was last seen in version 2.6.27-rc5, and first seen in 
>> 2.6.24-rc6.
>> 	More info: http://www.kerneloops.org/searchweek.php?search=sysfs_add_one
> 
> This one is going to be a bit tough to track over time as it is the low
> level sysfs code complaining that a user of it is doing something wrong.
> So you can get all sorts of different callers causing the same warning,
> we just have to look at the backtrace to get a hint of who is causing
> the problem.
> 
> Is there any way to break this one down further by caller so we can try
> to narrow it down?  I thought you did that for other types of warnings
> in the past (may_sleep(), etc.)
> 

it's.. a harder one than that.
All the cases so far were "if it's <this function> for <this class>, go one
down in the stacktrace", which I've done table driven.

For sysfs_add_one() it seems to be "if it is sysfs_add_one, dive into the
stacktrace to pick the one below device_add except if that is device_register
or device_create, because then you pick the one below that instead"

Not impossible, just going to take me more than the 3 minutes it normally takes ;-)

(but please correct me if my description of the heuristic is wrong)
--
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/