linux-kernel - Re: Problem with DMA on x86

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: <200611211931.53802.ak@suse.de>
Date:	Tue, 21 Nov 2006 19:31:53 +0100
From:	Andi Kleen <ak@...e.de>
To:	Alan <alan@...rguk.ukuu.org.uk>
Cc:	Larry Finger <Larry.Finger@...inger.net>,
	Ray Lee <ray-lk@...rabbit.org>, linux-kernel@...r.kernel.org
Subject: Re: Problem with DMA on x86_64 with 3 GB RAM

> The documentation is correct, the implementation is broken. The
> documented behaviour works for all platforms except one whose maintainer
> has a problem with it and refuses to follow the spec.

The reference is still what i386 does.

> > Possibly, but devices that cannot address at least 4GB are normally
> > categorized as "hardware bugs" (or less polite descriptions) and those don't 
> > tend to get much airtime in documentation.
> 
> The rest of the kernel deals with hardware limitations, 

Yes, but you don't find it normally in the documentation, just
in some very dark corners of the code.

> 30bit DMA works 
> on the other platforms. This is an x86-64 platform problem. It
> misimplements the basic pci_ functionality. 

Well, if you claim that then i386 misimplements it too. 

Normally people don't hit it on 32bit because with the default user/kernel split
the limit is 900MB, which tends to be ok for most hardware. But you
could easily hit it with non standard __PAGE_OFFSET as it is now
possible to configure. 

I claim x86-64 is bug to bug compatible to i386 as far as possible. 
Since that is what drivers are typically written for it's the most
important specification.

> If it doesn't wish to 
> implement the stuff (and there btw Andi I do think your view has
> considerable merit) it should fail the set_mask requests.

If it did like you're recommending a huge number of drivers
in the tree wouldn't work anymore (just think about what pci_alloc_consistent
does) 

I have a long term master plan to merge GFP_DMA and swiotlb
into a single pool -- if that ever happens it might be possible
to fix it properly. But probably most of the drivers who needed
it wouldn't work anyways because they typically tend to forget
enough *_sync calls to make software bounce buffering work.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/