linux-next: manual merge of the security tree with the mm tree

Stephen Rothwell posted 1 patch 2 months, 2 weeks ago
There is a newer version of this series
linux-next: manual merge of the security tree with the mm tree
Posted by Stephen Rothwell 2 months, 2 weeks ago
Hi all,

Today's linux-next merge of the security tree got conflicts in:

  include/linux/lsm_hooks.h
  security/security.c

between commit:

  3346ada04cf5 ("bcachefs: do not use PF_MEMALLOC_NORECLAIM")

from the mm-unstable branch of the mm tree and commit:

  711f5c5ce6c2 ("lsm: cleanup lsm_hooks.h")

from the security tree.

I fixed it up (I used the latter version ofinclude/linux/lsm_hooks.h
and 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.

-- 
Cheers,
Stephen Rothwell

diff --cc security/security.c
index 3581262da5ee,4564a0a1e4ef..000000000000
--- a/security/security.c
+++ b/security/security.c
@@@ -660,7 -745,7 +745,7 @@@ static int lsm_file_alloc(struct file *
   *
   * Returns 0, or -ENOMEM if memory can't be allocated.
   */
- int lsm_inode_alloc(struct inode *inode, gfp_t gfp)
 -static int lsm_inode_alloc(struct inode *inode)
++static int lsm_inode_alloc(struct inode *inode, gfp_t gfp)
  {
  	if (!lsm_inode_cache) {
  		inode->i_security = NULL;
Re: linux-next: manual merge of the security tree with the mm tree
Posted by Stephen Rothwell 2 months, 2 weeks ago
Hi all,

On Wed, 11 Sep 2024 14:28:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the security tree got conflicts in:
> 
>   include/linux/lsm_hooks.h
>   security/security.c
> 
> between commit:
> 
>   3346ada04cf5 ("bcachefs: do not use PF_MEMALLOC_NORECLAIM")
> 
> from the mm-unstable branch of the mm tree and commit:
> 
>   711f5c5ce6c2 ("lsm: cleanup lsm_hooks.h")
> 
> from the security tree.
> 
> I fixed it up (I used the latter version ofinclude/linux/lsm_hooks.h
> and 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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc security/security.c
> index 3581262da5ee,4564a0a1e4ef..000000000000
> --- a/security/security.c
> +++ b/security/security.c
> @@@ -660,7 -745,7 +745,7 @@@ static int lsm_file_alloc(struct file *
>    *
>    * Returns 0, or -ENOMEM if memory can't be allocated.
>    */
> - int lsm_inode_alloc(struct inode *inode, gfp_t gfp)
>  -static int lsm_inode_alloc(struct inode *inode)
> ++static int lsm_inode_alloc(struct inode *inode, gfp_t gfp)
>   {
>   	if (!lsm_inode_cache) {
>   		inode->i_security = NULL;

This is now a conflict between the mm tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell
Re: linux-next: manual merge of the security tree with the mm tree
Posted by Michal Hocko 2 months, 1 week ago
On Tue 17-09-24 09:30:48, Stephen Rothwell wrote:
> Hi all,
> 
> On Wed, 11 Sep 2024 14:28:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the security tree got conflicts in:
> > 
> >   include/linux/lsm_hooks.h
> >   security/security.c
> > 
> > between commit:
> > 
> >   3346ada04cf5 ("bcachefs: do not use PF_MEMALLOC_NORECLAIM")
> > 
> > from the mm-unstable branch of the mm tree and commit:
> > 
> >   711f5c5ce6c2 ("lsm: cleanup lsm_hooks.h")
> > 
> > from the security tree.
> > 
> > I fixed it up (I used the latter version ofinclude/linux/lsm_hooks.h
> > and 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.
> > 
> > -- 
> > Cheers,
> > Stephen Rothwell
> > 
> > diff --cc security/security.c
> > index 3581262da5ee,4564a0a1e4ef..000000000000
> > --- a/security/security.c
> > +++ b/security/security.c
> > @@@ -660,7 -745,7 +745,7 @@@ static int lsm_file_alloc(struct file *
> >    *
> >    * Returns 0, or -ENOMEM if memory can't be allocated.
> >    */
> > - int lsm_inode_alloc(struct inode *inode, gfp_t gfp)
> >  -static int lsm_inode_alloc(struct inode *inode)
> > ++static int lsm_inode_alloc(struct inode *inode, gfp_t gfp)
> >   {
> >   	if (!lsm_inode_cache) {
> >   		inode->i_security = NULL;
> 
> This is now a conflict between the mm tree and Linus' tree.

Andrew said he would drop the mm patches and I will resubmit when merge
window closes.


-- 
Michal Hocko
SUSE Labs
Re: linux-next: manual merge of the security tree with the mm tree
Posted by Stephen Rothwell 2 months, 1 week ago
Hi Michal,

On Tue, 17 Sep 2024 09:51:05 +0200 Michal Hocko <mhocko@suse.com> wrote:
>
> On Tue 17-09-24 09:30:48, Stephen Rothwell wrote:
> > 
> > On Wed, 11 Sep 2024 14:28:22 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> > >
> > > Today's linux-next merge of the security tree got conflicts in:
> > > 
> > >   include/linux/lsm_hooks.h
> > >   security/security.c
> > > 
> > > between commit:
> > > 
> > >   3346ada04cf5 ("bcachefs: do not use PF_MEMALLOC_NORECLAIM")
> > > 
> > > from the mm-unstable branch of the mm tree and commit:
> > > 
> > >   711f5c5ce6c2 ("lsm: cleanup lsm_hooks.h")
> > > 
> > > from the security tree.
> > > 
> > > I fixed it up (I used the latter version ofinclude/linux/lsm_hooks.h
> > > and 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.
> > > 
> > > -- 
> > > Cheers,
> > > Stephen Rothwell
> > > 
> > > diff --cc security/security.c
> > > index 3581262da5ee,4564a0a1e4ef..000000000000
> > > --- a/security/security.c
> > > +++ b/security/security.c
> > > @@@ -660,7 -745,7 +745,7 @@@ static int lsm_file_alloc(struct file *
> > >    *
> > >    * Returns 0, or -ENOMEM if memory can't be allocated.
> > >    */
> > > - int lsm_inode_alloc(struct inode *inode, gfp_t gfp)
> > >  -static int lsm_inode_alloc(struct inode *inode)
> > > ++static int lsm_inode_alloc(struct inode *inode, gfp_t gfp)
> > >   {
> > >   	if (!lsm_inode_cache) {
> > >   		inode->i_security = NULL;  
> > 
> > This is now a conflict between the mm tree and Linus' tree.  
> 
> Andrew said he would drop the mm patches and I will resubmit when merge
> window closes.

Yeah, I normally drop the unstable parts of the mm tree during the merge
window, so I will do that from tomorrow.

-- 
Cheers,
Stephen Rothwell
Re: linux-next: manual merge of the security tree with the mm tree
Posted by Paul Moore 2 months, 2 weeks ago
On Wed, Sep 11, 2024 at 12:28 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the security tree got conflicts in:
>
>   include/linux/lsm_hooks.h
>   security/security.c
>
> between commit:
>
>   3346ada04cf5 ("bcachefs: do not use PF_MEMALLOC_NORECLAIM")
>
> from the mm-unstable branch of the mm tree and commit:
>
>   711f5c5ce6c2 ("lsm: cleanup lsm_hooks.h")
>
> from the security tree.
>
> I fixed it up (I used the latter version ofinclude/linux/lsm_hooks.h
> and 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 Stephen.

> diff --cc security/security.c
> index 3581262da5ee,4564a0a1e4ef..000000000000
> --- a/security/security.c
> +++ b/security/security.c
> @@@ -660,7 -745,7 +745,7 @@@ static int lsm_file_alloc(struct file *
>    *
>    * Returns 0, or -ENOMEM if memory can't be allocated.
>    */
> - int lsm_inode_alloc(struct inode *inode, gfp_t gfp)
>  -static int lsm_inode_alloc(struct inode *inode)
> ++static int lsm_inode_alloc(struct inode *inode, gfp_t gfp)
>   {
>         if (!lsm_inode_cache) {
>                 inode->i_security = NULL;



-- 
paul-moore.com