linux-kernel - Re: [PATCH 5.10 392/530] iommu/vt-d: Preset Access/Dirty bits for IOVA over FL

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <YKHZ4AEUkXEqkFNW@sashalap>
Date:   Sun, 16 May 2021 22:50:08 -0400
From:   Sasha Levin <sashal@...nel.org>
To:     Lu Baolu <baolu.lu@...ux.intel.com>
Cc:     Wolfgang Müller <wolf@...ole.systems>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Ashok Raj <ashok.raj@...el.com>, Joerg Roedel <jroedel@...e.de>
Subject: Re: [PATCH 5.10 392/530] iommu/vt-d: Preset Access/Dirty bits for
 IOVA over FL

On Mon, May 17, 2021 at 10:38:42AM +0800, Lu Baolu wrote:
>Hi Wolfgang,
>
>On 5/15/21 9:28 PM, Wolfgang Müller wrote:
>>Hi!
>>
>>First of all, apologies if this is the wrong place to post a problem
>>report. I figured since I was going to reference a particular commit
>>anyway I might as well reply to the patch series that (seemed to have)
>>introduced the problem.
>>
>>>From: Lu Baolu <baolu.lu@...ux.intel.com>
>>>
>>>[ Upstream commit a8ce9ebbecdfda3322bbcece6b3b25888217f8e3 ]
>>>
>>>The Access/Dirty bits in the first level page table entry will be set
>>>whenever a page table entry was used for address translation or write
>>>permission was successfully translated. This is always true when using
>>>the first-level page table for kernel IOVA. Instead of wasting hardware
>>>cycles to update the certain bits, it's better to set them up at the
>>>beginning.
>>
>>This commit seems to trigger a kernel panic very early in boot for me in
>>5.10.37 (36 is fine):
>
>It seems due to the back-ported patch:
>
>-	if (!sg) {
>-		sg_res = nr_pages;
>-		pteval = ((phys_addr_t)phys_pfn << VTD_PAGE_SHIFT) | attr;
>+		if (domain->domain.type == IOMMU_DOMAIN_DMA) {
>+			attr |= DMA_FL_PTE_ACCESS;
>+			if (prot & DMA_PTE_WRITE)
>+				attr |= DMA_FL_PTE_DIRTY;
>+		}
> 	}
>
>+	pteval = ((phys_addr_t)phys_pfn << VTD_PAGE_SHIFT) | attr;
>
>Greg, do you want me to rework this patch, or submit an incremental fix?

Could you send a reworked patch please?

-- 
Thanks,
Sasha