From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9271FC433DB for ; Tue, 16 Feb 2021 00:44:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4818764E00 for ; Tue, 16 Feb 2021 00:44:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229710AbhBPAoQ (ORCPT ); Mon, 15 Feb 2021 19:44:16 -0500 Received: from www62.your-server.de ([213.133.104.62]:32878 "EHLO www62.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229670AbhBPAoP (ORCPT ); Mon, 15 Feb 2021 19:44:15 -0500 Received: from sslproxy05.your-server.de ([78.46.172.2]) by www62.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1lBoSh-0006Jy-NC; Tue, 16 Feb 2021 01:43:31 +0100 Received: from [85.7.101.30] (helo=pc-9.home) by sslproxy05.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lBoSh-000E2g-H2; Tue, 16 Feb 2021 01:43:31 +0100 Subject: Re: [PATCH bpf-next] bpf: x86: Explicitly zero-extend rax after 32-bit cmpxchg To: KP Singh , Ilya Leoshkevich Cc: Brendan Jackman , bpf , Alexei Starovoitov , Andrii Nakryiko , Florent Revest References: <20210215171208.1181305-1-jackmanb@google.com> <44912664-5c0b-8d95-de01-c87b1e8a846c@iogearbox.net> <725b73b5-be08-f253-165d-e027ec568691@iogearbox.net> <5f7b836cc07980352215a5ad9a959c7e7c47f1cf.camel@linux.ibm.com> From: Daniel Borkmann Message-ID: Date: Tue, 16 Feb 2021 01:43:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: daniel@iogearbox.net X-Virus-Scanned: Clear (ClamAV 0.102.4/26081/Mon Feb 15 13:19:24 2021) Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On 2/16/21 12:30 AM, KP Singh wrote: > On Mon, Feb 15, 2021 at 11:42 PM Ilya Leoshkevich wrote: >> > > [...] > >>>>> How does the situation look on other archs when they need to >>>>> implement this in future? >>>>> Mainly asking whether it would be better to instead to move this >>>>> logic into the verifier >>>>> instead, so it'll be consistent across all archs. >>>> >>>> I have exactly the same check in my s390 wip patch. >>>> So having a common solution would be great. >>> >>> We do rewrites for various cases like div/mod handling, perhaps would >>> be >>> best to emit an explicit BPF_MOV32_REG(insn->dst_reg, insn->dst_reg) >>> there, >>> see the fixup_bpf_calls(). > > Agreed, this would be better. > >> >> How about BPF_ZEXT_REG? Then arches that don't need this (I think >> aarch64's instruction always zero-extends) can detect this using >> insn_is_zext() and skip such insns. >> > > +1 That would be nicer indeed.