Re: [PATCH] filemap: Handle error return from __filemap_get_folio()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 10, 2023 at 4:33 PM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> We'd still keep the RETRY bit as a "this did not complete, you need to
> retry", but at least the whole secondary meaning of "oh, and if it
> isn't set, you need to release the lock you took" would go away.

"unless VM_FAULT_COMPLETED is set, in which case everything was fine,
and you shouldn't release the lock because we already released it".

I completely forgot about that wart that came in last year.

I think that if we made handle_mm_fault() always unlock, that thing
would go away entirely, since "0" would now just mean the same thing.

Is there really any case that *wants* to keep the mmap lock held, and
couldn't just always re-take it if it needs to do another page
(possibly retry, but the retry case obviously already has that issue)?

Certainly nothing wants the vma lock, so it's only the "mmap_sem" case
that would be an issue.

              Linus





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux