Received: by 2002:a05:6358:45e:b0:b5:b6eb:e1f9 with SMTP id 30csp3676205rwe; Mon, 29 Aug 2022 17:33:31 -0700 (PDT) X-Google-Smtp-Source: AA6agR4/3RWhtuKIaSBxcUv7CjEHcVYnwr+nSOOnt70YKHe4wsZjPK1kSxJI/XB9uNjFDoWoFGOJ X-Received: by 2002:a17:907:728d:b0:73d:693c:738 with SMTP id dt13-20020a170907728d00b0073d693c0738mr15102987ejc.134.1661819611020; Mon, 29 Aug 2022 17:33:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661819611; cv=none; d=google.com; s=arc-20160816; b=hfCvOB7c0xwVWcexLtTHncII061E6nstUhRxCEejMADslZ18rDS9/09tWii6MRs50/ 3u+Xu5Nye1FcBV7zpcWtnU004Ml7Phe2fyCRGDGycrAvXgCy8EmM3GXYwL/ZvbN+ok2U e8QUEhWL5VhBumvhahkib+YWlV3krDi9E+pOLwOGCm9btzk1rYP8M7wnDlhOsf0k2ax3 YZKlfOXsXyYfE4UWR/DiL/TUd+vpRaaKD6DnP2/KHx4ZppusFzF/iByPx24aKe1ulSJ3 /p+KCrZyqTobdFfqHNYhFPNQcaeqzaNssCOD9/Y239jiw/jk5JpjpKlHqLqN2fP5qSM3 /37Q== 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=+IcUApVhhRXn9dL/Sn9lQ7owQd37yO7YZ+ZOj1J1q9c=; b=sSLvFjZfntm3aeCi0r+LtkbZJvWDE55jVM3hTpVWAUd2FaN7bJN7sgujHid06/XfZ+ EC2MughCLiAinzGjAsf86BOQvcKZDnpzcIeiD1cf/qB2wYpGpKlXLit7hyT0y/wI0mkd MqjEDlqgsuDluesrLrrC7e6Z45cpWnekQ4jW4CaEgW+I0RJxe/5E/9rrAXirw1zZPH/n GLY6RdauRpIYO7pZaF1jIvwze6FyP7LHBehoxLNk7a3ibXw8vAohNVBEsE8oDVNqtnTL 26O3xa1wqLaixZPliwsvwiZGAx8vkhWncUczzbnSgdcsZ9SUo05aNVjELselZD1+Umvw Oogg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=icKnWS+4; 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 s4-20020a170906a18400b0072f0f088ed7si6632091ejy.712.2022.08.29.17.33.06; Mon, 29 Aug 2022 17:33:31 -0700 (PDT) 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=icKnWS+4; 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 S229622AbiH3AT0 (ORCPT + 99 others); Mon, 29 Aug 2022 20:19:26 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229579AbiH3ATY (ORCPT ); Mon, 29 Aug 2022 20:19:24 -0400 Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 634AC7C772 for ; Mon, 29 Aug 2022 17:19:23 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id x14so3112733qvr.6 for ; Mon, 29 Aug 2022 17:19:23 -0700 (PDT) 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; bh=+IcUApVhhRXn9dL/Sn9lQ7owQd37yO7YZ+ZOj1J1q9c=; b=icKnWS+4zvyLBC2dPq3Jw3kDx+SdPoS9gqv5cR59cRvHUjDeKnl06BAse9dQOTFqpF t2b8cvzyqfXN+vVN0w94czWiNhW3qigbU7WugRjslUoUPKfjdIZUW6rXaodBZFRE0CUR pKyCeWZ/AWqrOj7fO5LOJVIFy/m1hA6HESsMqvYnjYN/yv2BrGjVK44oIxPDNWfC53d1 nQv0pY0EH7HXyO2cQUfZj2mGZ38D5rem6rasFohmD1kcXB7kfPk+KFCzVmq8u4kKVSX7 eMKBxZI+sv+z+gCUxC01usErbm/53WD+Oram6DXVcZT/nfI6NrSXKlRUKi4SpOsvZ+fX CLuA== 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; bh=+IcUApVhhRXn9dL/Sn9lQ7owQd37yO7YZ+ZOj1J1q9c=; b=BS85PkRE8SLQ8WMAdCKFvNCh7w3HVa3H/gv6rqkkQ37YoBIbOaEtAvXFHCiZPA/MCx u3MpGMnpDzBpPwwC2T4WM24h59B1TdZrPh2I9lyGLpckNtLGKL8jh+FNeNWGZz2KKzi9 zO38S5bMjKnc9s49fYJqIo+8iviPPjh+EnkfpeoxnTPRVz5arAMMVC0KOFKA1y6zXNPN 8UldvVBkeEH3YNWfeWllQO3YJy6JnzBVTCwHO9Nd9gb8g0pmsgom2rTI7tW4+1+qPbCv zZwJi8anQELM2jo3CpWGWy1n/Sohek0y7sfX8d11CxD56BaNzTiIkKy+SiWfRvWk2SNr Ve/Q== X-Gm-Message-State: ACgBeo2wlyMSsqzb5+3dJ2ZFxXYURyxi+12OEWp8kOc6/LCC/N1cdB0Y zT+NWfBp5aYEAQV7rNCldB3Uqwhcj7xEDj1pGB3Gng== X-Received: by 2002:a05:6214:2267:b0:474:8ff7:a21c with SMTP id gs7-20020a056214226700b004748ff7a21cmr13080856qvb.56.1661818762403; Mon, 29 Aug 2022 17:19:22 -0700 (PDT) MIME-Version: 1.0 References: <5d2addca-10e5-f7a6-9efd-43322eec8347@iogearbox.net> <20220827135711.21507-1-liulin063@gmail.com> In-Reply-To: <20220827135711.21507-1-liulin063@gmail.com> From: Hao Luo Date: Mon, 29 Aug 2022 17:19:10 -0700 Message-ID: Subject: Re: [PATCH bpf v2 1/2] bpf: Do more tight ALU bounds tracking To: Youlin Li Cc: daniel@iogearbox.net, ast@kernel.org, john.fastabend@gmail.com, andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com, kpsingh@kernel.org, sdf@google.com, jolsa@kernel.org, bpf@vger.kernel.org, linux-kernel@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, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Hi Youlin, On Sat, Aug 27, 2022 at 6:57 AM Youlin Li wrote: > > In adjust_scalar_min_max_vals(), let 32bit bounds learn from 64bit bounds > to get more tight bounds tracking. Similar operation can be found in > reg_set_min_max(). > > Note that we cannot simply add a call to __reg_combine_64_into_32(). In > previous versions of the code, when __reg_combine_64_into_32() was > called, the 32bit boundary was completely deduced from the 64bit > boundary, so there was a call to __mark_reg32_unbounded() in > __reg_combine_64_into_32(). But in adjust_scalar_min_max_vals(), the 32bit > bounds are already calculated to some extent, and __mark_reg32_unbounded() > will eliminate these information. > > Simply copying a code without __mark_reg32_unbounded() should work. > > Also, we can now fold reg_bounds_sync() into zext_32_to_64(). > > Before: > > func#0 @0 > 0: R1=ctx(off=0,imm=0) R10=fp0 > 0: (b7) r0 = 0 ; R0_w=0 > 1: (b7) r1 = 0 ; R1_w=0 > 2: (87) r1 = -r1 ; R1_w=scalar() > 3: (87) r1 = -r1 ; R1_w=scalar() > 4: (c7) r1 s>>= 63 ; R1_w=scalar(smin=-1,smax=0) > 5: (07) r1 += 2 ; R1_w=scalar(umin=1,umax=2,var_off=(0x0; 0xffffffff)) <--- [*] > 6: (95) exit > > It can be seen that even if the 64bit bounds is clear here, the 32bit > bounds is still in the state of 'UNKNOWN'. > > After: > > func#0 @0 > 0: R1=ctx(off=0,imm=0) R10=fp0 > 0: (b7) r0 = 0 ; R0_w=0 > 1: (b7) r1 = 0 ; R1_w=0 > 2: (87) r1 = -r1 ; R1_w=scalar() > 3: (87) r1 = -r1 ; R1_w=scalar() > 4: (c7) r1 s>>= 63 ; R1_w=scalar(smin=-1,smax=0) > 5: (07) r1 += 2 ; R1_w=scalar(umin=1,umax=2,var_off=(0x0; 0x3)) <--- [*] > 6: (95) exit > > Signed-off-by: Youlin Li > --- It might be better to put the code that performs the actual bounds deduction into a helper function. It avoids code duplication. But the current version looks fine to me. Thanks for the patch! Acked-by: Hao Luo