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:	Tue, 02 Jan 2007 17:34:18 -0600
From:	James Bottomley <James.Bottomley@...elEye.com>
To:	David Miller <davem@...emloft.net>
Cc:	rmk+lkml@....linux.org.uk, 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 Tue, 2007-01-02 at 15:19 -0800, David Miller wrote:
> From: James Bottomley <James.Bottomley@...elEye.com>
> Date: Tue, 02 Jan 2007 16:53:23 -0600
> 
> > OK, so lets get down to brass tacks and look at the API characteristics.
> > 
> > Some of the issues are:
> > 
> >      1. Should kmap() actually flush all the user spaces? 
> >      2. Do we need additional hints in to kmap/kunmap?
> > 
> > My initial thought on 1. is no, since by and large we use kmap on pages
> > that have come to use via an I/O path, so usually they've already had
> > the user caches made coherent, unless you want do do this via a hint.
> 
> Who did this cache flush?  The idea is to make flush_dcache_page()
> do nothing, and have all of the work be done via the kmap()/kunmap()
> sequence.

Erm ... for a device driver, if we're preparing to do I/O on the page
something must have made the user caches coherent ... that can't be
kmap, because the driver might elect to DMA on the page ... unless
another component of this API is going to be to make dma_map_... also
flush the user cache?

> The case you're speaking about isn't a fault path, so it's not
> like there will be a flush_cache_page() call somewhere either.

well ... currently the pages come down to fuse via get_user_pages()
which does have a flush_dcache_page() as part of its operation.

> > For 2. like I said, I coded this on parisc without hints (using the page
> > table information instead to deduce what type of access the page had
> > taken) but we could equally well have used hints.
> 
> There are two important attributes 1) most permissive page protection
> of the user mappings, essentially does anyone have a writable access
> to the page and 2) the access the kernel will make, read or write.
> 
> If the kernel is going to read, kmap() would need to flush any
> writable user mappings, that's all.

Agreed.

> If the kernel is going to write, all user mappings have to be
> purged completely so that the writes are visible.

Agreed.

> I'm going to coneniently remind you it's possible to avoid all of the
> cache flushes by using TLB mappings at kmap() time.  I think PARISC
> can even do this, to be honest.  What makes that scheme unusable on
> PARISC?

You mean to map congruently for the page using something like our
temporary cache alias scheme?  Yes ... it should be possible for the
short lived kmap_atomic() type maps ... it will be a bit harder for the
non-atomic longer lived maps ... but I think we're deprecating those.

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/