linux-kernel - [PATCH 00/13] FS-Cache: Fix a number of bugs that occur when the cache runs out of space

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

Message-ID: <20150226140155.2387.70579.stgit@warthog.procyon.org.uk>
Date:	Thu, 26 Feb 2015 14:01:55 +0000
From:	David Howells <dhowells@...hat.com>
To:	linux-cachefs@...hat.com
Cc:	dhowells@...hat.com, linux-fsdevel@...r.kernel.org,
	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 00/13] FS-Cache: Fix a number of bugs that occur when the
 cache runs out of space


Attached are a bunch of patches that progressively fix bugs that can occur
when the cache hits the hard "must maintain X free space" limit and starts
rejecting requests.

The commit ensubjected "FS-Cache: Synchronise object death state change vs
operation submission" is the main bug I was looking for.  Some of the other
patches fix other bugs I found along the way and the remaining patches are
changes pulled out of the bugfixes to make the bugfix commits more narrowly
targeted.

Note that I added some new stats:

	Ops    : ini=836360 dfr=19 rel=836360 gc=19

The ini=N field here indicates the number of fscache_operation structs that
were initialised and should match the rel=M value.

	CacheEv: nsp=3425 stl=0 rtr=0 cul=0

Indicates counts of certain cache backend events: nsp=N shows how many objects
were rejected due to lack of space in the cache, stl=N shows how many objects
were found to be stale upon reuse and thus discarded, rtr=N how many objects
were retired and cul=N shows how many inactive objects were culled.

These can also be found here:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=fscache-fixes

tagged with:

	fscache-fixes-20150226

David
---
David Howells (13):
      FS-Cache: Count culled objects and objects rejected due to lack of space
      FS-Cache: Move fscache_report_unexpected_submission() to make it more available
      FS-Cache: When submitting an op, cancel it if the target object is dying
      FS-Cache: Handle a new operation submitted against a killed object
      FS-Cache: Synchronise object death state change vs operation submission
      FS-Cache: fscache_object_is_dead() has wrong logic, kill it
      FS-Cache: Permit fscache_cancel_op() to cancel in-progress operations too
      FS-Cache: Out of line fscache_operation_init()
      FS-Cache: Count the number of initialised operations
      FS-Cache: Fix cancellation of in-progress operation
      FS-Cache: Put an aborted initialised op so that it is accounted correctly
      FS-Cache: The operation cancellation method needs calling in more places
      FS-Cache: Retain the netfs context in the retrieval op earlier


 Documentation/filesystems/caching/backend-api.txt |   23 ++
 Documentation/filesystems/caching/fscache.txt     |    7 -
 fs/cachefiles/internal.h                          |    1 
 fs/cachefiles/namei.c                             |   33 ++-
 fs/fscache/cookie.c                               |    8 -
 fs/fscache/internal.h                             |   12 +
 fs/fscache/object.c                               |   69 +++++-
 fs/fscache/operation.c                            |  254 ++++++++++++++-------
 fs/fscache/page.c                                 |   86 ++++---
 fs/fscache/stats.c                                |   14 +
 include/linux/fscache-cache.h                     |   55 ++---
 11 files changed, 378 insertions(+), 184 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/