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. might_fault() however should call might_sleep() if page faults aren't disabled, but that's what you proposed anyway I think. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
