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: <MWHPR11MB14061D584C7CC0CE3AD58F1A85BE9@MWHPR11MB1406.namprd11.prod.outlook.com>
Date:   Sun, 24 Jan 2021 11:48:29 +0000
From:   "Thokala, Srikanth" <srikanth.thokala@...el.com>
To:     Greg KH <gregkh@...uxfoundation.org>,
        "mgross@...ux.intel.com" <mgross@...ux.intel.com>
CC:     "markgross@...nel.org" <markgross@...nel.org>,
        "arnd@...db.de" <arnd@...db.de>, "bp@...e.de" <bp@...e.de>,
        "damien.lemoal@....com" <damien.lemoal@....com>,
        "dragan.cvetic@...inx.com" <dragan.cvetic@...inx.com>,
        "corbet@....net" <corbet@....net>,
        "leonard.crestez@....com" <leonard.crestez@....com>,
        "palmerdabbelt@...gle.com" <palmerdabbelt@...gle.com>,
        "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
        "peng.fan@....com" <peng.fan@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "jassisinghbrar@...il.com" <jassisinghbrar@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Derek Kiernan <derek.kiernan@...inx.com>
Subject: RE: [PATCH v2 09/34] misc: xlink-pcie: lh: Add PCIe EPF driver for
 Local Host

Hi Greg,

Thank you for the review.

> -----Original Message-----
> From: Greg KH <gregkh@...uxfoundation.org>
> Sent: Wednesday, January 20, 2021 11:28 PM
> To: mgross@...ux.intel.com
> Cc: markgross@...nel.org; arnd@...db.de; bp@...e.de;
> damien.lemoal@....com; dragan.cvetic@...inx.com; corbet@....net;
> leonard.crestez@....com; palmerdabbelt@...gle.com;
> paul.walmsley@...ive.com; peng.fan@....com; robh+dt@...nel.org;
> shawnguo@...nel.org; jassisinghbrar@...il.com; linux-
> kernel@...r.kernel.org; Thokala, Srikanth <srikanth.thokala@...el.com>;
> Derek Kiernan <derek.kiernan@...inx.com>
> Subject: Re: [PATCH v2 09/34] misc: xlink-pcie: lh: Add PCIe EPF driver
> for Local Host
> 
> On Fri, Jan 08, 2021 at 01:25:35PM -0800, mgross@...ux.intel.com wrote:
> > From: Srikanth Thokala <srikanth.thokala@...el.com>
> >
> > Add PCIe EPF driver for local host (lh) to configure BAR's and other
> > HW resources. Underlying PCIe HW controller is a Synopsys DWC PCIe core.
> >
> > Cc: Derek Kiernan <derek.kiernan@...inx.com>
> > Cc: Dragan Cvetic <dragan.cvetic@...inx.com>
> > Cc: Arnd Bergmann <arnd@...db.de>
> > Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> > Reviewed-by: Mark Gross <mgross@...ux.intel.com>
> > Signed-off-by: Srikanth Thokala <srikanth.thokala@...el.com>
> > ---
> >  MAINTAINERS                                 |   6 +
> >  drivers/misc/Kconfig                        |   1 +
> >  drivers/misc/Makefile                       |   1 +
> >  drivers/misc/xlink-pcie/Kconfig             |   9 +
> >  drivers/misc/xlink-pcie/Makefile            |   1 +
> >  drivers/misc/xlink-pcie/local_host/Makefile |   2 +
> >  drivers/misc/xlink-pcie/local_host/epf.c    | 413 ++++++++++++++++++++
> >  drivers/misc/xlink-pcie/local_host/epf.h    |  39 ++
> >  drivers/misc/xlink-pcie/local_host/xpcie.h  |  38 ++
> 
> Why such a deep directory tree?  Why is "local_host" needed?

Xlink-pcie comprises of local host (ARM CPU) and remote host (IA CPU)
variants. It is a transport layer that establishes communication between
them. 

local_host/ running on ARM CPU is based on PCI Endpoint Framework
remote_host/ running on IA CPU is a PCIe Endpoint driver

As these two variants are architecturally different, we are maintaining
under two directories.

> 
> Anyway, one thing stood out instantly:
> 
> > +static int intel_xpcie_check_bar(struct pci_epf *epf,
> > +				 struct pci_epf_bar *epf_bar,
> > +				 enum pci_barno barno,
> > +				 size_t size, u8 reserved_bar)
> > +{
> > +	if (reserved_bar & (1 << barno)) {
> > +		dev_err(&epf->dev, "BAR%d is already reserved\n", barno);
> > +		return -EFAULT;
> 
> That error is only allowed when you really have a fault from
> reading/writing to/from userspace memory.  Not this type of foolish
> programming error by the caller.

Thanks for pointing out, I will use appropriate error value to return.
 
> > +	}
> > +
> > +	if (epf_bar->size != 0 && epf_bar->size < size) {
> > +		dev_err(&epf->dev, "BAR%d fixed size is not enough\n", barno);
> > +		return -ENOMEM;
> 
> Did you really run out of memory or was the parameters sent to you
> incorrect?  -EINVAL is the properly thing here, right?

Sure, I will change to return -EINVAL.

> 
> 
> 
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int intel_xpcie_configure_bar(struct pci_epf *epf,
> > +				     const struct pci_epc_features
> > +					*epc_features)
> 
> Odd indentation :(

I had to break this as the checkpatch complained about 80-line warning.
I will fix this to have better indentation.

> 
> > +{
> > +	struct pci_epf_bar *epf_bar;
> > +	bool bar_fixed_64bit;
> > +	int ret, i;
> > +
> > +	for (i = BAR_0; i <= BAR_5; i++) {
> > +		epf_bar = &epf->bar[i];
> > +		bar_fixed_64bit = !!(epc_features->bar_fixed_64bit & (1 <<
> i));
> > +		if (bar_fixed_64bit)
> > +			epf_bar->flags |= PCI_BASE_ADDRESS_MEM_TYPE_64;
> > +		if (epc_features->bar_fixed_size[i])
> > +			epf_bar->size = epc_features->bar_fixed_size[i];
> > +
> > +		if (i == BAR_2) {
> > +			ret = intel_xpcie_check_bar(epf, epf_bar, BAR_2,
> > +						    BAR2_MIN_SIZE,
> > +						    epc_features->reserved_bar);
> > +			if (ret)
> > +				return ret;
> > +		}
> > +
> > +		if (i == BAR_4) {
> > +			ret = intel_xpcie_check_bar(epf, epf_bar, BAR_4,
> > +						    BAR4_MIN_SIZE,
> > +						    epc_features->reserved_bar);
> > +			if (ret)
> > +				return ret;
> > +		}
> 
> Why do you need to check all of this?  Where is the data coming from
> that could be incorrect?

PCI BAR attributes, as inputs, are coming from the PCIe controller driver
through PCIe End Point Framework.  These checks are required to compare the 
configuration this driver is expecting to the configuration coming from
the PCIe controller driver.

FYI, PCIe controller driver for Intel Keem Bay is currently under review:
https://lore.kernel.org/linux-pci/20210122032610.4958-1-srikanth.thokala@intel.com/

Thanks!
Srikanth

> 
> thanks,
> 
> greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ