On Mon, Mar 16, 2026 at 08:41:48PM -0700, Suren Baghdasaryan wrote: > On Mon, Mar 16, 2026 at 7:29 AM Lorenzo Stoakes (Oracle) <[email protected]> > wrote: > > > > On Sun, Mar 15, 2026 at 07:32:54PM -0700, Suren Baghdasaryan wrote: > > > On Fri, Mar 13, 2026 at 5:00 AM Lorenzo Stoakes (Oracle) > > > <[email protected]> wrote: > > > > > > > > On Fri, Mar 13, 2026 at 04:07:43AM -0700, Usama Arif wrote: > > > > > On Thu, 12 Mar 2026 20:27:20 +0000 "Lorenzo Stoakes (Oracle)" > > > > > <[email protected]> wrote: > > > > > > > > > > > Commit 9d5403b1036c ("fs: convert most other generic_file_*mmap() > > > > > > users to > > > > > > .mmap_prepare()") updated AFS to use the mmap_prepare callback in > > > > > > favour of > > > > > > the deprecated mmap callback. > > > > > > > > > > > > However, it did not account for the fact that mmap_prepare can fail > > > > > > to map > > > > > > due to an out of memory error, and thus should not be incrementing a > > > > > > reference count on mmap_prepare. > > > > > > This is a bit confusing. I see the current implementation does > > > afs_add_open_mmap() and then if generic_file_mmap_prepare() fails it > > > does afs_drop_open_mmap(), therefore refcounting seems to be balanced. > > > Is there really a problem? > > > > Firstly, mmap_prepare is invoked before we try to merge, so the VMA could in > > theory get merged and then the refcounting will be wrong. > > I see now. Ok, makes sense. > > > > > Secondly, mmap_prepare occurs at such at time where it is _possible_ that > > allocation failures as described below could happen. > > Right, but in that case afs_file_mmap_prepare() would drop its > refcount and return an error, so refcounting is still good, no?
Nope, in __mmap_region(): call_mmap_prepare() -> __mmap_new_vma() vm_area_alloc() -> can fail vma_iter_prealloc() -> can fail __mmap_new_file_vma() / shmem_zero_setup() -> can fail If any of those fail the VMA is not even set up, so no close() will be called because there's no VMA to call close on. This is what makes mmap_prepare very different from mmap which passes in (a partially established) VMA. That and of course a potential merge would mean any refcount increment would be wrong. > > > > > I'll update the commit message to reflect the merge aspect actually. > > Thanks! You're welcome, and done in v2 :) > > > > > > > > > > > > > > > > > > With the newly added vm_ops->mapped callback available, we can > > > > > > simply defer > > > > > > this operation to that callback which is only invoked once the > > > > > > mapping is > > > > > > successfully in place (but not yet visible to userspace as the mmap > > > > > > and VMA > > > > > > write locks are held). > > > > > > > > > > > > Therefore add afs_mapped() to implement this callback for AFS. > > > > > > > > > > > > In practice the mapping allocations are 'too small to fail' so this > > > > > > is > > > > > > something that realistically should never happen in practice (or > > > > > > would do > > > > > > so in a case where the process is about to die anyway), but we > > > > > > should still > > > > > > handle this. > > > > > > nit: I would drop the above paragraph. If it's impossible why are you > > > handling it? If it's unlikely, then handling it is even more > > > important. > > > > Sure I can drop it, but it's an ongoing thing with these small allocations. > > > > I wish we could just move to a scenario where we can simpy assume > > allocations > > will always succeed :) > > That would be really nice but unfortunately the world is not that > perfect. I just don't want to be chasing some rarely reproducible bug > because of the assumption that an allocation is too small to fail. I mean I agree, we should handle all error paths. Cheers, Lorenzo
