From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 47AD514A8B; Fri, 10 Jul 2026 07:33:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783668822; cv=none; b=tGMwyGXfRzVXSf8p5Ktr5rUdRpdQ24niWdQMTnG+G56cDQ8OdzljFBLf1cGLoSet0mQEw1JqUIPv4HfCnJY1zT8cls3uskJQI5Vff1j1pjB/mxV5o++K6XaV2neBi8L303zl8ZwvW7mov83bjYgWkpZFZPt5dLPlZEsLLZSZnv0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783668822; c=relaxed/simple; bh=kNsy/6tv8sfSadwcHSU7jGy9MP7ecHLyHUyiUD9PN+Q=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=eF/A4lZngZcqOvyraT+thWBw2sk0FoPPyLvYURrl6sz754pD5qQWfcJeovX1coAe2hEtl+ejd1ShZTn40Fb0l7iRFyqa4rrD5zrBAtGsZV687aQqKxSHkz/N87HgLNS/BsM4KIuiYSSd+ZAHBUU7aIeakMPJf1wSgfbRv/yFfO4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=g1UIIdk5; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="g1UIIdk5" Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 66A7X2x13244461 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 10 Jul 2026 00:33:03 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 66A7X2x13244461 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026062701; t=1783668784; bh=R7qHRjvq2LJmHgy6sldSxUlAWJNI91+gaFZFN9Tqg9I=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=g1UIIdk5pjqV2N31jmsKpN4koJTZcIovjS1U1+JkReNqzgb8ot9onoFRPREBkTcTh B9yqfm+MwyMqAam2FtNBxLTg/LgVr+iLebT/WYtDRMhrOlvVLYvyGDlPRkR0gV+h13 1kzt8aKBAzwWrfH52Z15bhIox2bVdFlQf/Smn4IaW9cj6xn2XO7Lf9kWLAI/MusxzH GwGImpzCCpv3/pmk3srR566CHzEI7wxtdpCQDQPafWF56dPwM7HFeV2CVcsBJxFRLg m7kuq0OXtnsFH7ApgHHPSopN7qL7KHIFp9L/Ou49OahvdiWWW5M2B9giLOAELf9JSk Q0YkMgwIWh3/g== Date: Fri, 10 Jul 2026 00:32:55 -0700 From: "H. Peter Anvin" To: =?ISO-8859-1?Q?Thomas_Wei=DFschuh?= CC: Vincenzo Frascino , Nathan Chancellor , Nicolas Schier , Thomas Gleixner , Andy Lutomirski , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, Nam Cao , Sebastian Andrzej Siewior , =?ISO-8859-1?Q?Andr=E9_Almeida?= Subject: Re: [PATCH] vDSO, kbuild: Provide vDSO debug variants at runtime User-Agent: K-9 Mail for Android In-Reply-To: <20260710081440-d355b1fd-c34d-40bb-965c-8bbe2a8c375a@linutronix.de> References: <20260708-vdso-sysfs-v1-1-fcd93385006d@linutronix.de> <947ba63d-59d5-4f4a-a037-c9de100ced97@arm.com> <9131ADF7-6D08-418F-BE2F-2E99CC83FD2E@zytor.com> <20260710081440-d355b1fd-c34d-40bb-965c-8bbe2a8c375a@linutronix.de> Message-ID: 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 On July 9, 2026 11:36:25 PM PDT, "Thomas Wei=C3=9Fschuh" wrote: >On Thu, Jul 09, 2026 at 12:06:07PM -0700, H=2E Peter Anvin wrote: >> On July 9, 2026 2:57:09 AM PDT, Vincenzo Frascino wrote: >> >On 08/07/2026 14:56, Thomas Wei=C3=9Fschuh wrote: >> >> Finding the debug version of the vDSO is not trivial as there is no = common >> >> scheme where it is placed=2E That's especially problematic for CI te= sting=2E >> >>=20 >> >> The vDSO futex unlock mechanism requires for testing to have access = to the >> >> inner labels of the unlock assembly, which are only accessible via t= he >> >> debug so=2E >> >>=20 >> >> Also for general debugging purposes it's convenient to have access t= o the >> >> debug vDSO at a well defined place=2E >> >>=20 >> >> The files are placed in /sys/kernel/vdso_debug=2Etar=2Exz=2E They us= e the >> >> regular 'make vdso_install' layout, including build-id symlinks to f= ind >> >> the correct file for each process=2E >> >>=20 >> >> The design is kept close to the ones of the similar IKCONFIG and IKH= EADERS=2E >> >>=20 >> >> On x86 the x32 vDSO is derived from the x86_64 one, necessitating an >> >> explicit dependency to avoid errors due to concurrent builds=2E >> >>=20 >> >> Suggested-by: Thomas Gleixner >> >> Link: https://lore=2Ekernel=2Eorg/lkml/20260602090536=2E045586688@ke= rnel=2Eorg/ >> >> Signed-off-by: Thomas Wei=C3=9Fschuh > >(=2E=2E=2E) > >> Why stuff them into a tarball? > >Because it was the easiest solution to implement and has been sufficient >for IKHEADERS so far=2E I don't see a clearly winning solution among the >possibilities to expose a directory: > >* Use plain sysfs: > Requires a new code generator and potentially changes to sysfs > >* Use a read-only filesystem like cramfs/erofs: > Introduces new build-time and runtime dependencies > >* Add a new filesystem backed by a tarball or cpio archive: > Lot's of complexity and work to implement > >But I am open to discussions and other ideas=2E > > >Thomas I discussed this with GregKH a while ago, in the context of eventually mak= ing the vdso an actual mapping of a virtual file=2E According to him it sho= uld be quite simple in sysfs; I got a bit stumped on the necessary hooks (t= he kernel needs to keep track of where the vdso lives in the address space= =2E)