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