On Thu, Jun 20, 2024 at 6:03 AM Ondrej Mosnacek <omosnace@xxxxxxxxxx> wrote: > On Wed, Jun 19, 2024 at 4:46 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > On June 14, 2024 11:08:41 AM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > On Fri, Jun 14, 2024 at 3:20 AM <patchwork-bot+netdevbpf@xxxxxxxxxx> wrote: > > >> > > >> Hello: > > >> > > >> This series was applied to netdev/net.git (main) > > >> by David S. Miller <davem@xxxxxxxxxxxxx>: > > > > > > 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. > Anyway, I still don't see why I should waste my > time on testing this scenario, since you didn't provide any credible > hypothesis on why/what should break there. I did share my concern about changes in packet length across the network path and an uncertainty about how different clients might react. While you tested with Linux based systems, I requested that you test with at least one non-Linux client to help verify that things are handled properly. Perhaps you don't view that concern as credible, but it is something I'm worried about as a common use case is for non-Linux clients to connect over an unlabeled, single label/level network to a Linux gateway which then routes traffic over different networks, some with explicit labeling. If you don't believe that testing this is important Ondrej, trust those who have worked with a number of users who have deployed these types of systems that this is important. > Convince me that there is a > valid concern and I will be much more willing to put more effort into > it. I've shared my concerns with you, both in previous threads and now in this thread. This really shouldn't be about convincing you to do The Right Thing and verify that your patch doesn't break existing users, it should be about you wanting to do The Right Thing so your work doesn't break the kernel. > 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. > BTW, I was also surprised that David merged the patches quietly like > this. I don't know if he didn't see your comments or if he knowingly > dismissed them... I've seen DaveM do this before, but as Jakub has been the one pulling the labeled networking patches after my ACK I thought DaveM was no longer doing that type of work. My guess based on previous experience is that DaveM didn't see any comments on your latest patchset - as we were still discussing things in the previous thread - but only DaveM can comment on that, and it really isn't very important at this point. -- paul-moore.com
