linux-kernel - Re: get_user_pages() cache issues on ARM

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] [day] [month] [year] [list]

Message-Id: <1160226818.3459.6.camel@mulgrave.il.steeleye.com>
Date:	Sat, 07 Oct 2006 08:13:38 -0500
From:	James Bottomley <James.Bottomley@...elEye.com>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	rmk+lkml@....linux.org.uk, dhylands@...il.com,
	guinan@...ebutton.com, linux-kernel@...r.kernel.org
Subject: Re: get_user_pages() cache issues on ARM

On Sat, 2006-09-30 at 19:18 +0200, Miklos Szeredi wrote:
> Added James Bottomley to the CC.  He designed this interface, and he
> explained to me how it's supposed to work, but I since forgot.
> 
> James, do you have some memory of these issues?

I can try, but the problems were very parisc specific.

> > The questions I have are:
> > 
> > - where do these pages that get_user_pages() finds and calls flush_anon_page()
> >   on come from?

Anonymous pages are non-file backed pages.  Fuse has them because it
uses non file backed buffers to operate the user level filesystem
(basically any memory you malloc at user level can end up as an
anonymous page).

> > - why is the current ARM flush_dcache_page() (which is also called after
> >   flush_anon_page()) not sufficient?

I think you do the same as we do on parisc: traverse the
page_mapping(page) list and flush.  Unfortunately, anonymous pages don't
have entries in the page_mapping(page) list (because they're not file
backed), so our flush_dcache_page() wasn't flushing them, hence the need
for an additional API for fuse.

if you have an archive of linux-arch, the original discussion is under
the subject

Potential problem with the page_mapping macro and flush_dcache_page()

and begins on 19 March 2006

> > - if we implement flush_anon_page() does that mean that we end up flushing
> >   multiple times in some circumstances?  If so, how do we avoid this?

In theory no, because the way I coded the parisc version, it ignores
non-anon pages, which are flushed by flush_dcache_page(); but it would
depend on how you implement this.

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/