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: <20081001150258.GB22031@flint.arm.linux.org.uk>
Date:	Wed, 1 Oct 2008 16:02:58 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	Nicolas Pitre <nico@....org>, lkml <linux-kernel@...r.kernel.org>
Subject: Re: wrong usage of MAX_DMA_ADDRESS in bootmem.h

On Wed, Oct 01, 2008 at 09:50:24AM -0500, Christoph Lameter wrote:
> Russell King - ARM Linux wrote:
> >> 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.

... so you didn't get my point.

> Maybe we should make these physical addresses to avoid the casts?

Finally, we agree on something.  Yes, they should be phys addresses.
But not for the sake of getting rid of casts, but because that's what
the bootmem allocator _actually_ wants to have in the first place.

And, to do this, the following are going to have to be changed:

drivers/block/floppy.c: } else if ((unsigned long)current_req->buffer < MAX_DMA_ADDRESS) {
drivers/block/floppy.c:          * Do NOT use minimum() here---MAX_DMA_ADDRESS is 64 bits wide
drivers/block/floppy.c:             (MAX_DMA_ADDRESS -
drivers/net/3c505.c:    if ((unsigned long)(target + rlen) >= MAX_DMA_ADDRESS) {
drivers/net/3c505.c:    if ((unsigned long)(skb->data + nlen) >= MAX_DMA_ADDRESS || nlen != skb->len) {
drivers/net/cs89x0.c:                   if ((unsigned long) lp->dma_buff >= MAX_DMA_ADDRESS ||
drivers/net/wan/cosa.c: if (b+len >= MAX_DMA_ADDRESS)
drivers/parport/parport_pc.c:   if (end < MAX_DMA_ADDRESS) {
drivers/scsi/BusLogic.c:        if (HostAdapter->HostAdapterBusType == BusLogic_ISA_Bus && (void *) high_memory > (void *)
drivers/scsi/BusLogic.c:        if (HostAdapter->BIOS_Address > 0 && strcmp(HostAdapter->ModelName, "BT-445S") == 0 && strc
sound/oss/dmabuf.c:                 || end_addr >= (char *) (MAX_DMA_ADDRESS)) {
sound/oss/sscape.c:                 || end_addr >= (char *) (MAX_DMA_ADDRESS)) {

which probably want to do the check in the phys address space anyway.
--
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/