linux-kernel - [PATCH 0/3] Fixes for FS-Cache and CacheFiles

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:	Fri, 20 Nov 2009 21:54:37 +0000
From:	David Howells <dhowells@...hat.com>
To:	wilhelm.meier@...kl.de, linux-cachefs@...hat.com,
	nfsv4@...ux-nfs.org, linux-kernel@...r.kernel.org
Cc:	dhowells@...hat.com, steved@...hat.com
Subject: [PATCH 0/3] Fixes for FS-Cache and CacheFiles

The associated patches provide three sets of changes:

 (1) More ways to get debugging information from the slow-work, FS-Cache and
     CacheFiles facilities.

 (2) Fixes for all facilities.

 (3) Some extensions for slow-work for users other than FS-Cache/CacheFiles
     that aren't included in this series, but upon which other patches have
     been built.

The patches can also be found in:

	http://people.redhat.com/~dhowells/fscache/patches/fscache-fixes.tar.bz2

The bugs fixed were found by running a simple stress tester:

	http://people.redhat.com/~dhowells/slurp.c

Build it and point it at a bunch of NFS (or AFS or whatever) directory trees,
and it forks and execs a copy of itself to handle each directory that it is
given.  Whilst scanning a directory, for each subdir of that directory a new
copy forked and exec'd, and then each file in that directory is read from end
to end.

This results in a large number of processes reading in parallel a large number
of files.  If the data set is large enough, it applies pressure to both RAM
space and cache space, and can cause OOMs to occur, and can cause cachefilesd
to run in parallel trying to cull the cache as well.

With these patches applied, you can see more counters in /proc/fs/fscache/stats
and new sources of information exist too:

 (*) /proc/slow_work_rq

	The items currently being processed by or currently queued for
	processing by the slow-work facility.

 (*) /proc/fs/fscache/objects

	A list of current fscache objects and their states.  This can be
	configured by loading a key into your session keyring before viewing
	the file, for instance:

		keyctl add user fscache:objlist KB @s

	This is described in Documentation/filesystems/caching/fscache.txt

David
---

David Howells (3):
      FS-Cache: Provide nop fscache_stat_d() if CONFIG_FSCACHE_STATS=n
      SLOW_WORK: Fix GFS2 to #include <linux/module.h> before using THIS_MODULE
      SLOW_WORK: Fix CIFS to pass THIS_MODULE to slow_work_register_user()

 fs/cifs/cifsfs.c      |    2 +-
 fs/fscache/internal.h |    1 +
 fs/gfs2/recovery.c    |    1 +
 3 files changed, 3 insertions(+), 1 deletions(-)

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