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 3597D3DE454 for ; Tue, 24 Mar 2026 09:59:20 +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=1774346361; cv=none; b=aOeV6X2oe87YoPReTUEbjVgtEwYdxAL4Ywo/pOE7rkcxZbuyNLWPbMECbx5svRbLoBSw307ionPbGrPN155Sa4Qlh5HAQwACo6UXbP+ZETch/OoATflcfDptpWA0A5EK0SxEo/A5XLsumbIJ28PhNo78prc5TEHpvz+pURws9rU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774346361; c=relaxed/simple; bh=lxYoyrstc5/1CgkMEtG6n6ebrZsJE/o/EqenBbaMkR0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SnWq1Ha5krHkV93ZJgvdRbyqOEXrpBrPmnBqGQ2rzb3gWWBYN/tZ+7E0sGF8ZiIFJomaoccOO8FFjB9yA5ruk+TpbV/2KLphzM/Uk5pnjgj81cXXitpoxeg2tDDks0KJ+Z+Jv/hJl2GZ8mi9mY3NDgBC8UCWA46VcZD8uiOkw9A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lrb7xzPE; 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="lrb7xzPE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 334A2C19424; Tue, 24 Mar 2026 09:59:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1774346360; bh=lxYoyrstc5/1CgkMEtG6n6ebrZsJE/o/EqenBbaMkR0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lrb7xzPEV//TYdgvsB1VGxTLu91i8UXSqD2fZxbFKrs7YMf8RA3X4VUMYgME0yssJ r+sjtDkcmvqG+AUW4nVbTYb8MO0bVoCvmiNc1L0GJ6QUG8iFF+3Nv8QhJzJNVc43g1 joyA6zm/Za90tZB+X+OmKm+K4KCwB5k0JSrBXpwxJUzxwXP9iIw2kJSCX+G3O3ZS5O xEkNV7EC7/bHCiGI40SbfUMJGV6ukfovAnxA0Vt7pEVVd+XDCbe2ku2gsy+uxDLfbo nva9XDTKQ1fugw2xz6LfukbsJSmmdCFFPnCJcBN7vhPc0vdmbK5OoMC1U7l1pbgbgs wC9ihikKZ8SJQ== Date: Tue, 24 Mar 2026 09:59:15 +0000 From: Will Deacon To: Osama Abdelkader Cc: Catalin Marinas , Kees Cook , Andrew Morton , "Liam R. Howlett" , Jeff Xu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: vdso: fix AArch32 compat init allocation leaks Message-ID: References: <20260323214117.241216-1-osama.abdelkader@gmail.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260323214117.241216-1-osama.abdelkader@gmail.com> On Mon, Mar 23, 2026 at 10:41:16PM +0100, Osama Abdelkader wrote: > aarch32_alloc_vdso_pages() allocates the AA32 vdso pagelist, the compat > sigpage, then the kuser vectors page. If aarch32_alloc_sigpage() or > aarch32_alloc_kuser_vdso_page() fails, earlier allocations were not freed. But why should they be freed? The vectors, sigpage and vdso are independent from one another, so we can limp along with whatever we managed to allocate. I'm not sure how far we'll get, mind, if single page allocations are failing at initcall time... Will