[<prev] [next>] [day] [month] [year] [list]
Message-ID: <c7f6f916-3855-f7ad-fa4d-153b80797cc3@intel.com>
Date: Mon, 16 Nov 2020 13:11:48 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Hillf Danton <hdanton@...a.com>,
Jarkko Sakkinen <jarkko@...nel.org>
Cc: x86@...nel.org, linux-sgx@...r.kernel.org,
linux-kernel@...r.kernel.org,
Sean Christopherson <sean.j.christopherson@...el.com>,
Jethro Beekman <jethro@...tanix.com>,
Serge Ayoun <serge.ayoun@...el.com>, akpm@...ux-foundation.org
Subject: Re: [PATCH v41 11/24] x86/sgx: Add SGX misc driver interface
On 11/14/20 8:01 PM, Hillf Danton wrote:
> On Fri, 13 Nov 2020 00:01:22 +0200 Jarkko Sakkinen wrote:
> +
> +static unsigned long sgx_get_unmapped_area(struct file *file,
> + unsigned long addr,
> + unsigned long len,
> + unsigned long pgoff,
> + unsigned long flags)
> +{
> + if ((flags & MAP_TYPE) == MAP_PRIVATE)
> + return -EINVAL;
> +
> + if (flags & MAP_FIXED)
> + return addr;
> +
> MAP_FIXED is checked in arch_get_unmapped_area() along with others,
> so better to check it always there.
In the whole tangle of get_unmapped_area() functions, it wasn't patently
obvious to me that MAP_FIXED functionality is guaranteed to be present
in the higher-level functions.
There are also a fair number of these fops->get_unmapped_area()
instances that have the same MAP_FIXED line. Are in need of fixups too?
Or are you suggesting that since SGX is x86-only, it can depend on the
x86 arch_get_unmapped_area() code to continue to have this MAP_FIXED
functionality?
Powered by blists - more mailing lists