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: <20180321225632.GI3214@redhat.com>
Date:   Wed, 21 Mar 2018 18:56:32 -0400
From:   Jerome Glisse <jglisse@...hat.com>
To:     Nicolin Chen <nicoleotsuka@...il.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 03:23:57PM -0700, Nicolin Chen wrote:
> Hello Jerome,
> 
> I started to looking at the mm/hmm code and having a question at the
> devm_request_mem_region() call in the hmm_devmem_add() implementation:
> 
> >	addr = min((unsigned long)iomem_resource.end,
> >		   (1UL << MAX_PHYSMEM_BITS) - 1);
> 
> The main question is here as I am a bit confused by this addr. The code
> is trying to get an addr from the end of memory space. However, I have
> tried on an ARM64 platform where ioport_resource.end is -1, so it takes
> "(1UL << MAX_PHYSMEM_BITS) - 1" as the addr base, while this addr is way
> beyond the actual main memory size that's available on my board. Is HMM
> supposed to get an memory region like this? Would it be possible for you
> to give some hint to help me understand it?

What are you trying to do ? hmm_devmem_add() is use either for device
private memory or device public memory. Device private memory is memory
that is not accessible by the CPU, the code you are pointing to is for
that case where i try to find a range of physical address not currently
use (memory not being accessible means that there is not any valid
physical address reserved for it). On x86 MAX_PHYSMEM_BITS is defined
to something that make sense, but as it is often the case for those
define, it seems that arm define an unreal value. My advice fix the
definition for ARM iirc it depends on the SOC dunno if you can know
that at build time. You can probably know the biggest one at build time
(1 << 47 or something like that).

But this all assume that you have a device with its own memory that is
not accessible from the CPU. Which is very uncommon on ARM, only case
i know of is regular PCIE GPU on a ARM system with PCIE.

Hope this helps,
Jérôme

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ