All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Hannes Reinecke <hare@suse.com>,
	Matthew Wilcox <willy@infradead.org>,
	David Hildenbrand <david@redhat.com>,
	Nikolay Borisov <nborisov@suse.com>,
	linux-block <linux-block@vger.kernel.org>,
	Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] io_uring: fix big-endian compat signal mask handling
Date: Tue, 26 Mar 2019 09:35:33 +0100	[thread overview]
Message-ID: <CAK8P3a3TbXZdo2Gom=GbvOeFkiJmGHXDfCq4unJn3-P_K5peJA@mail.gmail.com> (raw)
In-Reply-To: <1553559185.2929.20.camel@HansenPartnership.com>

On Tue, Mar 26, 2019 at 1:13 AM James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Mon, 2019-03-25 at 17:24 +0100, Arnd Bergmann wrote:
> > On Mon, Mar 25, 2019 at 5:19 PM James Bottomley
> > <James.Bottomley@hansenpartnership.com> wrote:
> > > This looks a bit suboptimal: shouldn't in_compat_syscall() be hard
> > > coded to return 0 if CONFIG_COMPAT isn't defined?  That way the
> > > compiler can do the correct optimization and we don't have to
> > > litter #ifdefs and worry about undefined variables and other
> > > things.
> >
> > The check can be outside of the #ifdef, but set_compat_user_sigmask
> > is not declared then.
>
> Right, but shouldn't it be declared?  I thought BUILD_BUG_ON had nice
> magic that allowed it to work here (meaning if the compiler doesn't
> eliminate the branch we get a build bug).

My y2038 series originally went in that direction by allowing much more
of the compat code to be compiled and then discarded without the
#ifdefs (and combine it with the 32-bit time_t handling on 32-bit
architectures). I went away from that after Christoph and others found
the reuse of the compat interfaces too confusing.

The current state now is that most compat_* interfaces cannot be
compiled unless CONFIG_COMPAT is set, and making that work
in general is a lot of work, so I followed the usual precedent here
and used that #ifdef. This also matches what is done elsewhere
in the same file (see io_import_iovec).

> > I think for the future we can consider just moving the compat logic
> > into set_user_sigmask(), which would simplify most of the callers,
> > but that seemed to invasive as a bugfix for 5.1.
>
> Well, that too.  I've just been on a recent bender to stop #ifdefs
> after I saw what some people were doing with them.

I absolutely agree in general, and have sent many patches to
remove #ifdefs in other code when there was a good alternative
and the #ifdefs are wrong (which they are at least 30% of the time
in my experience).

The problems for doing this in general for compat code are

- some structures have a conditional compat_ioctl() callback
  pointer, and need an #ifdef around the assignment until
  we change the struct as well.
- Most compat handlers require the use of the compat_ptr()
  wrapper, I have a patch to move this to common code, but
  that was rejected previously
- many compat handlers rely on types from asm/compat.h
  that does not exist on architectures without compat support.

In this specific case, compat_sigset_t is required for declaring
set_compat_user_sigmask(), and the former is not easy to
define on non-compat architectures. I still think that the best
way forward here is to move it into set_user_sigmask()
next merge window, rather than doing a larger scale rewrite
of linux/compat.h to get this bug fixed now.

      Arnd

      reply	other threads:[~2019-03-26  8:35 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25 14:34 [PATCH 1/2] io_uring: fix big-endian compat signal mask handling Arnd Bergmann
2019-03-25 14:47 ` [PATCH 2/2] arch: add pidfd and io_uring syscalls everywhere Arnd Bergmann
2019-03-25 14:47   ` Arnd Bergmann
2019-03-25 14:47   ` Arnd Bergmann
2019-03-25 14:47   ` Arnd Bergmann
2019-03-25 14:47   ` Arnd Bergmann
2019-03-25 17:37   ` Paul Burton
2019-03-25 17:37     ` Paul Burton
2019-03-25 17:37     ` Paul Burton
2019-03-25 17:37     ` Paul Burton
2019-03-25 17:37     ` Paul Burton
2019-03-26  8:40     ` Arnd Bergmann
2019-03-26  8:40       ` Arnd Bergmann
2019-03-26  8:40       ` Arnd Bergmann
2019-03-26  8:40       ` Arnd Bergmann
2019-03-26  8:40       ` Arnd Bergmann
2019-03-30  9:42   ` Heiko Carstens
2019-03-30  9:42     ` Heiko Carstens
2019-03-30  9:42     ` Heiko Carstens
2019-03-30  9:42     ` Heiko Carstens
2019-03-30  9:42     ` Heiko Carstens
2019-03-31  9:47   ` Michael Ellerman
2019-03-31  9:47     ` Michael Ellerman
2019-03-31  9:47     ` Michael Ellerman
2019-03-31  9:47     ` Michael Ellerman
2019-03-31  9:47     ` Michael Ellerman
2019-03-31  9:47     ` Michael Ellerman
2019-03-31 16:28     ` Arnd Bergmann
2019-03-31 16:28       ` Arnd Bergmann
2019-03-31 16:28       ` Arnd Bergmann
2019-03-31 16:28       ` Arnd Bergmann
2019-03-31 16:28       ` Arnd Bergmann
2019-04-03  1:19       ` Michael Ellerman
2019-04-03  1:19         ` Michael Ellerman
2019-04-03  1:19         ` Michael Ellerman
2019-04-03  1:19         ` Michael Ellerman
2019-04-03  1:19         ` Michael Ellerman
2019-04-01  8:19   ` Geert Uytterhoeven
2019-04-01  8:19     ` Geert Uytterhoeven
2019-04-01  8:19     ` Geert Uytterhoeven
2019-04-01  8:19     ` Geert Uytterhoeven
2019-04-01  8:19     ` Geert Uytterhoeven
2019-04-03  2:47   ` Michael Ellerman
2019-04-03  2:47     ` Michael Ellerman
2019-04-03  2:47     ` Michael Ellerman
2019-04-03  2:47     ` Michael Ellerman
2019-04-03  2:47     ` Michael Ellerman
2019-04-03  2:47     ` Michael Ellerman
2019-04-03 11:11     ` Will Deacon
2019-04-03 11:11       ` Will Deacon
2019-04-03 11:11       ` Will Deacon
2019-04-03 11:11       ` Will Deacon
2019-04-03 11:11       ` Will Deacon
2019-04-03 13:49       ` Jens Axboe
2019-04-03 13:49         ` Jens Axboe
2019-04-03 13:49         ` Jens Axboe
2019-04-03 13:49         ` Jens Axboe
2019-04-03 13:49         ` Jens Axboe
2019-04-03 15:19         ` Will Deacon
2019-04-03 15:19           ` Will Deacon
2019-04-03 15:19           ` Will Deacon
2019-04-03 15:19           ` Will Deacon
2019-04-03 15:19           ` Will Deacon
2019-04-03 15:39           ` Jens Axboe
2019-04-03 15:39             ` Jens Axboe
2019-04-03 15:39             ` Jens Axboe
2019-04-03 15:39             ` Jens Axboe
2019-04-03 15:39             ` Jens Axboe
2019-04-03 15:49             ` Will Deacon
2019-04-03 15:49               ` Will Deacon
2019-04-03 15:49               ` Will Deacon
2019-04-03 15:49               ` Will Deacon
2019-04-03 15:49               ` Will Deacon
2019-04-03 15:51               ` Jens Axboe
2019-04-03 15:51                 ` Jens Axboe
2019-04-03 15:51                 ` Jens Axboe
2019-04-03 15:51                 ` Jens Axboe
2019-04-03 15:51                 ` Jens Axboe
2019-04-04  6:08         ` Michael Ellerman
2019-04-04  6:08           ` Michael Ellerman
2019-04-04  6:08           ` Michael Ellerman
2019-04-04  6:08           ` Michael Ellerman
2019-04-04  6:08           ` Michael Ellerman
2019-03-25 16:05 ` [PATCH 1/2] io_uring: fix big-endian compat signal mask handling Jens Axboe
2019-03-25 16:11   ` Arnd Bergmann
2019-03-25 16:15     ` Jens Axboe
2019-03-25 16:19 ` James Bottomley
2019-03-25 16:23   ` Jens Axboe
2019-03-25 16:24   ` Arnd Bergmann
2019-03-26  0:13     ` James Bottomley
2019-03-26  8:35       ` Arnd Bergmann [this message]

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='CAK8P3a3TbXZdo2Gom=GbvOeFkiJmGHXDfCq4unJn3-P_K5peJA@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=david@redhat.com \
    --cc=hare@suse.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nborisov@suse.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=willy@infradead.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.