On Jul 20, 2020, at 10:02 AM, Jens Axboe [off-list ref] wrote:

On 7/20/20 10:58 AM, Andy Lutomirski wrote:

quoted

quoted

quoted

On Jul 20, 2020, at 9:37 AM, Jens Axboe [off-list ref] wrote:

On 7/20/20 12:10 AM, Christoph Hellwig wrote:

quoted

Hi Jens,

I just found a (so far theoretical) issue with the io_uring submission
offloading to workqueues or threads.  We have lots of places using
in_compat_syscall() to check if a syscall needs compat treatmenet.
While the biggest users is iocttl(), we also have a fair amount of
places using in_compat_task() in read and write methods, and these
will not do the wrong thing when used with io_uring under certain
conditions.  I'm not sure how to best fix this, except for making sure
in_compat_syscall() returns true one way or another for these cases.

We can probably propagate this information in the io_kiocb via a flag,
and have the io-wq worker set TS_COMPAT if that's the case.

Is TS_COMPAT actually a cross-arch concept for which this is safe?
Having a real arch helper for “set the current syscall arch for the
current kernel thread” seems more sensible to me. 

Sure, I'd consider that implementation detail for the actual patch(es)
for this issue.

There’s a corner case, though: doesn’t io_uring submission frequently do the work synchronously in the context of the calling thread?  If so, can a thread do a 64-bit submit with 32-bit work or vice versa?

Sometimes I think that in_compat_syscall() should have a mode in which calling it warns (e.g. not actually in a syscall when doing things in io_uring).  And the relevant operations should be properly wired up to avoid global state like this.

-- 
Jens Axboe