On Sat, 23 Feb 2019 20:38:03 -0800 Andy Lutomirski <luto@xxxxxxxxxx> wrote: > On Sat, Feb 23, 2019 at 4:44 PM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > On Sat, 23 Feb 2019 12:47:46 +0900 > > Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > > > > Since kprobes handler runs in IRQ context, we can not use access_ok() in it. > > > (only on x86 + CONFIG_DEBUG_ATOMIC_SLEEP=y) > > > > Is it really IRQ context or exception context? That is, one > > (interrupts) happen for any task, but exceptions happen because of the > > software that is executed (like a breakpoint). Although you can have a > > kprobe trigger in an interrupt handler (where user access wouldn't make > > sense anyway). But there should be no problem with user access from an > > exception handler. > > > > Can we just get rid of this might_sleep()? access_ok() doesn't sleep > as far as I know. Hmm, which might_sleep() would you pointed? What I talked was a WARN_ON_ONCE(!in_task()) in access_ok() on x86 (only!), and in_task() just checks preempt_count. I guess PeterZ assumed that access_ok() is used only with user space access APIs (e.g. copy_from_user) which can cause page-fault and locks mm (and might sleep :)), but now we are trying to use access_ok() with new functions which disables page-fault and just return -EFAULT. Thank you, -- Masami Hiramatsu <mhiramat@xxxxxxxxxx>
