On Thu, Oct 18, 2018 at 11:25 AM Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > On 2018-10-18 09:48:24 [-0700], Andy Lutomirski wrote: > > > On Oct 18, 2018, at 9:26 AM, Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> wrote: > > >> On 2018-10-12 11:02:18 [-0700], Andy Lutomirski wrote: > > >> On Fri, Oct 12, 2018 at 10:54 AM Dave Hansen > > >>> So I'm kinda missing the point of the patch. > > >> > > >> use_mm(). > > > > > > So. I would drop that patch from queue. Anyone feels different about it? > > > > > > > I think we *do* want the patch. It’s a bugfix for use_mm users, right? > > This is the loophole that has been pointed out. I am not convinced what > the correct behaviour should be here (and we have five users of that > interface). For instance f_fs[0]. It reads data from the USB EP and > then writes it to userland task. Due to $circumstances it happens in a > workqueue instead of the task's context. So it borrows the mm with > use_mm(). The current behaviour random because the PKRU value can not > be predicted. It may or may not work. > > Setting it to allow-all/none would let the operation always fail or > succeed which might be an improvement in terms of debugging. However it > is hard to judge what the correct behaviour should be. Should fail or > succeed. > But this is not the only loophole: There is ptrace interface which is > used by gdb (just checked) and also bypasses PKRU. So… > > [0] drivers/usb/gadget/function/f_fs.c::ffs_user_copy_worker() > > Sebastian I think we need an entirely new API: user_mm_ctx_t ctx = user_mm_ctx_get(); ... use_user_mm_ctx(ctx); unuse_user_mm_ctx(ctx); ... user_mm_ctx_put(ctx); and ctx will store a copy of mm and PKRU.
