[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c024c20d-17d0-4b20-9f81-f9934d4f151f@lucifer.local>
Date: Tue, 24 Sep 2024 08:49:06 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Shakeel Butt <shakeel.butt@...ux.dev>,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
"Liam R. Howlett" <Liam.Howlett@...cle.com>,
Suren Baghdasaryan <surenb@...gle.com>, linux-api@...r.kernel.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Minchan Kim <minchan@...nel.org>
Subject: Re: [PATCH 1/2] mm/madvise: introduce PR_MADV_SELF flag to
process_madvise()
On Mon, Sep 23, 2024 at 09:49:43PM GMT, Arnd Bergmann wrote:
> On Mon, Sep 23, 2024, at 19:34, Lorenzo Stoakes wrote:
> > On Mon, Sep 23, 2024 at 11:56:06AM GMT, Shakeel Butt wrote:
> >
> > + /* Require PTRACE_MODE_READ to avoid leaking ASLR metadata. */
> > + mm = mm_access(task, PTRACE_MODE_READ_FSCREDS);
> > + if (IS_ERR_OR_NULL(mm)) {
> > + ret = IS_ERR(mm) ? PTR_ERR(mm) : -ESRCH;
> > + goto release_task;
> > + }
>
> Any chance we can fix mm_access() to not be able to return
> a NULL pointer and an error pointer? IS_ERR_OR_NULL() is
> usually an indication of a confusing API, and this is
> clearly one of them, given that only one of the
> callers actually wants the NULL value instead of -ESRCH.
>
> Arnd
Agreed, this should be fixed. I think it'd be a bit out of the scope of
this series so will send something separately for this.
Powered by blists - more mailing lists