linux-kernel - Re: [PATCH 1/2] mmu_notifiers: Restore documentation for .invalidate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZHKYmOc/x+0w2Nd3@nvidia.com>
Date:   Sat, 27 May 2023 20:56:08 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     John Hubbard <jhubbard@...dia.com>
Cc:     Alistair Popple <apopple@...dia.com>,
        Andrew Morton <akpm@...ux-foundation.org>, will@...nel.org,
        catalin.marinas@....com, David Rientjes <rientjes@...gle.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        robin.murphy@....com, nicolinc@...dia.com,
        linux-arm-kernel@...ts.infradead.org, kvm@...r.kernel.org,
        zhi.wang.linux@...il.com, Sean Christopherson <seanjc@...gle.com>
Subject: Re: [PATCH 1/2] mmu_notifiers: Restore documentation for
 .invalidate_range()

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