Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Song Liu <songliubraving@fb.com>
To:     Andrii Nakryiko <andrii@kernel.org>
CC:     bpf <bpf@vger.kernel.org>, Networking <netdev@vger.kernel.org>,
        "Alexei Starovoitov" <ast@fb.com>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Kernel Team <Kernel-team@fb.com>,
        open list <linux-kernel@vger.kernel.org>,
        "rafael@kernel.org" <rafael@kernel.org>,
        "jeyu@kernel.org" <jeyu@kernel.org>,
        Arnaldo Carvalho de Melo <acme@redhat.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v2 bpf-next 1/5] bpf: add in-kernel split BTF support
Thread-Topic: [PATCH v2 bpf-next 1/5] bpf: add in-kernel split BTF support
Thread-Index: AQHWtJFbvugjqI1ENU6MqzyHA3nlY6m74ToA
Date:   Sat, 7 Nov 2020 01:27:41 +0000
Message-ID: <712CED9D-91E3-4CF1-AAFC-3E970582D06D@fb.com>
References: <20201106230228.2202-1-andrii@kernel.org>
 <20201106230228.2202-2-andrii@kernel.org>
In-Reply-To: <20201106230228.2202-2-andrii@kernel.org>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5F8835E5381BF94D99BC38F893165B70@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 81fff83d-165c-4457-4f8c-08d882bc5222
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2020 01:27:41.4968
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: pXRhJaf2BvBeYLNAUdRyjQuWQrtM4U1DxCtLYRp/TPxR0z4bPv7oRmLoWPZhrxZMk5z1l7dx6ndVJ5x1lVdpFA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR15MB3713
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312,18.0.737
 definitions=2020-11-06_06:2020-11-05,2020-11-06 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 malwarescore=0
 phishscore=0 clxscore=1011 lowpriorityscore=0 mlxlogscore=999
 suspectscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 bulkscore=0
 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2009150000 definitions=main-2011070006
X-FB-Internal: deliver
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Nov 6, 2020, at 3:02 PM, Andrii Nakryiko <andrii@kernel.org> wrote:
>=20
> Adjust in-kernel BTF implementation to support a split BTF mode of operat=
ion.
> Changes are mostly mirroring libbpf split BTF changes, with the exception=
 of
> start_id being 0 for in-kernel implementation due to simpler read-only mo=
de.
>=20
> Otherwise, for split BTF logic, most of the logic of jumping to base BTF,
> where necessary, is encapsulated in few helper functions. Type numbering =
and
> string offset in a split BTF are logically continuing where base BTF ends=
, so
> most of the high-level logic is kept without changes.
>=20
> Type verification and size resolution is only doing an added resolution o=
f new
> split BTF types and relies on already cached size and type resolution res=
ults
> in the base BTF.
>=20
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>

[...]

>=20
> @@ -600,8 +618,15 @@ static const struct btf_kind_operations *btf_type_op=
s(const struct btf_type *t)
>=20
> static bool btf_name_offset_valid(const struct btf *btf, u32 offset)
> {
> -	return BTF_STR_OFFSET_VALID(offset) &&
> -		offset < btf->hdr.str_len;
> +	if (!BTF_STR_OFFSET_VALID(offset))
> +		return false;
> +again:
> +	if (offset < btf->start_str_off) {
> +		btf =3D btf->base_btf;
> +		goto again;

Can we do a while loop instead of "goto again;"?

> +	}
> +	offset -=3D btf->start_str_off;
> +	return offset < btf->hdr.str_len;
> }
>=20
> static bool __btf_name_char_ok(char c, bool first, bool dot_ok)
> @@ -615,10 +640,25 @@ static bool __btf_name_char_ok(char c, bool first, =
bool dot_ok)
> 	return true;
> }
>=20
> +static const char *btf_str_by_offset(const struct btf *btf, u32 offset)
> +{
> +again:
> +	if (offset < btf->start_str_off) {
> +		btf =3D btf->base_btf;
> +		goto again;
> +	}

Maybe add a btf_find_base_btf(btf, offset) helper for this logic?

> +
> +	offset -=3D btf->start_str_off;
> +	if (offset < btf->hdr.str_len)
> +		return &btf->strings[offset];
> +
> +	return NULL;
> +}
> +

[...]

> }
>=20
> const char *btf_name_by_offset(const struct btf *btf, u32 offset)
> {
> -	if (offset < btf->hdr.str_len)
> -		return &btf->strings[offset];
> -
> -	return NULL;
> +	return btf_str_by_offset(btf, offset);
> }

IIUC, btf_str_by_offset() and btf_name_by_offset() are identical. Can we
just keep btf_name_by_offset()?

>=20
> const struct btf_type *btf_type_by_id(const struct btf *btf, u32 type_id)
> {
> -	if (type_id > btf->nr_types)
> -		return NULL;
> +again:
> +	if (type_id < btf->start_id) {
> +		btf =3D btf->base_btf;
> +		goto again;
> +	}

ditto, goto again..

[...]