From: Feng Tang <feng.tang@intel.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 3/3] mbind01: add more tests for MPOL_LOCAL
Date: Fri, 30 Jul 2021 19:35:34 +0800 [thread overview]
Message-ID: <20210730113534.GB87305@shbuild999.sh.intel.com> (raw)
In-Reply-To: <CAEemH2cJHtVkaaH5OokAHfVLzPdxU=SqiCf_Gg_ntX_fnWorYw@mail.gmail.com>
Hi Li,
On Fri, Jul 30, 2021 at 04:03:28PM +0800, Li Wang wrote:
[....]
> On Thu, Jul 29, 2021 at 10:20 PM Jan Stancek <jstancek@redhat.com> wrote:
> >> @@ -101,6 +101,20 @@ static struct test_case tcase[] = {
> >> .test = test_default,
> >> .exp_nodemask = &nodemask,
> >> },
> >> + {
> >> + POLICY_DESC(MPOL_LOCAL),
> >> + .ret = 0,
> >> + .err = 0,
> >> + .test = test_none,
> >> + .exp_nodemask = &empty_nodemask,
> >> + .check_policy = check_policy_pref_or_local,
> >>
> >
> > This is a bit more permissive, it allows for MPOL_LOCAL to return also
> > MPOL_PREFERRED.
> > Shouldn't that still be treated as error?
> >
>
> To strictly this should be an error.
>
> But I slightly think that it's acceptable to get 'MPOL_PREFERRED' on the old
> kernel (i.e. 4.18.0, v5.13) because 'MPOL_LOCAL' is not treated as a real
> policy.
> And the situation exists for quite a long time.
>
> 7858d7bca7fb ("mm/mempolicy: don't handle MPOL_LOCAL like a fake
> MPOL_PREFERRED policy")
>
> Without this kernel commit, looks like the MPOL_LOCAL will convert to
> MPOL_PREFERRED in mpol_new.
>
> SYSCAL_DEFINE6(mbind, ...)
> kernel_mbind
> do_mbind
> mpol_new
> ....
>
> # cat mempolicy.c -n
>
> 287 /*
> 288 * MPOL_PREFERRED cannot be used with MPOL_F_STATIC_NODES or
> 289 * MPOL_F_RELATIVE_NODES if the nodemask is empty (local
> allocation).
> 290 * All other modes require a valid pointer to a non-empty
> nodemask.
> 291 */
> 292 if (mode == MPOL_PREFERRED) {
> 293 if (nodes_empty(*nodes)) {
> 294 if (((flags & MPOL_F_STATIC_NODES) ||
> 295 (flags & MPOL_F_RELATIVE_NODES)))
> 296 return ERR_PTR(-EINVAL);
> 297 }
> 298 } else if (mode == MPOL_LOCAL) {
> 299 if (!nodes_empty(*nodes) ||
> 300 (flags & MPOL_F_STATIC_NODES) ||
> 301 (flags & MPOL_F_RELATIVE_NODES))
> 302 return ERR_PTR(-EINVAL);
> 303 mode = MPOL_PREFERRED; <--------- this line has
> been removed after the commit
> 304 } else if (nodes_empty(*nodes))
> 305 return ERR_PTR(-EINVAL);
>
> But maybe I was wrong here, CC FengTang in case he has suggestions on this.
Yes, you are right. With the commit MPOL_LOCAL will be taken as a real
policy, be MPOL_LOCAL itself, and not a fake MPOL_PREFERRED.
Faking MPOL_LOCAL as a MPOL_PREFERRED makes the semantic very confusing,
and the kenrel code is also very confusing and difficult to be maintained,
as there are many ambiguous logic to check this faking and transform the
policy back and forth. So we chosed to clean it up.
Thanks,
Feng
>
> >
> >> + if ((tst_kvercmp(3, 8, 0)) < 0 && (tc->policy == MPOL_LOCAL)) {
> >> + tst_res(TCONF, "%s is not supported",
> >> tst_mempolicy_mode_name(tc->policy));
> >> + return;
> >> + }
> >>
> >
> > I was thinking of runtime check (to support also downstream kernels that
> > backported it),
> > but I don't have strong opinion.
> >
>
> Thanks, I assume there is little probability to backport it.
>
> --
> Regards,
> Li Wang
next prev parent reply other threads:[~2021-07-30 11:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-29 13:25 [LTP] [PATCH 1/3] mbind01: make use of tst_numa_mode_name Li Wang
2021-07-29 13:25 ` [LTP] [PATCH 2/3] libs: rename tst_numa_mode_name to tst_mempolicy_mode_name Li Wang
2021-07-29 13:25 ` [LTP] [PATCH 3/3] mbind01: add more tests for MPOL_LOCAL Li Wang
2021-07-29 14:20 ` Jan Stancek
2021-07-30 8:03 ` Li Wang
2021-07-30 10:35 ` Jan Stancek
2021-07-30 10:44 ` Li Wang
2021-07-30 11:54 ` Jan Stancek
2021-07-30 11:35 ` Feng Tang [this message]
2021-08-02 2:03 ` Li Wang
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=20210730113534.GB87305@shbuild999.sh.intel.com \
--to=feng.tang@intel.com \
--cc=ltp@lists.linux.it \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.