lkml.org 
[lkml]   [2022]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 01/12] iommu/vt-d: Use iommu_get_domain_for_dev() in debugfs
    From
    On 2022/5/31 21:10, Jason Gunthorpe wrote:
    > On Tue, May 31, 2022 at 11:02:06AM +0800, Baolu Lu wrote:
    >
    >> For case 2, it is a bit weird. I tried to add a rwsem lock to make the
    >> iommu_unmap() and dumping tables in debugfs exclusive. This does not
    >> work because debugfs may depend on the DMA of the devices to work. It
    >> seems that what we can do is to allow this race, but when we traverse
    >> the page table in debugfs, we will check the validity of the physical
    >> address retrieved from the page table entry. Then, the worst case is to
    >> print some useless information.
    >
    > Sounds horrible, don't you have locking around the IOPTEs of some
    > kind? How does updating them work reliably?

    There's no locking around updating the IOPTEs. The basic assumption is
    that at any time, there's only a single thread manipulating the mappings
    of the range specified in iommu_map/unmap() APIs. Therefore, the race
    only exists when multiple ranges share some high-level IOPTEs. The IOMMU
    driver updates those IOPTEs using the compare-and-exchange atomic
    operation.

    >
    > It is just debugfs, so maybe it is not the end of the world, but
    > still..

    Fair enough. I think this is somewhat similar to that IOMMU hardware can
    traverse the page table at any time without considering when the CPUs
    update it. The IOMMU hardware will generate faults when it encounters
    failure during the traverse of page table. Similarly, perhaps debugfs
    could dump all-ones for an invalid IOPTE?

    Best regards,
    baolu

    \
     
     \ /
      Last update: 2022-05-31 16:12    [W:2.075 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site