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
