Received-SPF: pass (google.com: domain of linux-kernel+bounces-155373-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <a60a0842-cff9-407b-b970-316e615e22e1@oracle.com>
Date: Tue, 23 Apr 2024 15:30:03 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] libbpf: extending BTF_KIND_INIT to accommodate some
 unusual types
To: Xin Liu <liuxin350@huawei.com>, ast@kernel.org, daniel@iogearbox.net,
        andrii@kernel.org, martin.lau@linux.dev, song@kernel.org, yhs@fb.com,
        john.fastabend@gmail.com, kpsingh@kernel.org, sdf@google.com,
        haoluo@google.com, jolsa@kernel.org
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org, yanan@huawei.com,
        wuchangye@huawei.com, xiesongyang@huawei.com, kongweibin2@huawei.com,
        zhangmingyi5@huawei.com, liwei883@huawei.com
References: <20240423131503.361149-1-liuxin350@huawei.com>
Content-Language: en-GB
From: Alan Maguire <alan.maguire@oracle.com>
In-Reply-To: <20240423131503.361149-1-liuxin350@huawei.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?Z1NMdlpTVTJHSGRuN0NDemZtU0o2UlE3eDY1V0lXUDZoQ0RPYVFTYlFva1ZK?=
 =?utf-8?B?SzZOdS9qRnA1SGQybmpyZkhLSkR3UllhQmtvVkNLUlZHeG1hVVZOVDJiZ05D?=
 =?utf-8?B?UTNmaC91djlnckFLeEpEZ1h4eXBkdkNrSkVLZENNUmUrWjZxQ0ZMWEVWWGs5?=
 =?utf-8?B?U3g3TmdQL3BtYmQ4OXJ0czkrNFFjSTY0bDBEYS9vZjlZbUV2aU5QL3JCL0NS?=
 =?utf-8?B?Q0ltTHRWMFVCcnZCaHJJUEo2dzMxazdhTnVUY2NRdHJ3TUlIMDIvK2xzdVhE?=
 =?utf-8?B?ZWxiWUEybUJ3YUxVVmdNVUJHUG02M1JiREVnQzVhK090QlR4Q2QvLzBvQkxY?=
 =?utf-8?B?WEJsN3p6QTNGdDdCUXNjZmZVZjd6QTN6UTFJYlVMYldzb1c1dVZHQUI1dGxJ?=
 =?utf-8?B?ZHBsODFDbW1pZ3NGbDBxQXdEdUpIVk9CVmtVRUhOY2I4b3JSMU82aklaZkxK?=
 =?utf-8?B?ejFZYlZ2QVJ2WTN4WUNITnFDOVY3eEJDaktSSTdlU3ZEYjE1aFVVOXBGQTF6?=
 =?utf-8?B?S3cwaEJSYXNkWEpPSytVRUxaM1YrNEY2WEFOeitERVJUY2VtMHhmNWhwMFVB?=
 =?utf-8?B?UVArYkowMGdLRE5Fc08wenNOS0M3dkFtdy9WR1BBQlhWTTBIOWJMYmhnNENt?=
 =?utf-8?B?NGd5WG5DRnBxMUlvL25LUFU0UVljSHF5SUtKQkZHcWVsRTZkRjc4aGYxYmJT?=
 =?utf-8?B?NlZJK1NxeUEwN2UvV0MyTHJmVGw3bC9RRWZEVmxZZ1ZLWm9ycTArN2phT2Nx?=
 =?utf-8?B?L1dXZlAvc2xKK2J5VmdSYWFwS2xSVERCR05JUkNUQUV1TVUrNE5vMEVqT0lS?=
 =?utf-8?B?ejdXY0o4YWZyRnZ6NzlqOERmYnp5dDIyaGF5aXo3MUV6M1ZvYTVZUHYweTNs?=
 =?utf-8?B?c1Q0RlBuOG9DMTBDbzZVUy92MTgrdUVFU2w3Um9vT0NQUWRRNE9XLzRtOHFP?=
 =?utf-8?B?bW5RNExaTXNWVVNmUzlLY1JldGVZZWgxNEM4WW9uMDhRK09JTVIraWRkU0t0?=
 =?utf-8?B?WXViR2U1Vmt5MTFhc2FIYzRVT3lKaGQ2VDJqNUlOUEc5MVAxN0pRUkxBWmpD?=
 =?utf-8?B?Zi9Xd2JzbVpQQjYzOG5DekYwa0IxdGxYR24wcW5id3ZMaDYwa2Yyb3JWOUlI?=
 =?utf-8?B?MllxSkozQXlzcUpUMUcyMEFGK29WQXpVSFUzbng4TnJrNHQ4aGdkUVFUc21l?=
 =?utf-8?B?Wm9FR2dXUnlnNEEyVFRhRW5vYmp4b256YlF4YXZ2amc1MTAyTW1JbTB2N3Mw?=
 =?utf-8?B?NGpSL3pHR1NkcEoyVlp0UUEwYW9obkxIdllWZllDQXp0N0VsRjlod0xMdG5P?=
 =?utf-8?B?bDY0YWNVZHh2em4yRGxTbnM0RHAwRkNLWmZIWGRjNjdzTzVoMDNzN3dsSENH?=
 =?utf-8?B?KzVMeWVkYmRjRjByNVNiRDRBeXlKbkx4bGg0NFppaitESXgzODMvemt2NVlz?=
 =?utf-8?B?Yk5jK1BpS2RYTGVFc1Z6QVRNQ2lQOGtSWUkrd0VsMHRVZkU0ckgyR2ViOEJy?=
 =?utf-8?B?RjgwMzhwNVVGYTBndU5wWTJlY3lpb3M0cnMzVDVOZzdOaTBOOU9tRDhGVURw?=
 =?utf-8?B?QVhnVUZVS0xJSVNvRGN1NXgxU2tlMEMyUlovL2RxSVVtNUV1Y0JYOWNJaEhG?=
 =?utf-8?B?ZklaQ2JXZ01HekZZMWt3c2graDRWbllLL2V1WGI5QmdMRDZtNzM3a1BTUWw2?=
 =?utf-8?B?OElKVXRnbFg4OTk5cm1WUGxSWGlWTTRnNUgreFFSWUJhaVNHTHdyZWRtbTB0?=
 =?utf-8?B?QmdmTC84c1VOdWNGVlVQRTg2TFZCOWxQbDdoK0tVRjh6S0wzSXdHNGdQd2FS?=
 =?utf-8?B?cm80ZkpTWTJPbGdZV0FlVUREaGVEV2dNdHVJTHF3T1lYTTM4d1oyRkd5TjA0?=
 =?utf-8?B?aFRvaGE3Y2lFWjJOZ0lmSEVEc1lQalZDa09EVEE4MFJwZFM1RElxc3NhREEv?=
 =?utf-8?B?M3VwRzJvQU5ILytQdFZTVS92WXFSVDJpdUEwMEdWYWRKdGJndGdYK1dobVBH?=
 =?utf-8?B?QzVzU1NHRE8rdFJ2U25xVGRxY3ROMStlclVmUi9tY3N4YVF0ZEU0Q0dhUWRO?=
 =?utf-8?B?bzlqczNXWUxzeEU0dGp2YmtYeFprRXlkUXd1Y3R1dFIra3RQc1pvbkZVem4x?=
 =?utf-8?B?R0I4NEFEL0txbkNhRlFESjh6WGVRK3ZWbkN3a3dsa2Z3ekh2eWJWM3lQdlZD?=
 =?utf-8?Q?Zy6aXNvx1MGn976s5EPTnc4=3D?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	IhIKdDbuLXxi7Q8tul5DBOCArt0FRXs+Y+GBMNcIqs/AEm3fLvX9P+BsA988T/jT+40yaCdsgmRsLgMMLYRRZ90ezbDlts4emyUSmIisiPJWdgo/htYE+NSBfhHqUChj6BksDNt44I2l9hj2XqX4m7bQO5QW9VDDDPqb5gTftSFLiSYHdBHLp1X/TOoTcFdSJo2eR+HNHKUOxy7V/vjxR8Br7tcGch5APwvxi5uF9Fg3S1zl5RWi4cQGRXBlz9MRaPdcs+zavvRySuKunCWTjA3nZ8Leeo7pGSVNqNxnXCMQihthf9Fffy1LoYwNmPhvweN8+jvuKIbCSALp2AAz4JH3ciJrq7MhxyeJRum1jP92hcntgUSPlCYh3Rt8nkpXMGVNEBfRRRBf6HhiZkU1Uw3j+U5lvE3i/Jo7N4SP5GGQZH5A4kYj6Zy5sTqfMZqwMv1YzAUYGjD6Xt5CPxfm35qOLXGZW8bFwh7+lfwk+bkKMjNOYW/iiYBeCEq8E9cHQPx/Uv/L5wKEAhn6ywTw+Y5+QJWtpAF0PTBZu7hoDkIAWvX4gRqFKIHENBl0tVw/WY5Od1yrLQyc+pfQylEq11FS4W4NDDNIjMJ7tBOi9Vc=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 67b8d56b-16c9-45bb-fdb8-08dc63a1e041
X-MS-Exchange-CrossTenant-AuthSource: BLAPR10MB5267.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2024 14:30:08.5175
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: vY4g4tizCgh57fZPUjtGuFRy4lfquBpdWqi5UzKZSLMd7qlJwnLYZCie4m6ZOxq9osLxVz0LNgyNbZMIzRK88w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR10MB5076
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26
 definitions=2024-04-23_12,2024-04-23_01,2023-05-22_02
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 suspectscore=0 mlxscore=0
 mlxlogscore=999 bulkscore=0 malwarescore=0 spamscore=0 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2404010000
 definitions=main-2404230035
X-Proofpoint-GUID: Zk0S1UNzhKTYAPdKvHDH7SeCgEOZ4SRU
X-Proofpoint-ORIG-GUID: Zk0S1UNzhKTYAPdKvHDH7SeCgEOZ4SRU

On 23/04/2024 14:15, Xin Liu wrote:
> On Mon, 22 Apr 2024 10:43:38 -0700 Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> 
>> On Mon, Apr 22, 2024 at 7:46 AM Xin Liu <liuxin350@huawei.com> wrote:
>>>
>>> In btf__add_int, the size of the new btf_kind_int type is limited.
>>> When the size is greater than 16, btf__add_int fails to be added
>>> and -EINVAL is returned. This is usually effective.
>>>
>>> However, when the built-in type __builtin_aarch64_simd_xi in the
>>> NEON instruction is used in the code in the arm64 system, the value
>>> of DW_AT_byte_size is 64. This causes btf__add_int to fail to
>>> properly add btf information to it.
>>>
>>> like this:
>>>   ...
>>>    <1><cf>: Abbrev Number: 2 (DW_TAG_base_type)
>>>     <d0>   DW_AT_byte_size   : 64              // over max size 16
>>>     <d1>   DW_AT_encoding    : 5        (signed)
>>>     <d2>   DW_AT_name        : (indirect string, offset: 0x53): __builtin_aarch64_simd_xi
>>>    <1><d6>: Abbrev Number: 0
>>>   ...
>>>
>>> An easier way to solve this problem is to treat it as a base type
>>> and set byte_size to 64. This patch is modified along these lines.
>>>
>>> Fixes: 4a3b33f8579a ("libbpf: Add BTF writing APIs")
>>> Signed-off-by: Xin Liu <liuxin350@huawei.com>
>>> ---
>>>  tools/lib/bpf/btf.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
>>> index 2d0840ef599a..0af121293b65 100644
>>> --- a/tools/lib/bpf/btf.c
>>> +++ b/tools/lib/bpf/btf.c
>>> @@ -1934,7 +1934,7 @@ int btf__add_int(struct btf *btf, const char *name, size_t byte_sz, int encoding
>>>         if (!name || !name[0])
>>>                 return libbpf_err(-EINVAL);
>>>         /* byte_sz must be power of 2 */
>>> -       if (!byte_sz || (byte_sz & (byte_sz - 1)) || byte_sz > 16)
>>> +       if (!byte_sz || (byte_sz & (byte_sz - 1)) || byte_sz > 64)
>>
>>
>> maybe we should just remove byte_sz upper limit? We can probably
>> imagine 256-byte integers at some point, so why bother artificially
>> restricting it?
>>
>> pw-bot: cr
> 
> In the current definition of btf_kind_int, bits has only 8 bits, followed
> by 8 bits of unused interval. When we expand, we should only use 16 bits
> at most, so the maximum value should be 8192(1 << 16 / 8), directly removing
> the limit of byte_sz. It may not fit the current design. For INT type btfs
> greater than 255, how to dump is still a challenge.
> 
> Does the current version support a maximum of 8192 bytes?
> 

Presuming we expanded BTF_INT_BITS() as per

-#define BTF_INT_BITS(VAL)       ((VAL)  & 0x000000ff)
+#define BTF_INT_BITS(VAL)       ((VAL)  & 0x0000ffff)

..as you say we'd be able to represent a 65535-bit value. So if we
preserve the power-of-two restriction on byte sizes, we'd have to choose
between either having ints which

- have a byte_sz maximum of <= 4096 bytes, with all 32768 bits usable; or
- have a byte_sz maximum of <= 8192 bytes, with 65535 out of 65536 bits
usable

The first option seems more intuitive to me.

In terms of dumping, we could probably just dump a hex representation of
the relevant bytes.

>>
>>>                 return libbpf_err(-EINVAL);
>>>         if (encoding & ~(BTF_INT_SIGNED | BTF_INT_CHAR | BTF_INT_BOOL))
>>>                 return libbpf_err(-EINVAL);
>>> --
>>> 2.33.0
>>>
>>
>