lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yv5EA8uuhwn049jx@kudzu.us>
Date:   Thu, 18 Aug 2022 09:52:03 -0400
From:   Jon Mason <jdmason@...zu.us>
To:     Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc:     ntb@...ts.linux.dev, Bjorn Helgaas <helgaas@...nel.org>,
        Frank.Li@....com, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org, kishon@...com
Subject: Re: [PATCH] MAINTAINERS: add PCI Endpoint NTB drivers to NTB files

On Thu, Aug 18, 2022 at 11:32:30AM +0530, Manivannan Sadhasivam wrote:
> + Kishon (PCI EP Maintainer)
> 
> On Fri, Aug 12, 2022 at 03:42:05PM -0400, Jon Mason wrote:
> > The PCI Endpoint NTB drivers are under the NTB umbrella.  Add an entry
> > there to allow for notification of changes for it.
> > 
> > Signed-off-by: Jon Mason <jdmason@...zu.us>
> 
> Hi Jason,

I assume you mean me.  Odd that you got my name wrong 2 lines below it
being properly written out.

> I know that this patch is already in Linus's tree but I think this PCI Endpoint
> VNTB driver is not going in a correct path. First, Kishon is not convinced with
> the way the PCI Endpoint VNTB function driver is written currently. He prefers
> the VirtIO approach over the current one [1].

To your point, this is already in Linus' tree.  If it is not the way
people want it, patches accepted.

Kishon (in the thread) recommended doing it one way, and Frank
responded he liked doing it another.  Kishon didn't respond to that
last email.  To me, this is an acceptable technical disagreement that
can be addressed in the future and no need to prevent working patches
from being accepted.

> But while the conversation was still going on, the series got merged via NTB
> tree without any ACKs from the PCI/PCI_EP maintainers. Also, note that there
> was a patch touching the PCI Controller driver as well and that was also not
> ACKed [2].

I put the series in my ntb-next branch, which was pulled into linux-next
for roughly 3 months, and he did not object then (though likely he did
not notice).  Multiple patches were submitted to the relevant mailing
lists to address minor issues in the series (from being in linux-next)
and most/all of those hit the PCI mailing list.  Bjorn responded to
all of them saying they needed to go through the ntb tree (because of
the dependency on Frank Li's original series).  So while not an
explicit ack, it was implicit to me in that he was aware of the
series.

Given the length of time and the public work on the series, how much
longer should I have waited for a nack?

> If this trend is going to continue in the coming days, then I'm afraid that NTB
> might end up being a backdoor for PCI/PCI_EP patches :(

Completely unfounded, per Bjorn's comment on
https://lore.kernel.org/all/20220815183920.GA1960006@bhelgaas/

Thanks,
Jon

> 
> Thanks,
> Mani
> 
> [1] https://lore.kernel.org/all/20220222162355.32369-4-Frank.Li@nxp.com
> [2] https://lore.kernel.org/all/20220222162355.32369-2-Frank.Li@nxp.com
> 
> > ---
> >  MAINTAINERS | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 64379c699903..47e9f86bd712 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -14254,6 +14254,7 @@ W:	https://github.com/jonmason/ntb/wiki
> >  T:	git git://github.com/jonmason/ntb.git
> >  F:	drivers/net/ntb_netdev.c
> >  F:	drivers/ntb/
> > +F:	drivers/pci/endpoint/functions/pci-epf-*ntb.c
> >  F:	include/linux/ntb.h
> >  F:	include/linux/ntb_transport.h
> >  F:	tools/testing/selftests/ntb/
> > -- 
> > 2.30.2
> > 
> 
> -- 
> மணிவண்ணன் சதாசிவம்

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ