Thread (67 messages) 67 messages, 11 authors, 2020-09-23

Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag

From: Pavel Begunkov <asml.silence@gmail.com>
Date: 2020-09-23 08:04:24
Also in: io-uring, keyrings, linux-arch, linux-arm-kernel, linux-block, linux-fsdevel, linux-mips, linux-mm, linux-s390, linux-scsi, linuxppc-dev, lkml, netdev, sparclinux

On 22/09/2020 12:01, Arnd Bergmann wrote:
On Tue, Sep 22, 2020 at 9:59 AM Pavel Begunkov [off-list ref] wrote:
quoted
On 22/09/2020 10:23, Arnd Bergmann wrote:
quoted
On Tue, Sep 22, 2020 at 8:32 AM Pavel Begunkov [off-list ref] wrote:
quoted
On 22/09/2020 03:58, Andy Lutomirski wrote:
quoted
On Mon, Sep 21, 2020 at 5:24 PM Pavel Begunkov [off-list ref] wrote:
I may be looking at a different kernel than you, but aren't you
preventing creating an io_uring regardless of whether SQPOLL is
requested?
I diffed a not-saved file on a sleepy head, thanks for noticing.
As you said, there should be an SQPOLL check.

...
if (ctx->compat && (p->flags & IORING_SETUP_SQPOLL))
        goto err;
Wouldn't that mean that now 32-bit containers behave differently
between compat and native execution?

I think if you want to prevent 32-bit applications from using SQPOLL,
it needs to be done the same way on both to be consistent:
The intention was to disable only compat not native 32-bit.
I'm not following why that would be considered a valid option,
as that clearly breaks existing users that update from a 32-bit
kernel to a 64-bit one.
Do you mean users who move 32-bit binaries (without recompiling) to a
new x64 kernel? Does the kernel guarantees that to work? I'd personally
care more native-bitness apps.
Taking away the features from users that are still on 32-bit kernels
already seems questionable to me, but being inconsistent
about it seems much worse, in particular when the regression
is on the upgrade path.
TBH, this won't fix that entirely (e.g. passing non-compat io_uring
to a compat process should yield the same problem). So, let's put
it aside for now until this bikeshedding would be relevant.
quoted
quoted
Can we expect all existing and future user space to have a sane
fallback when IORING_SETUP_SQPOLL fails?
SQPOLL has a few differences with non-SQPOLL modes, but it's easy
to convert between them. Anyway, SQPOLL is a privileged special
case that's here for performance/latency reasons, I don't think
there will be any non-accidental users of it.
Ok, so the behavior of 32-bit tasks would be the same as running
the same application as unprivileged 64-bit tasks, with applications
Yes, something like that, but that's not automatic and in some
(hopefully rare) cases there may be pitfalls. That's in short,
I can expand the idea a bit if anyone would be interested.
already having to implement that fallback, right?
Well, not everyone _have_ to implement such a fallback, e.g.
applications working only whilst privileged may use SQPOLL only.

-- 
Pavel Begunkov
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help