[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17b2f95a-b6ce-47d5-a826-9cfd1ff3f419@web.de>
Date: Wed, 26 Jun 2024 16:00:40 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Gerd Bayer <gbayer@...ux.ibm.com>, Ma Ke <make24@...as.ac.cn>,
linux-s390@...r.kernel.org, netdev@...r.kernel.org,
Alexander Gordeev <agordeev@...ux.ibm.com>,
Alexandra Winter <wintera@...ux.ibm.com>,
Christian Bornträger <borntraeger@...ux.ibm.com>,
"David S. Miller" <davem@...emloft.net>, Heiko Carstens <hca@...ux.ibm.com>,
Niklas Schnelle <schnelle@...ux.ibm.com>, Stefan Raspl
<raspl@...ux.ibm.com>, Sven Schnelle <svens@...ux.ibm.com>,
Thorsten Winkler <twinkler@...ux.ibm.com>,
Wenjia Zhang <wenjia@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH] s390/ism: Add check for dma_set_max_seg_size in
ism_probe()
> > As the possible failure of the dma_set_max_seg_size(), we should
> > better check the return value of the dma_set_max_seg_size().
>
> I think formally you're correct. dma_set_max_seg_size() could return an
> error if dev->dma_parms was not present.
>
> However, since ISM devices are PCI attached (and will remain PCI
> attached I believe) we can take the existance of dev->dma_parms for
> granted since pci_device_add() (in drivers/pci/probe.c) will make that
> point to the pci_dev's dma_parms for every PCI device.
>
> So I'm not sure how important this fix is.
Another function call can fail eventually.
dma_set_seg_boundary()
https://elixir.bootlin.com/linux/v6.10-rc5/source/include/linux/dma-mapping.h#L562
Will it become relevant to complete the error detection
and corresponding exception handling any further?
Regards,
Markus
Powered by blists - more mailing lists