public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Nathan Lynch <ntl@pobox.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Davide Libenzi <davidel@xmailserver.org>,
	stable@kernel.org
Subject: Re: [PATCH] signalfd: fill in ssi_int for posix timers and message queues
Date: Tue, 20 Jul 2010 15:42:05 -0700	[thread overview]
Message-ID: <20100720154205.667e95aa.akpm@linux-foundation.org> (raw)
In-Reply-To: <1278117528.21917.354.camel@localhost>

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.

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

> ---
>  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.


  parent reply	other threads:[~2010-07-20 22:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-03  0:38 [PATCH] signalfd: fill in ssi_int for posix timers and message queues Nathan Lynch
2010-07-03 19:09 ` Davide Libenzi
2010-07-05 12:22   ` Nathan Lynch
2010-07-05 18:23     ` Davide Libenzi
2010-07-20 22:42 ` Andrew Morton [this message]
2010-07-21  3:44   ` Nathan Lynch
2010-07-21  4:10     ` Andrew Morton
2010-07-21 17:39       ` Nathan Lynch
2010-07-25  4:09       ` Davide Libenzi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100720154205.667e95aa.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=davidel@xmailserver.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ntl@pobox.com \
    --cc=stable@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox