linux-kernel - Re: [PATCH v12 5/5] iommu: Remove mode argument from iommu_set_dma

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0e477a85-db02-1513-a449-02a9fbfccdfa@huawei.com>
Date:   Mon, 14 Jun 2021 18:24:39 +0100
From:   John Garry <john.garry@...wei.com>
To:     Robin Murphy <robin.murphy@....com>, <joro@...tes.org>,
        <will@...nel.org>, <dwmw2@...radead.org>,
        <baolu.lu@...ux.intel.com>
CC:     <linux-kernel@...r.kernel.org>, <iommu@...ts.linux-foundation.org>,
        <linuxarm@...wei.com>, <thunder.leizhen@...wei.com>,
        <chenxiang66@...ilicon.com>
Subject: Re: [PATCH v12 5/5] iommu: Remove mode argument from
 iommu_set_dma_strict()

On 14/06/2021 18:19, Robin Murphy wrote:
>>> We shouldn't need to keep IOMMU_CMD_LINE_STRICT at all now, since it 
>>> was only to prevent a driver's "default lazy" setting passed in here 
>>> from downgrading an explicitly-set strict mode.
>>>
>>> With that cleaned up too,
>>>
>>
>> Patch 1/5 mentions whether the invalidation policy comes from the 
>> cmdline - similar to the default domain type print - so I was going to 
>> keep that.
> 
> Oh, silly me, I'd forgotten that already and was just looking at my 
> local tree... Let's keep it for consistency with how we report the 
> domain type then.
> 
>> And then maybe we should also set it from the deprecated x86 
>> driver-specific params.
> 
> I don't think it's worth exporting more low-level guts to allow that to 
> happen - tying in to iommu_set_dma_strict() would be too late, as 
> before. I think the separate pr_warn()s which announce the relevant 
> parameter is deprecated (but has still taken effect) should be enough.
> 

Fine, I suppose someone using a deprecated interface can't complain 
about imperfect prints.

And I'll pick up your RB tag (unless you mention otherwise).

Thanks,
John