From: Stanislav Fomichev <sdf@fomichev.me>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Lorenzo Bianconi <lorenzo@kernel.org>, Daniel Xu <dxu@dxuuu.xyz>,
John Fastabend <john.fastabend@gmail.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
bpf@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH bpf-next 2/9] kthread: allow vararg kthread_{create,run}_on_cpu()
Date: Tue, 3 Sep 2024 10:04:09 -0700 [thread overview]
Message-ID: <ZtdBieFVdpT4Jsf_@mini-arch> (raw)
In-Reply-To: <235dcd89-54a6-43ca-bbb3-45dfd6db97e6@intel.com>
On 09/03, Alexander Lobakin wrote:
> From: Stanislav Fomichev <sdf@fomichev.me>
> Date: Fri, 30 Aug 2024 15:56:12 -0700
>
> > On 08/30, Alexander Lobakin wrote:
> >> Currently, kthread_{create,run}_on_cpu() doesn't support varargs like
> >> kthread_create{,_on_node}() do, which makes them less convenient to
> >> use.
> >> Convert them to take varargs as the last argument. The only difference
> >> is that they always append the CPU ID at the end and require the format
> >> string to have an excess '%u' at the end due to that. That's still true;
> >> meanwhile, the compiler will correctly point out to that if missing.
> >> One more nice side effect is that you can now use the underscored
> >> __kthread_create_on_cpu() if you want to override that rule and not
> >> have CPU ID at the end of the name.
> >> The current callers are not anyhow affected.
> >>
> >> Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
> >> ---
> >> include/linux/kthread.h | 51 ++++++++++++++++++++++++++---------------
> >> kernel/kthread.c | 22 ++++++++++--------
> >> 2 files changed, 45 insertions(+), 28 deletions(-)
> >>
> >> diff --git a/include/linux/kthread.h b/include/linux/kthread.h
> >> index b11f53c1ba2e..27a94e691948 100644
> >> --- a/include/linux/kthread.h
> >> +++ b/include/linux/kthread.h
> >> @@ -27,11 +27,21 @@ struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
> >> #define kthread_create(threadfn, data, namefmt, arg...) \
> >> kthread_create_on_node(threadfn, data, NUMA_NO_NODE, namefmt, ##arg)
> >>
> >> -
> >> -struct task_struct *kthread_create_on_cpu(int (*threadfn)(void *data),
> >> - void *data,
> >> - unsigned int cpu,
> >> - const char *namefmt);
> >> +__printf(4, 5)
> >> +struct task_struct *__kthread_create_on_cpu(int (*threadfn)(void *data),
> >> + void *data, unsigned int cpu,
> >> + const char *namefmt, ...);
> >> +
> >> +#define kthread_create_on_cpu(threadfn, data, cpu, namefmt, ...) \
> >> + _kthread_create_on_cpu(threadfn, data, cpu, __UNIQUE_ID(cpu_), \
> >> + namefmt, ##__VA_ARGS__)
> >> +
> >> +#define _kthread_create_on_cpu(threadfn, data, cpu, uc, namefmt, ...) ({ \
> >> + u32 uc = (cpu); \
> >> + \
> >> + __kthread_create_on_cpu(threadfn, data, uc, namefmt, \
> >> + ##__VA_ARGS__, uc); \
> >> +})
> >>
> >> void get_kthread_comm(char *buf, size_t buf_size, struct task_struct *tsk);
> >> bool set_kthread_struct(struct task_struct *p);
> >> @@ -62,25 +72,28 @@ bool kthread_is_per_cpu(struct task_struct *k);
> >> * @threadfn: the function to run until signal_pending(current).
> >> * @data: data ptr for @threadfn.
> >> * @cpu: The cpu on which the thread should be bound,
> >> - * @namefmt: printf-style name for the thread. Format is restricted
> >> - * to "name.*%u". Code fills in cpu number.
> >> + * @namefmt: printf-style name for the thread. Must have an excess '%u'
> >> + * at the end as kthread_create_on_cpu() fills in CPU number.
> >> *
> >> * Description: Convenient wrapper for kthread_create_on_cpu()
> >> * followed by wake_up_process(). Returns the kthread or
> >> * ERR_PTR(-ENOMEM).
> >> */
> >> -static inline struct task_struct *
> >> -kthread_run_on_cpu(int (*threadfn)(void *data), void *data,
> >> - unsigned int cpu, const char *namefmt)
> >> -{
> >> - struct task_struct *p;
> >> -
> >> - p = kthread_create_on_cpu(threadfn, data, cpu, namefmt);
> >> - if (!IS_ERR(p))
> >> - wake_up_process(p);
> >> -
> >> - return p;
> >> -}
> >> +#define kthread_run_on_cpu(threadfn, data, cpu, namefmt, ...) \
> >> + _kthread_run_on_cpu(threadfn, data, cpu, __UNIQUE_ID(task_), \
> >> + namefmt, ##__VA_ARGS__)
> >> +
> >> +#define _kthread_run_on_cpu(threadfn, data, cpu, ut, namefmt, ...) \
> >> +({ \
> >> + struct task_struct *ut; \
> >> + \
> >> + ut = kthread_create_on_cpu(threadfn, data, cpu, namefmt, \
> >> + ##__VA_ARGS__); \
> >> + if (!IS_ERR(ut)) \
> >> + wake_up_process(ut); \
> >> + \
> >> + ut; \
> >> +})
> >
> > Why do you need to use __UNIQUE_ID here? Presumably ({}) in _kthread_run_on_cpu
>
> It will still be a -Wshadow warning if the caller has a variable with
> the same name. I know it's enabled only on W=2, but anyway I feel like
> we shouldn't introduce any new warnings when possible.
Makes sense, thanks! That's why, presumably, kthread_run uses __k name
to avoid the warning..
next prev parent reply other threads:[~2024-09-03 17:04 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-30 16:24 [PATCH bpf-next 0/9] bpf: cpumap: enable GRO for XDP_PASS frames Alexander Lobakin
2024-08-30 16:25 ` [PATCH bpf-next 1/9] firmware/psci: fix missing '%u' format literal in kthread_create_on_cpu() Alexander Lobakin
2024-08-30 23:31 ` Daniel Xu
2024-08-30 16:25 ` [PATCH bpf-next 2/9] kthread: allow vararg kthread_{create,run}_on_cpu() Alexander Lobakin
2024-08-30 22:56 ` Stanislav Fomichev
2024-09-03 12:25 ` Alexander Lobakin
2024-09-03 17:04 ` Stanislav Fomichev [this message]
2024-08-30 16:25 ` [PATCH bpf-next 3/9] net: napi: add ability to create CPU-pinned threaded NAPI Alexander Lobakin
2024-08-31 0:19 ` Daniel Xu
2024-08-30 16:25 ` [PATCH bpf-next 4/9] bpf: cpumap: use CPU-pinned threaded NAPI w/GRO instead of kthread Alexander Lobakin
2024-08-30 16:25 ` [PATCH bpf-next 5/9] bpf: cpumap: reuse skb array instead of a linked list to chain skbs Alexander Lobakin
2024-08-30 16:25 ` [PATCH bpf-next 6/9] net: skbuff: introduce napi_skb_cache_get_bulk() Alexander Lobakin
2024-08-30 16:25 ` [PATCH bpf-next 7/9] bpf: cpumap: switch to napi_skb_cache_get_bulk() Alexander Lobakin
2024-08-30 16:25 ` [PATCH bpf-next 8/9] veth: use napi_skb_cache_get_bulk() instead of xdp_alloc_skb_bulk() Alexander Lobakin
2024-08-30 16:25 ` [PATCH bpf-next 9/9] xdp: remove xdp_alloc_skb_bulk() Alexander Lobakin
2024-09-03 20:51 ` [PATCH bpf-next 0/9] bpf: cpumap: enable GRO for XDP_PASS frames Jakub Kicinski
2024-09-03 21:33 ` Lorenzo Bianconi
2024-09-05 11:53 ` Jesper Dangaard Brouer
2024-09-05 17:01 ` Lorenzo Bianconi
2024-09-06 0:20 ` Jakub Kicinski
2024-09-06 8:15 ` Lorenzo Bianconi
2024-09-07 13:22 ` Lorenzo Bianconi
2024-09-04 13:13 ` Alexander Lobakin
2024-09-04 14:50 ` Jakub Kicinski
2024-09-04 15:13 ` Alexander Lobakin
2024-09-04 18:29 ` Jakub Kicinski
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=ZtdBieFVdpT4Jsf_@mini-arch \
--to=sdf@fomichev.me \
--cc=aleksander.lobakin@intel.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dxu@dxuuu.xyz \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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;
as well as URLs for NNTP newsgroup(s).