netdev - Re: [PATCH V7 9/9] PCI/P2PDMA: Add a 10-Bit Tag check in P2PDMA

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210809173113.GA2166744@bjorn-Precision-5520>
Date:   Mon, 9 Aug 2021 12:31:13 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Dongdong Liu <liudongdong3@...wei.com>
Cc:     hch@...radead.org, kw@...ux.com, logang@...tatee.com,
        leon@...nel.org, linux-pci@...r.kernel.org, rajur@...lsio.com,
        hverkuil-cisco@...all.nl, linux-media@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH V7 9/9] PCI/P2PDMA: Add a 10-Bit Tag check in P2PDMA

On Sat, Aug 07, 2021 at 03:11:34PM +0800, Dongdong Liu wrote:
> 
> On 2021/8/6 2:12, Bjorn Helgaas wrote:
> > On Wed, Aug 04, 2021 at 09:47:08PM +0800, Dongdong Liu wrote:
> > > Add a 10-Bit Tag check in the P2PDMA code to ensure that a device with
> > > 10-Bit Tag Requester doesn't interact with a device that does not
> > > support 10-BIT Tag Completer. Before that happens, the kernel should
> > > emit a warning. "echo 0 > /sys/bus/pci/devices/.../10bit_tag" to
> > > disable 10-BIT Tag Requester for PF device.
> > > "echo 0 > /sys/bus/pci/devices/.../sriov_vf_10bit_tag_ctl" to disable
> > > 10-BIT Tag Requester for VF device.
> > 
> > s/10-BIT/10-Bit/ several times.
> Will fix.
> > 
> > Add blank lines between paragraphs.
> Will fix.
> > 
> > > Signed-off-by: Dongdong Liu <liudongdong3@...wei.com>
> > > ---
> > >  drivers/pci/p2pdma.c | 40 ++++++++++++++++++++++++++++++++++++++++
> > >  1 file changed, 40 insertions(+)
> > > 
> > > diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> > > index 50cdde3..948f2be 100644
> > > --- a/drivers/pci/p2pdma.c
> > > +++ b/drivers/pci/p2pdma.c
> > > @@ -19,6 +19,7 @@
> > >  #include <linux/random.h>
> > >  #include <linux/seq_buf.h>
> > >  #include <linux/xarray.h>
> > > +#include "pci.h"
> > > 
> > >  enum pci_p2pdma_map_type {
> > >  	PCI_P2PDMA_MAP_UNKNOWN = 0,
> > > @@ -410,6 +411,41 @@ static unsigned long map_types_idx(struct pci_dev *client)
> > >  		(client->bus->number << 8) | client->devfn;
> > >  }
> > > 
> > > +static bool check_10bit_tags_vaild(struct pci_dev *a, struct pci_dev *b,
> > 
> > s/vaild/valid/
> > 
> > Or maybe s/valid/safe/ or s/valid/supported/, since "valid" isn't
> > quite the right word here.  We want to know whether the source is
> > enabled to generate 10-bit tags, and if so, whether the destination
> > can handle them.
> > 
> > "if (check_10bit_tags_valid())" does not make sense because
> > "check_10bit_tags_valid()" is not a question with a yes/no answer.
> > 
> > "10bit_tags_valid()" *might* be, because "if (10bit_tags_valid())"
> > makes sense.  But I don't think you can start with a digit.
> > 
> > Or maybe you want to invert the sense, e.g.,
> > "10bit_tags_unsupported()", since that avoids negation at the caller:
> > 
> >   if (10bit_tags_unsupported(a, b) ||
> >       10bit_tags_unsupported(b, a))
> >         map_type = PCI_P2PDMA_MAP_NOT_SUPPORTED;
> Good suggestion. add a pci_ prefix.
> 
> if (pci_10bit_tags_unsupported(a, b) ||
>     pci_10bit_tags_unsupported(b, a))
> 	map_type = PCI_P2PDMA_MAP_NOT_SUPPORTED;

This treats both directions as equally important.  I don't know P2PDMA
very well, but that doesn't seem like it would necessarily be the
case.  I would think a common case would be device A doing DMA to B,
but B *not* doing DMA to A.  So can you tell which direction you're
setting up here, and can you take advantage of any asymmetry, e.g., by
enabling 10-bit tags in the direction that supports it even if the
other direction does not?