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]

Date:	Sun, 07 Jan 2007 10:09:13 -0600
From:	James Bottomley <James.Bottomley@...elEye.com>
To:	Russell King <rmk+lkml@....linux.org.uk>
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, 2007-01-03 at 15:09 +0000, Russell King wrote:
> 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.

OK, so the bottom line we seem to have reached is that we can't manage
the user coherency in the DMA API.  Does this also mean you can't do it
for non-DMA cases (kmap_atomic would seem to be a likely problem)? in
which case the only coherency kmap would control would be kernel
coherency?

James


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