linux-kernel - Re: linux-next: manual merge of the slab tree with the rcu tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z6wy388KxXI2xpfA@Mac.home>
Date: Tue, 11 Feb 2025 21:34:23 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Vlastimil Babka <vbabka@...e.cz>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Frederic Weisbecker <frederic@...nel.org>,
	Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
	Uladzislau Rezki <urezki@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the slab tree with the rcu tree

Hi Stephen,

On Wed, Feb 12, 2025 at 03:09:41PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the slab tree got a conflict in:
> 
>   kernel/rcu/tiny.c
> 
> between commits:
> 
>   84ae91018af5 ("rcutorture: Include grace-period sequence numbers in failure/close-call")
>   2db7ab8c1086 ("rcutorture: Expand failure/close-call grace-period output")
>   7acc2d90151f ("rcutorture: Make cur_ops->format_gp_seqs take buffer length")
> 
> from the rcu tree and commit:
> 
>   b14ff274e8aa ("slab, rcu: move TINY_RCU variant of kvfree_rcu() to SLAB")
> 
> from the slab tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Thanks for reporting this, the below resolution looks good to me, I also
created a branch recording this:

	git://git.kernel.org/pub/scm/linux/kernel/git/rcu/linux.git merge/rcu-vs-slab.2025.02.11a

Regards,
Boqun

> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc kernel/rcu/tiny.c
> index 8a52aca686a5,7a34a99d4664..000000000000
> --- a/kernel/rcu/tiny.c
> +++ b/kernel/rcu/tiny.c
> @@@ -246,31 -232,6 +232,20 @@@ bool poll_state_synchronize_rcu(unsigne
>   }
>   EXPORT_SYMBOL_GPL(poll_state_synchronize_rcu);
>   
> - #ifdef CONFIG_KASAN_GENERIC
> - void kvfree_call_rcu(struct rcu_head *head, void *ptr)
> - {
> - 	if (head)
> - 		kasan_record_aux_stack(ptr);
> - 
> - 	__kvfree_call_rcu(head, ptr);
> - }
> - EXPORT_SYMBOL_GPL(kvfree_call_rcu);
> - #endif
> - 
>  +#if IS_ENABLED(CONFIG_RCU_TORTURE_TEST)
>  +unsigned long long rcutorture_gather_gp_seqs(void)
>  +{
>  +	return READ_ONCE(rcu_ctrlblk.gp_seq) & 0xffffULL;
>  +}
>  +EXPORT_SYMBOL_GPL(rcutorture_gather_gp_seqs);
>  +
>  +void rcutorture_format_gp_seqs(unsigned long long seqs, char *cp, size_t len)
>  +{
>  +	snprintf(cp, len, "g%04llx", seqs & 0xffffULL);
>  +}
>  +EXPORT_SYMBOL_GPL(rcutorture_format_gp_seqs);
>  +#endif
>  +
>   void __init rcu_init(void)
>   {
>   	open_softirq(RCU_SOFTIRQ, rcu_process_callbacks);