> 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? > page_fault_disable(); > if (copy_to_user(...)) > rc = ... > page_fault_enable(); > spin_unlock(&lock); > should not generate warnings, since the author hopefully knew what he did. > > We could achieve that by e.g. adding a couple of pagefault disabled bits > within current_thread_info()->preempt_count, which would allow > pagefault_disable() and pagefault_enable() to modify a different part of > preempt_count than it does now, so there is a way to tell if pagefaults have > been explicitly disabled or are just a side effect of preemption being > disabled. > This would allow might_fault() to restore its old sane behaviour for the > !page_fault_disabled() case. So we would have pagefault code rely on: in_disabled_pagefault() ( pagefault_disabled() ... whatever ) instead of in_atomic(). I agree with this approach, as this is basically what I suggested in one of my previous mails. -- 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
