From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E932337BE99 for ; Tue, 18 Aug 2026 21:38:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787089111; cv=none; b=s80JKDgTLQW4V5tqxKJz4vhB/7/llGXRNLjs5Df9YreuOwK7KDSlV1kyx0iSC0G84ej//VT25tGYdmdaNkwtj1NJgunhRar26X11QJy9tJDN4IefvpwhFY3g2Yp39EjzH0E8GJtBYMVP94nBCxF80i1RByNNF7bULBZ0XuZl8A4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787089111; c=relaxed/simple; bh=GPinSQFO4keSd1Q5bC5YTK7Ezticd5+rWlEfu42Fe/E=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=pGNlRknPOo06jc9KagOVW7+IqPcS7TIMTxhDBcp4vpwk6m/SZRm66DBdeo0xlNNug8Q62kH3QhkBoZx3vLcYm/ZaIW0SR+z1+39s1DOTd6cHWWhAQDEWuVxEx5tGL3twkn7J+5+Heoy8W9Z+ZdI5oJdbxGsj2+KIkj2KpuZ27pg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=DHqH2vfI; arc=none smtp.client-ip=209.85.216.47 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="DHqH2vfI" Received: by mail-pj1-f47.google.com with SMTP id 98e67ed59e1d1-38511175ad3so404860a91.2 for ; Tue, 18 Aug 2026 14:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787089109; x=1787693909; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to:content-type; bh=5pr8D9dTko0nm5cpxv7gLu3MP5nFNJnzsxpSKuqHUmo=; b=DHqH2vfI3CokoJHsnQ2zLyJc+J9LVADwT0fEANQxoIF4V2+R9fY24HG1QvTqD+SQv7 7yrs7/cpYTV1RcV4ORupXm5oq9+NODSsrstcGeuy86MrjBkEPKZ1xGE9jKAy6KjBumvn j16Nl3Rlhd+27KFWoatYUulQNQJD9rymfk0cEOfHU0WVsBwKNa2PMwNmdD1P8KL+rJEP cy+qr7AXdFf3/rOG4o7KExAMBatknXXDPNlUKEtQOPIoAvv/7v7RyKSNtZE598C2F2x3 OYH9XlgZR3Gc/YKfEdzZQ9E1RwuH+wog28obhfP2MGek1YtAAdXYlwnPZex6xd6HcUWr Ep6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787089109; x=1787693909; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=5pr8D9dTko0nm5cpxv7gLu3MP5nFNJnzsxpSKuqHUmo=; b=ZrwwVHTUfpMcU4IbmTZeruF78gAp7P9/7pDuYkHslMQg/YHPhQNZCoxRp+EEBlLbSf 4vOFIkDYgkEaSZBx+LSrr7BvOZNHkfj5c+6vMSZSjefN5tJQPpQCOBa3KsSa6BFTJFZE CcC1VS/qH6RjWM/DwUP1kDv9ND3BX58NCVzrq27QUA757gkKg/6Oqt8BooA7VnwTfHRv wmU0YNj7PQp6rmaEsjL9agAImfZfKUwBrivjI2A5sAxrLZHSferjCzjfc4W26ZUTl1Hg TWe/5Qn7EPGA5a3RqNBF/aHgLO48L2lts1kZjma7xkuM+LeXN0hbo35lSmS5C4gd743s NHDA== X-Forwarded-Encrypted: i=1; AHgh+RqcP0U3rKxsuBbu/9d4p8xk8jpGyr6tUpLxVx95swmj9KcdPLTHJWSWhHXwHOaPP0J6RbKPVyOzJpjSR50=@vger.kernel.org X-Gm-Message-State: AOJu0YxnSRUEomh2OpV1em9E0yVzm9fPFnW0b7mwEhazA5gqXeN+lcln w1xgQMKAeoz0/pGhPHhV1jCo3ab/nd1TKayqFTEjek7dOlL7WUvEUh1T X-Gm-Gg: AR+sD13oChLDjrOyA5U5c7VFLy+ABmWmYiu6dSA/7WD6rU2E1vhOcaupQ+dzVt7uNTH mf2itm/Q8+5Ch4vvyhcUzfuIpRo7F8SjAv5pUCtFPGtLbl+WSBNypebyEuXLs91vCOntNRIrr+n z+HxcgwF/VzLGmETUKZPf73Bn6owO3etOwdxrsbry2zmCSUtOv4U3tdUile/p63IH8+YbsCfbM8 Ud9FklJ6Vz2A27x5keGofmJ5xedfPr4sCJ4Ne7mcEh47IEZpoEdM93qYqoEY5MR06I/5U33dtXA Gf/m0GVpDco1ZucEzSQV1hv4L2P82kdjVtJGYjmy8nC9SFh7wvjdtxVmetseKHUPZHXXMu3z9rL +9wrPLI7RgXUi8IbvZ60lDpXMTZqOJ6osxazcpnsMnaxLljN3dVtb01YR80NXopwc1C1iMneWLZ eVj8rwFrav62kJczHdRtvcS8j0o05WRY+0HyTU+XRV3XkhvfVW0UjKal13RQ8A8CRL0d2O8GRoL JkUe2rFfB3rvqFkBux6nRS9tDI= X-Received: by 2002:a17:90b:54c5:b0:38e:6aa7:68ad with SMTP id 98e67ed59e1d1-3957b1c5cc4mr1267082a91.5.1787089109181; Tue, 18 Aug 2026 14:38:29 -0700 (PDT) Received: from [192.168.0.13] ([38.34.87.7]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-3957fbba811sm122046a91.13.2026.08.18.14.38.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Aug 2026 14:38:28 -0700 (PDT) Message-ID: <17813f00c2c81cd2588672197cc6d4de619ca36b.camel@gmail.com> Subject: Re: [RFC bpf-next 1/6] bpf: turn bpf_reg_state->precise into a flags field [NFC] From: Eduard Zingerman To: Vineet Gupta , ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org, memxor@gmail.com Cc: martin.lau@linux.dev, song@kernel.org, yonghong.song@linux.dev, jolsa@kernel.org, emil@etsalapatis.com, ihor.solodrai@linux.dev, john.fastabend@gmail.com, shuah@kernel.org, bpf@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Date: Tue, 18 Aug 2026 14:38:25 -0700 In-Reply-To: <20260814231945.3884596-2-vineet.gupta@linux.dev> References: <20260814231945.3884596-1-vineet.gupta@linux.dev> <20260814231945.3884596-2-vineet.gupta@linux.dev> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2-10 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Fri, 2026-08-14 at 16:19 -0700, Vineet Gupta wrote: > bpf_reg_state carries a single bool, ->precise. Other per-register boolea= n > properties exist (and more are coming), so convert the bool into a u8, > call it flags and give the property a name. >=20 > =C2=A0 - bool precise; > =C2=A0 +#define BPF_FLAG_PRECISE (1U << 7) > =C2=A0 + u8 flags; >=20 > Both occupy 1 byte at the same offset, so the struct layout is unchanged. > ->precise was the last field, after ->frameno, and ->flags takes exactly > that slot, so the memcmp()/offsetof() based comparisons are unaffected: > every one of them stops at offsetof(id), offsetof(var_off) or > offsetof(frameno), i.e. at or before the field either way. >=20 > That tail position is not an accident -- it is where fields live that are > compared semantically rather than byte-wise. ->precise is never memcmp()e= d; > regsafe() tests it explicitly, and an imprecise old scalar is a wildcard: >=20 > if (!reg_is_precise(rold) && exact =3D=3D NOT_EXACT) > return true; >=20 > PRECISE also takes bit 7 rather than bit 0, because it is the odd one out > among the flags that will share this byte: the others describe how a regi= ster > relates to its ->id set and are cleared as a group, while PRECISE belongs= to > the register alone and must survive that clearing. Growing the rest up fr= om > bit 0 keeps a clear-the-link-bits mask from reaching it by construction. >=20 > Reads go through a helper, since they are the common case and read better= . > Set and clear stay open-coded as the usual reg->flags |=3D / &=3D ~ bit o= ps. >=20 > No functional change intended. >=20 > Suggested-by: Eduard Zingerman > Signed-off-by: Vineet Gupta > --- Sorry for the confusion, what I intended to suggest is usage of bitfields, instead of carving out bits from the 'id' field. Let me read the rest of the series to see how the flags look overall, but looking just at this patch I'd suggest bitfields.