[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a3f7aed9-0df2-2fd6-cebb-ba569ad66781@redhat.com>
Date: Fri, 17 Nov 2017 08:30:48 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Michal Hocko <mhocko@...nel.org>, linux-api@...r.kernel.org
Cc: Khalid Aziz <khalid.aziz@...cle.com>,
Michael Ellerman <mpe@...erman.id.au>,
Andrew Morton <akpm@...ux-foundation.org>,
Russell King - ARM Linux <linux@...linux.org.uk>,
Andrea Arcangeli <aarcange@...hat.com>, linux-mm@...ck.org,
LKML <linux-kernel@...r.kernel.org>, linux-arch@...r.kernel.org,
Michal Hocko <mhocko@...e.com>
Subject: Re: [RFC PATCH 1/2] mm: introduce MAP_FIXED_SAFE
On 11/16/2017 11:18 AM, Michal Hocko wrote:
> + if (flags & MAP_FIXED_SAFE) {
> + struct vm_area_struct *vma = find_vma(mm, addr);
> +
> + if (vma && vma->vm_start <= addr)
> + return -ENOMEM;
> + }
Could you pick a different error code which cannot also be caused by a
an unrelated, possibly temporary condition? Maybe EBUSY or EEXIST?
This would definitely help with application-based randomization of
mappings, and there, actual ENOMEM and this error would have to be
handled differently.
Thanks,
Florian
Powered by blists - more mailing lists