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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250311093011.48fa9d08@fedora>
Date: Tue, 11 Mar 2025 09:30:11 -0400
From: Luiz Capitulino <luizcap@...hat.com>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Daniel Borkmann <daniel@...earbox.net>, Alexei Starovoitov
 <ast@...nel.org>, Andrii Nakryiko <andrii@...nel.org>, Andrew Morton
 <akpm@...ux-foundation.org>, bpf <bpf@...r.kernel.org>, Networking
 <netdev@...r.kernel.org>, 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 bpf-next tree with the mm tree

On Tue, 11 Mar 2025 12:04:22 +1100
Stephen Rothwell <sfr@...b.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   mm/page_owner.c
> 
> between commit:
> 
>   a5bc091881fd ("mm: page_owner: use new iteration API")
> 
> from the mm-unstable branch of the mm tree and commit:
> 
>   8c57b687e833 ("mm, bpf: Introduce free_pages_nolock()")
> 
> from the bpf-next 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.
> 

This looks good to me:

Reviewed-by: Luiz Capitulino <luizcap@...hat.com>

> -- 
> Cheers,
> Stephen Rothwell
>
> diff --cc mm/page_owner.c
> index 849d4a471b6c,90e31d0e3ed7..000000000000
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@@ -297,11 -293,17 +297,17 @@@ void __reset_page_owner(struct page *pa
>  
>  	page_owner = get_page_owner(page_ext);
>  	alloc_handle = page_owner->handle;
> +	page_ext_put(page_ext);
>  
> - 	handle = save_stack(GFP_NOWAIT | __GFP_NOWARN);
> + 	/*
> + 	 * Do not specify GFP_NOWAIT to make gfpflags_allow_spinning() == false
> + 	 * to prevent issues in stack_depot_save().
> + 	 * This is similar to try_alloc_pages() gfp flags, but only used
> + 	 * to signal stack_depot to avoid spin_locks.
> + 	 */
> + 	handle = save_stack(__GFP_NOWARN);
>  -	__update_page_owner_free_handle(page_ext, handle, order, current->pid,
>  +	__update_page_owner_free_handle(page, handle, order, current->pid,
>   					current->tgid, free_ts_nsec);
>  -	page_ext_put(page_ext);
>   
>   	if (alloc_handle != early_handle)
>   		/*


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ