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 3BEBDC05027 for ; Thu, 9 Feb 2023 23:19:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F2D56B00B8; Thu, 9 Feb 2023 18:19:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A2776B00B9; Thu, 9 Feb 2023 18:19:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 691406B00BA; Thu, 9 Feb 2023 18:19:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5B3F26B00B8 for ; Thu, 9 Feb 2023 18:19:45 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id EEE43C1007 for ; Thu, 9 Feb 2023 23:19:44 +0000 (UTC) X-FDA: 80449322688.29.E780D8C Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf22.hostedemail.com (Postfix) with ESMTP id 3C310C0009 for ; Thu, 9 Feb 2023 23:19:41 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=lmDhAP1P; dkim=pass header.d=linutronix.de header.s=2020e header.b=S+GJCt6I; spf=pass (imf22.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675984782; 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=KNBAizjZNrVbj6pu64DG8DfhaakV1VisWaDQqQ90zu4=; b=VkK1Rw23cbmtpXLSDdFJt72Bt9cIBxLz3I438K383IJRsSyhcbKFSAjkwWjJRIe0b8NxR/ ysnyyCiWjOLbKlSQMOwnFhLlTk8hw3r63mphbID5N891qVhC7Vw2WlkWWIHX3myf8flXG+ 3KcxXG76R++AXaovkx9uIqVrd4cMqwk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=lmDhAP1P; dkim=pass header.d=linutronix.de header.s=2020e header.b=S+GJCt6I; spf=pass (imf22.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675984782; a=rsa-sha256; cv=none; b=7ZIUR4smaic4XNBS00eUtuwWCTrnQirpXJ7hwRde6rEFf/3TMXG3oy9MoYRANym0ZA0dgS Qa6Q+bGpvE5qxrBdANX6C2EL6K0hx/7+n40IVAnT+C8v/IFDgyqk3f8YcmZpao63oXuwfE rTzuIflLLXy9/iE+jZui115L38Pny94= From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1675984778; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KNBAizjZNrVbj6pu64DG8DfhaakV1VisWaDQqQ90zu4=; b=lmDhAP1PQMG2F0l6M/QJaBtsmc9DkUkHKzdMPAZ5U/UHcjh8SOqbIBGFq9gBkxmGtxZcPv rVd/IabCM5zxTh5bsnS8+W1Q1c5S9OmKcHv0ioCw4AXrtBfGPDhYXjqoydMJZQVisjLuxK VGb1rXri4AhIfKr4qd8ToCPOwcX3ehu8r8v+/VyXHtOZbzKSVgmhyw3Z9qnEWyaB07f6uZ 2hDhcCoGpibZdMS0xqDzlxCjqN32sJ6omeybEyENes49sCcDZK8BSgWNwnMGPyFyjyAgl0 9wHTKSr94+ytBY6/cEjfZMM7ZAMx0InU5JSWvQ1Ddyv1dCRParVEyhJv90t1Ig== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1675984778; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=KNBAizjZNrVbj6pu64DG8DfhaakV1VisWaDQqQ90zu4=; b=S+GJCt6IlD44szHumRK564PyKeEcwcKJMXnI8vs0nAARVs0FVWrqyh74z/i8zQ4GvuSniE Z3WMNSsvckHj1oCQ== To: Matthew Wilcox Cc: Vlastimil Babka , kernel test robot , Shanker Donthineni , oe-lkp@lists.linux.dev, lkp@intel.com, linux-kernel@vger.kernel.org, Marc Zyngier , Michael Walle , Sebastian Andrzej Siewior , Hans de Goede , Wolfram Sang , linux-mm@kvack.org, "Liam R. Howlett" , David Rientjes , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Roman Gushchin Subject: Re: mm, slab/slub: Ensure kmem_cache_alloc_bulk() is available early In-Reply-To: References: <202302011308.f53123d2-oliver.sang@intel.com> <87o7qdzfay.ffs@tglx> <9a682773-df56-f36c-f582-e8eeef55d7f8@suse.cz> <875ycdwyx6.ffs@tglx> <871qn1wofe.ffs@tglx> <6c0b681e-97bc-d975-a8b9-500abdaaf0bc@suse.cz> <8b7762c3-02be-a5c9-1c4d-507cfb51a15c@suse.cz> <87edr1uykw.ffs@tglx> <878rh73mxl.ffs@tglx> Date: Fri, 10 Feb 2023 00:19:38 +0100 Message-ID: <87h6vu1l6d.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 3C310C0009 X-Stat-Signature: 7xbjeyik4s3qh6yk9ym6c6jhck6rrb3s X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1675984781-201140 X-HE-Meta: U2FsdGVkX18+lQ9/jrju4ygFRfUrOKXUt+EG8wCic72axSYe74n339xMofbij/tSGaO/6sh5Jt8gT4sPbL1lJtEhMEjEBnUBl3dWwIlBJ1KiMFr2YlfzISty9ujNKKGNR4uGmcMGR59eiq3+JW6iDuqmGeY5DWiKu4m1HJn/eUa/2ZEun/MhwqX4MvZPFakcR1YXleg3l8VqIX9yGUcB8cNp7k88KD8GwnmT+8Kd6gA0hcHoz059ZxPchtWTGzvRE7S0N/2E3VFJQ7o6V67Q2emTPK+JxBylWl0Jzmr09xaAhhrq4//JYVHKSgh9+PXF5GlPyaQlWCCSZbl/qil9i6NT1mekt4QBHckTFq5wnPOJZmkUyCzG19DW3s39tVqhQorE/UjQe2Z27DAhQOr+KFCYl6jIfTWLsMzxGYegJSjJnzqWcdpV4TCW38b/1osomSaHlp/4shUjz4Rq8iUFBU32tUJw4erJkj18aeatgg00BSzf9EUvOvI+jT0tIwrQwjhi4GARztAxLzXgN9fRPwYy2oqq+dQtNx+mcxO9d9trbFtU0ZW1lZfYmqywDJQ9k25adcJTnRZzZqxwfqPcXroUYCmShsV9KX2ALc5Uiyar8wUg9/ePMg0P4lTxl7wypPCamzj3TEw+k/VwcG4J43QfzKVnQwLH4X2/Lo9p7vdFJaj3oCrP6PtkEy21L6V8UDMVnoWi7jGeESopC6X7Sg9k0DqsevvBm3OGQ8LK9BBliN083fRbdXtdSISXxoFax7Ozp/nILMeeTzsEdNhciVh5MJupSN4Zr/84Nesj5/RLs9a5xpKvh9krFzfPN6ORKvUYcz9AwTLcuuREozjmjiKaJDtOg0mC7ZnlZLLT92VS4u9iNRBqfWCRCL46dOqG8p68xoJPh+dZRZfSNrzMrYl9pk3d+13jY+dPvgkFYXqCfVUaqz2x5APiMK+uq4BRH7LDBuuF+QEjnO79FXI 4uCRsN5M zYVS9baVwXcy4YO9bjp1GoEw5DnXgtqHi3PK5xD+J7uEpddgyR0+2JrVy/WinSUtnxm5/9xPNxafBJjJ9h7hyLJn7DsLahLx+rMPM8QGwxEU8qYFPJl586iNK6n0oDEog4Re7ep25rXkMhplEOKB1/8tVfEOi7HQwQqgVm0FRweHRSZNjjF5bAVLWR5T7LOXjPtNs 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: On Thu, Feb 09 2023 at 20:28, Matthew Wilcox wrote: > On Wed, Feb 08, 2023 at 09:46:30PM +0100, Thomas Gleixner wrote: >> The issue is that there might be maple_tree users which depend on >> GFP_ATOMIC, but call in from interrupt enabled context, which is >> legitimate today. >> >> Willy might have some insight on that. > > Not today, but eventually. There are XArray users which modify the tree > in interrupt context or under some other spinlock that we can't drop > for them in order to do an allocation. And I want to replace the radix > tree underpinnings of the XArray with the maple tree. In my copious > spare time. If any usage which you described, i.e. interrupt context or with a spinlock held, where interrupts were disabled on acquisition of the lock, ends up calling into kmem_cache_alloc_bulk() today, then that's broken because kmem_cache_alloc_bulk() reenables interrupts unconditionally. So either such code does not exist as of today or it just gets lucky to not run into the code path leading up to kmem_cache_alloc_bulk(). We have to clarify what the valid calling convention of kmem_cache_alloc_bulk() is in the regular kernel context, i.e. outside of early boot. Thanks, tglx