From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 A2AC67263B; Tue, 3 Mar 2026 05:32:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772515979; cv=none; b=QpOuLdEm1yqKWSaGg+UdaoizvttRjb8rFd4dX+tbL+4C0HzBT6KEmRuvBYxJ+LZj2gBCT4dsVGBjiCD1NqDLtgzIKM6rDo2oax5+eKPH4vytdp9L1hgNpetor9Vnnv6VcUbLTGGqCTPPfbQdvig1UeMuiVhLOeL+Cg6ikb8/i/c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772515979; c=relaxed/simple; bh=xS+nv1OwFlWYOB99RwANSvzwf94XHReZwmRZ9xx6BxQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Q1ehiuJNYDZsnWOaDR973uU6lUQ4bb+5iqk7DXLOxVGFfMcf2iuouWjOV94pGwTBMhbRSNXe2+GgHhPY14zbh/LCd72J2FmYjd0boy8/JV8kxM+WaI+uNVsSt4GDjUuY1C8s7MPtWiQmcNGBzxrtFq3FxcUR0vZJFYv9mIjmqJw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=B0NJYVfT; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="B0NJYVfT" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=GPV+zg14s52g5SFoFfrYx5Ptt123SRCGdsVSmGW4Gcs=; b=B0NJYVfTPQrwUmRyc/SBngXZNs H5h1n+NJNoO4prO4VMLunBPH9juYPi88vUvHivlxvubTjNcXFWHTZJ7alrBh/ThhUwesqbtGr+YFT 9F20bfQfoObMbqrPd++hk84EjORkxhTqOmeGmHxqYQcxSGjMsXzrxVI7M5jHtDscb8mcg795WpK3u Z3A3mgGSxeRc2vV48jIVZME4xa+Wsm1krQg5ZMM+iaeSHPh3/WhjSi6VUc3l4Ziu250/93g9VtgEg iH03oAc6TZteIx/s6TaLgMlkp4FCgR00uNOKKlclZCetwu1lRff8nn1wvOT34T1na8siSvLEAz1lY RYl8A5oQ==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1vxINH-0000000Av9d-1mHC; Tue, 03 Mar 2026 05:32:51 +0000 Date: Tue, 3 Mar 2026 05:32:51 +0000 From: Matthew Wilcox To: hev Cc: Alexander Viro , Christian Brauner , Jan Kara , Kees Cook , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] binfmt_elf: Align eligible read-only PT_LOAD segments to PMD_SIZE for THP Message-ID: References: <20260302155046.286650-1-r@hev.cc> 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-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Mar 03, 2026 at 12:31:59PM +0800, hev wrote: > On Tue, Mar 3, 2026 at 12:46 AM Matthew Wilcox wrote: > > > > On Mon, Mar 02, 2026 at 11:50:46PM +0800, WANG Rui wrote: > > > +config ELF_RO_LOAD_THP_ALIGNMENT > > > + bool "Align read-only ELF load segments for THP (EXPERIMENTAL)" > > > + depends on READ_ONLY_THP_FOR_FS > > > > This doesn't deserve a config option. > > This optimization is not entirely free. Increasing PT_LOAD alignment > can waste virtual address space, which is especially significant on > 32-bit systems, and it also reduces ASLR entropy by limiting the > number of possible load addresses. > > In addition, coarser alignment may have secondary microarchitectural > effects (eg. on indirect branch prediction), depending on the > workload. Because this change affects address space layout and > security-related properties, providing users with a way to opt out is > reasonable, rather than making it completely unconditional. This > behavior fits naturally under READ_ONLY_THP_FOR_FS. This isn't reasonable at all. You're asking distro maintainers to make a decision they have insufficient information to make. Almost none of our users compile their own kernels, and frankly those that do don't have enough information to make an informed decision about which way to choose. So if we're going to have a way to opt in/out, it needs to be something different. Maybe a heuristic based on size of text segment? Maybe an ELF flag? But then, if we're going to modify the binary, why not just set p_align and then we don't need this patch at all?