From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta1.migadu.com (out-171.mta1.migadu.com [95.215.58.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 13C672F4317 for ; Fri, 13 Jun 2025 02:04:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749780299; cv=none; b=X879MANSh6TeKZZaMMvjk2Xmf/vkKrJZbEpBolZU/dZHvO8kA+ZvTCo9mQuGhhKGvcV3l1sZ9XgFSD1NWXMQeHtpK7McmXGX2RVPNEM0arJ2YiU6YbGRJd/bA+TC0f08e8MICiPB/HPrpuqwZeazMOLLk8fwWwSYNnVum/tWcUw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749780299; c=relaxed/simple; bh=b1NwGXziPuiEtzg8q4rgrEA2clxx8KG5yocHGOauRww=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=YS68ez3ixfwXhV8X42X8SFtLEgyk3zT6VEctjR/EFLPDSOcbDnHU1UtNA6m8PukxZEFGIu3lDwm4quv+qiOpnQccGEWOTfIp3B8zT8S/FKwi94YKg5eBsYzCLfGrCEt4/7Sp5BkEO4uj/fvWQeQYdgecEs0UZbkFDUNHyd4xAAk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=RH+W2vxV; arc=none smtp.client-ip=95.215.58.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="RH+W2vxV" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1749780293; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=haQaEUxie13iosvitaSwvORL082+TwgVbxxuiIyz0D0=; b=RH+W2vxVTs+2gmEBXo4uFSGNTVXouqa87yqnlzH4EuXmhr7Msj//PANRppwNF1AkUtctZa aDuwAQiR5KnCDnB/6SekIiqErJBSDLXS69e15DIIwC83Ifso6lXeD/jksU/7dOC1CUyvnX hFyD5/jraePRBaxfMO72BJN933IgGaE= Date: Thu, 12 Jun 2025 19:04:42 -0700 Precedence: bulk X-Mailing-List: bpf@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf-next] selftests/bpf: Fix some incorrect inline asm codes Content-Language: en-GB To: Alexei Starovoitov Cc: Eduard Zingerman , "Jose E. Marchesi" , bpf , Alexei Starovoitov , Andrii Nakryiko , Daniel Borkmann , Kernel Team , Martin KaFai Lau References: <20250612171938.2373564-1-yonghong.song@linux.dev> <5341c8c05537d6f9a4d252f5c98ec895ade09430.camel@gmail.com> <9665f3b3-1c8e-4dae-b8df-c3147b119ff2@linux.dev> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yonghong Song In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On 6/12/25 2:42 PM, Alexei Starovoitov wrote: > On Thu, Jun 12, 2025 at 2:39 PM Yonghong Song wrote: >> >> >> On 6/12/25 2:15 PM, Alexei Starovoitov wrote: >>> On Thu, Jun 12, 2025 at 12:49 PM Eduard Zingerman wrote: >>>> On Thu, 2025-06-12 at 12:29 -0700, Yonghong Song wrote: >>>> >>>> [...] >>>> >>>>>> Warning in llvm/gcc on imm32 > UINT_MAX is not correct either. >>>>>> llvm should probably accept 0xffffFFFFdeadbeef as imm32. >>>>> In llvm, the value is represented as an int64, we probably >>>>> can just check the upper 32bit must be 0 or 0xffffFFFF. >>>>> Otherwise, the value is out of range. >>>> I agree with Yonghong, supporting things like 0xffffFFFFdeadbeef and >>>> rejecting things like 0x8000FFFFdeadbeef would require changes to the >>>> assembly parser to behave differently for literals of length 8 (signe >>>> extend them) and >8 (zero extend them), which might be surprising in >>>> some other ways. >>> Ok. So what's the summary? >>> No selftest changes needed and we add a check to llvm >>> to warn when upper 32 bits !=0 and != 0xffffFFFF ? >> I did a little more checking, I think the value range >> in [INT_MIN, UINT_MAX] is what we want. This is also my v1 of >> llvm patch. > and that's buggy because it will reject 0xffffFFFFdeadbeef > >> Support we have 64bit value, 0xffffFFFF00000001, >> truncating the top 32bit, it becomes 1 and this value 1 >> won't be able to sign extension properly to 0xffffFFFF00000001. > well, yeah, 0xfff.. case should match 31-bit, of course. Right. Just uploaded a new llvm patch for this issue: https://github.com/llvm/llvm-project/pull/142989