linux-kernel - Re: mm/hmm: a simple question regarding devm_request_mem

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] [day] [month] [year] [list]

Message-ID: <20180322020013.GA26480@Asurada-Nvidia>
Date:   Wed, 21 Mar 2018 19:00:14 -0700
From:   Nicolin Chen <nicoleotsuka@...il.com>
To:     Jerome Glisse <jglisse@...hat.com>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: mm/hmm: a simple question regarding devm_request_mem_region()

On Wed, Mar 21, 2018 at 08:32:54PM -0400, Jerome Glisse wrote:

> > I am testing with drivers/char/hmm_dmirror.c from your git repository.
> > 
> > The addr I got (before "- size") is actually 0x7fffffffff, so equally
> > (1 << 40).
> > 
> > So from your reply, it seems to me that HMM is supposed to request a
> > region like it.
> 
> The dummy driver by default test the private memory, i had patches to
> make it test public memory too somewhere in a branch. So yes this is
> expected from the dummy driver. HMM here is trying to get a region that
> will not collide with any known existing resources. Idealy we would
> like a platform/arch function for that but it is hard to justify it
> nor is there a safe way to find such thing either from arch/platform
> specific code (there isn't for x86 at least).
> 
> For real device driver of pcie devices, the advice is to use the pci
> bar region of the device. This way we know for sure we do not collide
> with anything (ie use hmm_devmem_add_resource() not hmm_devmem_add()
> but this need some code change for res->desc).

I see. Thank you!