From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from todd.t-8ch.de (todd.t-8ch.de [159.69.126.157]) (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 2A07E175A91 for ; Sat, 18 Apr 2026 11:56:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.69.126.157 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776513414; cv=none; b=RdVnt/h68khU93gmkd029/srB/EXOwYzFph04+V4/uxJnevcky+UyWmbMKP1Uz19aMmu3ocYcthRQFmCBmFA/V288jG9sES2fkX5vWUxDs7Rx0dnukNjdKXt0ovdVptjYE4MUtaKBnpNIJ0DCvy3+fjDmYJ++08YF2RUV3hznWI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776513414; c=relaxed/simple; bh=OC4zKRuLK7SU9921xIHKK+YFgNO99WZBSZtz+yAp3k4=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=m+zZGIP3xCeSdMQneg17Le64P7MYY9OXOuVq1Xv7ctGfMumHfeAk+9CriKBGscO7B3qgzP7VHaCCXDbDzDVBtNtozA/ReMQpDoJ3COrfgHpK/ps0oBQcBaqEsQP0wXsgPHABeRZarWF6AawaRp1y58/JCrZnr9IXkolMan66GaY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=weissschuh.net; spf=pass smtp.mailfrom=weissschuh.net; dkim=pass (1024-bit key) header.d=weissschuh.net header.i=@weissschuh.net header.b=ed+cByB4; arc=none smtp.client-ip=159.69.126.157 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=weissschuh.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=weissschuh.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=weissschuh.net header.i=@weissschuh.net header.b="ed+cByB4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=weissschuh.net; s=mail; t=1776513411; bh=OC4zKRuLK7SU9921xIHKK+YFgNO99WZBSZtz+yAp3k4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ed+cByB4g9sEV8jC7k+0chsh4zYoRTWMORbGz1bLgHydnNHQvbPNnhEqKNISs0X/s wukaAbESQl5nwAXCgI0skoYDQCeWk23SYYU4jOEOm4fxFkNNKQLdvtVI3t0vyV1kle FAqicY+wtwFp4qBxl/Wf/VKJO/ByHUAS2VFu3r6Q= Date: Sat, 18 Apr 2026 13:56:46 +0200 From: =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= To: David Laight Cc: Willy Tarreau , Daniel Palmer , linux-kernel@vger.kernel.org Message-ID: <6fe77be2-39be-4976-99d6-aced2bf3d955@weissschuh.net> In-Reply-To: <20260418122340.1dc07834@pumpkin> References: <20260418-nolibc-largefile-v1-0-b91f0775bac3@weissschuh.net> <20260418-nolibc-largefile-v1-1-b91f0775bac3@weissschuh.net> <20260418122340.1dc07834@pumpkin> Subject: Re: [PATCH 1/7] tools/nolibc: also handle _llseek system call Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Correlation-ID: <6fe77be2-39be-4976-99d6-aced2bf3d955@weissschuh.net> Apr 18, 2026 13:23:43 David Laight : > On Sat, 18 Apr 2026 12:19:56 +0200 > Thomas Wei=C3=9Fschuh wrote: > >> On some architectures the llseek system call contains a leading >> underscore. Also check for that one and prefer it over the lseek system >> call as it is necessary for 64-bit offset handling. >> > ... >> +#if defined(__NR_llseek) >> +=C2=A0=C2=A0 nr_llseek =3D __NR_llseek; >> +#else >> +=C2=A0=C2=A0 nr_llseek =3D __NR__llseek; >> +#endif > > Is that test the right way around? > The commit messages says prefer _llseek, but that seems to prefer llseek. Yes. lseek is the ifdef case below. Here we have _llseek and llseek. lseek always exists, but may no handle 64 bit offsets. Only one of llseek and _llseek exists for one given architecture. >> + >> +=C2=A0=C2=A0 ret =3D __nolibc_syscall5(nr_llseek, fd, offset >> 32, (ui= nt32_t)offset, &loff, whence); >> =C2=A0=C2=A0=C2=A0 if (ret < 0) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 result =3D ret; >> =C2=A0=C2=A0=C2=A0 else >>