From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AEBFAC369AB for ; Thu, 24 Apr 2025 05:50:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB9ED6B0006; Thu, 24 Apr 2025 01:50:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B699C6B0007; Thu, 24 Apr 2025 01:50:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A31556B0008; Thu, 24 Apr 2025 01:50:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 8819E6B0006 for ; Thu, 24 Apr 2025 01:50:49 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 86082B3E02 for ; Thu, 24 Apr 2025 05:50:49 +0000 (UTC) X-FDA: 83367863418.30.BE661E8 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf20.hostedemail.com (Postfix) with ESMTP id D5AEA1C0002 for ; Thu, 24 Apr 2025 05:50:47 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Yf7P+cj/"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745473848; a=rsa-sha256; cv=none; b=tgvIvWhKsB1ZKava8/DM5yufQ8Kho8K0CU9dZhNqztqgIwRQmC3xTgqjiDnEbT23LenIXt uWLdKbD1XgwArH7lg7CHM9dPkq26kqZAJnT+lzM0zVcthjU1qGhPuDMdju9KzsJrsOVx7I 0pECmpwtisREcflPJhBkOaSnRo15RjM= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="Yf7P+cj/"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of rppt@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1745473848; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cKCkGAPOAm7cQc81jm1OYPrcUK+8LtMrzSkdQXxXDU4=; b=hjU5kY0Uq+kftCDOYpUvUcKwZfx8hm4ZeqQ3xBt7q5Ten5mTNy9Lquvhhe5NWhcZn+0sJR JT97bwQwOgloGWtJattTw5i0DpDoqKG6rDAIrdZtJDqg95PrgpBxuQoNKFlJTg3APabsUq Uo939WA+lZmImZWYhirF3fmyx2GuGgc= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id EAE5543FAD; Thu, 24 Apr 2025 05:50:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADBFEC4CEE3; Thu, 24 Apr 2025 05:50:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1745473846; bh=sB0hUbV58wH1WzUzW0e3EsN347j5zpwecXfO1q1RcPc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Yf7P+cj/WjG4xDNnJeeXFp9SIDXaBLmddmL7fBn9ZIsgT69CUajoQN67/NbtNc9bc UWZgoNgBAbtvD/fkFLFaWlseB8IbWTqgGag8iNTph2RvTC9ulA8MdICXvB+GOy+s5G sHIHyBrmy3xZsyoX6Os5xSPaB8vRyiBzwx79pzwsa6ylUQAwY+I5baSGuLwwwgq/vO 1D/sdImaEAUmHqi6GK+aIRL2eiPtcyJ8Ol+hhi0rCN/gWJxflG0C2HoAf9cmt1ttfZ eTRBmPMYiPMbOmUkboGxL14DSyWJ+PFX5fS+QI078fjPvIzVEniGcrPhSmCZg0Vj93 iN+1rWfE+ZGZQ== Date: Thu, 24 Apr 2025 08:50:40 +0300 From: Mike Rapoport To: Andrew Morton Cc: Peter Zijlstra , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] execmem: enforce allocation size aligment to PAGE_SIZE Message-ID: References: <20250423144808.1619863-1-rppt@kernel.org> <20250423143650.6595dcc7178351b62c31782c@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250423143650.6595dcc7178351b62c31782c@linux-foundation.org> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: D5AEA1C0002 X-Stat-Signature: a9aizmefxo9rnn34ytiuwpy1f4gqz6rm X-Rspam-User: X-HE-Tag: 1745473847-391 X-HE-Meta: U2FsdGVkX1/E4yF6L2nQ7JyUKRlz9ybCs7cy3ir6qLSYAt9vsLdzKdHQO5ArcS8VrPA5HAHp32AckS0z/THkdRdQkQSSBgnnv3HVhYle6WdfvnK+rw70bs4t88wDJDSmvqj7MCPDihVBH2pSOFxlEwgiD7MCW+fSte1v4m5CO3yOVNZJYOUCYuTRyHZjEuylvDjhHb3I6CcnmV6yB1YxqHILuStvS4XizDYIm8HJXkgunR2GeMuoAPUw7WIbHi8eHhoFu00/CZcgjDvnsDFN7HmK/9mFe9ihmA606wSxOiMOsNMuRopTJqIenOBTXVOe3BT94sk0q3FovWp3Aho9RqDe9/gznpV9IgkFw8PLJfGDDKO7UlLS+yINOZIGYlbu8dYNFuvxn8Vi9aaV4V6P0TvchS5j32VuUUlLRpSvi98+mSsrTLi/1HR1dfwCurgUy9Z6Y85lljiL2OCXS7FSDS4VjlMWWZ+1HKoxf5UH3cANRq/7BRECscyf3ruT3MdgKH45v7RTxJSMChBKj6FAlmGYPd7JxeGsXOCiyk52azpYFrBPLAKZExPDoadnKaxNOQPMSZaUTZrnV/EQZvCzcf+m8bqRBC1prRgRPUGRY28VLa1Bs/sFT9EX0LuLlAfuzmXb+HmxTBxN9HBLDGq9tRX7hUuBmwgcP8s+hECTadd1htyCaRUdfBpQaHExTufEBHSL8SZAdRjgXUMg4XmTtY5AHrndmxEqrGarEmqB3k9sipIiHZkU3IhJf92HbQNUT90OSBdJhFR2W7M/ds1y4BKWjDMzNLb//G6tHRTYbMnz9XcNT1utXnUWa5cm0fjueT8BxcklF2TLd0bVGCRs2caE7pVrkaxMQox8W/+wfkO7l9+XjMNIegIRvhsdwG6W8nYGUeqrNPJifsboEBgNh42MqxknKI5IabxEp3xKBbjeCJ/4wBGIUc89Duz7/4nFoIQCUSw0Ap2BVlBk89E XMZoPGKT OSqY5jPMU+55qvC9u4CWt4AIcOe2qKdA+Zq3cMkUQKQUA7DlHGEJR4ifrw+7N+8ag7Apl9uNSUzM4Y2mlXrCJIYNRuh+E2XdNoxVSrqgyKgyTrRi6ys+piZzP+ZAkchufrzFzaYzRzyimQdHOkQ+eJq6JxH2SwGMFVZE8wUYjbNESYv0fzKegETiqhgBaWzJOmWVDgqCWZE3Q088QOX4ohyTnlRoZXkgqRUyQq8AVOdV3tGU9DFE3ynG8FNihBEI4hxSZyn2a6HfnE5mQtwfYxghb9cDo2TSDVYsvuIayOB7TV+JT4qJ9qt7/Nu5SqbBIquad X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Apr 23, 2025 at 02:36:50PM -0700, Andrew Morton wrote: > On Wed, 23 Apr 2025 17:48:07 +0300 Mike Rapoport wrote: > > > Before introduction of ROX cache execmem allocation size was always > > implicitly aligned to PAGE_SIZE inside vmalloc. > > > > However, when allocation happens from the ROX cache, this is not > > enforced. > > > > Make sure that the allocation size is always consistently aligned to > > PAGE_SIZE. > > Does this have any known runtime effect? Right now it'll make the maple trees in execmem_cache more compact. And it's a precaution for the case when execmem callers would want to change permissions on unaligned range because that would WARN_ON() loudly. -- Sincerely yours, Mike.