lkml.org 
[lkml]   [2024]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] swiotlb: Do not set total_used to 0 in swiotlb_create_debugfs_files()
Date
> 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

\
 
 \ /
  Last update: 2024-05-27 16:15    [W:0.649 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site