Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp5702946rwb; Tue, 22 Nov 2022 03:57:12 -0800 (PST) X-Google-Smtp-Source: AA0mqf5wLzmcvAF4aCKlEECC8BhCXTv6OdLYBqJX6uhcg5It2EafAb8nB1hUiRd3ji69OT+sPBWX X-Received: by 2002:a17:907:10c3:b0:7ae:98fc:aaa3 with SMTP id rv3-20020a17090710c300b007ae98fcaaa3mr19748392ejb.547.1669118232665; Tue, 22 Nov 2022 03:57:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669118232; cv=none; d=google.com; s=arc-20160816; b=JPlcJIUW8Di7qN9ks8zdvAwfimdVZxR0EmcjlOrJYOIAFPGt43ewPv84lb2H/O4H2M /JRmKTQrsSteP5zzUuz4A4vfL7v3fS4BZsPB7NunImGgRYsIvpaGdL0x6qqG32odYa5x 0jPsq+wNOhAK2i/YlFG6MXFSpL/VaNCgUxZomRxQZJckHbvCaNC94hGiVvm6IEoCKY5e +3XENAx5Y0bG4tINYeLI82PEjeu+S9Hi+3ndRJmwfLQz3MVAtNOtkEAccGGa+4jZdSUF caK6qi8gLTEISQqd7qEdryaQS11KnsDa3COx4db37JOFCIIhbnoGDM8OZlxMDFZVmZmq hIuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=i7zhY67HvXsANWaMrM7PgcglBFkDMzl8D8aIeEogL08=; b=P4+D/WmIGRi4kPbWGNhVbAHgnt9mChkV6avUwmta8DDS0XcdPpXsbcKh8JrjlnkFsX ShLlB5JJMVtOOm2fcpFXrUxp0rLLdmF1ZAkaFXmfEW3NirCwWQg4Rt2tRmbsNvocQDFP 2ksbKfbTzapT52xg1PvjKXKRmZHSE8EqKWZp6qBNYsLXpJ2vbaCGXeCAGPpuhdEKuPqt Zk5Gn6+8D04cNoGLNdKdDfdlb7+M3U9LAQJ2D2yTy9zQ/dcEsr5ThT9U5bXO+bveg+0n itSNuaQPZmB6FjX44PE/UtMpUR+gV+HyvvlX+C0xdxmqA/rjkC/U6tVfiRE2k3o+OdD5 HU+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@crudebyte.com header.s=kylie header.b=T922QQ41; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=crudebyte.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id wz13-20020a170906fe4d00b0072a477a55e0si11591451ejb.369.2022.11.22.03.56.50; Tue, 22 Nov 2022 03:57:12 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@crudebyte.com header.s=kylie header.b=T922QQ41; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=crudebyte.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232866AbiKVL1e (ORCPT + 90 others); Tue, 22 Nov 2022 06:27:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233161AbiKVL0i (ORCPT ); Tue, 22 Nov 2022 06:26:38 -0500 Received: from kylie.crudebyte.com (kylie.crudebyte.com [5.189.157.229]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CB4363CE3 for ; Tue, 22 Nov 2022 03:20:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crudebyte.com; s=kylie; h=Content-Type:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: Content-ID:Content-Description; bh=i7zhY67HvXsANWaMrM7PgcglBFkDMzl8D8aIeEogL08=; b=T922QQ41QNfXRiKkPBs6IilCD2 mfwcj4X4w9JP9blv78Y36yEJXwYQTEuxvWDbjuFOGv888tfIcdl+URcwnTK3zFKfUkpfnOeHKT2/8 dE7h9O0yVj9jFIwS2qWExD/cXlRFN/OC7fFs8bt8ff5eYQPICphtC29cpK1LqG7OmKzaor2WOJp0W 1JVXlpw9uDRmQtaHU4sjZT9ucyPNXqltGSKxhb1r1Z2SLDMsVpEMjWyj69VFun8uSp5dhIVmWgzZI 8acITSPAfWoVsSQLjPxVQzi5boMPeAU3BMLvtpCYLyYjgqhPZMG6vOVkGhwOegLz4jcBYdHGk103p OE/c/jRbdCkkv6gbteXYAxsN5lpmIjDfhymSGZV7hTRKEeGJ1lsM/KnUmLI+0fy+Thdg4+Bvp01CZ qpGKffntcK+z8Gf+GJNyR+sfzjVpalQLzG8PvgQDxZjckR8CkztmSOkZD2npMBzWcNzCNPNlMNt1R Hh6u5MIQr7qYIPNyPuDlyoR8UOirpomSaQBOvyZ23cpMUte3Oe0J2zVz1cneJ/Y+IhHBvds257wcy C1uTchNGh2fviTgpIEJbGSiG9NkhV/zWvmyFxCBkziY0J5J0di1OVah4e2Rxf/YsqiNXse93XyycL tjb5Lnn/VFO658Fb+w2CzXstf8XP6hxfrvmldB+oM=; From: Christian Schoenebeck To: Dominique Martinet Cc: Stefano Stabellini , v9fs-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org, GUO Zihua Subject: Re: [PATCH 2/2] net/9p: fix response size check in p9_check_errors() Date: Tue, 22 Nov 2022 12:20:12 +0100 Message-ID: <2474218.LCornM2og2@silver> In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, November 22, 2022 1:21:43 AM CET Dominique Martinet wrote: > 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? For now that would do as well of course. I just had a feeling that this might be used for other purposes as well in future and some of these functions are already somewhat overloaded with arguments. No strong opinion, your choice. > 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 Yeah, that layout optimization would make sense indeed. > 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 > > --- > > 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. Lazy me, I haven't run checkpatch.pl this time. I'll fix that. I also have to fix the format specifier for `capacity` that kernel test bot barked on. > > + 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)