From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 75192C77B7D for ; Mon, 15 May 2023 19:27:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245051AbjEOT1N (ORCPT ); Mon, 15 May 2023 15:27:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42482 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245209AbjEOT0y (ORCPT ); Mon, 15 May 2023 15:26:54 -0400 Received: from www62.your-server.de (www62.your-server.de [213.133.104.62]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D491111B6C; Mon, 15 May 2023 12:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iogearbox.net; s=default2302; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=lXoK52Fe6kW0CWMrJKqKJEGH9DkEiqD01FgLyUl7s7g=; b=dtqWCor9ITYNxXRSr7OHKTFRJc o3DgfYVjDYAhIvGriT7EefUAx2OTizr8BlYhDHBnw2PUlwSYXbk2fmq4bz8uaVDXx3fsFjy6PmT7q C3vOa2JH6TuYCNO1AcWdjh+UFE7+uU414FgoaLFZJmV9vRZn8Nf159f1BnsGYrTcR+ht/ZyL4A/zx EKlBHim0Ph41InK492svugSiULU+3EgU+kDNfykOV+9uLZ3k2Ko9R06+3laYTxTszouUmSKYxkrYl kdZdAIXLpUrwJO39+EuCIy8Y/ACFaq+b0pIwC9N50I9LFRy1gv/OXvPQIfyB1kTTxCaAKszdXZMeL /2AM38Kg==; Received: from sslproxy05.your-server.de ([78.46.172.2]) by www62.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pydqE-000E0c-TB; Mon, 15 May 2023 21:26:42 +0200 Received: from [85.1.206.226] (helo=linux.home) by sslproxy05.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pydqE-0007iu-8s; Mon, 15 May 2023 21:26:42 +0200 Subject: Re: [PATCH bpf-next] bpf: btf: restore resolve_mode when popping the resolve stack To: Lorenz Bauer , Martin KaFai Lau , Alexei Starovoitov , Andrii Nakryiko , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org References: <20230515121521.30569-1-lmb@isovalent.com> From: Daniel Borkmann Message-ID: <6b585a75-ae1a-1ad5-2756-bcce78fbd2fd@iogearbox.net> Date: Mon, 15 May 2023 21:26:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20230515121521.30569-1-lmb@isovalent.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.103.8/26907/Mon May 15 09:25:12 2023) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/15/23 2:15 PM, Lorenz Bauer wrote: > In commit 9b459804ff99 ("btf: fix resolving BTF_KIND_VAR after ARRAY, STRUCT, UNION, PTR") > I fixed a bug that occurred during resolving of a DATASEC by strategically resetting > resolve_mode. This fixes the immediate bug but leaves us open to future bugs where > nested types have to be resolved. Lgtm, is there a way we could also craft a test case for this corner case? Thanks, Daniel