From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 E956629B8D3 for ; Thu, 9 Apr 2026 20:21:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775766101; cv=none; b=T0ZlfBFIIlB1R1rMjll39/TgGw8gSeRKFmNtbb507b+kzTb1+QQI8IH2sQ7fDuoYudFFdaaFlgPR1HFXGsGGjwPGkeuRAXKU+HGQUJ7+sVlHzyI69WjqoHZa8L19lqFEO+NpEg7shrFsYmSSX8TUUwCdkxIFd6WbrNNBfdZo1DY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775766101; c=relaxed/simple; bh=e98qFrhligE18L9wgTXhYkEdW5jXnSfbwRPYUj2gBfw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=q5sVpVdLQgmvf+YNfZ61K32MrLwsOvhxaTA7LyhwofUyMNeUjlbiH8u40vfneHjfRhMUriDaF8sUQtlySul5mGkoTjBXkdX5+w0rR/BR243+KDbKGHDy+kF4zFJBq/ryszXorbnZiwhDnTTY3Zd8zmFiVLJmEhxZMSeJb2cSLO8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ns0hCYUD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ns0hCYUD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9AE07C4CEF7; Thu, 9 Apr 2026 20:21:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1775766100; bh=e98qFrhligE18L9wgTXhYkEdW5jXnSfbwRPYUj2gBfw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Ns0hCYUD41+r3Rb2fK4JqBtMAIy0ZeolfJH4HXV1eerYLthZ+dg9tVU2M+jVNaecO /XdtqCsDvcgSHIh2JxlHYcICNZQLdmUyq7qpFsnQvtnIwMC6jVUNhBXpp0CNu38+ve 94vn59ejgNn98arCiWvCQrrsFOhC22DB8tUcwRhzv1mCzIgy/C9isYRuzQAv9nDt10 uEX/BhgczHIwvuFo50MYmpQRNe4pKyR2eYRGha8z8/ejC5oLfqVdikSPyw9kGtk4bZ IJhG4SI7Andv+v9GwYIKy1YEVgTUBLlnEWD9QE+Pt0tn5zBfs2mxykBlt5hK9lPbCv xWqWMW9Re7Jaw== From: Thomas Gleixner To: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= , Andy Lutomirski , Vincenzo Frascino , "Christophe Leroy (CS GROUP)" Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] vdso/datastore: Zero out newly allocated datastore pages In-Reply-To: <20260409131620-8b31cf24-e2da-4650-a3f6-97a35fdaeb36@linutronix.de> References: <20260409-vdso-datastore-zero-v1-1-e7b64a7c54b5@linutronix.de> <20260409131620-8b31cf24-e2da-4650-a3f6-97a35fdaeb36@linutronix.de> Date: Thu, 09 Apr 2026 22:21:36 +0200 Message-ID: <87ik9z28bz.ffs@tglx> 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 Thu, Apr 09 2026 at 13:17, Thomas Wei=C3=9Fschuh wrote: >> The data pages need to be zeroed initially, as garbage data can break >> the vDSO userspace logic. >>=20 >> Fixes: 05988dba1179 ("vdso/datastore: Allocate data pages dynamically") >> Link: https://lore.kernel.org/lkml/aQjJNmwniQwwjeBR@finisterre.sirena.or= g.uk/ >> Signed-off-by: Thomas Wei=C3=9Fschuh >> --- >> I messed up and dropped __GFP_ZERO again when switching from folio_alloc= () to >> alloc_pages() in v6 of "sparc64: vdso: Switch to the generic vDSO librar= y" >> Previously the missing __GFP_ZERO triggered boot-failures in -next, but >> apparently with alloc_pages() we got "lucky" so far. > > ... I panicked a bit after looking at the code again and not seeing the > explicit zeroing. The actually works fine, as the memcpy() from the stat= ic > vdso_initdata will do the zeroing. > > Sorry for the noise. Happens to all of us. Better safe than sorry six weeks down the road.