On 3/29/2024 1:30 PM, Dexuan Cui wrote: >> From: Dexuan Cui >> Sent: Friday, March 29, 2024 1:23 PM >> To: Easwar Hariharan <eahariha@xxxxxxxxxxxxxxxxxxx>; hch@xxxxxx; >> m.szyprowski@xxxxxxxxxxx; robin.murphy@xxxxxxx; >> zhangpeng362@xxxxxxxxxx; iommu@xxxxxxxxxxxxxxx; >> mhklinux@xxxxxxxxxxx >> Cc: linux-kernel@xxxxxxxxxxxxxxx; stable@xxxxxxxxxxxxxxx >> Subject: RE: [PATCH] swiotlb: Do not set total_used to 0 in >> swiotlb_create_debugfs_files() >> >>> From: Easwar Hariharan <eahariha@xxxxxxxxxxxxxxxxxxx> >>> Sent: Friday, March 29, 2024 12:47 PM >>> [...] >>> Sorry, I'm missing a why in this commit message. Can you say what >> happens >>> if the total_used and used_hiwater IS blindly set to 0? Is the only effect >>> the change in the readout of the swiotlb debugfs files? >>> >>> Thanks, >>> Easwar >> >> Right, when the system is not doing any I/O, the readout may >> return a huge number while it should return 0. This is the only effect. >> >> Thanks, >> Dexuan > > Let me share more details. > > kernel/dma/swiotlb.c uses inc_used_and_hiwater() and dec_used() > to do the accounting. > > The issue happens this way: > > 1. inc_used_and_hiwater() adds n to total_used. > 2. swiotlb_create_debugfs_files() sets total_used to 0. > 3. dec_used() decreases total_used by n, i.e. total_used incorrectly > becomes a negative number -n, which is a huge number since > mem_used() converts the 'long' to 'unsigned long'. > > Thanks, > Dexuan > Thanks for the detail. I only ask because the patch is marked for stable, and I was wondering if it meets the criteria. But, as you mentioned off list, two Fixes tags probably do meet the bar. Thanks, Easwar
