| 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
| ||
|
Message-ID: <ZSbtMO8AWLx29RBS@x130>
Date: Wed, 11 Oct 2023 11:45:04 -0700
From: Saeed Mahameed <saeed@...nel.org>
To: Leon Romanovsky <leon@...nel.org>
Cc: Niklas Schnelle <schnelle@...ux.ibm.com>,
Saeed Mahameed <saeedm@...dia.com>, Jason Gunthorpe <jgg@...pe.ca>,
Matthew Rosato <mjrosato@...ux.ibm.com>,
Joerg Roedel <joro@...tes.org>, Robin Murphy <robin.murphy@....com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Shay Drory <shayd@...dia.com>, Moshe Shemesh <moshe@...dia.com>,
Heiko Carstens <hca@...ux.ibm.com>,
Alexander Gordeev <agordeev@...ux.ibm.com>,
linux-s390@...r.kernel.org, netdev@...r.kernel.org,
linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net] net/mlx5: fix calling mlx5_cmd_init() before DMA
mask is set
On 29 Sep 13:31, Leon Romanovsky wrote:
>On Fri, Sep 29, 2023 at 11:40:49AM +0200, Niklas Schnelle wrote:
>> On Thu, 2023-09-28 at 20:59 +0300, Leon Romanovsky wrote:
>> > On Thu, Sep 28, 2023 at 03:55:47PM +0200, Niklas Schnelle wrote:
>> > > Since commit 06cd555f73ca ("net/mlx5: split mlx5_cmd_init() to probe and
>> > > reload routines") mlx5_cmd_init() is called in mlx5_mdev_init() which is
>> > > called in probe_one() before mlx5_pci_init(). This is a problem because
>> > > mlx5_pci_init() is where the DMA and coherent mask is set but
>> > > mlx5_cmd_init() already does a dma_alloc_coherent(). Thus a DMA
>> > > allocation is done during probe before the correct mask is set. This
>> > > causes probe to fail initialization of the cmdif SW structs on s390x
>> > > after that is converted to the common dma-iommu code. This is because on
>> > > s390x DMA addresses below 4 GiB are reserved on current machines and
>> > > unlike the old s390x specific DMA API implementation common code
>> > > enforces DMA masks. Fix this by switching the order of the
>> > > mlx5_mdev_init() and mlx5_pci_init() in probe_one().
>> > >
>> > > Link: https://lore.kernel.org/linux-iommu/cfc9e9128ed5571d2e36421e347301057662a09e.camel@linux.ibm.com/
>> > > Fixes: 06cd555f73ca ("net/mlx5: split mlx5_cmd_init() to probe and reload routines")
>> > > Signed-off-by: Niklas Schnelle <schnelle@...ux.ibm.com>
>> > > ---
>> > > Note: I ran into this while testing the linked series for converting
>> > > s390x to use dma-iommu. The existing s390x specific DMA API
>> > > implementation doesn't respect DMA masks and is thus not affected
>> > > despite of course also only supporting DMA addresses above 4 GiB.
>> > > That said ConnectX VFs are the primary users of native PCI on s390x and
>> > > we'd really like to get the DMA API conversion into v6.7 so this has
>> > > high priority for us.
>> > > ---
>> > > drivers/net/ethernet/mellanox/mlx5/core/main.c | 12 ++++++------
>> > > 1 file changed, 6 insertions(+), 6 deletions(-)
>> > >
>> > > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>> > > index 15561965d2af..06744dedd928 100644
>> > > --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
>> > > +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>> > > @@ -1908,10 +1908,6 @@ static int probe_one(struct pci_dev *pdev, const struct pci_device_id *id)
>> > > goto adev_init_err;
>> > > }
>> > >
>> > > - err = mlx5_mdev_init(dev, prof_sel);
>> > > - if (err)
>> > > - goto mdev_init_err;
>> > > -
>> > > err = mlx5_pci_init(dev, pdev, id);
>> > > if (err) {
>> > > mlx5_core_err(dev, "mlx5_pci_init failed with error code %d\n",
>> > > @@ -1919,6 +1915,10 @@ static int probe_one(struct pci_dev *pdev, const struct pci_device_id *id)
>> > > goto pci_init_err;
>> > > }
>> > >
>> > > + err = mlx5_mdev_init(dev, prof_sel);
>> > > + if (err)
>> > > + goto mdev_init_err;
>> > > +
>> >
>> > I had something different in mind as I'm worry that call to pci_enable_device()
>> > in mlx5_pci_init() before we finished FW command interface initialization is a bit
>> > premature.
>> >
>> > What about the following patch?
>> >
>> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>> > index 15561965d2af..31f1d701116a 100644
>> > --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
>> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>> > @@ -905,12 +905,6 @@ static int mlx5_pci_init(struct mlx5_core_dev *dev, struct pci_dev *pdev,
>> >
>> > pci_set_master(pdev);
>> >
>> > - err = set_dma_caps(pdev);
>> > - if (err) {
>> > - mlx5_core_err(dev, "Failed setting DMA capabilities mask, aborting\n");
>> > - goto err_clr_master;
>> > - }
>> > -
>> > if (pci_enable_atomic_ops_to_root(pdev, PCI_EXP_DEVCAP2_ATOMIC_COMP32) &&
>> > pci_enable_atomic_ops_to_root(pdev, PCI_EXP_DEVCAP2_ATOMIC_COMP64) &&
>> > pci_enable_atomic_ops_to_root(pdev, PCI_EXP_DEVCAP2_ATOMIC_COMP128))
>> > @@ -1908,9 +1902,15 @@ static int probe_one(struct pci_dev *pdev, const struct pci_device_id *id)
>> > goto adev_init_err;
>> > }
>> >
>> > + err = set_dma_caps(pdev);
>> > + if (err) {
>> > + mlx5_core_err(dev, "Failed setting DMA capabilities mask, aborting\n");
>> > + goto dma_cap_err;
>> > + }
>> > +
>> > err = mlx5_mdev_init(dev, prof_sel);
>> > if (err)
>> > - goto mdev_init_err;
>> > + goto dma_cap_err;
>> >
>> > err = mlx5_pci_init(dev, pdev, id);
>> > if (err) {
>> > @@ -1942,7 +1942,7 @@ static int probe_one(struct pci_dev *pdev, const struct pci_device_id *id)
>> > mlx5_pci_close(dev);
>> > pci_init_err:
>> > mlx5_mdev_uninit(dev);
>> > -mdev_init_err:
>> > +dma_cap_err:
>> > mlx5_adev_idx_free(dev->priv.adev_idx);
>> > adev_init_err:
>> > mlx5_devlink_free(devlink);
>> >
>> > Thanks
>>
>> The above works too. Maybe for consistency within probe_one() it would
>> then make sense to also rename set_dma_caps() to mlx5_dma_init()?
>
>Sounds great, thanks
>
>BTW, I was informed offlist that Saeed also has fix to this issue,
>but I don't know if he wants to progress with that fix as it has wrong
>RCA in commit message and as an outcome of that much complex solution,
>which is not necessary.
>
>So I would be happy to see your patch with mlx5_dma_init().
>
>Thanks
>
Actually I prefer the internal patch, it moves the dma parts out of
mlx5_cmd_init() into mlx5_cmd_enable() which happens after dma caps are
set. since it is using the current mlx5 function structure and breakdown,
I prefer it over adding new function to the driver.
I will share the patch, I will let Niklas test it and approve it before
submission.
Thanks,
Saeed.
>
Powered by blists - more mailing lists