From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: Dominique Martinet <asmadeus@codewreck.org>
Cc: Eric Van Hensbergen <ericvh@gmail.com>,
Latchesar Ionkov <lucho@ionkov.net>,
David Howells <dhowells@redhat.com>,
linux-fsdevel@vger.kernel.org, stable@vger.kernel.org,
v9fs-developer@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 9p: fix EBADF errors in cached mode
Date: Tue, 14 Jun 2022 16:11:35 +0200 [thread overview]
Message-ID: <1796737.mFSqR1lx0c@silver> (raw)
In-Reply-To: <YqiC8luskkxUftQl@codewreck.org>
On Dienstag, 14. Juni 2022 14:45:38 CEST Dominique Martinet wrote:
> Christian Schoenebeck wrote on Tue, Jun 14, 2022 at 02:10:01PM +0200:
> > It definitely goes into the right direction, but I think it's going a bit
> > too far by using writeback_fid also in cases where it is not necessary
> > and wasn't used before in the past.
>
> Would help if I had an idea of what was used where in the past.. :)
>
> From a quick look at the code, checking out v5.10,
> v9fs_vfs_writepage_locked() used the writeback fid always for all writes
> v9fs_vfs_readpages is a bit more complex but only seems to be using the
> "direct" private_data fid for reads...
> It took me a bit of time but I think the reads you were seeing on
> writeback fid come from v9fs_write_begin that does some readpage on the
> writeback fid to populate the page before a non-filling write happens.
Yes, the overall picture in the past was not clear to me either.
To be more specific, I was reading your patch as if it would e.g. also use the
writeback_fid if somebody explicitly called read() (i.e. not an implied read
caused by a partial write back), and was concerned about a potential privilege
escalation. Maybe it's just a theoretical issue, as this case is probably
already catched on a higher, general fs handling level, but worth
consideration.
> > What about something like this in v9fs_init_request() (yet untested):
> > /* writeback_fid is always opened O_RDWR (instead of just O_WRONLY)
> >
> > * explicitly for this case: partial write backs that require a read
> > * prior to actual write and therefore requires a fid with read
> > * capability.
> > */
> >
> > if (rreq->origin == NETFS_READ_FOR_WRITE)
> >
> > fid = v9inode->writeback_fid;
>
> ... Which seems to be exactly what this origin is about, so if that
> works I'm all for it.
>
> > If desired, this could be further constrained later on like:
> > if (rreq->origin == NETFS_READ_FOR_WRITE &&
> >
> > (fid->mode & O_ACCMODE) == O_WRONLY)
> >
> > {
> >
> > fid = v9inode->writeback_fid;
> >
> > }
>
> That also makes sense, if the fid mode has read permissions we might as
> well use these as the writeback fid would needlessly be doing root IOs.
>
> > I will definitely give these options some test spins here, a short
> > feedback
> > ahead would be appreciated though.
>
> Please let me know how that works out, I'd be happy to use either of
> your versions instead of mine.
> If I can be greedy though I'd like to post it together with the other
> couple of fixes next week, so having something before the end of the
> week would be great -- I think even my first overkill version early and
> building on it would make sense at this point.
>
> But I think you've got the right end, so hopefully won't be needing to
> delay
I need a day or two for testing, then I will report back for sure. So it
should perfectly fit into your intended schedule.
Thanks!
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2022-06-14 14:11 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAAZOf26g-L2nSV-Siw6mwWQv1nv6on8c0fWqB4bKmX73QAFzow@mail.gmail.com>
2022-03-26 11:46 ` [syzbot] WARNING in p9_client_destroy David Kahurani
2022-03-26 11:48 ` Christian Schoenebeck
2022-03-26 12:24 ` asmadeus
2022-03-26 12:36 ` Christian Schoenebeck
2022-03-26 13:35 ` 9p fscache Duplicate cookie detected (Was: [syzbot] WARNING in p9_client_destroy) asmadeus
2022-03-30 12:21 ` 9p fs-cache tests/benchmark (was: 9p fscache Duplicate cookie detected) Christian Schoenebeck
2022-03-30 21:47 ` asmadeus
2022-04-01 14:19 ` Christian Schoenebeck
2022-04-01 23:11 ` asmadeus
2022-04-02 12:43 ` Christian Schoenebeck
2022-04-11 8:10 ` David Howells
2022-04-11 7:59 ` David Howells
2022-04-09 11:16 ` Christian Schoenebeck
2022-04-10 16:18 ` Christian Schoenebeck
2022-04-10 22:54 ` asmadeus
2022-04-11 13:41 ` Christian Schoenebeck
2022-04-12 22:38 ` asmadeus
2022-04-14 12:44 ` Christian Schoenebeck
2022-04-17 12:56 ` asmadeus
2022-04-17 13:52 ` Christian Schoenebeck
2022-04-17 21:22 ` asmadeus
2022-04-17 22:17 ` 9p EBADF with cache enabled (Was: 9p fs-cache tests/benchmark (was: 9p fscache Duplicate cookie detected)) asmadeus
2022-04-21 10:36 ` David Howells
2022-04-21 11:36 ` Christian Schoenebeck
2022-04-22 13:13 ` asmadeus
2022-04-25 14:10 ` David Howells
2022-04-26 15:38 ` Christian Schoenebeck
2022-05-03 10:21 ` asmadeus
2022-05-04 18:33 ` Christian Schoenebeck
2022-05-04 21:48 ` asmadeus
2022-05-06 19:14 ` Christian Schoenebeck
2022-06-03 16:46 ` Christian Schoenebeck
2022-06-12 10:02 ` asmadeus
2022-06-14 3:38 ` [PATCH] 9p: fix EBADF errors in cached mode Dominique Martinet
2022-06-14 3:41 ` Dominique Martinet
2022-06-14 12:10 ` Christian Schoenebeck
2022-06-14 12:45 ` Dominique Martinet
2022-06-14 14:11 ` Christian Schoenebeck [this message]
2022-06-16 13:35 ` Christian Schoenebeck
2022-06-16 13:51 ` Dominique Martinet
2022-06-16 14:11 ` Dominique Martinet
2022-06-16 20:14 ` Christian Schoenebeck
2022-06-16 20:53 ` Dominique Martinet
2022-06-16 21:10 ` [PATCH v3] " Dominique Martinet
2022-06-20 12:47 ` Christian Schoenebeck
2022-06-20 20:34 ` Dominique Martinet
2022-06-21 12:13 ` Christian Schoenebeck
2022-06-16 13:52 ` [PATCH v2] " Dominique Martinet
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=1796737.mFSqR1lx0c@silver \
--to=linux_oss@crudebyte.com \
--cc=asmadeus@codewreck.org \
--cc=dhowells@redhat.com \
--cc=ericvh@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=stable@vger.kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.