From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: Gary Guo <gary@garyguo.net>, Boqun Feng <boqun@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>,
Bert Karwatzki <spasswolf@web.de>, Harry Yoo <harry@kernel.org>,
linux-kernel@vger.kernel.org, linux-next@vger.kernel.org,
Alice Ryhl <aliceryhl@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
rust-for-linux@vger.kernel.org, Miguel Ojeda <ojeda@kernel.org>,
Mark Brown <broonie@kernel.org>
Subject: Re: rust compile failure in next-20260730
Date: Tue, 4 Aug 2026 12:35:42 +0200 [thread overview]
Message-ID: <7189ebb5-ae48-4466-9055-1ab1b0b5ef7c@kernel.org> (raw)
In-Reply-To: <DKG2TQ94TGLB.3EO7ZNVKB50KY@garyguo.net>
On 8/4/26 12:10, Gary Guo wrote:
> On Mon Aug 3, 2026 at 10:04 PM BST, Vlastimil Babka (SUSE) wrote:
>> On 8/3/26 17:32, Gary Guo wrote:
>>> On Mon Aug 3, 2026 at 4:10 PM BST, Vlastimil Babka (SUSE) wrote:
>>>> On 8/3/26 16:23, Boqun Feng wrote:
>>>>> On Mon, Aug 03, 2026 at 02:57:49PM +0100, Gary Guo wrote:
>>>>>>
>>>>>> We could also unconditionally use `kvfree_rcu_head` here, and
>>>>>> add
>>>>>>
>>>>>> #[cfg(not(CONFIG_KVFREE_RCU_BATCHED))]
>>>>>> pub type kvfree_rcu_head = callback_head;
>>>>>>
>>>>>> to bindings.rs?
>>>>>>
>>>>>
>>>>> This option is currently not maintainable unless it becomes a
>>>>> maintainer-aware way to handle things like this.
>>>>>
>>>>>> (Or even better, changing `#define` to `typedef` so bindgen takes care of
>>>>>> everything).
>>>>>>
>>>>>
>>>>> Yes, this is better IMO, but it's up to slab maintainers. :-)
>>>>
>>>> Can you elaborate a bit please, how would that look like?
>>>
>>> I was thinking of doing `typedef struct rcu_head kvfree_rcu_head;` but of course
>>> that didn't work because you can't use typedef to create `kvfree_rcu_head` :)
>>>
>>> However, something like this could work?
>>>
>>> #ifdef CONFIG_KVFREE_RCU_BATCHED
>>> ...
>>> #else
>>> struct kvfree_rcu_head {
>>> struct rcu_head head;
>>> };
>>> #endif
>>>
>>> and everywhere add a cast everywhere that expects kvfree_rcu_head == rcu_head.
>>>
>>> but this would indeed be more complex :(
>>
>> So you mean like this? Doesn't seem so complex and seems to compile here
>> with CONFIG_KVFREE_RCU_BATCHED both disabled and enabled.
>
> I thought that a lot more places have to be updated, but it looks from your diff
> below that this is simple enough.
Thanks. The slab/for-next branch now includes the slab changes.
The merge commit should thus perform the rust/kernel/sync/poll.rs change.
> Best,
> Gary
>
>> I can apply the slab part in slab tree, but AFAICS the poll.rs
>> change still needs to be done in the merge commit. Unless there's
>> some way to make things conditional on whether kvfree_rcu_head exists?
>>
>> diff --git a/include/linux/types.h b/include/linux/types.h
>> index 79bf419c69e4..53e0adca4b9f 100644
>> --- a/include/linux/types.h
>> +++ b/include/linux/types.h
>> @@ -262,7 +262,9 @@ struct kvfree_rcu_head {
>> struct kvfree_rcu_head *next;
>> };
>> #else
>> -#define kvfree_rcu_head rcu_head
>> +struct kvfree_rcu_head {
>> + struct rcu_head head;
>> +};
>> #endif
>>
>> typedef void (*rcu_callback_t)(struct rcu_head *head);
>> diff --git a/mm/slab_common.c b/mm/slab_common.c
>> index 64845ac81b79..aecbe9b9df4c 100644
>> --- a/mm/slab_common.c
>> +++ b/mm/slab_common.c
>> @@ -1325,11 +1325,11 @@ EXPORT_SYMBOL_GPL(kfree_call_rcu_nolock);
>>
>> #ifndef CONFIG_KVFREE_RCU_BATCHED
>>
>> -void kvfree_call_rcu(struct rcu_head *head, void *ptr)
>> +void kvfree_call_rcu(struct kvfree_rcu_head *head, void *ptr)
>> {
>> if (head) {
>> kasan_record_aux_stack(ptr);
>> - call_rcu(head, kvfree_rcu_cb);
>> + call_rcu(&head->head, kvfree_rcu_cb);
>> return;
>> }
>>
>> diff --git a/rust/kernel/sync/poll.rs b/rust/kernel/sync/poll.rs
>> index 684dfa242b1a..f3cdf95db12d 100644
>> --- a/rust/kernel/sync/poll.rs
>> +++ b/rust/kernel/sync/poll.rs
>> @@ -124,7 +124,7 @@ pub struct PollCondVarBox {
>> struct PollCondVarBoxInner {
>> #[pin]
>> inner: PollCondVar,
>> - rcu: Opaque<bindings::callback_head>,
>> + rcu: Opaque<bindings::kvfree_rcu_head>,
>> }
>>
>> // SAFETY: PollCondVar is Send
>
>
prev parent reply other threads:[~2026-08-04 10:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 12:28 rust compile failure in next-20260730 Bert Karwatzki
2026-07-31 13:19 ` Thorsten Leemhuis
2026-07-31 13:48 ` Luna Jernberg
2026-07-31 19:25 ` Nathan Chancellor
2026-08-03 13:57 ` Gary Guo
2026-08-03 14:23 ` Boqun Feng
2026-08-03 15:10 ` Vlastimil Babka (SUSE)
2026-08-03 15:32 ` Gary Guo
2026-08-03 21:04 ` Vlastimil Babka (SUSE)
2026-08-04 10:10 ` Gary Guo
2026-08-04 10:35 ` Vlastimil Babka (SUSE) [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=7189ebb5-ae48-4466-9055-1ab1b0b5ef7c@kernel.org \
--to=vbabka@kernel.org \
--cc=aliceryhl@google.com \
--cc=boqun@kernel.org \
--cc=broonie@kernel.org \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=harry@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=nathan@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=spasswolf@web.de \
/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 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.