From: Dennis Zhou <dennis@kernel.org>
To: Ye Bin <yebin@huaweicloud.com>
Cc: tj@kernel.org, cl@linux.com, linux-mm@kvack.org,
yury.norov@gmail.com, andriy.shevchenko@linux.intel.com,
linux@rasmusvillemoes.dk, linux-kernel@vger.kernel.org,
yebin10@huawei.com, dchinner@redhat.com
Subject: Re: [PATCH v2 2/2] lib/percpu_counter: fix dying cpu compare race
Date: Sat, 8 Apr 2023 00:13:26 -0700 [thread overview]
Message-ID: <ZDEUFlwlDOTfLshS@snowbird> (raw)
In-Reply-To: <20230406015629.1804722-3-yebin@huaweicloud.com>
Hello,
On Thu, Apr 06, 2023 at 09:56:29AM +0800, Ye Bin wrote:
> From: Ye Bin <yebin10@huawei.com>
>
> In commit 8b57b11cca88 ("pcpcntrs: fix dying cpu summation race") a race
> condition between a cpu dying and percpu_counter_sum() iterating online CPUs
> was identified.
> Acctually, there's the same race condition between a cpu dying and
> __percpu_counter_compare(). Here, use 'num_online_cpus()' for quick judgment.
> But 'num_online_cpus()' will be decreased before call 'percpu_counter_cpu_dead()',
> then maybe return incorrect result.
> To solve above issue, also need to add dying CPUs count when do quick judgment
> in __percpu_counter_compare().
>
I've thought a lot of about this since you've sent v1. For the general
problem, you haven't addressed Dave's concerns from [1].
I agree you've found a valid race condition, but as Dave mentioned,
there's no synchronization in __percpu_counter_compare() and
consequently no guarantees about the accuracy of the value.
However, I might be missing something, but I do think the use case in
5825bea05265 ("xfs: __percpu_counter_compare() inode count debug too expensive")
is potentially valid. If the rhs is an expected lower bound or upper
bound (depending on if you're counting up or down, but not both) and the
count you're accounting has the same expectations as percpu_refcount
(you can only subtract what you've already added), then should the
percpu_counter_sum() ever be on the wrong side of rhs, that should be an
error and visible via percpu_counter_compare().
I need to think a little longer, but my initial thought is while you
close a race condition, the function itself is inherently vulnerable.
[1] https://lore.kernel.org/lkml/ZCu9LtdA+NMrfG9x@rh/
Thanks,
Dennis
> Signed-off-by: Ye Bin <yebin10@huawei.com>
> ---
> lib/percpu_counter.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
> index 5004463c4f9f..399840cb0012 100644
> --- a/lib/percpu_counter.c
> +++ b/lib/percpu_counter.c
> @@ -227,6 +227,15 @@ static int percpu_counter_cpu_dead(unsigned int cpu)
> return 0;
> }
>
> +static __always_inline unsigned int num_count_cpus(void)
> +{
> +#ifdef CONFIG_HOTPLUG_CPU
> + return (num_online_cpus() + num_dying_cpus());
> +#else
> + return num_online_cpus();
> +#endif
> +}
> +
> /*
> * Compare counter against given value.
> * Return 1 if greater, 0 if equal and -1 if less
> @@ -237,7 +246,7 @@ int __percpu_counter_compare(struct percpu_counter *fbc, s64 rhs, s32 batch)
>
> count = percpu_counter_read(fbc);
> /* Check to see if rough count will be sufficient for comparison */
> - if (abs(count - rhs) > (batch * num_online_cpus())) {
> + if (abs(count - rhs) > (batch * num_count_cpus())) {
> if (count > rhs)
> return 1;
> else
> --
> 2.31.1
>
>
next prev parent reply other threads:[~2023-04-08 7:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-06 1:56 [PATCH v2 0/2] " Ye Bin
2023-04-06 1:56 ` [PATCH v2 1/2] cpu/hotplug: introduce 'num_dying_cpus' to get dying CPUs count Ye Bin
2023-04-10 17:42 ` Yury Norov
2023-04-10 20:12 ` Thomas Gleixner
2023-04-06 1:56 ` [PATCH v2 2/2] lib/percpu_counter: fix dying cpu compare race Ye Bin
2023-04-08 7:13 ` Dennis Zhou [this message]
2023-04-10 20:53 ` Thomas Gleixner
2023-04-11 6:56 ` Thomas Gleixner
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=ZDEUFlwlDOTfLshS@snowbird \
--to=dennis@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=cl@linux.com \
--cc=dchinner@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=tj@kernel.org \
--cc=yebin10@huawei.com \
--cc=yebin@huaweicloud.com \
--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