Alan Stern wrote:
> On Thu, 10 May 2007, Tejun Heo wrote:
>
>> Currently, devt_attr for the "dev" file is freed immediately on device
>> removal, but if the "dev" sysfs file is open when a device is removed,
>> sysfs will access its attribute str
Kay Sievers wrote:
> On 5/10/07, Tejun Heo <[EMAIL PROTECTED]> wrote:
>> Currently, devt_attr for the "dev" file is freed immediately on device
>> removal, but if the "dev" sysfs file is open when a device is removed,
>> sysfs will access its a
Greg KH wrote:
>> Applies well to 2.6.20 and 21. As sysfs-immediate-disconnect doesn't
>> seem to be included in 2.6.22, this should be included in linus#master
>> too (applies well there as well).
>
> As I don't think we should be adding your sysfs rework to 2.6.22 just
> yet, any objections to
y postponing
freeing devt_attr to device release time.
Note that devt_attr for class_device is already freed on release.
This bug is reported by Chris Rankin as bugzilla bug#8198.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Chris Rankin <[EMAIL PROTECTED]>
---
Applies well to 2.
this. Remove these attributes from
[class_]device and use static attribute structures instead.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
drivers/base/class.c | 44
drivers/base/core.c
Greg KH wrote:
> On Wed, May 09, 2007 at 03:30:41PM +0200, Tejun Heo wrote:
>> Chris Rankin wrote:
>>> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
>>>> So, we can fix the problem Chris is seeing by breaking module unload (by
>>>> allowing it to unload
Dmitry Torokhov wrote:
>> As written above, I think it's better to risk module unload / sysfs race
>> than keeping the current sysfs deletion / open race. What do you guys
>> think?
>>
>
> How about embedding struct attribute fro devt into struct
> [class_]device for now? It is not too big and de
Chris Rankin wrote:
> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
>> Okay, here's a half-assed fix. With this patch applied, if you try to
>> unload a module while you're opening it's dev attribute, kernel will
>> oops later when the file is accessed or
Chris Rankin wrote:
> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
>> 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 nod
[adding back linux-usb-devel. please don't drop cc]
[also adding lkml and Greg K-H]
Chris Rankin wrote:
> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
>> Okay, here's patch against 2.6.20.11. Let's hope we're not chasing
>> something which is already fixed
Chris Rankin wrote:
> Will this patch apply against 2.6.20.x? I haven't tried triggering this
> problem on 2.6.21.x yet.
Okay, here's patch against 2.6.20.11. Let's hope we're not chasing
something which is already fixed.
--
tejun
---
fs/sysfs/dir.c| 57 +
Tejun Heo wrote:
> Hello, Alan, Chris.
>
> Alan Stern wrote:
>> On Sat, 5 May 2007, Chris Rankin wrote:
>>
>>> --- Alan Stern <[EMAIL PROTECTED]> wrote:
>>>> However it is usually the same endpoint number and the same device (even
>>>>
Hello, Alan, Chris.
Alan Stern wrote:
> On Sat, 5 May 2007, Chris Rankin wrote:
>
>> --- Alan Stern <[EMAIL PROTECTED]> wrote:
>>> However it is usually the same endpoint number and the same device (even
>>> if the device number changes)? In that case we can tell the code where to
>>> look for
Chris Rankin wrote:
> --- Tejun Heo <[EMAIL PROTECTED]> wrote:
>> I'm curious whether recent sysfs rework makes the problem go away
>> but as -mm containing those updates aren't released yet, there's no
>> easy tree to test.
>
> I'm not sure
Chris Rankin wrote:
> --- Alan Stern <[EMAIL PROTECTED]> wrote:
>> There may indeed be a race condition somewhere, but so far you
>> haven't proved there is or pinned down exactly where.
>
> However, I have *definitely* demonstrated the existence of a
> memory-corrupting **BUG**. I am consistently
Alan Stern wrote:
> On Thu, 3 May 2007, Tejun Heo wrote:
>
>> Hello, Alan Stern.
>>
>> Alan Stern wrote:
>>>> The endpoint directory shown in the oops report does not exist if I'm not
>>>> thrashing the box with
>>>> winecfg.
Hello, Alan Stern.
Alan Stern wrote:
>> The endpoint directory shown in the oops report does not exist if I'm not
>> thrashing the box with
>> winecfg. On Tejun Heo's suggestion, I put some debug code at the beginning
>> of sysfs_release() to
>> print a stack-dump and the kobject's path if the a
17 matches
Mail list logo
