linux-kernel - Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again

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: <20070103150912.GB25434@flint.arm.linux.org.uk>
Date:	Wed, 3 Jan 2007 15:09:12 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	James Bottomley <James.Bottomley@...elEye.com>
Cc:	David Miller <davem@...emloft.net>, miklos@...redi.hu,
	arjan@...radead.org, torvalds@...l.org,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	akpm@...l.org
Subject: Re: fuse, get_user_pages, flush_anon_page, aliasing caches and all that again

On Wed, Jan 03, 2007 at 09:00:58AM -0600, James Bottomley wrote:
> However, I was wondering if there might be a different way around this.
> We can't really walk all the user mappings because of the locks, but
> could we store the user flush hints in the page (or a related
> structure)?  On parisc we don't care about the process id (called space
> in our architecture) because we've turned off the pieces of the cache
> that match on space id.  Thus, all we care about is flushing with the
> physical address and virtual address (and only about 10 bits of this are
> significant for matching).  We go to great lengths to ensure that every
> mapping in user space all has the same 10 bits of virtual address, so if
> we just new what they were we could flush the whole of the user spaces
> for the page without having to walk any VMA lists.  Could arm do this as
> well?

I don't think so.  The organisation of the VIVT caches in terms of
how the set index and tag correspond with virtual addresses are hardly
ever documented.  When they are, they don't appear to lend themselves
to such an approach.  For example,  Xscale has:

 tag:       virtual address b31-10
 set index: b9-5

and there's 32 ways per set.  So there's nothing to be gained from
controlling the virtual address which individual mappings end up at
in this case.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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/