[PATCH v2] input: constify valuators passed in by input drivers.

Fernando Carrijo fcarrijo at yahoo.com.br
Wed Aug 11 10:56:22 PDT 2010


Tiago Vignatti <tiago.vignatti at nokia.com> wrote:

> Hi,
> 
> On Tue, Aug 10, 2010 at 07:28:30AM +0200, ext Peter Hutterer wrote:
> > On Tue, Aug 10, 2010 at 03:05:48PM +1000, Daniel Stone wrote:
> > > 
> > > malloc() in a signal handler ftl 
> > 
> > urgh, yes, thanks.
> 
> ...
> 
> > > I guess you could just have a static int copied_valuators[MAX_VALUATORS].
> > 
> > I thought about that but there's more cleanup needed, GPE isn't 100%
> > signal-safe yet, there's at least one caller that may screw up here. 
> > squash one bug, two more come out of the woodworks...
> > 
> > Either way, please ignore this patch for now, it was only exposed due to a
> > new proposed change in the wacom driver and I've already put said patch
> > on hold for backwards compat issues.
> 
> FYI, myself and Fernando have already a working tree with input generation
> running inside a thread:
> 
> http://cgit.freedesktop.org/~vignatti/xserver/log/?h=inputthread
> 
> I don't expect/want reviews yet though. Right now we're discussing the method
> of communication between threads (we're using a pipe, which seems too much for
> it) and some proper test stills needed (hotplug, multiple mice, display
> blanking, etc). Probably we're going to rearrange the commits in a more
> human-readable form before send around.
> 
> This work would solve mostly of this SIGIO issues we have today, for instance
> Daniel's argument to not use malloc()ing during signal handler would not be
> valid anymore and cursor jumping when the server is in D state
> (uninterruptible).

If I'm not mistaken, the situation Daniel relates has more to do with the signal
handler being unaware of the routine it interrupts. Thus, if during heap memory
allocation a function is preempted by a signal handler that also allocates heap
memory, the allocator could get confused and possibly corrupt its own internal
state.

This is a symptom of a more serious problem, which is nicely depicted here:

  http://www.ibm.com/developerworks/linux/library/l-reent.html



More information about the xorg-devel mailing list