io-uring.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Matthew Wilcox <willy@infradead.org>
Cc: Christoph Hellwig <hch@lst.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Arnd Bergmann <arnd@arndb.de>,
	David Howells <dhowells@redhat.com>,
	linux-arm-kernel@lists.infradead.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
	linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	linux-s390@vger.kernel.org, sparclinux@vger.kernel.org,
	linux-block@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-aio@kvack.org,
	io-uring@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-mm@kvack.org, netdev@vger.kernel.org,
	keyrings@vger.kernel.org, linux-security-module@vger.kernel.org
Subject: Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
Date: Sun, 20 Sep 2020 20:10:31 +0100	[thread overview]
Message-ID: <20200920191031.GQ3421308@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200920190159.GT32101@casper.infradead.org>

On Sun, Sep 20, 2020 at 08:01:59PM +0100, Matthew Wilcox wrote:
> On Sun, Sep 20, 2020 at 07:07:42PM +0100, Al Viro wrote:
> > 	2) a few drivers are really fucked in head.  They use different
> > *DATA* layouts for reads/writes, depending upon the calling process.
> > IOW, if you fork/exec a 32bit binary and your stdin is one of those,
> > reads from stdin in parent and child will yield different data layouts.
> > On the same struct file.
> > 	That's what Christoph worries about (/dev/sg he'd mentioned is
> > one of those).
> > 
> > 	IMO we should simply have that dozen or so of pathological files
> > marked with FMODE_SHITTY_ABI; it's not about how they'd been opened -
> > it describes the userland ABI provided by those.  And it's cast in stone.
> > 
> > 	Any in_compat_syscall() in ->read()/->write() instances is an ABI
> > bug, plain and simple.  Some are unfixable for compatibility reasons, but
> > any new caller like that should be a big red flag.
> 
> So an IOCB_COMPAT flag would let us know whether the caller is expecting
> a 32-bit or 64-bit layout?  And io_uring could set it based on the
> ctx->compat flag.

So you want to convert all that crap to a form that would see iocb
(IOW, ->read_iter()/->write_iter())?  And, since quite a few are sysfs
attributes, propagate that through sysfs, changing the method signatures
to match that and either modifying fuckloads of instances or introducing
new special methods for the ones that are sensitive to that crap?

IMO it's much saner to mark those and refuse to touch them from io_uring...

  reply	other threads:[~2020-09-20 19:10 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-18 12:45 let import_iovec deal with compat_iovecs as well Christoph Hellwig
2020-09-18 12:45 ` [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag Christoph Hellwig
2020-09-18 13:40   ` Al Viro
2020-09-18 13:44     ` Christoph Hellwig
2020-09-18 13:58       ` Al Viro
2020-09-18 15:16         ` Christoph Hellwig
2020-09-19 16:21           ` Andy Lutomirski
2020-09-19 21:16             ` Arnd Bergmann
2020-09-19 21:52               ` Finn Thain
2020-09-19 22:22               ` Andy Lutomirski
2020-09-21 16:10                 ` Pavel Begunkov
2020-09-21 16:13                   ` Pavel Begunkov
2020-09-21 23:51                     ` Andy Lutomirski
2020-09-22  0:22                       ` Pavel Begunkov
2020-09-22  0:58                         ` Andy Lutomirski
2020-09-22  6:30                           ` Pavel Begunkov
2020-09-22  7:23                             ` Arnd Bergmann
2020-09-22  7:57                               ` Pavel Begunkov
2020-09-22  9:01                                 ` Arnd Bergmann
2020-09-22 16:20                                   ` Andy Lutomirski
2020-09-23  8:01                                   ` Pavel Begunkov
2020-09-23 13:22                                     ` Al Viro
2020-09-19 22:09           ` Al Viro
2020-09-19 22:23             ` Andy Lutomirski
2020-09-19 22:41               ` Al Viro
2020-09-19 22:53                 ` Andy Lutomirski
2020-09-19 23:24                   ` Al Viro
2020-09-20  0:14                     ` Andy Lutomirski
2020-09-20  2:57                       ` Al Viro
2020-09-20 16:59                         ` Andy Lutomirski
2020-09-20 18:12                           ` Al Viro
2020-09-20 13:55             ` Arnd Bergmann
2020-09-20 15:02               ` Al Viro
2020-09-19 14:53         ` David Laight
2020-09-18 13:59       ` Arnd Bergmann
2020-09-20 15:15   ` Matthew Wilcox
2020-09-20 15:55     ` William Kucharski
2020-09-21 16:20       ` Pavel Begunkov
2020-09-20 16:00     ` Arnd Bergmann
2020-09-20 18:07     ` Al Viro
2020-09-20 18:41       ` Al Viro
2020-09-20 19:01       ` Matthew Wilcox
2020-09-20 19:10         ` Al Viro [this message]
2020-09-20 19:22           ` Matthew Wilcox
2020-09-20 19:28             ` Andy Lutomirski
2020-09-20 20:49               ` Arnd Bergmann
2020-09-20 21:13                 ` David Laight
2020-09-21 16:31                   ` Pavel Begunkov
2020-09-20 21:42             ` Al Viro
2020-09-21 16:26             ` Pavel Begunkov
2020-09-20 19:14       ` Andy Lutomirski
2020-09-21  4:28         ` Christoph Hellwig
2020-09-18 12:45 ` [PATCH 2/9] compat.h: fix a spelling error in <linux/compat.h> Christoph Hellwig
2020-09-18 13:37   ` Johannes Thumshirn
2020-09-18 12:45 ` [PATCH 3/9] fs: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector Christoph Hellwig
2020-09-18 12:56   ` Matthew Wilcox
2020-09-18 13:39   ` Johannes Thumshirn
2020-09-18 12:45 ` [PATCH 4/9] fs: handle the compat case in import_iovec Christoph Hellwig
2020-09-18 12:45 ` [PATCH 5/9] fs: remove various compat readv/writev helpers Christoph Hellwig
2020-09-18 12:45 ` [PATCH 6/9] fs: remove the compat readv/writev syscalls Christoph Hellwig
2020-09-18 12:45 ` [PATCH 7/9] fs: remove compat_sys_vmsplice Christoph Hellwig
2020-09-18 12:45 ` [PATCH 8/9] mm: remove compat_process_vm_{readv,writev} Christoph Hellwig
2020-09-18 13:48   ` Arnd Bergmann
2020-09-18 12:45 ` [PATCH 9/9] security/keys: remove compat_keyctl_instantiate_key_iov Christoph Hellwig
2020-09-19 14:24 ` let import_iovec deal with compat_iovecs as well David Laight
2020-09-21  4:41   ` 'Christoph Hellwig'
2020-09-21 11:11     ` David Laight

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=20200920191031.GQ3421308@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=axboe@kernel.dk \
    --cc=dhowells@redhat.com \
    --cc=hch@lst.de \
    --cc=io-uring@vger.kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-aio@kvack.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=netdev@vger.kernel.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=willy@infradead.org \
    --cc=x86@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;
as well as URLs for NNTP newsgroup(s).