Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp612677rwb; Wed, 7 Dec 2022 02:51:19 -0800 (PST) X-Google-Smtp-Source: AA0mqf42xM+EKEg5XHRNRwDlSLDpcT/JCI0dH0UjTp+nxMJTYgtBV2+95AcewOK7sMdwvxn/EFbO X-Received: by 2002:a17:90a:8b03:b0:213:16d2:4d4c with SMTP id y3-20020a17090a8b0300b0021316d24d4cmr100286207pjn.70.1670410279579; Wed, 07 Dec 2022 02:51:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670410279; cv=none; d=google.com; s=arc-20160816; b=g9qHylAyTi16iHz+36AZHeTcy4JSYdQCFWLUsKE1bB8+n857Bc69le/ZoH3L9uLc/0 Ib6h4017Bjkb0+dQfNCo6Pch+Z5Q/sKC9WlZsO/XivfZCLMFUb5/f8SRLMDCs6RpNdDk /NomLRIgjhhOUnoWC78PiyVFTc2P8hBx/eTTK/zjw2nYzjGTS0Y4rQm9DdphDWm4gIVB ewVTYhMW9Jj9ogC5pdewCuN+xotZlrSkzdQRIGIgmZ8N9Olx39yoUgb5EYu12DMiHv2u PH3QZgk4GSCsQj+75dkvuXBDTaB50JX3aipb3mr7YFDkJo5ohxGxz1EJBE7cqKMG/NrM Mg0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Te+qRfL0gSPa2I5bK5OY5bAXbxohK6qh4ntuX06onLw=; b=0qvMnKNF2iFIbC5RhIlXELAU1MBZA3w27wjQDq4Cy8jgg4YkcXr7K+kLyFdtbf9czW 8wQFSixSmZfICc8PRYhond363JscD6AbvanqvnPJgABobVmoUOhYkyH7mBVLeozMUHyA o3FFVH83s3WjjIjxj+JdWSusfuKYaIRh62FSDOr6ffA3Dohb/2W+HqY35dWDepaaa+/F +9JvaK6Tc2pbogJtgXr3D1U5TmBuGUn3k83FnaW03LvRJCpeEmatnYIrV/OaTh1OFIL9 bKL1yawLUnq/DF1MJ3F6BqQuiuj+JZ0zqqaL/8ieml5A7YhpRmEiNkPUBeRoZg3e7V6D 4zgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=eBPc6LCd; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b1-20020a170903228100b00188dba5ea57si9140923plh.70.2022.12.07.02.51.08; Wed, 07 Dec 2022 02:51:19 -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=@google.com header.s=20210112 header.b=eBPc6LCd; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229456AbiLGKbH (ORCPT + 76 others); Wed, 7 Dec 2022 05:31:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58110 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229523AbiLGKbE (ORCPT ); Wed, 7 Dec 2022 05:31:04 -0500 Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C3239194 for ; Wed, 7 Dec 2022 02:31:01 -0800 (PST) Received: by mail-yb1-xb30.google.com with SMTP id o127so22102292yba.5 for ; Wed, 07 Dec 2022 02:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Te+qRfL0gSPa2I5bK5OY5bAXbxohK6qh4ntuX06onLw=; b=eBPc6LCdVbJNZrD/vNuWi34IC2I2EByvcZ8T0bOHHwJG02J4XKMyBtJKL5TXNyKr4l d2If4UglHwt630P/gso8MBO1XAPD4/15iytfqwluNRAjCjHvYaQX6lqz92qU1KueqWLl NmEtQ6abKgUm6qF8HpC29w+VmYMpJBX6lk06RhkXqIM9gvHs/UgSHGt9e1c749PUkstn JEkgkYj0nWksUc/pyFxQvgoiSB+fxrbCrHfYpt751cz2XxTcjqE/hdsmUs5eBIkUlkj6 Y0xvfCUPe9v+Y3nCGvY+7x0g7pjw9eqxhnA819SOFLRlldbiFVDZtpE2xX/6x/MdWLVi l40Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Te+qRfL0gSPa2I5bK5OY5bAXbxohK6qh4ntuX06onLw=; b=5lSlBNfvT29u6tMnFTlxppI3NFCP7vTUZzwNcKvIi0QSVdT+sB6VMLM8bcT0nzhHOq uIkEThbrHbfLGmHUc2CrtCW1yFpxgxQIkkn5seW5akHxNRsFjfaHClht7Sc0kLWhubMV /bwxVX8k1v+VUAeCL8iLLOmTkIX72PiyeG4KI8bvzatcXiYGwQgX/96N7PlUPYgiB/Px gg8EQHiL6bVZTTfA4W4//w1lLBFpxZ013/TjtsPy5GXTSPU7m+vlHJjRLW+aTA+6Ntim rwNbPMtImAbPIB3boS7aA+D9z+pt3vt2ilDdBMDFqIk59rWxzzO4bhAi6asYywTS70Gw NboQ== X-Gm-Message-State: ANoB5pkjR3yZ2EhOnipPPE3LDNtlk/fK4NnwA3ceHnLAa7MliLczFuq0 ml/Zmd6tMrcMgMlMoH6jv8uMhBhx1yUIQMcVbDlKeg== X-Received: by 2002:a05:6902:1004:b0:6fe:d784:282a with SMTP id w4-20020a056902100400b006fed784282amr17363367ybt.598.1670409060680; Wed, 07 Dec 2022 02:31:00 -0800 (PST) MIME-Version: 1.0 References: <20221206231659.never.929-kees@kernel.org> <20221206175557.1cbd3baa@kernel.org> In-Reply-To: <20221206175557.1cbd3baa@kernel.org> From: Eric Dumazet Date: Wed, 7 Dec 2022 11:30:36 +0100 Message-ID: Subject: Re: [PATCH] skbuff: Reallocate to ksize() in __build_skb_around() To: Jakub Kicinski Cc: Kees Cook , "David S. Miller" , syzbot+fda18eaa8c12534ccb3b@syzkaller.appspotmail.com, Paolo Abeni , Pavel Begunkov , pepsipu , Vlastimil Babka , kasan-dev , Andrii Nakryiko , ast@kernel.org, bpf , Daniel Borkmann , Hao Luo , Jesper Dangaard Brouer , John Fastabend , jolsa@kernel.org, KP Singh , martin.lau@linux.dev, Stanislav Fomichev , song@kernel.org, Yonghong Song , netdev@vger.kernel.org, LKML , Menglong Dong , David Ahern , Martin KaFai Lau , Luiz Augusto von Dentz , Richard Gobert , Andrey Konovalov , David Rientjes , linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable 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 Wed, Dec 7, 2022 at 2:56 AM Jakub Kicinski wrote: > > On Tue, 6 Dec 2022 15:17:14 -0800 Kees Cook wrote: > > - unsigned int size = frag_size ? : ksize(data); > > + unsigned int size = frag_size; > > + > > + /* When frag_size == 0, the buffer came from kmalloc, so we > > + * must find its true allocation size (and grow it to match). > > + */ > > + if (unlikely(size == 0)) { > > + void *resized; > > + > > + size = ksize(data); > > + /* krealloc() will immediate return "data" when > > + * "ksize(data)" is requested: it is the existing upper > > + * bounds. As a result, GFP_ATOMIC will be ignored. > > + */ > > + resized = krealloc(data, size, GFP_ATOMIC); > > + if (WARN_ON(resized != data)) > > + data = resized; > > + } > > > > Aammgh. build_skb(0) is plain silly, AFAIK. The performance hit of > using kmalloc()'ed heads is large because GRO can't free the metadata. > So we end up carrying per-MTU skbs across to the application and then > freeing them one by one. With pages we just aggregate up to 64k of data > in a single skb. > > I can only grep out 3 cases of build_skb(.. 0), could we instead > convert them into a new build_skb_slab(), and handle all the silliness > in such a new helper? That'd be a win both for the memory safety and one > fewer branch for the fast path. > > I think it's worth doing, so LMK if you're okay to do this extra work, > otherwise I can help (unless e.g. Eric tells me I'm wrong..). I totally agree, I would indeed remove ksize() use completely, let callers give us the size, and the head_frag boolean, instead of inferring from size==0