--- Tejun Heo <[EMAIL PROTECTED]> wrote:
> Looking at the code, class
> device is already doing it that way, so here's the full-assed fix.
> Chris, can you please test the attached patch?
Tejun,
So far so good; my 2.6.20.11+patch kernel hasn't oopsed yet. I'm going to start
using this kernel
as
On Wed, May 09, 2007 at 05:01:25PM +0200, Tejun Heo wrote:
> 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
>
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 too early). It doesn't sound too hot but module
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 too early). It doesn't sound too hot but module
> >> unloading
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
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
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
--- 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
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 node deletion/open race.
>
> Yikes!
--- 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 node deletion/open race.
Yikes! Just temporary breakage, I
[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.
>
> Hooray! The trick was to trace the
[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.
Hooray! The trick was to trace the dev file
--- 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 node deletion/open race.
Yikes! Just temporary breakage, I hope
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 node deletion/open race.
Yikes! Just
--- 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
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
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
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 too early). It doesn't sound too hot but module
unloading race is much less
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 device is
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 too early). It doesn't sound too hot but module
unloading race
On Wed, May 09, 2007 at 05:01:25PM +0200, Tejun Heo wrote:
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
--- Tejun Heo [EMAIL PROTECTED] wrote:
Looking at the code, class
device is already doing it that way, so here's the full-assed fix.
Chris, can you please test the attached patch?
Tejun,
So far so good; my 2.6.20.11+patch kernel hasn't oopsed yet. I'm going to start
using this kernel
as my
22 matches
Mail list logo