mbox series

[GIT,PULL] fscache and cachefiles fixes

Message ID 7828.1532527332@warthog.procyon.org.uk (mailing list archive)
State New, archived
Headers show
Series [GIT,PULL] fscache and cachefiles fixes | expand

Pull-request

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

Message

David Howells July 25, 2018, 2:02 p.m. UTC
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(-)

Comments

Linus Torvalds July 25, 2018, 6:13 p.m. UTC | #1
On Wed, Jul 25, 2018 at 7:02 AM David Howells <dhowells@redhat.com> wrote:
>
> Can you pull these fixes for fscache and cachefiles please?

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
David Howells July 25, 2018, 6:18 p.m. UTC | #2
Linus Torvalds <torvalds@linux-foundation.org> wrote:

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

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
Linus Torvalds July 25, 2018, 6:23 p.m. UTC | #3
On Wed, Jul 25, 2018 at 11:18 AM David Howells <dhowells@redhat.com> wrote:
>
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > Why do they have commit times literally *minutes* before your email to
> > ask me to pull?
>
> 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.

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
David Howells July 25, 2018, 7:31 p.m. UTC | #4
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