Re: [linux-usb-devel] Bug creating USB endpoints in 2.6.20.x (kernel bug 8198)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Tejun,

On 5/9/07, Tejun Heo <[email protected]> wrote:
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 closed later but it should fix
>> the bug winecfg triggers.  I really dunno how to fix this the right way
>> in the stable kernel.  Better ideas?  Anyone?
>
> How about a WARN() and a small(?) memory leak? Better than an oops, surely?

Device node creation/deletion can be quite often depending on
configuration, so I don't think we can afford memory leak here.  It can
develop into a big problem for long running hosts.  IMHO, just
introducing module unload/deletion race is much better.  It's the lesser
evil, difficult to trigger and already broken in other places anyway.

I think we need to hear what other people are thinking about it.  Cc'ing
Maneesh, Dmitry and Cornelia.  The whole thread can be read at...

 http://thread.gmane.org/gmane.linux.usb.devel/53559
 http://thread.gmane.org/gmane.linux.usb.devel/53846

The thread is rather long but just reading the message from the second
URL should be enough.  The problem is that dev->devt_attr (class dev has
the same problem) is deallocated when the device is deleted.  If the dev
sysfs attribute has users at that point, the dev sysfs node is left with
garbled struct attribute causing oops later.

IMHO, the proper fix for this is immediate-disconnect which is no in -mm
as the problem is caused by expecting immediate-disconnect behavior when
it isn't implemented.

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 device is still going to
be pinned into memory while there are sysfs users... I don't like
fattening of device structures but leaks and/or oopses are worse in my
book.

--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux