lkml.org 
[lkml]   [2010]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] signalfd: fill in ssi_int for posix timers and message queues
    From
    Date
    On Tue, 2010-07-20 at 15:42 -0700, Andrew Morton wrote:
    > On Fri, 02 Jul 2010 19:38:48 -0500
    > Nathan Lynch <ntl@pobox.com> wrote:
    >
    > > If signalfd is used to consume a signal generated by a POSIX interval
    > > timer or POSIX message queue, the ssi_int field does not reflect the
    > > data (sigevent->sigev_value) supplied to timer_create(2) or
    > > mq_notify(3). (The ssi_ptr field, however, is filled in.)
    > >
    > > This behavior differs from signalfd's treatment of sigqueue-generated
    > > signals -- see the default case in signalfd_copyinfo. It also gives
    > > results that differ from the case when a signal is handled
    > > conventionally via a sigaction-registered handler.
    > >
    > > So, set signalfd_siginfo->ssi_int in the remaining cases (__SI_TIMER,
    > > __SI_MESGQ) where ssi_ptr is set.
    > >
    >
    > This introduces an incompatibility between kernel versions. Someone
    > develops and tests an application on 2.6.36 or later then ships it and
    > lo, it malfunctions on 2.6.35 and earlier.
    >
    > Is there a way to avoid that? Don't think so.
    >
    > How should the more-awake-than-average application developer prevent
    > this problem? Should he probe the syscall at runtime to determine its
    > behaviour? He can't use the kernel version number because the kernel
    > provider might have backported this patch into an earlier kernel.
    >
    > We can minimise the problem by backporting into -stable, and hoping
    > that awake kernel packagers understand the issue, and backport the
    > change as far as they can.

    And perhaps document it in the signalfd man page. This was done for
    commit 0859ab5 "signalfd: fix for incorrect SI_QUEUE user data
    reporting", which seems to a be a similar case.


    > So it's not 100% obvious that this change is desirable. Does the
    > functionality which this patch adds justify the introduction of these
    > problems?

    I think the change is desirable in that no user of the interface could
    reasonably expect the current behavior with respect to the ssi_int
    field, and that it reconciles signalfd's behavior with its design
    intentions. On the other hand, I noticed this discrepancy only because
    I was cribbing signalfd's data structures for checkpoint/restart, not
    because I am aware of any application that is affected, nor was I able
    to find one using Google's code search. It would be highly speculative
    of me to say that no application depends on the current behavior, but it
    is difficult to imagine a correctly functioning application that depends
    on it.

    Davide, any opinion here?


    > > fs/signalfd.c | 2 ++
    > > 1 files changed, 2 insertions(+), 0 deletions(-)
    > >
    > > diff --git a/fs/signalfd.c b/fs/signalfd.c
    > > index f329849..1c5a6ad 100644
    > > --- a/fs/signalfd.c
    > > +++ b/fs/signalfd.c
    > > @@ -88,6 +88,7 @@ static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo,
    > > err |= __put_user(kinfo->si_tid, &uinfo->ssi_tid);
    > > err |= __put_user(kinfo->si_overrun, &uinfo->ssi_overrun);
    > > err |= __put_user((long) kinfo->si_ptr, &uinfo->ssi_ptr);
    > > + err |= __put_user(kinfo->si_int, &uinfo->ssi_int);
    > > break;
    >
    > hm, someone bollixed the __SI_TIMER indenting.

    In kernel/signal.c::copy_siginfo_to_user() too :)




    \
     
     \ /
      Last update: 2010-07-21 05:47    [W:0.027 / U:0.760 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site