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 C248CC77B6C for ; Thu, 6 Apr 2023 22:35:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238308AbjDFWfc (ORCPT ); Thu, 6 Apr 2023 18:35:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230210AbjDFWf3 (ORCPT ); Thu, 6 Apr 2023 18:35:29 -0400 Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 748BA7ED3 for ; Thu, 6 Apr 2023 15:35:27 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id w4so38718344plg.9 for ; Thu, 06 Apr 2023 15:35:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680820527; x=1683412527; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Q2S3D1pZbFjzSQGr6ymBjndZ14Ty5JYYwZq/s9YKUYw=; b=NC/P+NUjLIH9ceTT5aAOEi4oKo521K55RNY3eFC1ntQyuCPpqCbfOPkdSm9tjhUjmo a3Br3WG0YiOIMINK170lf0Szcn+iT324gVFvydToNPxee1A+ug6gigKmLyG8XF6E72ll xJ1m8oJzEuToFZvcVhlMMlwz1sxmQd4wgxcqL9LTWf4E/Rag6Th1DMqV0bjP8ld/M55r SpEiNoOst7nyscQYC/8DrrUXoeRvF7qIKTEcOXs7z/FYkIIrUx/LvkoVxsBw+CZxh+c7 /uGWbsjECm913JmXGBkgenfkpjw5t/YW2bqnZ6vJXQ7awkoXgBDuOyzPs1DCAIUWVnCL LUHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680820527; x=1683412527; h=content-transfer-encoding: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=Q2S3D1pZbFjzSQGr6ymBjndZ14Ty5JYYwZq/s9YKUYw=; b=48KR+GB5Z3NNsPrZXdGWvWU7b9clcYQhuGpOmNtQTQ8nllYB4J0g0OGYZ2H3STluip KidK/djpvKMjFFsqkJ107YNWmQ0xNMCb9rjsFPnaKNE38TUlhcfDYeCxEUqpI02r6zgq TEF4KCYoK9bWkPHpc/FNjljzT/3T+eABfFtWwwtygHIz76Cm4vpIjUhoU9wX44UcsysF 2YsdL8J5SuPFCFlypLDZCKNIcCAuP+Jbklt9fDDljpSJkLhpJOpELkfsYi3iq/UcndSz IJYuPM9Bcnqr8w/xCU+Vqlrf79lf5hlSSZ2DKLW9ljRUN+YPW9BWiQVg1MkD6wzeQJB/ Y9XA== X-Gm-Message-State: AAQBX9dV3ivUhr01e9no6D6ugKvmKwJgcby2E3npGe25b5NfxgJrG6et pfHNVY5/SavZh0nox4PsmOo+3IWA/fuSGLNnsnJ9MQ== X-Google-Smtp-Source: AKy350ah2O8qYURR1sUGonwB93ZBhpzt1TblHI7jb/4F+Y4ShGWiAjdHhab88q75Bq27Kx1cNZs015oX4B64nE556dE= X-Received: by 2002:a17:902:ab93:b0:19a:7bd4:5b0d with SMTP id f19-20020a170902ab9300b0019a7bd45b0dmr262103plr.8.1680820526770; Thu, 06 Apr 2023 15:35:26 -0700 (PDT) MIME-Version: 1.0 References: <20230406004018.1439952-1-drosen@google.com> <20230406004018.1439952-2-drosen@google.com> In-Reply-To: From: Daniel Rosenberg Date: Thu, 6 Apr 2023 15:35:15 -0700 Message-ID: Subject: Re: [PATCH 1/3] bpf: verifier: Accept dynptr mem as mem in helpers To: Andrii Nakryiko Cc: bpf@vger.kernel.org, Alexei Starovoitov , Daniel Borkmann , John Fastabend , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Shuah Khan , Jonathan Corbet , Joanne Koong , Mykola Lysenko , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 6, 2023 at 1:55=E2=80=AFPM Andrii Nakryiko wrote: > > Something feels off here. Can you paste a bit of verifier log for the > failure you were getting. And let's have a selftest for this situation > as well. > > ARG_PTR_TO_MEM shouldn't be qualified with the DYNPTR_TYPE flag, it's > just memory, there is no need to know what type of dynptr it was > derived from. So if that happens, the problem is somewhere else. Let's > root cause and fix that. Having a selftest that demonstrates the > problem will help with that. > > This label is added by dynptr_slice(_rdwr) if (meta.func_id =3D=3D special_kfunc_list[KF_bpf_dynptr_slice] || meta.func_id =3D=3D special_kfunc_list[KF_bpf_dynptr_slice_rdwr]) { enum bpf_type_flag type_flag =3D get_dynptr_type_flag(meta.initialized_dynptr.type); ... regs[BPF_REG_0].type =3D PTR_TO_MEM | type_flag; That extra flag was causing the type to be unexpected later on. I'll add a selftest for this as well.