lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAK8P3a3TbXZdo2Gom=GbvOeFkiJmGHXDfCq4unJn3-P_K5peJA@mail.gmail.com> Date: Tue, 26 Mar 2019 09:35:33 +0100 From: Arnd Bergmann <arnd@...db.de> To: James Bottomley <James.Bottomley@...senpartnership.com> Cc: Andrew Morton <akpm@...ux-foundation.org>, Jens Axboe <axboe@...nel.dk>, Alexander Viro <viro@...iv.linux.org.uk>, Hannes Reinecke <hare@...e.com>, Matthew Wilcox <willy@...radead.org>, David Hildenbrand <david@...hat.com>, Nikolay Borisov <nborisov@...e.com>, linux-block <linux-block@...r.kernel.org>, Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 1/2] io_uring: fix big-endian compat signal mask handling On Tue, Mar 26, 2019 at 1:13 AM James Bottomley <James.Bottomley@...senpartnership.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@...senpartnership.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
Powered by blists - more mailing lists