public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christian Schoenebeck <linux_oss@crudebyte.com>,
	Tyler Hicks <tyhicks@linux.microsoft.com>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	v9fs-developer@lists.sourceforge.net
Subject: [GIT PULL] 9p fixes for 5.19-rc4
Date: Wed, 22 Jun 2022 13:44:12 +0900	[thread overview]
Message-ID: <YrKeHMRfXTNw3vTE@codewreck.org> (raw)


Thanks to Tyler and Christian for the patch/reviews/tests!


The following changes since commit b13baccc3850ca8b8cccbf8ed9912dbaa0fdf7f3:

  Linux 5.19-rc2 (2022-06-12 16:11:37 -0700)

are available in the Git repository at:

  https://github.com/martinetd/linux tags/9p-for-5.19-rc4

for you to fetch changes up to b0017602fdf6bd3f344dd49eaee8b6ffeed6dbac:

  9p: fix EBADF errors in cached mode (2022-06-17 06:03:30 +0900)

----------------------------------------------------------------
9p-for-5.19-rc4: fid refcount and fscache fixes

This contains a couple of fixes:
 - fid refcounting was incorrect in some corner cases and would
leak resources, only freed at umount time. The first three commits
fix three such cases
 - cache=loose or fscache was broken when trying to write a partial
page to a file with no read permission since the rework a few releases
ago. The fix taken here is just to restore old behavior of using the
special 'writeback_fid' for such reads, which is open as root/RDWR
and such not get complains that we try to read on a WRONLY fid.
Long-term it'd be nice to get rid of this and not issue the read at
all (skip cache?) in such cases, but that direction hasn't progressed

----------------------------------------------------------------
Dominique Martinet (3):
      9p: fix fid refcount leak in v9fs_vfs_atomic_open_dotl
      9p: fix fid refcount leak in v9fs_vfs_get_link
      9p: fix EBADF errors in cached mode

Tyler Hicks (1):
      9p: Fix refcounting during full path walks for fid lookups

 fs/9p/fid.c            | 22 +++++++++-------------
 fs/9p/vfs_addr.c       | 13 +++++++++++++
 fs/9p/vfs_inode.c      |  8 ++++----
 fs/9p/vfs_inode_dotl.c |  3 +++
 4 files changed, 29 insertions(+), 17 deletions(-)

--
Dominique

             reply	other threads:[~2022-06-22  4:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-22  4:44 Dominique Martinet [this message]
2022-06-22  4:50 ` [GIT PULL] 9p fixes for 5.19-rc4 Dominique Martinet
2022-06-22 15:58 ` pr-tracker-bot

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=YrKeHMRfXTNw3vTE@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux_oss@crudebyte.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tyhicks@linux.microsoft.com \
    --cc=v9fs-developer@lists.sourceforge.net \
    /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