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 Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux