On Thu, Nov 4, 2021 at 3:49 PM Xin Long [off-list ref] wrote:

On Thu, Nov 4, 2021 at 3:10 PM Paul Moore [off-list ref] wrote:

quoted

On Thu, Nov 4, 2021 at 7:02 AM David Miller [off-list ref] wrote:

quoted

From: Paul Moore <paul@paul-moore.com>
Date: Wed, 3 Nov 2021 23:17:00 -0400

quoted

While I understand you did not intend to mislead DaveM and the netdev
folks with the v2 patchset, your failure to properly manage the
patchset's metadata *did* mislead them and as a result a patchset with
serious concerns from the SELinux side was merged.  You need to revert
this patchset while we continue to discuss, develop, and verify a
proper fix that we can all agree on.  If you decide not to revert this
patchset I will work with DaveM to do it for you, and that is not
something any of us wants.

I would prefer a follow-up rathewr than a revert at this point.

Please work with Xin to come up with a fix that works for both of you.

We are working with Xin (see this thread), but you'll notice there is
still not a clear consensus on the best path forward.  The only thing
I am clear on at this point is that the current code in linux-next is
*not* something we want from a SELinux perspective.  I don't like
leaving known bad code like this in linux-next for more than a day or
two so please revert it, now.  If your policy is to merge substantive
non-network subsystem changes into the network tree without the proper
ACKs from the other subsystem maintainers, it would seem reasonable to
also be willing to revert those patches when the affected subsystems
request it.

I understand that if a patchset is being ignored you might feel the
need to act without an explicit ACK, but this particular patchset
wasn't even a day old before you merged into the netdev tree.  Not to
mention that the patchset was posted during the second day of the
merge window, a time when many maintainers are busy testing code,
sending pull requests to Linus, and generally managing merge window
fallout.

Hi Paul,

It's applied on net tree, I think mostly because I posted this on net.git tree.
Also, it's well related to the network part and affects SCTP protocol
quite a lot.

Yes, I know it is in the net tree, that is how it made its way into
linux-next.  I wouldn't have merged it yet, and if not me who else
would have merged it beside the netdev folks?

Am I misunderstanding your comment?

I wanted to post it on selinux tree: pcmoore/selinux.git, but I noticed the
commit on top is written in 2019:

commit 6e6934bae891681bc23b2536fff20e0898683f2c (HEAD -> main,
origin/main, origin/HEAD)
Author: Paul Moore [off-list ref]
Date:   Tue Sep 17 15:02:56 2019 -0400

    selinux: add a SELinux specific README.md

    DO NOT SUBMIT UPSTREAM

Then I thought this tree was no longer active, sorry about that.

Like many kernel trees the default/main branch for the SELinux tree
doesn't contain anything useful, for the SELinux tree (and audit for
that matter) it is basically just the most recent major/minor tag from
Linus tree with a single tree specific README.md file patch so that
the GitHub mirror has a pretty landing page and a canonical reference
for how the tree is maintained.

* https://github.com/SELinuxProject/selinux-kernel

The general approach to the SELinux tree, as documented in the
README.md, is to do all of the linux-next work in the selinux/next
branch with the stable work happening in the selinux/stable-X.Y
branches.

FWIW, once we've resolved things I would be happy to have the patchset
live in the SELinux tree as opposed to the netdev tree.

-- 
paul moore
www.paul-moore.com