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: <20091217170743.GA10431@infradead.org>
Date:	Thu, 17 Dec 2009 12:07:44 -0500
From:	Christoph Hellwig <hch@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	tytso@....edu, Kyle McMartin <kyle@...artin.ca>,
	linux-parisc@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	James.Bottomley@...e.de, hch@...radead.org,
	linux-arch@...r.kernel.org, Jens Axboe <jens.axboe@...cle.com>
Subject: Re: [git patches] xfs and block fixes for virtually indexed arches

On Thu, Dec 17, 2009 at 08:46:33AM -0800, Linus Torvalds wrote:
> The whole "vmalloc is special" has always been true. If you want to 
> treat vmalloc as normal memory, you need to look up the pages yourself. We 
> have helpers for that (including helpers that populate vmalloc space from 
> a page array to begin with - so you can _start_ from some array of pages 
> and then lay them out virtually if you want to have a convenient CPU 
> access to the array).

Which is exactly what the XFS code does.  Pages are allocated manually
and we store pointers to the page struct that later get added to the
bio.  But we access them through vmap (which I added exactly for this
reason back in 2002) for kernel accesses.  On all architectures with
sane caches things just work, but for parisc, arm and friends that have
virtually indexed caches we need to make sure to flush caches for this
different access.  The vmalloc linear address is not used for I/O
everywhere.

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