[PATCH v2 0/2] cipso: make cipso_v4_skbuff_delattr() fully remove the CIPSO options

[Paul Moore]

On Fri, Jul 26, 2024 at 8:44 AM Ondrej Mosnacek <omosnace at redhat.com> wrote:
> On Thu, Jun 20, 2024 at 4:39 PM Paul Moore <paul at paul-moore.com> wrote:
> > On Thu, Jun 20, 2024 at 6:03 AM Ondrej Mosnacek <omosnace at redhat.com> wrote:
> > > On Wed, Jun 19, 2024 at 4:46 AM Paul Moore <paul at paul-moore.com> wrote:
> > > > On June 14, 2024 11:08:41 AM Paul Moore <paul at paul-moore.com> wrote:
> > > > > On Fri, Jun 14, 2024 at 3:20 AM <patchwork-bot+netdevbpf at kernel.org> wrote:
> > > > >>
> > > > >> Hello:
> > > > >>
> > > > >> This series was applied to netdev/net.git (main)
> > > > >> by David S. Miller <davem at davemloft.net>:
> > > > >
> > > > > Welp, that was premature based on the testing requests in the other
> > > > > thread, but what's done is done.
> > > > >
> > > > > Ondrej, please accelerate the testing if possible as this patchset now
> > > > > in the netdev tree and it would be good to know if it need a fix or
> > > > > reverting before the next merge window.
> > > >
> > > > Ondrej, can you confirm that you are currently working on testing this
> > > > patchset as requested?
> >
> > [NOTE: adding SELinux list as a FYI for potential breakage in upcoming kernels]
> >
> > > Not really... I tried some more to get cloud-init to work on FreeBSD,
> > > but still no luck...
> >
> > As mentioned previously, if you aren't able to fit the testing into
> > your automated framework, you'll need to do some manual testing to
> > verify the patches.
>
> Sigh... okay, I now did test the scenario with a FreeBSD system as B
> and it passed.

Great, thank you.

> I'm not saying the concern is not credible or that (in general)
> testing this use case is not important. What I'm missing is some
> explanation/reasoning that would make me think "Oh yeah, these patches
> really could break this scenario" ...

One of the challenges to network testing is that you don't always know
how other network stack implementations are going to react when you
start getting into corner cases or lesser implemented protocols.  You
just need to test your patches to make sure nothing breaks.

> > > You see something there that I don't, and I'd like to see and
> > > understand it, too. Let's turn it from *your* concern to *our* concern
> > > (or lack of it) and then the cooperation will work better.
> >
> > It's not about you or I, it's about all of the users who rely on this
> > functionality and not wanting to break things for them.
> >
> > Test your patches Ondrej, if you don't you'll find me increasingly
> > reluctant to accept anything from you in any of the trees I look
> > after.
>
> Paul, I don't want to break the kernel, but that doesn't mean I will
> do an excessive amount of work for someone else when there doesn't
> seem to be a logical reason to do so. IMHO, just because someone
> somewhere has a special hard-to-test use case that is very important
> to them doesn't mean that it is your job as a community project
> maintainer to force other contributors to do work to defend these
> peoples' use cases.

I have a responsibility to ensure that we provide a stable, secure,
maintainable kernel that is as bug-free as we can possibly make it.
If I see a patch that I believe warrants a certain type of test to
help meet those goals I'm going to ask for that testing.  Of course
like many things, even things we believe to be very clear, there is
always going to be a chance that disagreements will happen around what
testing is relevant or necessary.  How you handle that disagreement is
a choice you will need to make for yourself, but I would encourage you
to consider that more testing is usually a good thing, and aggravating
those who review/ACK your patches is generally not a good long term
strategy.

-- 
paul-moore.com