From: David Laight <[email protected]>
To: 'Al Viro' <[email protected]>, Christoph Hellwig <[email protected]>
Cc: Andrew Morton <[email protected]>,
Jens Axboe <[email protected]>, Arnd Bergmann <[email protected]>,
David Howells <[email protected]>,
"[email protected]"
<[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]" <[email protected]>,
"[email protected]"
<[email protected]>
Subject: RE: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
Date: Sat, 19 Sep 2020 14:53:08 +0000 [thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
From: Al Viro
> Sent: 18 September 2020 14:58
>
> On Fri, Sep 18, 2020 at 03:44:06PM +0200, Christoph Hellwig wrote:
> > On Fri, Sep 18, 2020 at 02:40:12PM +0100, Al Viro wrote:
> > > > /* Vector 0x110 is LINUX_32BIT_SYSCALL_TRAP */
> > > > - return pt_regs_trap_type(current_pt_regs()) == 0x110;
> > > > + return pt_regs_trap_type(current_pt_regs()) == 0x110 ||
> > > > + (current->flags & PF_FORCE_COMPAT);
> > >
> > > Can't say I like that approach ;-/ Reasoning about the behaviour is much
> > > harder when it's controlled like that - witness set_fs() shite...
> >
> > I don't particularly like it either. But do you have a better idea
> > how to deal with io_uring vs compat tasks?
>
> <wry> git rm fs/io_uring.c would make a good starting point </wry>
> Yes, I know it's not going to happen, but one can dream...
Maybe the io_uring code needs some changes to make it vaguely safe.
- No support for 32-bit compat mixed working (or at all?).
Plausibly a special worker could do 32bit work.
- ring structure (I'm assuming mapped by mmap()) never mapped
in more than one process (not cloned by fork()).
- No implicit handover of files to another process.
Would need an munmap, handover, mmap sequence.
In any case the io_ring rather abuses the import_iovec() interface.
The canonical sequence is (types from memory):
struct iovec cache[8], *iov = cache;
struct iter iter;
...
rval = import_iovec(..., &iov, 8, &iter);
// Do read/write user using 'iter'
free(iov);
I don't think there is any strict requirement that iter.iov
is set to either 'cache' or 'iov' (it probably must point
into one of them.)
But the io_uring code will make that assumption because the
actual copies can be done much later and it doesn't save 'iter'.
It gets itself in a right mess because it doesn't separate
the 'address I need to free' from 'the iov[] for any transfers'.
io_uring is also the only code that relies on import_iovec()
returning the iter.count on success.
It would be much better to have:
iov = import_iovec(..., &cache, ...);
free(iov);
and use ERR_PTR() et al for error detectoion.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2020-09-19 14:54 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 [this message]
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
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 \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
/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