linux-kernel - Re: [PATCH v5 07/17] dma-mapping: Implement link/unlink ranges API

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] [day] [month] [year] [list]

Message-Id: <45eee716-83fd-4b15-ae11-2414aa119db3@app.fastmail.com>
Date: Thu, 16 Jan 2025 23:00:14 +0200
From: "Leon Romanovsky" <leon@...nel.org>
To: "Jason Gunthorpe" <jgg@...pe.ca>
Cc: "Robin Murphy" <robin.murphy@....com>, "Jens Axboe" <axboe@...nel.dk>,
 "Joerg Roedel" <joro@...tes.org>, "Will Deacon" <will@...nel.org>,
 "Christoph Hellwig" <hch@....de>, "Sagi Grimberg" <sagi@...mberg.me>,
 "Keith Busch" <kbusch@...nel.org>, "Bjorn Helgaas" <bhelgaas@...gle.com>,
 "Logan Gunthorpe" <logang@...tatee.com>,
 "Yishai Hadas" <yishaih@...dia.com>,
 "Shameer Kolothum" <shameerali.kolothum.thodi@...wei.com>,
 "Kevin Tian" <kevin.tian@...el.com>,
 "Alex Williamson" <alex.williamson@...hat.com>,
 "Marek Szyprowski" <m.szyprowski@...sung.com>,
 Jérôme Glisse <jglisse@...hat.com>,
 "Andrew Morton" <akpm@...ux-foundation.org>,
 "Jonathan Corbet" <corbet@....net>, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
 linux-rdma@...r.kernel.org, iommu@...ts.linux.dev,
 linux-nvme@...ts.infradead.org, linux-pci@...r.kernel.org,
 kvm@...r.kernel.org, linux-mm@...ck.org,
 "Randy Dunlap" <rdunlap@...radead.org>
Subject: Re: [PATCH v5 07/17] dma-mapping: Implement link/unlink ranges API



On Thu, Jan 16, 2025, at 22:18, Jason Gunthorpe wrote:
> On Wed, Jan 15, 2025 at 10:33:40AM +0200, Leon Romanovsky wrote:
>> > > +	do {
>> > > +		phys_addr_t phys;
>> > > +		size_t len;
>> > > +
>> > > +		phys = iommu_iova_to_phys(domain, addr);
>> > > +		if (WARN_ON(!phys))
>> > > +			continue;
>> > 
>> > Infinite WARN_ON loop, nice.
>> 
>> No problem, will change it to WARN_ON_ONCE.
>
> I think the other point is that the addr doesn't increase, so this
> loop will lock up.

Yes, this is what I planned to do.

>
> Possibly just do return? I suppose something is hopelessly corrupted
> if we ever hit this..
>
> Jason