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-next>] [day] [month] [year] [list]
Message-ID: <1351194980.2432.88.camel@lorien2>
Date:	Thu, 25 Oct 2012 13:56:20 -0600
From:	Shuah Khan <shuah.khan@...com>
To:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	akpm@...ux-foundation.org, Joerg Roedel <joerg.roedel@....com>
Cc:	LKML <linux-kernel@...r.kernel.org>, shuahkhan@...il.com
Subject: dma_mapping_error() interfaces

I am working on changing dma_mapping_error() interfaces to add call to
debug_dma_mapping_error() interface. I found several dma_mapping_error()
defines in various arch specific dma-mapping.h files.

Majority of these arch specific defines look identical - simply

static inline int dma_mapping_error(struct device *dev, dma_ addr_t
dma_addr)
{
       struct dma_map_ops *dma_ops = get_dma_ops(dev);

       if (dma_ops->mapping_error)
                return dma_ops->mapping_error(dev, dma_addr);
}

Maybe a generic dma_mapping_error() could be added to augment the
existing dma_map_page() and dma_map_single() generic interfaces in
include/asm-generic/dma-mapping-common.h (Future work)

For the most part, architecture specific
dma_map_page()/dma_map_single(), dma_unmap_page() interfaces are
implemented as a pair, however arch/m68k/include/asm/dma-mapping.h is an
exception. In this case generic dma_map_page()/dma_map_single() are
used, and arch specific dma_unmap_page() is defined. Couple of issues,
unmap routines do nothing. Maybe just fine for this architecture.
However, when dma_debug is enabled, debug is lopsided and debug entries
don't get releases.

For the present here is what I am planning to do:

Change dma_mapping_error() defines to add debug_dma_mapping_error() on
architectures that use the generic dma_map_page() and dma_map_single()
interfaces from include/asm-generic/dma-mapping-common.h to debug
inconsistency between invoking dma-debug at mapping time and missing
debug at error check time. Inconsistency will result in false warnings.
The following fall into this category.

arch/alpha/include/asm/dma-mapping.h
arch/arm/include/asm/dma-mapping.h
arch/arm64/include/asm/dma-mapping.h
arch/c6x/include/asm/dma-mapping.h
arch/frv/include/asm/dma-mapping.h
arch/hexagon/include/asm/dma-mapping.h
arch/ia64/include/asm/dma-mapping.h
arch/m68k/include/asm/dma-mapping.h
arch/microblaze/include/asm/dma-mapping.h
arch/mips/include/asm/dma-mapping.h
arch/powerpc/include/asm/dma-mapping.h
arch/sh/include/asm/dma-mapping.h
arch/sparc/include/asm/dma-mapping.h

Leave dma_mapping_error() defines as is in arch header files that also
define dma_map_page() and dma_map_single() and not call
debug_dma_map_page() interface. The following fall into this category.

arch/avr32/include/asm/dma-mapping.h
arch/blackfin/include/asm/dma-mapping.h
arch/cris/include/asm/dma-mapping.h
arch/mn10300/include/asm/dma-mapping.h
arch/parisc/include/asm/dma-mapping.h
arch/xtensa/include/asm/dma-mapping.h

- There is this inconsistency now with the debug_dma_mapping_error()
interface in linux-next. If this is unacceptable, I will send a patch
that marks dma debug entries checked for mapping errors in the interim
(an easy change to initialize the flag to have been checked) while I get
the existing dma_mapping_error() interface patches done.

Comments, concerns.

Thanks,
-- Shuah



- 


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ