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: <c38b7123-f76d-d4b6-f36e-a385d5ea0cf5@linux.intel.com>
Date:   Sun, 3 Jul 2022 12:34:29 +0800
From:   Baolu Lu <baolu.lu@...ux.intel.com>
To:     "Tian, Kevin" <kevin.tian@...el.com>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>
Cc:     baolu.lu@...ux.intel.com, "Raj, Ashok" <ashok.raj@...el.com>,
        "Liu, Yi L" <yi.l.liu@...el.com>,
        "Pan, Jacob jun" <jacob.jun.pan@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 02/11] iommu/vt-d: Remove clearing translation data in
 disable_dmar_iommu()

On 2022/7/1 15:58, Tian, Kevin wrote:
>> From: Lu Baolu <baolu.lu@...ux.intel.com> Sent: Wednesday, June 29,
>> 2022 3:47 PM
>> 
>> The disable_dmar_iommu() is called when IOMMU initialization fails
>> or the IOMMU is hot-removed from the system. In both cases, there
>> is no need to clear the IOMMU translation data structures for
>> devices.
>> 
>> On the initialization path, the device probing only happens after
>> the IOMMU is initialized successfully, hence there're no
>> translation data structures.
>> 
>> On the hot-remove path, there is no real use case where the IOMMU
>> is hot-removed, but the devices that it manages are still alive in
>> the system. The translation data structures were torn down during
>> device release, hence there's no need to repeat it in IOMMU
>> hot-remove path either. This removes the unnecessary code and only
>> leaves a check.
>> 
>> Signed-off-by: Lu Baolu <baolu.lu@...ux.intel.com>
> 
> You probably overlooked my last comment on kexec:
> 
> https://lore.kernel.org/lkml/BL1PR11MB52711A71AD9F11B7AE42694C8CAC9@BL1PR11MB5271.namprd11.prod.outlook.com/
>
>  I think my question is still not answered.

Sorry! I did overlook that comment. I can see your points now, though it
seems to be irrelevant to the problems that this series tries to solve.

The failure path of copying table still needs some improvement. At least
the pages allocated for root/context tables should be freed in the
failure path. Even worse, the software occupied a bit of page table
entry which is feasible for the old ECS, but not work for the new
scalable mode anymore.

All these problems deserve a separate series. We could address your
concerns there. Does this work for you?

Best regards,
baolu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ