> On Jul 20, 2020, at 10:02 AM, Jens Axboe <axboe@xxxxxxxxx> wrote: > > On 7/20/20 10:58 AM, Andy Lutomirski wrote: >> >>>> On Jul 20, 2020, at 9:37 AM, Jens Axboe <axboe@xxxxxxxxx> wrote: >>> >>> On 7/20/20 12:10 AM, Christoph Hellwig wrote: >>>> 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 >
