All of lore.kernel.org
 help / color / mirror / Atom feed
* [LTP] [PATCH] mbind01: accept MPOL_LOCAL when passing empty set for MPOL_PREFERRED
@ 2021-07-26 12:53 Jan Stancek
  2021-07-29  7:27 ` Li Wang
  2021-07-29  8:12 ` Li Wang
  0 siblings, 2 replies; 6+ messages in thread
From: Jan Stancek @ 2021-07-26 12:53 UTC (permalink / raw)
  To: ltp

When empty set is passed to MPOL_PREFERRED, memory is allocated
on the node of the CPU that triggered the allocation.

After kernel commit:
  7858d7bca7fb ("mm/mempolicy: don't handle MPOL_LOCAL like a fake MPOL_PREFERRED policy")
kernel returns stored policy as MPOL_LOCAL.

Per mhocko@suse.com in https://lists.linux.it/pipermail/ltp/2021-June/023037.html
  Strictly speaking this is breaking user interface but I am wondering
  whether this really matter or is completely unexpected ... I would
  be inclined to keep this inconsistency and see whether anybody
  actually complains and have a relevant use for this behavior.

Modify the test to accept either MPOL_PREFERRED or MPOL_LOCAL.

Signed-off-by: Jan Stancek <jstancek@redhat.com>
---
 include/lapi/numaif.h                     | 13 +++++++++++++
 testcases/kernel/syscalls/mbind/mbind01.c | 18 +++++++++++++++++-
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 include/lapi/numaif.h

diff --git a/include/lapi/numaif.h b/include/lapi/numaif.h
new file mode 100644
index 000000000000..32dfb565223e
--- /dev/null
+++ b/include/lapi/numaif.h
@@ -0,0 +1,13 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (c) 2021 Linux Test Project
+ */
+
+#ifndef NUMAIF_H__
+#define NUMAIF_H__
+
+#ifndef MPOL_LOCAL
+# define MPOL_LOCAL	4
+#endif
+
+#endif /* NUMAIF_H__ */
diff --git a/testcases/kernel/syscalls/mbind/mbind01.c b/testcases/kernel/syscalls/mbind/mbind01.c
index bc713d78b5c8..0f9f7d3e62b7 100644
--- a/testcases/kernel/syscalls/mbind/mbind01.c
+++ b/testcases/kernel/syscalls/mbind/mbind01.c
@@ -17,6 +17,7 @@
 #include "config.h"
 #include "numa_helper.h"
 #include "tst_test.h"
+#include "lapi/numaif.h"
 
 #ifdef HAVE_NUMA_V2
 
@@ -32,6 +33,7 @@ static struct bitmask *nodemask, *getnodemask, *empty_nodemask;
 static void test_default(unsigned int i, char *p);
 static void test_none(unsigned int i, char *p);
 static void test_invalid_nodemask(unsigned int i, char *p);
+static void check_policy_pref_no_target(int);
 
 struct test_case {
 	int policy;
@@ -39,6 +41,7 @@ struct test_case {
 	unsigned flags;
 	int ret;
 	int err;
+	void (*check_policy)(int);
 	void (*test)(unsigned int, char *);
 	struct bitmask **exp_nodemask;
 };
@@ -88,6 +91,7 @@ static struct test_case tcase[] = {
 		.ret = 0,
 		.err = 0,
 		.test = test_none,
+		.check_policy = check_policy_pref_no_target,
 	},
 	{
 		POLICY_DESC(MPOL_PREFERRED),
@@ -117,6 +121,15 @@ static struct test_case tcase[] = {
 	},
 };
 
+static void check_policy_pref_no_target(int policy)
+{
+	if (policy != MPOL_PREFERRED && policy != MPOL_LOCAL) {
+		tst_res(TFAIL, "Wrong policy: %d, "
+			"expected MPOL_PREFERRED or MPOL_LOCAL",
+			policy);
+	}
+}
+
 static void test_default(unsigned int i, char *p)
 {
 	struct test_case *tc = &tcase[i];
@@ -183,7 +196,10 @@ static void do_test(unsigned int i)
 			tst_res(TFAIL | TTERRNO, "get_mempolicy failed");
 			return;
 		}
-		if (tc->policy != policy) {
+
+		if (tc->check_policy)
+			tc->check_policy(policy);
+		else if (tc->policy != policy) {
 			tst_res(TFAIL, "Wrong policy: %d, expected: %d",
 				tc->policy, policy);
 			fail = 1;
-- 
2.27.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [LTP] [PATCH] mbind01: accept MPOL_LOCAL when passing empty set for MPOL_PREFERRED
  2021-07-26 12:53 [LTP] [PATCH] mbind01: accept MPOL_LOCAL when passing empty set for MPOL_PREFERRED Jan Stancek
@ 2021-07-29  7:27 ` Li Wang
  2021-07-29  8:32   ` Jan Stancek
  2021-07-29  8:12 ` Li Wang
  1 sibling, 1 reply; 6+ messages in thread
From: Li Wang @ 2021-07-29  7:27 UTC (permalink / raw)
  To: ltp

On Mon, Jul 26, 2021 at 8:53 PM Jan Stancek <jstancek@redhat.com> wrote:

> When empty set is passed to MPOL_PREFERRED, memory is allocated
> on the node of the CPU that triggered the allocation.
>
> After kernel commit:
>   7858d7bca7fb ("mm/mempolicy: don't handle MPOL_LOCAL like a fake
> MPOL_PREFERRED policy")
> kernel returns stored policy as MPOL_LOCAL.
>

As the MPOL_LOCAL has been setup as a real policy, I'm wondering should we
add more tests for it in the next? e.g.

--- a/testcases/kernel/syscalls/mbind/mbind01.c
+++ b/testcases/kernel/syscalls/mbind/mbind01.c
@@ -47,6 +47,19 @@ struct test_case {
 };

 static struct test_case tcase[] = {
+       {
+               POLICY_DESC(MPOL_LOCAL),
+               .ret = 0,
+               .err = 0,
+               .test = test_none,
+               .exp_nodemask = &empty_nodemask,
+       },
+       {
+               POLICY_DESC_TEXT(MPOL_LOCAL, "target exists"),
+               .ret = -1,
+               .err = EINVAL,
+               .test = test_default,
+       },
        {
                POLICY_DESC(MPOL_DEFAULT),
                .ret = 0,



>
> Per mhocko@suse.com in
> https://lists.linux.it/pipermail/ltp/2021-June/023037.html
>   Strictly speaking this is breaking user interface but I am wondering
>   whether this really matter or is completely unexpected ... I would
>   be inclined to keep this inconsistency and see whether anybody
>   actually complains and have a relevant use for this behavior.
>
> Modify the test to accept either MPOL_PREFERRED or MPOL_LOCAL.
>
> Signed-off-by: Jan Stancek <jstancek@redhat.com>
>

Reviewed-by: Li Wang <liwang@redhat.com>

But anyway, this patch makes sense!

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210729/e122676e/attachment.htm>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [LTP] [PATCH] mbind01: accept MPOL_LOCAL when passing empty set for MPOL_PREFERRED
  2021-07-26 12:53 [LTP] [PATCH] mbind01: accept MPOL_LOCAL when passing empty set for MPOL_PREFERRED Jan Stancek
  2021-07-29  7:27 ` Li Wang
@ 2021-07-29  8:12 ` Li Wang
  1 sibling, 0 replies; 6+ messages in thread
From: Li Wang @ 2021-07-29  8:12 UTC (permalink / raw)
  To: ltp

>  static void test_default(unsigned int i, char *p)
>  {
>         struct test_case *tc = &tcase[i];
> @@ -183,7 +196,10 @@ static void do_test(unsigned int i)
>                         tst_res(TFAIL | TTERRNO, "get_mempolicy failed");
>                         return;
>                 }
> -               if (tc->policy != policy) {
> +
> +               if (tc->check_policy)
> +                       tc->check_policy(policy);
> +               else if (tc->policy != policy) {
>                         tst_res(TFAIL, "Wrong policy: %d, expected: %d",
>                                 tc->policy, policy);
>

Seems the error print is reverse, which should be corrected as:

                        tst_res(TFAIL, "Wrong policy: %d, expected: %d",
-                               tc->policy, policy);
+                               policy, tc->policy);



-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210729/8ebe60f0/attachment-0001.htm>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [LTP] [PATCH] mbind01: accept MPOL_LOCAL when passing empty set for MPOL_PREFERRED
  2021-07-29  7:27 ` Li Wang
@ 2021-07-29  8:32   ` Jan Stancek
  2021-07-29  8:52     ` Li Wang
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Stancek @ 2021-07-29  8:32 UTC (permalink / raw)
  To: ltp

On Thu, Jul 29, 2021 at 9:27 AM Li Wang <liwang@redhat.com> wrote:

>
>
> On Mon, Jul 26, 2021 at 8:53 PM Jan Stancek <jstancek@redhat.com> wrote:
>
>> When empty set is passed to MPOL_PREFERRED, memory is allocated
>> on the node of the CPU that triggered the allocation.
>>
>> After kernel commit:
>>   7858d7bca7fb ("mm/mempolicy: don't handle MPOL_LOCAL like a fake
>> MPOL_PREFERRED policy")
>> kernel returns stored policy as MPOL_LOCAL.
>>
>
> As the MPOL_LOCAL has been setup as a real policy, I'm wondering should we
> add more tests for it in the next? e.g.
>

Right, but we also need something in setup to avoid running it
for kernels that don't support MPOL_LOCAL.

You're right that parameters in tst_res message appear to be in wrong order.



>
> --- a/testcases/kernel/syscalls/mbind/mbind01.c
> +++ b/testcases/kernel/syscalls/mbind/mbind01.c
> @@ -47,6 +47,19 @@ struct test_case {
>  };
>
>  static struct test_case tcase[] = {
> +       {
> +               POLICY_DESC(MPOL_LOCAL),
> +               .ret = 0,
> +               .err = 0,
> +               .test = test_none,
> +               .exp_nodemask = &empty_nodemask,
> +       },
> +       {
> +               POLICY_DESC_TEXT(MPOL_LOCAL, "target exists"),
> +               .ret = -1,
> +               .err = EINVAL,
> +               .test = test_default,
> +       },
>         {
>                 POLICY_DESC(MPOL_DEFAULT),
>                 .ret = 0,
>
>
>
>>
>> Per mhocko@suse.com in
>> https://lists.linux.it/pipermail/ltp/2021-June/023037.html
>>   Strictly speaking this is breaking user interface but I am wondering
>>   whether this really matter or is completely unexpected ... I would
>>   be inclined to keep this inconsistency and see whether anybody
>>   actually complains and have a relevant use for this behavior.
>>
>> Modify the test to accept either MPOL_PREFERRED or MPOL_LOCAL.
>>
>> Signed-off-by: Jan Stancek <jstancek@redhat.com>
>>
>
> Reviewed-by: Li Wang <liwang@redhat.com>
>
> But anyway, this patch makes sense!
>
> --
> Regards,
> Li Wang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210729/4cb69142/attachment.htm>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [LTP] [PATCH] mbind01: accept MPOL_LOCAL when passing empty set for MPOL_PREFERRED
  2021-07-29  8:32   ` Jan Stancek
@ 2021-07-29  8:52     ` Li Wang
  2021-07-29 10:05       ` Jan Stancek
  0 siblings, 1 reply; 6+ messages in thread
From: Li Wang @ 2021-07-29  8:52 UTC (permalink / raw)
  To: ltp

On Thu, Jul 29, 2021 at 4:33 PM Jan Stancek <jstancek@redhat.com> wrote:

>
>
> On Thu, Jul 29, 2021 at 9:27 AM Li Wang <liwang@redhat.com> wrote:
>
>>
>>
>> On Mon, Jul 26, 2021 at 8:53 PM Jan Stancek <jstancek@redhat.com> wrote:
>>
>>> When empty set is passed to MPOL_PREFERRED, memory is allocated
>>> on the node of the CPU that triggered the allocation.
>>>
>>> After kernel commit:
>>>   7858d7bca7fb ("mm/mempolicy: don't handle MPOL_LOCAL like a fake
>>> MPOL_PREFERRED policy")
>>> kernel returns stored policy as MPOL_LOCAL.
>>>
>>
>> As the MPOL_LOCAL has been setup as a real policy, I'm wondering should we
>> add more tests for it in the next? e.g.
>>
>
> Right, but we also need something in setup to avoid running it
> for kernels that don't support MPOL_LOCAL.
>

+1 we can achieve that in a separate patch.

I'm also planning to add one more function which named mbind_policy_name()
in the mbind.h to help make the log more readable, just like what we did in:
   static inline const char *mbind_flag_name(unsigned flag)

And yes, we can do that separately.


> You're right that parameters in tst_res message appear to be in wrong
> order.
>

Feel free to fix it while merging this patch.

-- 
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210729/0dbee0c1/attachment.htm>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [LTP] [PATCH] mbind01: accept MPOL_LOCAL when passing empty set for MPOL_PREFERRED
  2021-07-29  8:52     ` Li Wang
@ 2021-07-29 10:05       ` Jan Stancek
  0 siblings, 0 replies; 6+ messages in thread
From: Jan Stancek @ 2021-07-29 10:05 UTC (permalink / raw)
  To: ltp

On Thu, Jul 29, 2021 at 10:52 AM Li Wang <liwang@redhat.com> wrote:

>
>
> On Thu, Jul 29, 2021 at 4:33 PM Jan Stancek <jstancek@redhat.com> wrote:
>
>>
>>
>> On Thu, Jul 29, 2021 at 9:27 AM Li Wang <liwang@redhat.com> wrote:
>>
>>>
>>>
>>> On Mon, Jul 26, 2021 at 8:53 PM Jan Stancek <jstancek@redhat.com> wrote:
>>>
>>>> When empty set is passed to MPOL_PREFERRED, memory is allocated
>>>> on the node of the CPU that triggered the allocation.
>>>>
>>>> After kernel commit:
>>>>   7858d7bca7fb ("mm/mempolicy: don't handle MPOL_LOCAL like a fake
>>>> MPOL_PREFERRED policy")
>>>> kernel returns stored policy as MPOL_LOCAL.
>>>>
>>>
>>> As the MPOL_LOCAL has been setup as a real policy, I'm wondering should
>>> we
>>> add more tests for it in the next? e.g.
>>>
>>
>> Right, but we also need something in setup to avoid running it
>> for kernels that don't support MPOL_LOCAL.
>>
>
> +1 we can achieve that in a separate patch.
>
> I'm also planning to add one more function which named mbind_policy_name()
> in the mbind.h to help make the log more readable, just like what we did
> in:
>    static inline const char *mbind_flag_name(unsigned flag)
>
> And yes, we can do that separately.
>
>
>> You're right that parameters in tst_res message appear to be in wrong
>> order.
>>
>
> Feel free to fix it while merging this patch.
>

Pushed with fix for tst_res parameters.



>
> --
> Regards,
> Li Wang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20210729/7300cd56/attachment.htm>

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-07-29 10:05 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-26 12:53 [LTP] [PATCH] mbind01: accept MPOL_LOCAL when passing empty set for MPOL_PREFERRED Jan Stancek
2021-07-29  7:27 ` Li Wang
2021-07-29  8:32   ` Jan Stancek
2021-07-29  8:52     ` Li Wang
2021-07-29 10:05       ` Jan Stancek
2021-07-29  8:12 ` Li Wang

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.