From: Dave Wysochanski <dwysocha@redhat.com>
To: dhowells@redhat.com, kiran.modukuri@gmail.com, carmark.dlut@gmail.com
Cc: linux-nfs@vger.kernel.org
Subject: [PATCH 0/1] cachefiles: Fix race between read_waiter and read_copier
Date: Thu, 7 May 2020 08:50:21 -0400 [thread overview]
Message-ID: <1588855822-5532-1-git-send-email-dwysocha@redhat.com> (raw)
This patch was originally posted by Lei Xue in 2018:
https://lore.kernel.org/patchwork/patch/889373/
The responses on the above thread ended up fixing a separate, but related
problem in this code path, but the last portion of the commit message
indicated the original problem was thought to have been fixed as well.
commit 934140ab028713a61de8bca58c05332416d037d1
Author: Kiran Kumar Modukuri <kiran.modukuri@gmail.com>
Date: 2018-07-25 15:04:25 +0100
cachefiles: Fix refcounting bug in backing-file read monitoring
However, the original problem reported by Lei still remains and is fairly
easy to reproduce. My reproducer details are below and I could reproduce
within a few minutes. I ended up at the same patch after tracing of the
problem and proving this race still exists, then testing with this patch
applied. The work is detailed in the following bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1829662
I am re-submitting this with Lei as author as I've only rebased the patch
on dhowells fscache-fixes branch, changed the subject line, and cleaned
up the patch header.
Reproducer
==========
# NFS server setup / config
# uname -r
3.10.0-1127.el7.x86_64
# cat /etc/exports
/data *(rw,sec=sys:krb5)
# df -h /data
Filesystem Size Used Avail Use% Mounted on
/dev/vdb 16G 16G 340M 98% /data
# time for i in $(seq 1 4000); do dd if=/dev/zero of=/data/file$i.bin bs=1M count=4; done &
# NFS client config and test
# uname -r
3.10.0-1062.23.1.el7.x86_64
# _or_
# From https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/commit/?h=fscache-fixes&id=1836833f67ab49363d221aeb120956448ca5be4f
# uname -r
5.7.0-rc3-1836833f67ab
# df /var/cache/fscache
Filesystem Size Used Avail Use% Mounted on
/dev/md0 7.8G 36M 7.3G 1% /var/cache/fscache
# make sure cachefilesd is running
systemctl status cachefilesd
# To run the test on the client:
# mount -overs=3,fsc nfs-server:/data /mnt/nfs
# cat dd-ioload.sh
NFS_MNT=/mnt/nfs
echo 3 > /proc/sys/vm/drop_caches
for i in $(seq 1 2000); do
dd if=$NFS_MNT/file$i.bin of=/dev/null bs=28k >/dev/null 2>&1 &
done
wait
# while true; do date; time ./dd-ioload.sh; done &
next reply other threads:[~2020-05-07 12:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 12:50 Dave Wysochanski [this message]
2020-05-07 12:50 ` [PATCH 1/1] cachefiles: Fix race between read_waiter and read_copier involving op->to_do Dave Wysochanski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1588855822-5532-1-git-send-email-dwysocha@redhat.com \
--to=dwysocha@redhat.com \
--cc=carmark.dlut@gmail.com \
--cc=dhowells@redhat.com \
--cc=kiran.modukuri@gmail.com \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox