linux-kernel - RE: bug in cleancache ocfs2 hook, anybody want to try cleancache?

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: <1307090628.2881.15.camel@menhir>
Date:	Fri, 03 Jun 2011 09:43:48 +0100
From:	Steven Whitehouse <swhiteho@...hat.com>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
Cc:	ocfs2-devel@....oracle.com, Joel Becker <jlbec@...lplan.org>,
	Sunil Mushran <sunil.mushran@...cle.com>,
	linux-kernel@...r.kernel.org
Subject: RE: bug in cleancache ocfs2 hook, anybody want to try cleancache?

Hi,

On Thu, 2011-06-02 at 11:26 -0700, Dan Magenheimer wrote:
> > Having started looking at the cleancache code in a bit more detail, I
> > have another question... what is the intended mechanism for selecting a
> > cleancache backend? The registration code looks like this:
> > 
> > struct cleancache_ops cleancache_register_ops(struct cleancache_ops
> > *ops)
> > {
> >         struct cleancache_ops old = cleancache_ops;
> > 
> >         cleancache_ops = *ops;
> >         cleancache_enabled = 1;
> >         return old;
> > }
> > EXPORT_SYMBOL(cleancache_register_ops);
> > 
> > but I wonder what the intent was here. It looks racy to me, and what
> > prevents the backend module from unloading while it is in use? Neither
> > of the two in-tree callers seems to do anything with the returned
> > structure beyond printing a warning if another backend has already
> > registered itself. Also why return the structure and not a pointer to
> > it? The ops structure pointer passed in should also be const I think.
> > 
> > From the code I assume that it is only valid to load the module for a
> > single cleancache backend at a time, though nothing appears to enforce
> > that.
> 
> Hi Steven --
> 
> The intent was to allow backends to be "chained", but this is
> not used yet and not really very well thought through yet either
> (e.g. possible coherency issues of chaining).
> So, yes, currently only one cleancache backend can be loaded
> at time.
> 
> There's another initialization issue... if mounts are done
> before a backend registers, those mounts are not enabled
> for cleancache.   As a result, cleancache backends generally
> need to be built-in, not loaded separately as a module.
> I've had ideas on how to fix this for some time (basically
> recording calls to cleancache_init_fs that occur when no
> backend is registered, then calling the backend lazily after
> registration occurs).
> 
Ok... but if cleancache_init_fs were to take (for example) an argument
specifying the back end to use (I'm thinking here of say a
cleancache=tmem mount argument for filesystems or something similar)
then the backend module could be automatically loaded if required. It
would also allow, by design, multiple backends to be used without
interfering with each other.

I don't understand the intent behind chaining of the backends. Did you
mean that pages would migrate from one backend to another down the stack
as each one discards pages and that pages would migrate back up the
stack again when pulled back in from the filesystem? I'm not sure I can
see any application for such a scheme, unless I'm missing something.

I'd like to try and understand the design of the existing code before I
consider anything more advanced such as writing a kvm backend,

Steve.


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