From: Jakub Kicinski <jakub.kicinski@netronome.com>
To: Takshak Chahande <ctakshak@fb.com>
Cc: <netdev@vger.kernel.org>, <ast@kernel.org>,
<daniel@iogearbox.net>, <rdna@fb.com>, <kernel-team@fb.com>,
<hechaol@fb.com>
Subject: Re: [PATCH bpf-next] libbpf : make libbpf_num_possible_cpus function thread safe
Date: Tue, 30 Jul 2019 16:05:02 -0700 [thread overview]
Message-ID: <20190730160502.699d0b9a@cakuba.netronome.com> (raw)
In-Reply-To: <20190730222447.3918919-1-ctakshak@fb.com>
On Tue, 30 Jul 2019 15:24:47 -0700, Takshak Chahande wrote:
> Having static variable `cpus` in libbpf_num_possible_cpus function without
> guarding it with mutex makes this function thread-unsafe.
>
> If multiple threads accessing this function, in the current form; it
> leads to incrementing the static variable value `cpus` in the multiple
> of total available CPUs.
>
> Let caching the number of possile CPUs handled by libbpf's users than
> this library itself;
Can we just use stack variable for the calculations and
READ_ONCE()/WRITE_ONCE() for assignment to the static?
libbpf itself uses this helper so caller caching wouldn't
work there.
> and let this function be rock bottom one which reads
> and parse the file (/sys/devices/system/cpu/possible) everytime it gets
> called to simplify the things.
I don't understand can you rephrase?
> Fixes: 6446b3155521 (bpf: add a new API libbpf_num_possible_cpus())
>
No new line after the fixes tag, also I think you're missing quotation
marks around the commit title?
> Signed-off-by: Takshak Chahande <ctakshak@fb.com>
> Acked-by: Andrey Ignatov <rdna@fb.com>
prev parent reply other threads:[~2019-07-30 23:05 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-30 22:24 [PATCH bpf-next] libbpf : make libbpf_num_possible_cpus function thread safe Takshak Chahande
2019-07-30 23:05 ` Jakub Kicinski [this message]
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=20190730160502.699d0b9a@cakuba.netronome.com \
--to=jakub.kicinski@netronome.com \
--cc=ast@kernel.org \
--cc=ctakshak@fb.com \
--cc=daniel@iogearbox.net \
--cc=hechaol@fb.com \
--cc=kernel-team@fb.com \
--cc=netdev@vger.kernel.org \
--cc=rdna@fb.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