Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753699Ab0GESXQ (ORCPT ); Mon, 5 Jul 2010 14:23:16 -0400 Received: from x35.xmailserver.org ([64.71.152.41]:44217 "EHLO x35.xmailserver.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752183Ab0GESXP (ORCPT ); Mon, 5 Jul 2010 14:23:15 -0400 X-AuthUser: davidel@xmailserver.org Date: Mon, 5 Jul 2010 11:23:13 -0700 (PDT) From: Davide Libenzi X-X-Sender: davide@makko.or.mcafeemobile.com To: Nathan Lynch cc: Linux Kernel Mailing List Subject: Re: [PATCH] signalfd: fill in ssi_int for posix timers and message queues In-Reply-To: <1278332575.13403.24.camel@tp-r400> Message-ID: References: <1278117528.21917.354.camel@localhost> <1278332575.13403.24.camel@tp-r400> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3253 Lines: 75 On Mon, 5 Jul 2010, Nathan Lynch wrote: > Hello Davide, > > On Sat, 2010-07-03 at 12:09 -0700, Davide Libenzi wrote: > > On Fri, 2 Jul 2010, Nathan Lynch 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. > > > > > > Signed-off-by: Nathan Lynch > > > --- > > > 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; > > > case __SI_POLL: > > > err |= __put_user(kinfo->si_band, &uinfo->ssi_band); > > > @@ -111,6 +112,7 @@ static int signalfd_copyinfo(struct signalfd_siginfo __user *uinfo, > > > err |= __put_user(kinfo->si_pid, &uinfo->ssi_pid); > > > err |= __put_user(kinfo->si_uid, &uinfo->ssi_uid); > > > err |= __put_user((long) kinfo->si_ptr, &uinfo->ssi_ptr); > > > + err |= __put_user(kinfo->si_int, &uinfo->ssi_int); > > > break; > > > default: > > > > I am fine with it, but I now noticed that signalfd_copyinfo() got out of > > sync from copy_siginfo_to_user(), which should match. > > Do you mind aligning that too, as part of your patch? > > An adding a comment on the lines of the one in copy_siginfo_to_user() to > > signalfd_copyinfo() too? > > Sorry, I'm not sure I understand. Are you saying that > copy_siginfo_to_user should have analogous lines added to assign to > si_int? That's actually not necessary if I read the code correctly: in > struct siginfo, si_ptr and si_int are members of a sigval union, so > assigning to the former covers the latter. signalfd must assign both > ssi_ptr and ssi_int since they occupy different locations in > signalfd_siginfo. > > Perhaps the attached testcases make the problem (as I see it) more > clear? The final assertion fails without this patch. Sorry, my bad. I had forgotten that siginfo had them in a union, so the different code in signalfd_copyinfo() is needed. Patch looks fine to me as is. - Davide -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/