linux-kernel - Re: [PATCH 06/43] FS-Cache: Recruit a couple of page flags for cache management [ver #46]

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: <200904030315.03606.nickpiggin@yahoo.com.au>
Date:	Fri, 3 Apr 2009 03:15:02 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	David Howells <dhowells@...hat.com>
Cc:	viro@...iv.linux.org.uk, nfsv4@...ux-nfs.org,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 06/43] FS-Cache: Recruit a couple of page flags for cache management [ver #46]

On Friday 03 April 2009 02:51:02 David Howells wrote:
> Nick Piggin <nickpiggin@...oo.com.au> wrote:
> 
> > Haven't looked closely at how fscache works.
> 
> It's fairly simple.  FS-Cache sets PG_private_2 (PageFsCache) on pages that the
> netfs tells it about, if it retains an interest in the page.  This causes
> invalidatepage() and suchlike to be invoked on that page when the page is
> discarded.
> 
> The netfs can check for the page being in use by calling PageFsCache() and then
> uncache the page if it is in use:
> 
> 	#ifdef CONFIG_AFS_FSCACHE
> 		if (PageFsCache(page)) {
> 			struct afs_vnode *vnode = AFS_FS_I(page->mapping->host);
> 			wait_on_page_fscache_write(page);
> 			fscache_uncache_page(vnode->cache, page);
> 		}
> 	#endif
> 
> which clears the bit.

OK, then you just use PG_private for that, and have the netfs
use a PG_owner_private or some such bit to tell that it is an
fscache page.

> Furthermore, when FS-Cache is asked to store a page to the cache, it
> immediately marks it with PG_owner_priv_2 (PageFsCacheWrite).  This is cleared
> when FS-Cache no longer needs the data in the page for writing to the cache.
> 
> This allows (1) invalidatepage() to wait until the page is written before it is
> returned to the memory allocator, and (2) releasepage() to indicate that the
> page is busy if __GFP_WAIT is not given.

So it isn't written synchronously at invalidatepage-time? OK.

> > Possibly you can't reuse mappedtodisk....
> 
> PG_mappedtodisk has a very specific meaning to fs/buffer.c and fs/mpage.c.  I
> can't also easily make it mean that a page is backed by the cache.  A page can
> be cached and not mapped to disk.

You have 2 types of pagecache pages you are dealing with here, right? The
netfs and the backingfs pages. From what you write above, am I to take it
that you need to know whether a backingfs page is "backed by the cache"?
WTF for? And what cache is it backed by if it is the backing store?

> > > We still need a way of triggering the page invalidation callbacks for in-use
> > > pages, however.  PG_private, as I've said, is not currently a viable option.
> > 
> > Can you say exactly why not?
> 
> fs/buffer.c owns PG_private in filesystems that use standard buffering.  It
> sets it, clears it and tests it at its own behest without recourse to the
> filesystem using it.

One of us is confused about how this works. Firstly, from your description
above, you're needing the invalidatepage call from the *netfs* page. This is
not using fs/buffer.c presumably, that is the backing store fs.

Secondly, I repeat again, PG_private is only to tell the VM to call the fs aop,
so if you just think you can override this without changing the aop then you
are mistaken: buffer.c will blow up in serveral places if its page aops are
called without buffers being attached to the page (try_to_release_page being one
of them).

Thirdly, buffer layer is just a library for the filesystem to use. Of course it
has recourse to override things just by giving different aops (which could then
call into buffer.c if PG_fscache is not set or whatever you require).

> Also NFS uses PG_private for its own nefarious purposes.  Making PG_private be
> the conjunction of both purposes entailed some fairly messy patching.

This is basically an NFS mess, so that's where it belongs. But anyway I don't
see how it could be less messy to add this in the VM because NFS aops *still*
need to distinguish between cases anyway.
--
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/