From: Gregory Price <gregory.price@memverge.com>
To: Michal Hocko <mhocko@suse.com>
Cc: Gregory Price <gourry.memverge@gmail.com>,
linux-mm@kvack.org, linux-doc@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org,
linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, arnd@arndb.de, tglx@linutronix.de,
luto@kernel.org, mingo@redhat.com, bp@alien8.de,
dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
tj@kernel.org, ying.huang@intel.com
Subject: Re: [RFC PATCH 05/11] mm/mempolicy: modify set_mempolicy_home_node to take a task argument
Date: Tue, 28 Nov 2023 09:14:46 -0500 [thread overview]
Message-ID: <ZWX11sUJQ8gQlZU1@memverge.com> (raw)
In-Reply-To: <ZWX0KkaUGJoUdmQS@tiehlicka>
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
next prev parent reply other threads:[~2023-11-28 14:14 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 21:11 [RFC PATCH 00/11] mm/mempolicy: Make task->mempolicy externally modifiable via syscall and procfs Gregory Price
2023-11-22 21:11 ` [RFC PATCH 01/11] mm/mempolicy: refactor do_set_mempolicy for code re-use Gregory Price
2023-11-22 21:11 ` [RFC PATCH 02/11] mm/mempolicy: swap cond reference counting logic in do_get_mempolicy Gregory Price
2023-11-28 14:07 ` Michal Hocko
[not found] ` <ZWX0ytAwmOdooHdZ@memverge.com>
2023-11-28 14:28 ` Michal Hocko
2023-11-22 21:11 ` [RFC PATCH 03/11] mm/mempolicy: refactor set_mempolicy stack to take a task argument Gregory Price
2023-11-22 21:11 ` [RFC PATCH 04/11] mm/mempolicy: modify get_mempolicy call " Gregory Price
2023-11-28 14:07 ` Michal Hocko
[not found] ` <ZWX1U1gCTXC+lFXn@memverge.com>
2023-11-28 14:49 ` Michal Hocko
2023-11-22 21:11 ` [RFC PATCH 05/11] mm/mempolicy: modify set_mempolicy_home_node " Gregory Price
2023-11-28 14:07 ` Michal Hocko
2023-11-28 14:14 ` Gregory Price [this message]
2023-11-22 21:11 ` [RFC PATCH 06/11] mm/mempolicy: modify do_mbind to operate on task argument instead of current Gregory Price
2023-11-28 14:11 ` Michal Hocko
2023-11-28 14:51 ` Gregory Price
2023-11-28 18:08 ` Gregory Price
2023-11-22 21:11 ` [RFC PATCH 07/11] mm/mempolicy: add task mempolicy syscall variants Gregory Price
2023-11-22 21:11 ` [RFC PATCH 08/11] mm/mempolicy: export replace_mempolicy for use by procfs Gregory Price
2023-11-22 21:11 ` [RFC PATCH 09/11] mm/mempolicy: build mpol_parse_str unconditionally Gregory Price
2023-11-22 21:11 ` [RFC PATCH 10/11] mm/mempolicy: mpol_parse_str should ignore trailing characters in nodelist Gregory Price
2023-11-22 21:12 ` [RFC PATCH 11/11] fs/proc: Add mempolicy attribute to allow read/write of task mempolicy Gregory Price
2023-11-22 21:33 ` [RFC PATCH 00/11] mm/mempolicy: Make task->mempolicy externally modifiable via syscall and procfs Andrew Morton
2023-11-22 21:35 ` Andrew Morton
2023-11-22 22:24 ` Gregory Price
2023-11-27 15:29 ` Michal Hocko
2023-11-27 16:14 ` Gregory Price
2023-11-28 9:45 ` Michal Hocko
2023-11-28 13:15 ` Gregory Price
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZWX11sUJQ8gQlZU1@memverge.com \
--to=gregory.price@memverge.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=gourry.memverge@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=x86@kernel.org \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).