Messages in this thread | | | Date | Fri, 29 Mar 2024 13:42:27 -0700 | Subject | Re: [PATCH] swiotlb: Do not set total_used to 0 in swiotlb_create_debugfs_files() | From | Easwar Hariharan <> |
| |
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@linux.microsoft.com>; hch@lst.de; >> m.szyprowski@samsung.com; robin.murphy@arm.com; >> zhangpeng362@huawei.com; iommu@lists.linux.dev; >> mhklinux@outlook.com >> Cc: linux-kernel@vger.kernel.org; stable@vger.kernel.org >> Subject: RE: [PATCH] swiotlb: Do not set total_used to 0 in >> swiotlb_create_debugfs_files() >> >>> From: Easwar Hariharan <eahariha@linux.microsoft.com> >>> 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
| |