From: Yi Wang <wang.yi59@zte.com.cn>
To: yury.norov@gmail.com, andriy.shevchenko@linux.intel.com,
linux@rasmusvillemoes.dk
Cc: linux-kernel@vger.kernel.org, xue.zhihong@zte.com.cn,
wang.yi59@zte.com.cn, wang.liang82@zte.com.cn
Subject: [PATCH] bitmap: fix a unproper remap when mpol_rebind_nodemask()
Date: Mon, 13 Jun 2022 19:29:37 +0800 [thread overview]
Message-ID: <20220613112937.65428-1-wang.yi59@zte.com.cn> (raw)
Consider one situation:
The app have two vmas which mbind() to node 1 and node3 respectively,
and its cpuset.mems is 0-3, now set its cpuset.mems to 1,3, according
to current bitmap_remap(), we got:
1 => 3
3 => 3
This maybe confused because node 1,3 have already in the new settiing
region but both nodes are binded to the same node 3 now.
Actually we found the situation on a very old libvirt and qemu, but
this can be easily reproduced in the current kernel, so we try to fix
it.
A possible fix way is to ignore the bits in @src have already existed
in @new.
Signed-off-by: Yi Wang <wang.yi59@zte.com.cn>
---
lib/bitmap.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index b18e31ea6e66..b77bf1b3852e 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -1006,8 +1006,8 @@ unsigned int bitmap_ord_to_pos(const unsigned long *buf, unsigned int ord, unsig
* @dst point to the same location, then this routine copies @src
* to @dst.
*
- * The positions of unset bits in @old are mapped to themselves
- * (the identify map).
+ * The positions of unset bits in @old or bits in @src have already
+ * existed in @new are mapped to themselves (the identify map).
*
* Apply the above specified mapping to @src, placing the result in
* @dst, clearing any bits previously set in @dst.
@@ -1033,7 +1033,7 @@ void bitmap_remap(unsigned long *dst, const unsigned long *src,
for_each_set_bit(oldbit, src, nbits) {
int n = bitmap_pos_to_ord(old, oldbit, nbits);
- if (n < 0 || w == 0)
+ if (n < 0 || w == 0 || test_bit(oldbit, new))
set_bit(oldbit, dst); /* identity map */
else
set_bit(bitmap_ord_to_pos(new, n % w, nbits), dst);
--
2.33.0.rc0.dirty
next reply other threads:[~2022-06-13 14:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-13 11:29 Yi Wang [this message]
2022-06-13 19:20 ` Yury Norov
2022-06-14 3:45 ` wang.yi59
2022-06-14 16:40 ` [PATCH] " Yury Norov
2022-06-14 16:50 ` Andy Shevchenko
2022-06-15 8:54 ` wang.yi59
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=20220613112937.65428-1-wang.yi59@zte.com.cn \
--to=wang.yi59@zte.com.cn \
--cc=andriy.shevchenko@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=wang.liang82@zte.com.cn \
--cc=xue.zhihong@zte.com.cn \
--cc=yury.norov@gmail.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
all inboxes | Powered by JetHome®