From patchwork Fri Apr 29 01:42:39 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pu Lehui X-Patchwork-Id: 12831395 X-Patchwork-Delegate: bpf@iogearbox.net 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 7E6EAC433F5 for ; Fri, 29 Apr 2022 01:14:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1353636AbiD2BR3 (ORCPT ); Thu, 28 Apr 2022 21:17:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38398 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351100AbiD2BRZ (ORCPT ); Thu, 28 Apr 2022 21:17:25 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4DF6BCB40; Thu, 28 Apr 2022 18:14:08 -0700 (PDT) Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.56]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KqDyf1fFXzhYlm; Fri, 29 Apr 2022 09:13:46 +0800 (CST) Received: from dggpemm500019.china.huawei.com (7.185.36.180) by dggpemm500020.china.huawei.com (7.185.36.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 29 Apr 2022 09:14:07 +0800 Received: from k04.huawei.com (10.67.174.115) by dggpemm500019.china.huawei.com (7.185.36.180) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Fri, 29 Apr 2022 09:14:06 +0800 From: Pu Lehui To: , , , , Pu Lehui CC: Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , =?utf-8?b?QmrDtnJuIFTDtnBlbA==?= , Luke Nelson , Xi Wang , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Paul Walmsley , Palmer Dabbelt , Albert Ou Subject: [PATCH bpf-next v2 1/2] bpf: Unify data extension operation of jited_ksyms and jited_linfo Date: Fri, 29 Apr 2022 09:42:39 +0800 Message-ID: <20220429014240.3434866-2-pulehui@huawei.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220429014240.3434866-1-pulehui@huawei.com> References: <20220429014240.3434866-1-pulehui@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.67.174.115] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemm500019.china.huawei.com (7.185.36.180) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org X-Patchwork-Delegate: bpf@iogearbox.net We found that 32-bit environment can not print bpf line info due to data inconsistency between jited_ksyms[0] and jited_linfo[0]. For example: jited_kyms[0] = 0xb800067c, jited_linfo[0] = 0xffffffffb800067c We know that both of them store bpf func address, but due to the different data extension operations when extended to u64, they may not be the same. We need to unify the data extension operations of them. Signed-off-by: Pu Lehui --- kernel/bpf/syscall.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index e9e3e49c0eb7..18137ea5190d 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -3871,13 +3871,16 @@ static int bpf_prog_get_info_by_fd(struct file *file, info.nr_jited_line_info = 0; if (info.nr_jited_line_info && ulen) { if (bpf_dump_raw_ok(file->f_cred)) { + unsigned long jited_linfo_addr; __u64 __user *user_linfo; u32 i; user_linfo = u64_to_user_ptr(info.jited_line_info); ulen = min_t(u32, info.nr_jited_line_info, ulen); for (i = 0; i < ulen; i++) { - if (put_user((__u64)(long)prog->aux->jited_linfo[i], + jited_linfo_addr = (unsigned long) + prog->aux->jited_linfo[i]; + if (put_user((__u64) jited_linfo_addr, &user_linfo[i])) return -EFAULT; }