Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp908177pxp; Wed, 16 Mar 2022 20:55:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx1N9iU6csrKxEjhNBDg13YwgA/bF36cn+NGdWIrtIRLSkosK3GC4aFULRelSA40m7huKU1 X-Received: by 2002:aa7:805a:0:b0:4f6:dc68:5d41 with SMTP id y26-20020aa7805a000000b004f6dc685d41mr2643818pfm.69.1647489346964; Wed, 16 Mar 2022 20:55:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1647489346; cv=none; d=google.com; s=arc-20160816; b=G1IXeIIUk73QJ3uOUkWuoCSALqWPtoJ8BYZi3Iiqi0eitQKa1ndbmB8bbmRQiHR+gj XmE4U7d8ekGtD+EXr0g6xe+TrwJ2EynmG1og9NVnIvl+H9If7iKaPVR9euqO9HUFficX xbA/qmdIV9A+IDT8LoiuPoNJDF/KIOkgy0NFqtrNSv89vZ/6k4WaMX4CnAxC1O5Md35s v4SPjInuALXz3I427fIUgGJ/dwL0m5ro2P7/E7EiVTuUQQ4YoQcfYTF35bpHSf/2aDWh 3s7otO0hopNGjm7QzEELuhnE5tP4ZWiTLhFkdfu9+c+RHkeE87ApiosLC5Q9iRD0ttvX G2cw== 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=Xt1UGiPjPraq4SpUxRWULqHUBLr6thKTQdGzdb7dfpU=; b=u7YUYsS3E9XiwJbBD/MxJY6s7zkG9g5QRbgLVy8Nlv/UIbhb+id33fb8DuF78yU1i+ Ax7xC/gP1AnQO8dkjdRONtLRO3Mx/Pl+bQ3qWboFbHLYvmlZpT/tbe0spAiku3w4NeWk mRgdx7Hu0rgb09SlB6hcTXEbYfFXtoTtq/J0fNqnQZ2B6zElPaGttl6kBVPsQxztIIoz tfJeGTwyJMXIR8BRx75TpHCeMZBna0j+G/UCRpP493fYJDGHxXJjWpka7E8xSGCgxA/A KtJowndxwCwSFZotDHVch99ezNfyTS32+ecwtCVmEVv/FI1wYmJpgqoBvATpKoLVAb+7 b8EA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=OshylebK; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id 35-20020a631463000000b003820705eb26si468979pgu.593.2022.03.16.20.55.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Mar 2022 20:55:46 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=OshylebK; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4727386E32; Wed, 16 Mar 2022 20:42:18 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351083AbiCOSiW (ORCPT + 99 others); Tue, 15 Mar 2022 14:38:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59786 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351067AbiCOSiV (ORCPT ); Tue, 15 Mar 2022 14:38:21 -0400 Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 60792483B4; Tue, 15 Mar 2022 11:37:08 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id l18so16013501ioj.2; Tue, 15 Mar 2022 11:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xt1UGiPjPraq4SpUxRWULqHUBLr6thKTQdGzdb7dfpU=; b=OshylebKscz8YB29+TTLvy9R7Pkgsr41xIUiFL5WB+I/Us2w2zSF1qNiwOb2YI93UC WYWA5TEWSEK3cHZn8tq03rqfIVUS+FzOInIPzd1u6UaehnD+5x8D01W5JQ7WNuxzLpoF G9XEheursO0oeR5F+1S/QY0jykmgsnQMOzKrH4U6woLChkX2lSQTcv96hsWmUIGjz59m NpjgMP767eeCFjTxmk4iNRUIJOccrQGf3NOv3fuhOsh9NiogcIldQGFYBUxRENqYw10h OMf1oU3x1UznfQQkBLiyL4IQJZEyyW2Qbi5zwxMvOU5dzDMQA8J25/KO3eK2YH2a95UY bXLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xt1UGiPjPraq4SpUxRWULqHUBLr6thKTQdGzdb7dfpU=; b=JcdUGI97gPUClFyJ4Pkx4dG2krX43rgj0BGG0vn6jgJWdl70hPMw/aI8RW+fxIcxCl z3JU1tHu+HILswbtCIJ4zymbCebSw81MlRr7OEB+OWuDiRE8Wbaj4VJg3+HAmkcJtXlZ bmoGegT4KtPjCL66ZQIo0DvHnNXZP1g+czsjZ7LyLqcOArWCWh4gw9pSWQ3cA1vIU9q9 uW6brJUV36Dq0hkdiKHMm5gjwr1AdlzC40zxITXo54hpLEWxaANKiH5yMwhTvVmGmlhB 945QmpezstXjx24M8QzIh1nzI2yzE6Djuc2btT+ulX67YTVHJjGq/qTkWIiDX4LAuLl4 Od0Q== X-Gm-Message-State: AOAM5330gKHdDdGJu/fcW4Jtnln/+0RBWxeMbSPjJRDjj6VBgYJzEDKJ j6NjAMBBVo9hJx7tHBRE0MJ69mw62nSKHLBvysmkccsZO4c= X-Received: by 2002:a02:c00e:0:b0:317:c548:97c with SMTP id y14-20020a02c00e000000b00317c548097cmr24845913jai.234.1647369427778; Tue, 15 Mar 2022 11:37:07 -0700 (PDT) MIME-Version: 1.0 References: <20220312171354.661448-1-ytcoode@gmail.com> In-Reply-To: <20220312171354.661448-1-ytcoode@gmail.com> From: Andrii Nakryiko Date: Tue, 15 Mar 2022 11:36:56 -0700 Message-ID: Subject: Re: [PATCH bpf-next] libbpf: Remove redundant check in btf_ext__new() To: Yuntao Wang Cc: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Networking , bpf , open list Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no 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 Sat, Mar 12, 2022 at 9:14 AM Yuntao Wang wrote: > > Since 'core_relo_len' is the last field of 'struct btf_ext_header', if > 'xxx->hdr_len' is not less than 'offsetofend(xxx, core_relo_len)', then > 'xxx->hdr_len' must also be not less than 'offsetofend(xxx, line_info_len)'. > > We can check 'xxx->hdr_len < offsetofend(xxx, core_relo_len)' first, if it > passes, the 'xxx->hdr_len < offsetofend(xxx, line_info_len)' check will be > redundant, it can be removed. > > Signed-off-by: Yuntao Wang > --- > tools/lib/bpf/btf.c | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) > > diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c > index 1383e26c5d1f..d55b44124c3e 100644 > --- a/tools/lib/bpf/btf.c > +++ b/tools/lib/bpf/btf.c > @@ -2813,7 +2813,7 @@ struct btf_ext *btf_ext__new(const __u8 *data, __u32 size) > if (err) > goto done; > > - if (btf_ext->hdr->hdr_len < offsetofend(struct btf_ext_header, line_info_len)) { > + if (btf_ext->hdr->hdr_len < offsetofend(struct btf_ext_header, core_relo_len)) { > err = -EINVAL; > goto done; > } > @@ -2826,11 +2826,6 @@ struct btf_ext *btf_ext__new(const __u8 *data, __u32 size) > if (err) > goto done; > > - if (btf_ext->hdr->hdr_len < offsetofend(struct btf_ext_header, core_relo_len)) { > - err = -EINVAL; > - goto done; > - } it seems like it's actually a bug. If header is smaller then core relos parsing should be skipped, I think. Maybe let's fix that instead? basically the logic should be: 1. if size of header is exactly == offsetof(core_relo_off) then skip core relos 2. otherwise check that it has enough size to cover core_relo_off and core_relo_len, and error out if not 3. otherwise proceed to parsing core relos > - > err = btf_ext_setup_core_relos(btf_ext); > if (err) > goto done; > -- > 2.35.1 >