linux-kernel - Re: [PATCH 2/3] dma-mapping: don't return errors from dma_set_seg

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: <d54f486d-36ae-4668-b314-27137bc4d832@arm.com>
Date: Thu, 1 Aug 2024 13:36:01 +0100
From: Robin Murphy <robin.murphy@....com>
To: Marek Szyprowski <m.szyprowski@...sung.com>,
 Christoph Hellwig <hch@....de>
Cc: iommu@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] dma-mapping: don't return errors from
 dma_set_seg_boundary

On 01/08/2024 1:00 pm, Marek Szyprowski wrote:
> On 23.07.2024 02:05, Christoph Hellwig wrote:
>> If dev->dma_parms is not allocate that indicates a grave bug in the
>> implementation of a DMA-capable bus.  There isn't much the driver can
>> do in terms of error handling, so just warn and continue as DMA
>> operations will fail anyway.
>>
>> Signed-off-by: Christoph Hellwig <hch@....de>
> 
> What about devices on platform or usb bus and subsystems calling this
> unconditionally, like scsi_init_limits()? With today's linux-next I got
> a bunch of warnings from this call for various USB storage devices.
> Before this patch, the errors from dma_set_seg_boundary() were silently
> ignored.

Maybe we could suppress the warning if the value being set is equal to 
the default, but the real point is that DMA-capable buses should be 
providing dma_parms, while non-DMA-capable devices have no business 
being here at all - if the caller isn't going to get the 
restriction/relaxation they requested, and that's not a problem, then 
why are they requesting it in the first place?

I guess I assumed that the old block layer bodges in this area had been 
cleaned up already - perhaps it *is* high time for whatever's left to 
grow a proper understanding of whether a block device actually does its 
own DMA or not.

Thanks,
Robin.

>> ---
>>    include/linux/dma-mapping.h | 10 ++++------
>>    1 file changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
>> index cfd6bafec3f944..6bd1333dbacb9b 100644
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -559,13 +559,11 @@ static inline unsigned long dma_get_seg_boundary_nr_pages(struct device *dev,
>>    	return (dma_get_seg_boundary(dev) >> page_shift) + 1;
>>    }
>>    
>> -static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask)
>> +static inline void dma_set_seg_boundary(struct device *dev, unsigned long mask)
>>    {
>> -	if (dev->dma_parms) {
>> -		dev->dma_parms->segment_boundary_mask = mask;
>> -		return 0;
>> -	}
>> -	return -EIO;
>> +	if (WARN_ON_ONCE(!dev->dma_parms))
>> +		return;
>> +	dev->dma_parms->segment_boundary_mask = mask;
>>    }
>>    
>>    static inline unsigned int dma_get_min_align_mask(struct device *dev)
> 
> Best regards