Messages in this thread | | | Date | Thu, 27 Nov 2014 13:08:03 +0100 | From | David Hildenbrand <> | Subject | Re: [RFC 0/2] Reenable might_sleep() checks for might_fault() when atomic |
| |
> On Thu, Nov 27, 2014 at 09:03:01AM +0100, David Hildenbrand wrote: > > > Code like > > > spin_lock(&lock); > > > if (copy_to_user(...)) > > > rc = ... > > > spin_unlock(&lock); > > > really *should* generate warnings like it did before. > > > > > > And *only* code like > > > spin_lock(&lock); > > > > Is only code like this valid or also with the spin_lock() dropped? > > (e.g. the access in patch1 if I remember correctly) > > > > So should page_fault_disable() increment the pagefault counter and the preempt > > counter or only the first one? > > Given that a sequence like > > page_fault_disable(); > if (copy_to_user(...)) > rc = ... > page_fault_enable(); > > is correct code right now I think page_fault_disable() should increase both. > No need for surprising semantic changes. > > > So we would have pagefault code rely on: > > > > in_disabled_pagefault() ( pagefault_disabled() ... whatever ) instead of > > in_atomic(). > > No, let's be more defensive: the page fault handler should do nothing if > in_atomic() just like now. But it could have a quick check and emit a one > time warning if page faults aren't disabled in addition. > That might help debugging but keeps the system more likely alive.
Sounds sane if we increase both counters!
> > might_fault() however should call might_sleep() if page faults aren't > disabled, but that's what you proposed anyway I think.
Jap, sounds good to me. Will see if I can come up with something.
Thanks!
| |