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]
Date:	Mon, 1 Jan 2007 05:27:10 -0500 (EST)
From:	"Robert P. J. Day" <rpjday@...dspring.com>
To:	Arjan van de Ven <arjan@...radead.org>
cc:	Folkert van Heusden <folkert@...heusden.com>,
	Paul Mundt <lethal@...ux-sh.org>,
	Denis Vlasenko <vda.linux@...glemail.com>,
	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: replace "memset(...,0,PAGE_SIZE)" calls with "clear_page()"?

On Mon, 1 Jan 2007, Arjan van de Ven wrote:

> >   Given the above, some basic suggestions for page-based memory management:
> >
> >  (a) If you need to allocate or free a single page, use the single page
> >      version of the routine/macro, rather than calling the multi-page
> >      version with an order value of zero, such as:
> >
> > 	alloc_pages(gfp_mask, 0);	/* no */
> > 	alloc_page(gfp_mask);		/* better */
> >
> >  (b) If you need to allocate a single zeroed page by logical address,
> >      use get_zeroed_page(), rather than __get_free_page() followed
> >      by a call to memset() to clear that page.
>
> both look good... I'd be in favor of this. Maybe also add a part
> about using GFP_KERNEL whenever possible, GFP_NOFS from filesystem
> writeout code and GFP_NOIO from block writeout code (and never doing
> in_interrupt()?GFP_ATOMIC:GFP_KERNEL !)

it strikes me that that latter part is starting to go beyond the scope
of simple coding style aesthetics and getting into actual coding
distinctions.  would that really be appropriate for the CodingStyle
doc?  i'm just asking.

> >  (c) If you need to specifically allocate some DMA pages, use the
> >      __get_dma_pages() macro, as in:
> >
> > 	__get_free_pages(GFP_KERNEL|GFP_DMA, order)	/* no */
> > 	__get_dma_pages(GFP_KERNEL, order)		/* better */
>
> this.. does not really. GFP_DMA is an ancient artifact from the ISA
> days. Better to describe the dma mapping interface (well give a
> pointer to the doc that already exists about that), that one is
> REALLY for allocating dma pages in this century.

ok, i was just trying to make the calls consistent based on what i
could see in the current source code.  i'm still reviewing the
material on DMA -- feel free to suggest better wording.

rday

p.s.  what DMA doc are you referring to above?  DMA-mapping.txt?
-
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