Re: [PATCH 1/2] mmu_notifiers: Restore documentation for .invalidate_range()

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, May 23, 2023 at 07:20:31PM -0700, John Hubbard wrote:
> On 5/23/23 18:47, Alistair Popple wrote:
> > The .invalidate_range() callback is called by
> > mmu_notifier_invalidate_range() which is often called while holding
> > the ptl spin-lock. Therefore any implementations of this callback must
> > not sleep. This was originally documented when the call back was added
> > in commit 0f0a327fa12c ("mmu_notifier: add the callback for
> > mmu_notifier_invalidate_range()") but appears to have been
> 
> Thanks for digging into this. I expect that you're on the right
> track, I'm just wondering about something still:
> 
> > inadvertently removed by commit 5ff7091f5a2c ("mm, mmu_notifier:
> > annotate mmu notifiers with blockable invalidate callbacks").
> 
> Was it really inadvertent, though? The initial patch proposed said this:
> 
> "Also remove a bogus comment about invalidate_range() always being called
> under the ptl spinlock." [1]

Right, it is not always called under PTL spinlocks and the
implementation cannot assume it, but that doesn't mean the
implementation is allowed to block.

That was one of the main motivating reasons to have both the
invalidate_start/end and invalidate_range variations, start/end are
allowed to block and range is not.

invalidate_range really only exists for the iommu drivers to use it
for SVA designs, there are a few other weird users, but iommu was the
motivation to create it in the first place.

So the comment should just clarify that it is not allowed to sleep and
can't assume anything about its locking environment.

Jason