On Wed, Mar 9, 2022 at 12:48 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Basically FAULT_FLAG_KILLABLE implies a kind of "half-way ALLOW_RETRY"
> - allow aborting, but only for the fatal signal case.
Side note: I'm not saying this is a *good* thing - it is very
confusing - but it's due to historical reasons where architectures
ended up getting these features incrementally.
So FAULT_FLAG_KILLABLE was one such half-way step, where you could
abort things without actually retrying them, because a fatal signal
could be handled without then repeating things.
These days, I think all architectures have converted their actual
fault handling to the full "retry/abort/error/success" spectrum, but
then you still have other uses of handle_mm_fault() that may not be
willing to have mmap_sem be dropped in the middle of operations
because they keep a 'vma' list around or something like that.
And then FAULT_FLAG_KILLABLE can still be a good way to say "ok, I'm
willing to _abort_ things entirely, but you can't drop the mmap sem
and ask me to recover if it's not fatal".
And this is all entirely due to historical behavior, since
_originally_ handle_mm_fault() wouldn't ever drop mmap_sem at all.
These days it would probably be simpler to *not* have all these
complicated special cases, and just say that FAULT_FLAG_ALLOW_RETRY is
always true.
But then somebody would have to walk through every user to make sure it's ok...
Linus
