Date: Thu, 15 Feb 2024 10:02:53 -0500
From: Paul Moore <paul@...l-moore.com>
To: Mimi Zohar <zohar@...ux.ibm.com>
Cc: Roberto Sassu <roberto.sassu@...weicloud.com>, viro@...iv.linux.org.uk, 
	brauner@...nel.org, chuck.lever@...cle.com, jlayton@...nel.org, neilb@...e.de, 
	kolga@...app.com, Dai.Ngo@...cle.com, tom@...pey.com, jmorris@...ei.org, 
	serge@...lyn.com, dmitry.kasatkin@...il.com, eric.snowberg@...cle.com, 
	dhowells@...hat.com, jarkko@...nel.org, stephen.smalley.work@...il.com, 
	eparis@...isplace.org, casey@...aufler-ca.com, shuah@...nel.org, 
	mic@...ikod.net, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-nfs@...r.kernel.org, linux-security-module@...r.kernel.org, 
	linux-integrity@...r.kernel.org, keyrings@...r.kernel.org, 
	selinux@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	Roberto Sassu <roberto.sassu@...wei.com>, Stefan Berger <stefanb@...ux.ibm.com>
Subject: Re: [PATCH v9 12/25] security: Introduce file_post_open hook

On Thu, Feb 15, 2024 at 3:18 AM Mimi Zohar <zohar@...ux.ibm.com> wrote:
> On Wed, 2024-02-14 at 16:21 -0500, Paul Moore wrote:
> > I'm not a big fan of sharing topic branches across different subsystem
> > trees, I'd much rather just agree that one tree or another takes the
> > patchset and the others plan accordingly.
>
> Just curious why not?

I don't like the idea of cross-tree dependencies, I realize the term
"dependency" isn't a great fit for a shared topic branch - no one
needs to feel the need to explain how pulls and merges work - but it's
the conceptual idea of there being a dependency across different trees
that bothers me.  I also tend to dislike the idea that a new feature
*absolutely* *must* *be* *in* *a* *certain* *release* to the point
that we need to subvert our normal processes to make it happen.

Further, I believe that shared topic branches also discourages
cooperation and collaboration.  With a topic branch, anyone who wants
to build on top of it simply merges the topic branch and off they go;
without a shared topic branch there needs to be a discussion about
which other patches are affected, which trees are involved, who is
going to carry the patches, when are they going up to Linus, etc.  As
someone who feels strongly that we need more collaboration across
kernel subsystems, I'm always going to pick the option that involves
developers talking with other developers outside their immediate
subsystem.

Hopefully that makes sense.

> > Based on our previous
> > discussions I was under the impression that you wanted me to merge
> > this patchset into lsm/dev, but it looks like that is no longer the
> > case - which is okay by me.
>
> Paul, I don't recall saying that.  Please go ahead and upstream it.  Roberto can
> add my acks accordingly.

I believe it was during an off-list chat when we were discussing an
earlier revision of the patchset, however, as I said earlier I'm not
bothered by who merges the patches, as long as they eventually end up
in Linus' tree I'm happy :)  I *really* want to stress that last bit,
if you and Roberto have stuff queued for the IMA/EVM tree that depends
on this patchset, please go ahead and merge it; you've got my ACKs on
the patches that need them, and I believe I've reviewed most of the
other patches that don't require my ACK.  While there are a some LSM
related patches that would sit on top of this patchset, there is
nothing that is so critical that it must go in now.

If I don't hear anything back from you, I'll go ahead and merge these
into lsm/dev later tonight (probably in about ~12 hours from this
email as I have some personal commitments early this evening) just so
we can get them into linux-next as soon as possible.

-- 
paul-moore.com

Powered by blists - more mailing lists