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: <20240129184255.GA12631@willie-the-truck>
Date: Mon, 29 Jan 2024 18:42:55 +0000
From: Will Deacon <will@...nel.org>
To: Petr Tesařík <petr@...arici.cz>
Cc: linux-kernel@...r.kernel.org, kernel-team@...roid.com,
	iommu@...ts.linux.dev, Christoph Hellwig <hch@....de>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Robin Murphy <robin.murphy@....com>,
	Petr Tesarik <petr.tesarik1@...wei-partners.com>,
	Dexuan Cui <decui@...rosoft.com>
Subject: Re: [PATCH 0/2] Fix double allocation in swiotlb_alloc()

On Fri, Jan 26, 2024 at 05:20:59PM +0100, Petr Tesařík wrote:
> On Fri, 26 Jan 2024 15:19:54 +0000
> Will Deacon <will@...nel.org> wrote:
> 
> > Hi folks,
> > 
> > These two patches fix a nasty double allocation problem in swiotlb_alloc()
> > and add a diagnostic to help catch any similar issues in future. This was
> > a royal pain to track down and I've had to make a bit of a leap at the
> > correct alignment semantics (i.e. iotlb_align_mask vs alloc_align_mask).
> 
> Welcome to the club. I believe you had to re-discover what I described here:
> 
>   https://lore.kernel.org/linux-iommu/20231108101347.77cab795@meshulam.tesarici.cz/

Lucky me...

> The relevant part would be this:
> 
>   To sum it up, there are two types of alignment:
> 
>   1. specified by a device's min_align_mask; this says how many low
>      bits of a buffer's physical address must be preserved,
> 
>   2. specified by allocation size and/or the alignment parameter;
>      this says how many low bits in the first IO TLB slot's physical
>      address must be zero.  
> 
> Fix for that has been sitting on my TODO list for too long. :-(

FWIW, it did _used_ to work (or appear to work), so it would be good to
at least get it back to the old behaviour if nothing else.

Anyway, cheers for reviewing the patches. I'll go through your comments
now...

Will

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ