Re: Possible bug in keyboard.c (2.6.10)

[Vojtech Pavlik <vojtech@xxxxxxx>]

On Sat, Jan 29, 2005 at 04:50:55AM +0000, Al Viro wrote:

> > I'm very sorry about the locking, but the thing grew up in times of
> > kernel 2.0, which didn't require any locking. There are a few possible
> 
> Incorrect.  You have blocking allocations in critical areas and they
> required locking all way back.

Ok. I see a problem where input_register_device() calls input handler
connect methods, which do kmalloc(). This would be bad even on 2.0.

Anything else? I believe the ->open()/->release() methods are still
protected.

> > races with device registration/unregistration, and it's on my list to
> > fix that, however under normal operation there shouldn't be any need for
> > locks, as there are no complex structures built that'd become
> > inconsistent. 
> 
> Um-hm...  Vojtech, meet USB mouse; USB mouse, meet Vojtech.  Now watch
> a disconnect and reconnect happening when luser suddenly gets overexcited
> and jerks the wrong hand a bit too hard while browsing the most profitable
> sort of website...

I know. As I said, this is a problem I know about, and will be fixed. I
was mainly interested whether anyone sees further problems in scenarios
which don't include device addition/removal.

We already fixed this in serio, and input and gameport are next in the
list.

> > If you find scenarios which will lead to trouble in the event delivery
> > system, please tell me, and I'll try to fix that as soon as possible.
> 
> See above.  Devices appearing and disappearing *are* normal.  

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/