On Thu, Mar 24, 2011 at 10:13 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote:
>
> I am wondering, can't we set FAULT_FLAG_KILLABLE unconditionally
> but check PF_USER when we get VM_FAULT_RETRY? I mean,
>
> if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) {
> if (!(error_code & PF_USER))
> no_context(...);
> return;
> }
I agree, we should do this.
> Probably not... but I can't find any example of in-kernel fault which
> can be broken by -EFAULT if current was killed.
There's no way that can validly break anything, since any such
codepath has to be able to handle -EFAULT for other reasons anyway.
The only issue is whether we're ok with a regular write() system call
(for example) not being atomic in the presence of a fatal signal. So
it does change semantics, but I think it changes it in a good way
(technically POSIX requires atomicity, but on the other hand,
technically POSIX also doesn't talk about the process being killed,
and writes would still be atomic for the case where they actually
return. Not to mention NFS etc where writes have never been atomic
anyway, so a program that relies on strict "all or nothing" write
behavior is fundamentally broken to begin with).
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href