linux-kernel - Re: wrong usage of MAX_DMA

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: <48E38E30.70901@linux-foundation.org>
Date:	Wed, 01 Oct 2008 09:50:24 -0500
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
CC:	Nicolas Pitre <nico@....org>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: wrong usage of MAX_DMA_ADDRESS in bootmem.h

Russell King - ARM Linux wrote:

>> Someone screwed around with the basics here. MAX_DMA_ADDRESS is no longer
>> related to MAX_DMA_PFN for the x86_32 case. What is the point of relating
>> MAX_DMA_ADDRESS to PAGE_OFFSET? Looks like we are creating more confusion
>> about the strange DMA zone.
> 
> Because it is a virtual address.  It has to be.  You're using __pa() on it,
> and __pa() ONLY takes a virtual address.

Ok. I agree you need to add a __va to it in order to convert it back later.
That was not really the point. MAX_DMA_PFN can be used as a base to calculate
MAX_DMA_ADDRESS. Both are related and currently some arches go one way and
other do vice versa. Its particularly strange that x86_32 and x86_64 go
different ways. Can we unify that to one way only and put the definition of
MAX_DMA_ADDRESS in core code?

Also as a result of the long type used for a kernel "virtual" address we have
the strange situation that all uses of MAX_DMA_ADDRESS require a cast.

>> The best would be to rename these variables to make the semantics clearer
>>
>> ZONE_DMA related variables:
>>
>> MAX_DMA_PFN -> MAX_ZONE_DMA_PFN
>> MAX_DMA_ADDRESS -> MAX_ZONE_DMA_ADDRESS
>>
>> MAX_DMA32_PFN -> MAX_ZONE_DMA32_PFN
>> MAX_DMA32_ADDRESS -> MAX_ZONE_DMA32_ADDRESS
>>
>> Then the general DMAability
>>
>> MAX_DMA_ADDRESS -> DMA_LIMIT
> 
> That's no clearer.  Are they physical addresses?  Or are they virtual
> addresses?  Can't guess that from the names.

It is clearer because the association with ZONE_DMA is in the name now. One no
longer has the impression that MAX_DMA_ADDRESS is upper bound of any DMA
transfer in the system.

Maybe we should make these physical addresses to avoid the casts? That would
avoid casts in the bootmem allocator etc etc.

--
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/