fscache and cachefiles fixes

Hi Linus,

Can you pull these fixes for fscache and cachefiles please?

There are five:

(1) Allow cancelled operations to be queued so they can be cleaned up.

(2) Fix a refcounting bug in the monitoring of reads on backend files whereby a race can occur between monitor objects being listed for work, the work processing being queued and the work processor running and destroying the monitor objects.

(3) Fix a ref overput in object attachment, whereby a tentatively considered object is put in error handling without first being 'got'.

(4) Fix a missing clear of the CACHEFILES_OBJECT_ACTIVE flag whereby an assertion occurs when we retry because it seems the object is now active.

(5) Wait rather BUG'ing on an object collision in the depths of cachefiles as the active object should be being cleaned up - also depends on (4).

David
---
The following changes since commit fc36def997cfd6cbff3eda4f82853a5c311c5466:

mm: teach dump_page() to correctly output poisoned struct pages (2018-07-03 17:32:19 -0700)

are available in the Git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git tags/fscache-fixes-20180725

for you to fetch changes up to c2412ac45a8f8f1cd582723c1a139608694d410d:

cachefiles: Wait rather than BUG'ing on "Unexpected object collision" (2018-07-25 14:49:00 +0100)

----------------------------------------------------------------
fscache fixes

----------------------------------------------------------------
Kiran Kumar Modukuri (5):
fscache: Allow cancelled operations to be enqueued
cachefiles: Fix refcounting bug in backing-file read monitoring
fscache: Fix reference overput in fscache_attach_object() error handling
cachefiles: Fix missing clear of the CACHEFILES_OBJECT_ACTIVE flag
cachefiles: Wait rather than BUG'ing on "Unexpected object collision"

 fs/cachefiles/bind.c   |  3 ++-
 fs/cachefiles/namei.c  |  3 +--
 fs/cachefiles/rdwr.c   | 17 ++++++++++++-----
 fs/fscache/cache.c     |  2 +-
 fs/fscache/cookie.c    |  7 ++++---
 fs/fscache/object.c    |  1 +
 fs/fscache/operation.c |  6 ++++--
 7 files changed, 25 insertions(+), 14 deletions(-)

I've pulled them, but I'm not happy about it. They are all *very* new.

Why do they have commit times literally *minutes* before your email to ask me to pull?

What kind of testing have these gotten?

Seriously, if I get a pull request with commits this new, I want to have an *explanation*. The explanation could be "I use quilt, and this underwent lots of testing outside of git", but the explanation should be there!

I took them because they look simple enough, but that still leaves me grumpy.

Linus

I split the first patch into two because it had two more-or-less independent changes and it made it easier to describe them separately.

David

This didn't explain the background before that happened.

I really want the warm and fuzzies about things, and when I see something being changed just minutes before, something like

"I did a rebase becasue XYZ, but this was around in linux-next for a
week before that without problems"

tells me not only why the times are so recent, but also tells me that I really shouldn't worry because so-and-so.

Linus

Okay, I posted four patches on 5th July:

	https://lore.kernel.org/lkml/153080826773.5496.7106875523806885716.stgit@warthog.procyon.org.uk/

These five patches are the same aggregate changes, just with the first patch split and a description composed for both parts:

	warthog>git diff fscache-fixes-20180705  fscache-fixes-20180725
	warthog>

The patch series as a whole got tested by Scott Mayhew whilst seeing if they cured a bug he was looking at:

	https://marc.info/?l=linux-nfs&m=153191593807248&w=2

I've also ported them to RHEL-7 where they've undergone some automated testing with iozone.

David