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.nakryiko@gmail.com>
CC:     Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
        Networking <netdev@vger.kernel.org>,
        Alexei Starovoitov <ast@fb.com>,
        "daniel@iogearbox.net" <daniel@iogearbox.net>,
        Kernel Team <Kernel-team@fb.com>,
        "linux-kernel@vger.kernel.org" <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 v4 bpf-next 1/5] bpf: add in-kernel split BTF support
Thread-Topic: [PATCH v4 bpf-next 1/5] bpf: add in-kernel split BTF support
Thread-Index: AQHWtwAHoXtpfdzO80ynz0OJjXLTl6nBpcmAgAALm4CAABzogA==
Date:   Tue, 10 Nov 2020 20:14:54 +0000
Message-ID: <E26C39E9-51C4-4E31-87AC-69CADE54A15F@fb.com>
References: <20201110011932.3201430-1-andrii@kernel.org>
 <20201110011932.3201430-2-andrii@kernel.org>
 <695E976D-DECA-4BE1-BFB0-771878B9CFCD@fb.com>
 <CAEf4BzYORuxNUvJDTe4cPvJ18HNhFDOuYGfLdUzuwHeddVLw6Q@mail.gmail.com>
In-Reply-To: <CAEf4BzYORuxNUvJDTe4cPvJ18HNhFDOuYGfLdUzuwHeddVLw6Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <15F7E46AD723EA4397CC868834F59A4D@namprd15.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a58e7411-a231-4a7d-5809-08d885b54983
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2020 20:14:54.1424
 (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: Mn0a/BFmmCtu9cAVlJ5CF+jFI7uoTaFUFLAHnuG9M86Y/C+AAiVv88tr6TXOvukONkwur4OfC/XEfLdkcvImYg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB2824
X-OriginatorOrg: fb.com
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312,18.0.737
 definitions=2020-11-10_07:2020-11-10,2020-11-10 signatures=0
X-Proofpoint-Spam-Details: rule=fb_default_notspam policy=fb_default score=0 spamscore=0 clxscore=1015
 suspectscore=0 lowpriorityscore=0 malwarescore=0 adultscore=0 phishscore=0
 bulkscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000
 definitions=main-2011100137
X-FB-Internal: deliver
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


> On Nov 10, 2020, at 10:31 AM, Andrii Nakryiko <andrii.nakryiko@gmail.com>=
 wrote:
>=20
> On Tue, Nov 10, 2020 at 9:50 AM Song Liu <songliubraving@fb.com> wrote:
>>=20
>>=20
>>=20
>>> On Nov 9, 2020, at 5:19 PM, Andrii Nakryiko <andrii@kernel.org> wrote:
>>>=20
>>> Adjust in-kernel BTF implementation to support a split BTF mode of oper=
ation.
>>> Changes are mostly mirroring libbpf split BTF changes, with the excepti=
on of
>>> start_id being 0 for in-kernel implementation due to simpler read-only =
mode.
>>>=20
>>> Otherwise, for split BTF logic, most of the logic of jumping to base BT=
F,
>>> where necessary, is encapsulated in few helper functions. Type numberin=
g and
>>> string offset in a split BTF are logically continuing where base BTF en=
ds, so
>>> most of the high-level logic is kept without changes.
>>>=20
>>> Type verification and size resolution is only doing an added resolution=
 of new
>>> split BTF types and relies on already cached size and type resolution r=
esults
>>> in the base BTF.
>>>=20
>>> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
>>> ---
>>> kernel/bpf/btf.c | 171 +++++++++++++++++++++++++++++++++--------------
>>> 1 file changed, 119 insertions(+), 52 deletions(-)
>>>=20
>>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>>> index 6324de8c59f7..727c1c27053f 100644
>>> --- a/kernel/bpf/btf.c
>>> +++ b/kernel/bpf/btf.c
>>> @@ -203,12 +203,17 @@ struct btf {
>>>      const char *strings;
>>>      void *nohdr_data;
>>>      struct btf_header hdr;
>>> -     u32 nr_types;
>>> +     u32 nr_types; /* includes VOID for base BTF */
>>>      u32 types_size;
>>>      u32 data_size;
>>>      refcount_t refcnt;
>>>      u32 id;
>>>      struct rcu_head rcu;
>>> +
>>> +     /* split BTF support */
>>> +     struct btf *base_btf;
>>> +     u32 start_id; /* first type ID in this BTF (0 for base BTF) */
>>> +     u32 start_str_off; /* first string offset (0 for base BTF) */
>>> };
>>>=20
>>> enum verifier_phase {
>>> @@ -449,14 +454,27 @@ static bool btf_type_is_datasec(const struct btf_=
type *t)
>>>      return BTF_INFO_KIND(t->info) =3D=3D BTF_KIND_DATASEC;
>>> }
>>>=20
>>> +static u32 btf_nr_types_total(const struct btf *btf)
>>> +{
>>> +     u32 total =3D 0;
>>> +
>>> +     while (btf) {
>>> +             total +=3D btf->nr_types;
>>> +             btf =3D btf->base_btf;
>>> +     }
>>> +
>>> +     return total;
>>> +}
>>> +
>>> s32 btf_find_by_name_kind(const struct btf *btf, const char *name, u8 k=
ind)
>>> {
>>>      const struct btf_type *t;
>>>      const char *tname;
>>> -     u32 i;
>>> +     u32 i, total;
>>>=20
>>> -     for (i =3D 1; i <=3D btf->nr_types; i++) {
>>> -             t =3D btf->types[i];
>>> +     total =3D btf_nr_types_total(btf);
>>> +     for (i =3D 1; i < total; i++) {
>>> +             t =3D btf_type_by_id(btf, i);
>>>              if (BTF_INFO_KIND(t->info) !=3D kind)
>>>                      continue;
>>>=20
>>> @@ -599,8 +617,14 @@ static const struct btf_kind_operations *btf_type_=
ops(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;
>>> +
>>> +     while (offset < btf->start_str_off)
>>> +             btf =3D btf->base_btf;
>>=20
>> Do we need "if (!btf) return false;" in the while loop? (and some other =
loops below)
>=20
> No, because for base btf start_str_off and start_type_id are always
> zero, so loop condition is always false.

Ah, I misread the code. Thanks for the explanation.=20

Acked-by: Song Liu <songliubraving@fb.com>=