linux-kernel - Re: [PATCH v4 2/2] mm/hmm/test: add self tests for HMM

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]

Date:   Thu, 14 Nov 2019 15:06:05 -0800
From:   Ralph Campbell <rcampbell@...dia.com>
To:     Christoph Hellwig <hch@....de>, Jason Gunthorpe <jgg@...lanox.com>
CC:     Andrew Morton <akpm@...ux-foundation.org>,
        Jerome Glisse <jglisse@...hat.com>,
        John Hubbard <jhubbard@...dia.com>,
        Shuah Khan <shuah@...nel.org>,
        "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>
Subject: Re: [PATCH v4 2/2] mm/hmm/test: add self tests for HMM

On 11/13/19 5:51 AM, Christoph Hellwig wrote:
> On Tue, Nov 12, 2019 at 11:45:52PM +0000, Jason Gunthorpe wrote:
>>> Well, it would mean registering for the whole process address space.
>>> I'll give it a try.
>>
>> I'm not sure it makes much sense that this testing is essentially
>> modeled after nouveau's usage which is very strange compared to the
>> other drivers.
> 
> Which means we really should make the test cases fit the proper usage.
> Maybe defer the tests for 5.5 and just merge the first patch for now?
> 

I think this a good point to discuss.
Some devices will want to register for all changes to the process address
space because there is no requirement to preregister regions that the
device can access verses devices like InfiniBand where a range of addresses
have to be registered before the device can access those addresses.
So for nouveau and the hmm-test driver, the mmu_range_notifier_insert()
and mmu_range_notifier_remove() are only used long enough to get a
stable copy of a small part of the process address space and copy it to
the device's page table. Then the regular process wide invalidations are
required to keep the device's page tables consistent with the process
page table.

The "hacky" part of the current design is the interaction between the
short term narrow address range invalidations verses the long term
process wide invalidations. (double callbacks, double locking of the
device page table)

Both types of invalidate callbacks seem useful to me so forcing a
driver to use only one type doesn't make sense to me.