linux-kernel - Re: [PATCH v5 1/2] mm/mmu_notifier: make interval notifier updates safe

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 15 Jan 2020 14:04:47 -0800
From:   Ralph Campbell <rcampbell@...dia.com>
To:     Jason Gunthorpe <jgg@...lanox.com>
CC:     "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
        Jerome Glisse <jglisse@...hat.com>,
        "John Hubbard" <jhubbard@...dia.com>,
        Christoph Hellwig <hch@....de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Shuah Khan <shuah@...nel.org>
Subject: Re: [PATCH v5 1/2] mm/mmu_notifier: make interval notifier updates
 safe

On 1/14/20 4:45 AM, Jason Gunthorpe wrote:
> On Mon, Jan 13, 2020 at 02:44:52PM -0800, Ralph Campbell wrote:
> 
>> I'm using the device driver lock to serialize find/insert/update/remove
>> changes to the interval tree.
> 
> The device driver lock can't really fully serialize this as it doesn't
> effect how the intersection lookup runs.
> 
> Jason
> 

Single updates to the interval notifier are atomic due to the
struct mmu_notifier_mm spinlock so the issue is with "punching a hole"
in the interval. In that case, the existing interval is updated to cover
one side of the hole and a new interval is inserted for the other side
while holding the driver lock.

Since this sequence is done from the invalidate() callback, those two
operations will be deferred until the callback returns and any other
parallel invalidates complete (which would be serialized on
the driver lock). So none of these changes will be visible to the
interval tree walks until the last invalidate task calls
mn_itree_inv_end() and all the deferred changes are applied atomically
while holding the spinlock. I'll make sure to add comments explaining
this.

But I see your point if this sequence is done outside of the invalidate
callback. In that case, if the driver shrank the interval, an invalidate
callback for the right hand side could be missed before the insertion of
the new interval for the right hand side.
I'll explain this in the comments for nouveau_svmm_do_unmap() and
dmirror_do_unmap().