From: Dominique Martinet <asmadeus@codewreck.org>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
v9fs-developer@lists.sourceforge.net,
linux-kernel@vger.kernel.org, GUO Zihua <guozihua@huawei.com>
Subject: Re: [PATCH 2/2] net/9p: fix response size check in p9_check_errors()
Date: Tue, 22 Nov 2022 09:21:43 +0900 [thread overview]
Message-ID: <Y3wWFxRVpei71PQt@codewreck.org> (raw)
In-Reply-To: <fffb512c532bf1290f0f2b1df6068b2ff6cd14c0.1669072186.git.linux_oss@crudebyte.com>
Christian Schoenebeck wrote on Tue, Nov 22, 2022 at 12:04:08AM +0100:
> Since 60ece0833b6c (net/9p: allocate appropriate reduced message buffers)
> it is no longer appropriate to check server's response size against
> msize. Check against the previously allocated buffer capacity instead.
Thanks for the follow up!
> - Omit this size check entirely for zero-copy messages, as those always
> allocate 4k (P9_ZC_HDR_SZ) linear buffers which are not used for actual
> payload and can be much bigger than 4k.
[review includes the new flag patch]
hmm, unless there's anywhere else you think we might use these flags it
looks simpler to just pass a flag to p9_check_errors?
In particular adding a bool in this position is not particularly efficient:
-------(pahole)-----
struct p9_fcall {
u32 size; /* 0 4 */
u8 id; /* 4 1 */
/* XXX 1 byte hole, try to pack */
u16 tag; /* 6 2 */
size_t offset; /* 8 8 */
size_t capacity; /* 16 8 */
bool zc; /* 24 1 */
/* XXX 7 bytes hole, try to pack */
struct kmem_cache * cache; /* 32 8 */
u8 * sdata; /* 40 8 */
/* size: 48, cachelines: 1, members: 8 */
/* sum members: 40, holes: 2, sum holes: 8 */
/* last cacheline: 48 bytes */
};
----------------
Not that adding it between id and tag sounds better to me, so this is
probably just as good as anywhere else :-D
Anyway, I'm just nitpicking -- on principle I agree just whitelisting zc
requests from this check makes most sense, happy with either way if you
think this is better for the future.
> - Replace p9_debug() by pr_err() to make sure this message is always
> printed in case this error is triggered.
>
> - Add 9p message type to error message to ease investigation.
Yes to these log changes!
>
> Signed-off-by: Christian Schoenebeck <linux_oss@crudebyte.com>
> ---
> net/9p/client.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 30dd82f49b28..63f13dd1ecff 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -514,10 +514,10 @@ static int p9_check_errors(struct p9_client *c, struct p9_req_t *req)
> int ecode;
>
> err = p9_parse_header(&req->rc, NULL, &type, NULL, 0);
> - if (req->rc.size >= c->msize) {
> - p9_debug(P9_DEBUG_ERROR,
> - "requested packet size too big: %d\n",
> - req->rc.size);
> + if (req->rc.size > req->rc.capacity && !req->rc.zc) {
> + pr_err(
> + "requested packet size too big: %d does not fit %ld (type=%d)\n",
> + req->rc.size, req->rc.capacity, req->rc.id);
Haven't seen this style before -- is that what qemu uses?
We normally keep the message on first line and align e.g.
> + pr_err("requested packet size too big: %d does not fit %ld (type=%d)\n",
> + req->rc.size, req->rc.capacity, req->rc.id);
(at least what's what other grep -A 1 'pr_err.*,$' seem to do, and
checkpatch is happier with that)
--
Dominique
next prev parent reply other threads:[~2022-11-22 0:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-21 23:09 [PATCH 0/2] " Christian Schoenebeck
2022-11-21 23:03 ` [PATCH 1/2] net/9p: distinguish zero-copy requests Christian Schoenebeck
2022-11-21 23:04 ` [PATCH 2/2] net/9p: fix response size check in p9_check_errors() Christian Schoenebeck
2022-11-22 0:21 ` Dominique Martinet [this message]
2022-11-22 11:20 ` Christian Schoenebeck
2022-11-22 9:37 ` kernel test robot
2022-11-22 2:27 ` [PATCH 0/2] " Stefano Stabellini
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=Y3wWFxRVpei71PQt@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=guozihua@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=sstabellini@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®