All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>, Oleg Nesterov <oleg@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [PATCH 4/8] waitid(2): leave copyout of siginfo to syscall itself
Date: Tue, 16 May 2017 00:46:33 +0100	[thread overview]
Message-ID: <20170515234633.GN390@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFx3mXkV7q=fZAQGJK=Xn4S1hLpLEfRhB0hN6aq5U16L1Q@mail.gmail.com>

On Mon, May 15, 2017 at 04:06:49PM -0700, Linus Torvalds wrote:
> On Mon, May 15, 2017 at 3:37 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > +struct waitid_info {
> > +       pid_t pid;
> > +       uid_t uid;
> > +       int status;
> > +       int why;
> > +};
> 
> Ugh. Could we please just name those with what they are actually used for?
> 
> Even if you hate the "si_" previx for some reason, I really don't see
> why we'd continue call it "why", when it's written to "si_code"
> 
> Yes, yes, I see the historical reason, and how "si_code" is just the
> low 16 bits of "why", and the high 16 bits is something else.

__SI_CHLD, and AFAICS it only matters for copy_siginfo_to_user() and its
relatives - basically, "how much of kernel-side struct siginfo do we have
initialized"...

> But now that there is a structure for that, could we not just make
> that explicit in the structure instead? Those games with "why" look
> really odd.

OK...

> So I can see why you'd like to keep this patch as "minimal
> conversion", but it would be really nice to have a followup patch that
> gets rid of the odd "why" games.

The thing is, we lack convenient defines for those constants.  We could
turn this "why" thing into u16 si_code, but then gcc will scream about
integer constant truncation ;-/  Suggestions?

BTW, I wonder if making those stores conditional is actually a win -
sure, for put_user() it used to be, but for plain stores...  Not sure.

  reply	other threads:[~2017-05-15 23:46 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-15 22:31 [RFC][PATCHSET] wait4()/waitid() cleanups Al Viro
2017-05-15 22:37 ` [PATCH 1/8] move compat wait4 and waitid next to native variants Al Viro
2017-05-15 22:37   ` [PATCH 2/8] wait4(2)/waitid(2): separate copying rusage to userland Al Viro
2017-05-15 22:37   ` [PATCH 3/8] kernel_wait4()/kernel_waitid(): delay copying status " Al Viro
2017-05-15 22:37   ` [PATCH 4/8] waitid(2): leave copyout of siginfo to syscall itself Al Viro
2017-05-15 23:06     ` Linus Torvalds
2017-05-15 23:46       ` Al Viro [this message]
2017-05-17 19:48         ` Eric W. Biederman
2017-05-15 22:37   ` [PATCH 5/8] lift getrusage() from wait_noreap_copyout() Al Viro
2017-05-15 22:37   ` [PATCH 6/8] kill wait_noreap_copyout() Al Viro
2017-05-15 22:37   ` [PATCH 7/8] wait_task_zombie: consolidate info logics Al Viro
2017-05-15 22:37   ` [PATCH 8/8] waitid(): switch copyout of siginfo to unsafe_put_user() Al Viro
2017-05-16  3:55     ` kbuild test robot
2017-05-16  4:17     ` kbuild test robot
2017-05-19  6:08     ` [lkp-robot] [waitid()] 75f64d68f9: Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= kernel test robot
2017-05-19  6:08       ` kernel test robot
2017-05-21  7:34       ` Al Viro
2017-05-21  7:34         ` Al Viro
2017-05-21 19:04         ` Linus Torvalds
2017-05-21 19:04           ` Linus Torvalds
2017-05-21 19:35         ` Linus Torvalds
2017-05-21 19:35           ` Linus Torvalds
2017-05-21 21:14           ` Al Viro
2017-05-21 21:14             ` Al Viro
2017-05-21 21:37             ` Linus Torvalds
2017-05-21 21:37               ` Linus Torvalds
2017-05-21 22:19               ` Linus Torvalds
2017-05-21 22:19                 ` Linus Torvalds
2017-05-22  1:39                 ` Linus Torvalds
2017-05-22  1:39                   ` Linus Torvalds
2017-05-17 19:57 ` [RFC][PATCHSET] wait4()/waitid() cleanups Eric W. Biederman

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=20170515234633.GN390@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.