[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <46419711.8050003@gmail.com>
Date: Wed, 09 May 2007 11:40:33 +0200
From: Tejun Heo <htejun@...il.com>
To: Chris Rankin <rankincj@...oo.com>
CC: Alan Stern <stern@...land.harvard.edu>,
linux-usb-devel@...ts.sourceforge.net,
linux-kernel <linux-kernel@...r.kernel.org>,
Greg K-H <greg@...ah.com>
Subject: Re: [linux-usb-devel] Bug creating USB endpoints in 2.6.20.x (kernel
bug 8198)
[adding back linux-usb-devel. please don't drop cc]
[also adding lkml and Greg K-H]
Chris Rankin wrote:
> --- Tejun Heo <htejun@...il.com> wrote:
>> Okay, here's patch against 2.6.20.11. Let's hope we're not chasing
>> something which is already fixed.
>
> Hooray! The trick was to trace the "dev" file instead of the endpoint directory itself. The
> compressed oops is attached.
Alright, it took a lot of work but the winner is the "dev" node. Gee...
We could have caught this earlier unless I forgot to print the name of
the last component in the initial debug patch. Well, better late than
never. :-(
Anyways, the problem is that the attribute "dev" is dynamically
allocated using kmalloc() in device_add() and freed immediately after
the file is removed in device_del(). It's basically assuming
immediate-disconnect but that apparently isn't true yet.
The dynamic allocation is to set the owner of the attribute to the owner
of the device being registered. This is twisted in that the field is
added to work around sysfs/module lifetime problem but the workaround
itself is broken with regard to lifetime rules. Aieeeeeeee... This
sort of things are why I implemented immediate disconnect on sysfs in
the first place.
So, we can fix the problem Chris is seeing by breaking module unload (by
allowing it to unload too early). It doesn't sound too hot but module
unloading race is much less likely than sysfs node deletion/open race.
Thanks.
--
tejun
-
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