From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 A2BDC33EAED for ; Fri, 5 Jun 2026 16:30:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780677040; cv=none; b=SHxdAap3K/8Pmm8tj/+p4DW3Yc48gFKerOFTUFeuhzUmsycnw8cOpqe6q4mwVJV0+MaE8nWkXd8mgnzWMukTmMw9lw6J1JWz9FSJCHHDHpjsHSvNZhrxZ+3BBvQMEAiyq7d2y8txgXNg7nBySg/TeFJio8QtFQnXB0uJgLxylrc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780677040; c=relaxed/simple; bh=GVKTJ1PUi145pODpne71tVTfx9y8nKFseHmwwZY5PTk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=oGZUKbKrSqe9oTPC3zU7g4i6TdOKoHO/YLIXfSCPQ6xnye0BxBHsGxQIsj6rR+VhFDNGhyyarDN2MsyvPcSNSWH/ELMZN5OyUenhWtiI4rxfB8CccS5N9vi97uV5Spn/lXpGYi0kTZF0oJmwWugvnzR/pooZ+BnO2skzznLnQus= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=dKaFqsfr; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="dKaFqsfr" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780677033; 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: in-reply-to:in-reply-to:references:references; bh=2WV80dwMeo/Oh+o/H20bt+QiS4rQvxiM6pL+lxNyrA4=; b=dKaFqsfr4DIvRIJD4RQz+iNfeUL5NtIy9qS9rK/r305axILaWiFdzM1PI1t4/+k8/bZhPU Cl0m4MTAaaFt+Ns2XU1QbC/npniEuYwh9qEIOWuzLJZM7dj+a0DFRCRa2d+5JactEe2mQ1 mSIgKDT8PrMgq3lmp8TWFkH8rCBLJ5A= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-384-g4IP06-0Mb-aHZMfCcNRyw-1; Fri, 05 Jun 2026 12:30:30 -0400 X-MC-Unique: g4IP06-0Mb-aHZMfCcNRyw-1 X-Mimecast-MFC-AGG-ID: g4IP06-0Mb-aHZMfCcNRyw_1780677025 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 7DA421800370; Fri, 5 Jun 2026 16:30:24 +0000 (UTC) Received: from oldenburg3.str.redhat.com (unknown [10.44.50.55]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id AEEB01800351; Fri, 5 Jun 2026 16:30:18 +0000 (UTC) From: Florian Weimer To: Linus Torvalds Cc: David Laight , Askar Safin , metze@samba.org, akpm@linux-foundation.org, axboe@kernel.dk, brauner@kernel.org, david@kernel.org, dhowells@redhat.com, hch@infradead.org, jack@suse.cz, linux-api@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, miklos@szeredi.hu, netdev@vger.kernel.org, patches@lists.linux.dev, pfalcato@suse.de, viro@zeniv.linux.org.uk, willy@infradead.org Subject: Re: [PATCH 2/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2 In-Reply-To: (Linus Torvalds's message of "Fri, 5 Jun 2026 08:54:07 -0700") References: <20260603211736.755139-1-safinaskar@gmail.com> <20260604100609.6b37f500@pumpkin> <20260604183829.63c35fd9@pumpkin> <20260604223216.73468830@pumpkin> <87se71jps4.fsf@oldenburg.str.redhat.com> Date: Fri, 05 Jun 2026 18:30:16 +0200 Message-ID: <87wlwdhrvr.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 * Linus Torvalds: > On Fri, 5 Jun 2026 at 02:33, Florian Weimer wrote: >> >> * Linus Torvalds: >> >> > x86 really doesn't *care*. If the caller zero-extends or leaves high >> > bits set randomly, according to the x86 ABI that's perfectly fine: the >> > callee will only care about the low 32 bits. So the high bits are >> > simply not relevant for the ABI. >> >> Please note that Clang does not implement the x86-64 ABI and requires >> zero extension. We see increasing problems from that, now that we have >> more C code calling Rust code. > > Uhhuh. But that is only specific to 'bool', right? Also char and short. This extern int a[]; int f (short i) { return a[i]; } gets turned into: f: movslq %edi, %rax movl a(,%rax,4), %eax retq This code assumes that the short value has been previously sign-extended into %edi. As I read the original psABI, this assumption was not valid, and the extra bits were unspecified by omission. And GCC tends to use shorter instruction encodings without extension if that does not result in partial register stalls. > If it were to have the same issue that powerpc(*) had - that 'unsigned > int' has to be passed to functions with well-defined high bits - that > would be bad. I would have to ask around. It's hard to tell from experiments what the expectations around int/unsigned arguments are. Clang and LLVM treat the upper bits from int/unsigned return values as undefined in some cases. > Anyway, for the kernel, this shouldn't be an issue simply because we > typically avoid 'bool' in arguments or structures that are exposed to > outside. Right, but array indexing with u8/u16/s8/s16 function arguments is impacted, too. Thanks, Florian