Date: Mon, 24 Jul 2023 22:04:12 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 272678] VFS: Incorrect data in read from concurrent write Message-ID: <bug-272678-3630-7hTeG7NLJF@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-272678-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-272678-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272678 --- Comment #6 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=3D5b353925ff61b9ddb97bb453ba75278b5= 78ed7d9 commit 5b353925ff61b9ddb97bb453ba75278b578ed7d9 Author: Konstantin Belousov <kib@FreeBSD.org> AuthorDate: 2023-07-23 15:55:50 +0000 Commit: Konstantin Belousov <kib@FreeBSD.org> CommitDate: 2023-07-24 22:02:59 +0000 vnode read(2)/write(2): acquire rangelock regardless of do_vn_io_fault() To ensure atomicity of reads against parallel writes and truncates, vnode lock was not enough at least since introduction of vn_io_fault(). That code only take rangelock when it was possible that vn_read() and vn_write() could drop the vnode lock. At least since the introduction of VOP_READ_PGCACHE() which generally does not lock the vnode at all, rangelocks become required even for filesystems that do not need vn_io_fault() workaround. For instance, tmpfs. PR: 272678 Analyzed and reviewed by: Andrew Gierth=20 <andrew@tao11.riddles.org.uk> Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D41158 sys/kern/vfs_vnops.c | 21 ++++++++++++++------- 1 file changed, 14 insertions(+), 7 deletions(-) --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-272678-3630-7hTeG7NLJF>