[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZWX11sUJQ8gQlZU1@memverge.com>
Date: Tue, 28 Nov 2023 09:14:46 -0500
From: Gregory Price <gregory.price@...verge.com>
To: Michal Hocko <mhocko@...e.com>
Cc: Gregory Price <gourry.memverge@...il.com>, linux-mm@...ck.org,
linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-api@...r.kernel.org, linux-arch@...r.kernel.org,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
arnd@...db.de, tglx@...utronix.de, luto@...nel.org,
mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
x86@...nel.org, hpa@...or.com, tj@...nel.org, ying.huang@...el.com
Subject: Re: [RFC PATCH 05/11] mm/mempolicy: modify set_mempolicy_home_node
to take a task argument
On Tue, Nov 28, 2023 at 03:07:38PM +0100, Michal Hocko wrote:
> On Wed 22-11-23 16:11:54, Gregory Price wrote:
> [...]
> > +
> > + if (!mm)
> > + return -ENODEV;
>
> Is this an expected error? No mm means task dying and mm has been
> already released. Should we simply return ESRCH wouldbe a better error
> code IMO. This should never happen for the current task so it sould be
> safe to add.
Hm, good point, and in fact i should make sure that the new pidfd code
is not susceptible to this.
This particular set of lines is not present in the new RFC (not out yet)
but the access to the remote task mm is more controlled via mm_access,
so I would presume that mm_access either returns error, I will make sure
it cannot return null and check for this.
>
> --
> Michal Hocko
> SUSE Labs
Powered by blists - more mailing lists