• Eric W. Biederman's avatar
    fcntl: Don't use ambiguous SIG_POLL si_codes · d08477aa
    Eric W. Biederman authored
    We have a weird and problematic intersection of features that when
    they all come together result in ambiguous siginfo values, that
    we can not support properly.
    
    - Supporting fcntl(F_SETSIG,...) with arbitrary valid signals.
    
    - Using positive values for POLL_IN, POLL_OUT, POLL_MSG, ..., etc
      that imply they are signal specific si_codes and using the
      aforementioned arbitrary signal to deliver them.
    
    - Supporting injection of arbitrary siginfo values for debugging and
      checkpoint/restore.
    
    The result is that just looking at siginfo si_codes of 1 to 6 are
    ambigious.  It could either be a signal specific si_code or it could
    be a generic si_code.
    
    For most of the kernel this is a non-issue but for sending signals
    with siginfo it is impossible to play back the kernel signals and
    get the same result.
    
    Strictly speaking when the si_code was changed from SI_SIGIO to
    POLL_IN and friends between 2.2 and 2.4 this functionality was not
    ambiguous, as only real time signals were supported.  Before 2.4 was
    released the kernel began supporting siginfo with non realtime signals
    so they could give details of why the signal was sent.
    
    The result is that if F_SETSIG is set to one of the signals with signal
    specific si_codes then user space can not know why the signal was sent.
    
    I grepped through a bunch of userspace programs using debian code
    search to get a feel for how often people choose a signal that results
    in an ambiguous si_code.  I only found one program doing so and it was
    using SIGCHLD to test the F_SETSIG functionality, and did not appear
    to be a real world usage.
    
    Therefore the ambiguity does not appears to be a real world problem in
    practice.  Remove the ambiguity while introducing the smallest chance
    of breakage by changing the si_code to SI_SIGIO when signals with
    signal specific si_codes are targeted.
    
    Fixes: v2.3.40 -- Added support for queueing non-rt signals
    Fixes: v2.3.21 -- Changed the si_code from SI_SIGIO
    Signed-off-by: 's avatar"Eric W. Biederman" <ebiederm@xmission.com>
    d08477aa
fcntl.c 22.9 KB