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 EB52BC369A2 for ; Tue, 8 Apr 2025 14:25:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0EFA46B000C; Tue, 8 Apr 2025 10:25:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 09FDA6B0010; Tue, 8 Apr 2025 10:25:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E83226B0011; Tue, 8 Apr 2025 10:25:43 -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 C69F56B000C for ; Tue, 8 Apr 2025 10:25:43 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CE67A12065C for ; Tue, 8 Apr 2025 14:25:43 +0000 (UTC) X-FDA: 83311100166.11.9E8D4BD Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf06.hostedemail.com (Postfix) with ESMTP id 5306618000A for ; Tue, 8 Apr 2025 14:25:41 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=UyGHUrCd; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf06.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744122341; a=rsa-sha256; cv=none; b=tvCXlHI1E1yxsCfQfkjOiNI0KF8CpcVTntrBFLP/Vp/FqXrHrvDPGXOR8pbqgorb7Gsj+f BldSB+cttOA5JMkmIsMQjicVkinn+n6RqxsLnkKqkNpCf51sJ2iwB9uP8mF5vlOK/k9RhE IWxR3idWwMwF9CZg2tO3eNamIBZnaq4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=UyGHUrCd; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf06.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744122341; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=cdYzwQdmas4AvXbPEP9rA3v9GgJ/jWsMLp6HlDh9xY4=; b=SpeDuuB3GaDgHa/cOGdoTfjMewz17hqVvhL56yMVS8ON4FsdonAfjB/k7qlnGrbqt8fioX VV5HEScllKR0G94fM8ss5jQlc2k8L0KOwuY+bofvc1hxTWihwsrwYNFmGbLg/uViKtIMhI U/cNyJp+EmFrZqmsD9j3idryZ6Cbx8I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1744122340; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=cdYzwQdmas4AvXbPEP9rA3v9GgJ/jWsMLp6HlDh9xY4=; b=UyGHUrCdpYsz3HDYGJhdwNj3lhvvLyaZzr2bwk7gflSe9kKaOUWv/wN53YIujHTYzUUIYR Dk7Wwvgud/UUPBsEp2Ki9tfwpzXw+LCG0RN9qfg7OfoHkZvYwj6x6D2Ul0aUEF0uRzMltp k9iE0LBfy0fNJLVCopzH7sLokaq2bjM= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-681-l-tk1AiMM_iCQUvh8QrzUg-1; Tue, 08 Apr 2025 10:25:36 -0400 X-MC-Unique: l-tk1AiMM_iCQUvh8QrzUg-1 X-Mimecast-MFC-AGG-ID: l-tk1AiMM_iCQUvh8QrzUg_1744122335 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-43ceeaf1524so32448095e9.1 for ; Tue, 08 Apr 2025 07:25:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744122335; x=1744727135; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=cdYzwQdmas4AvXbPEP9rA3v9GgJ/jWsMLp6HlDh9xY4=; b=g7Yk7hKJhdfekIAPu6oZY+jiI+faQTEcuzJEf/uHpDzz4rpTwsScLdiZm+pdao9mkJ 38e5ubC1tTt+S58DZGu/nKU59wDxnPC/BSz95wIF8p6lB8/08Td6l2bx/Xg6BrIE98CU /jEO+SGgSN5bXYxBgHKRjE60mn1wuxv8shded+d2Xzjq5O5n1m8P/hP9dluGYE2U/SVE 7MAc3wguaSDnCGYLJARUmsmefeFSbxavxgx6gFzTuyTUbzRA7hSTAXhrNdWEeJIFZW9S H5dTdULPTLNsqorvFOmhNkX64barSjA1kHLBaRSBsjdKB12O9PlVxcd2wZ4kYobJNBry IoRw== X-Forwarded-Encrypted: i=1; AJvYcCX7qG3/XovoUf9AJ6v7ybVPsasAtPmEX2dzZMN3c6eBJCgDjDocqq0R/0KHtjwYbnzfQltwi2ivWw==@kvack.org X-Gm-Message-State: AOJu0YzIp/CVU2Z668z4b308UFIWskdPKRvfqbBu2nGZavzyBMkC544J cfp8AYkPD3U6MzmvgPvIJMhJ2rwnJlimGYp8VPqKDEBiIUSCUJxrJCz95+U2zvVtQXfLg68bcMj 7JNp53aURNRQBkaktUJn8T8Xc2IREpQIJXhcZrQRb4RH07pIN X-Gm-Gg: ASbGnctU2JyyAeKEFfSs5Rcvk3DbHx5jtk4rNyFrAmBLHoI8qUP2x3uPfCWUjpXQHqr CYwds1zE8oirUMbVgsm8WBqcTVa2FNyGQvdz5KLA33iHEJIrjPALxuQIzcSfDe0rDYpwPjsFaP7 Mg6bd+MXQ+vdc6dL6p8GUgpIxeIT44lBymE/ldjhoukPsMnRZD3tlmo08762P4b/U/T40lkkaKe Sz33SS0IF2blN7mTctRo8SBTH4CC+8F0LdrxMt5Rz/qmZ7THtCX3M5SlFSdgOpoKwwl3E5Jx4kN gjPR/qmneFS8nMOzdYsFmfx2w8/34/JEVAsk/N0cHzlcUA== X-Received: by 2002:a05:600c:4fcf:b0:439:8878:5029 with SMTP id 5b1f17b1804b1-43f0e559b59mr25070655e9.2.1744122335139; Tue, 08 Apr 2025 07:25:35 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEmTbfxJIh666ObJTK1RRy0WNRsx3t3PI5C48zyEfbY1TrN6gfjIulvoD2QknSx2rkn+d8uDg== X-Received: by 2002:a05:600c:4fcf:b0:439:8878:5029 with SMTP id 5b1f17b1804b1-43f0e559b59mr25070395e9.2.1744122334712; Tue, 08 Apr 2025 07:25:34 -0700 (PDT) Received: from [192.168.3.141] (p4ff236e3.dip0.t-ipconnect.de. [79.242.54.227]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43f0e5e8dfasm28445335e9.27.2025.04.08.07.25.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Apr 2025 07:25:34 -0700 (PDT) Message-ID: Date: Tue, 8 Apr 2025 16:25:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/3] mm,slub: Do not special case N_NORMAL nodes for slab_nodes To: Harry Yoo Cc: Oscar Salvador , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Vlastimil Babka , Jonathan Cameron , linux-cxl@vger.kernel.org References: <20250408084153.255762-1-osalvador@suse.de> <20250408084153.255762-2-osalvador@suse.de> <92ff4f7f-90d2-48ab-8f7d-7fc3485276b5@redhat.com> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: od_yF9lqeVgNf2WD_LI0bdZOyMyFO2gZhrApThuYaa4_1744122335 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 5306618000A X-Stat-Signature: yzq4c7hd3nsbwzr9kj1196jm8c95ypdc X-Rspam-User: X-HE-Tag: 1744122341-36110 X-HE-Meta: U2FsdGVkX1/eVaQHoWlG3RYiNHrCgJk6pPZvPzpuBXXPzQKg63aq381V7rfUD7Dz1SStEzO4c9o1MdglfTkqGaSUP1t2mfLpSlDbkUTs4aglQdjBVqhHExZho8+Gml9IDp6GnJH+wLWbslnDHXqb3nkzh82XyMbwFBJ9AZcHyzCSO2Bk+TGS2q8eBvVBV0hrGNeJfcnKRGIrxYh8bjZ2pEf9AWhjJCSbuF/NEvRJ2ubZRCumy7+7kVSxetXbbB61L5z/QI0YzzpwovBRmZxVhC7csE85tZdmLqz5si78qPHg9WmGuDfsMrgThv6+q6L12A2IwRBRMCuHd40wb8YEJYRT5OmQ9bZxrl2qBvEW3RNSDKE0b6WKSVBX+JloBJimMZN/j80njXR0vLV7L4NcHls8nrS7jjt+1xGPvzXteF/zp+lqGnj6s2fBKrTzTk03PNwkQZ3LP6MbqTWDAYHqvylJfRT/dF+0/A28CIpPpuICBXxoXJu5kwK5MhAZlBqp77kurI/tUcqbKBi/wMCO3SdHFQmHMd//5lMQ81i6Oa0JpYN18JtqNewZqVzqDYfcB1Px5PFqaT7reFZJ76iBTIFAsxkz5SW6XOjEQ/zx8eeFo+pWxmEs5qpaoAvP2s6Sop7drsyiBMl8ICscSv7EZ0zyJ1o08w0DVCtQHfyHNODw3JvEgXiUoMzHKU5Cj3vHaneoNMJGW2WGSBj/pj2db+cRUHtOULfwp9+Wc6yzGTvj7F6wcaXnMb8oL8Vlfos3scdctLiyUFrdY1QRYo2HnnNTuwe8fuJn1LI37xjQO/8S8PzJsBXl7EsnAEDOHAikcFXILYCOJUSDo9jORTMZVWh0v8DWOMfN0TBIO0PrPMBXyHIVjAVitG5AbQf+1iQrnrWsECYThVI0PriX6gaoQiqbyK3r+qz4ZWY6RBDfJAVuidKNZGz+3nesQ+SoeE+eREnFT0UTAZpfjc3FtJq nJJui8S9 mYsvGISZ9pF20zJB6FDkr512/IDiOPdK1+bj+ilv4GZ7Nz0D9ubHvwM7o4zlBQKOk+/VlKBhHXzVRr3BjM0KZdVTQUuVB1DW0RtC9zR0krdE76GaUe9i/+SDmwsX5im617c2Ds41dV0EnVIrmdo2cT70SywV/d0E4UrIXZEXFw/rt2n2ftQRGQInbj3bZkIGY2z2hUfd4lH8ans/O+tLTQwK6zEGr5ojgXeYOJEEgWWkmKXStBHoYToLyiWxDDF7fCUB2fgdOgJ+KXehMEeJxlaCnx2OoRTykkTopWDdmmfv0ebkSj/as5ottYNBk09mOmaApjGzZnxN9aGR9Ki16x1GQD3J5gtgEvfF3zrxwl1jRauWx7ZEGWamz86LTrgrv3x2t/c4erBNwLnZydtVIRpZYcj27QHpA9+aNpSwsDA4uBoByScXCwd4oLuUrWvR1ubQAM/KYrBbBojJ3Mupl8Qjh+Kdc4Ve0u3eENunwur0bQoOZB0NjyBZPh8r6UP/u1EY08Oi2E6baSZXbqEZ07aYYiNnR1IJLKLEsMAaMqn0fHWDy9JMssftGw2ZXb8nNj/MIkz90O2i8E507RykmffzCdb6KnOsZcKYuYrURUR8X7SqpxCdiGhFXSnZsg2HTJaSuuVY+qsNPTDoixOdrn0Ps7KUcKPc27tgCBJuupO2u/zAuSGSkY003DqyEQymCNTwU 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 08.04.25 16:18, Harry Yoo wrote: > On Tue, Apr 08, 2025 at 12:17:52PM +0200, David Hildenbrand wrote: >> On 08.04.25 10:41, Oscar Salvador wrote: >>> Currently, slab_mem_going_going_callback() checks whether the node has >>> N_NORMAL memory in order to be set in slab_nodes. >>> While it is true that gettind rid of that enforcing would mean >>> ending up with movables nodes in slab_nodes, the memory waste that comes >>> with that is negligible. >>> >>> So stop checking for status_change_nid_normal and just use status_change_nid >>> instead which works for both types of memory. >>> >>> Also, once we allocate the kmem_cache_node cache for the node in >>> slab_mem_online_callback(), we never deallocate it in >>> slab_mem_off_callback() when the node goes memoryless, so we can just >>> get rid of it. >>> >>> The only side effect is that we will stop clearing the node from slab_nodes. >>> >> >> Feel free to add a Suggested-by: if you think it applies. >> >> >> Do we have to take care of the N_NORMAL_MEMORY check in kmem_cache_init() ? Likely it >> would have to be a N_MEMORY check. >> >> >> But, I was wondering if we could get rid of the "slab_nodes" thingy as a first step? > > The following commit says that SLUB has slab_nodes thingy for a reason... > kmem_cache_node might not be ready yet even when N_NORMAL_MEMORY check > says it now has normal memory. node_states_set_node() is called from memory hotplug code after MEM_GOING_ONLINE and after online_pages_range(). Pages might be isolated at that point, but node_states_set_node() is set only after the memory notifier (MEM_GOING_ONLINE) was triggered. So I don't immediately see the problem assuming that we never free the structures. But yeah, this is what I raised below: "Not sure if there are any races to consider" :) > > @Vlastimil maybe a dumb question but why not check s->node[nid] > instead of having slab_nodes bitmask? > > commit 7e1fa93deff44677a94dfc323ff629bbf5cf9360 > Author: Vlastimil Babka > Date: Wed Feb 24 12:01:12 2021 -0800 > > mm, slab, slub: stop taking memory hotplug lock > > Since commit 03afc0e25f7f ("slab: get_online_mems for > kmem_cache_{create,destroy,shrink}") we are taking memory hotplug lock for > SLAB and SLUB when creating, destroying or shrinking a cache. It is quite > a heavy lock and it's best to avoid it if possible, as we had several > issues with lockdep complaining about ordering in the past, see e.g. > e4f8e513c3d3 ("mm/slub: fix a deadlock in show_slab_objects()"). > > The problem scenario in 03afc0e25f7f (solved by the memory hotplug lock) > can be summarized as follows: while there's slab_mutex synchronizing new > kmem cache creation and SLUB's MEM_GOING_ONLINE callback > slab_mem_going_online_callback(), we may miss creation of kmem_cache_node > for the hotplugged node in the new kmem cache, because the hotplug > callback doesn't yet see the new cache, and cache creation in > init_kmem_cache_nodes() only inits kmem_cache_node for nodes in the > N_NORMAL_MEMORY nodemask, which however may not yet include the new node, > as that happens only later after the MEM_GOING_ONLINE callback. > > Instead of using get/put_online_mems(), the problem can be solved by SLUB > maintaining its own nodemask of nodes for which it has allocated the > per-node kmem_cache_node structures. This nodemask would generally mirror > the N_NORMAL_MEMORY nodemask, but would be updated only in under SLUB's > control in its memory hotplug callbacks under the slab_mutex. This patch > adds such nodemask and its handling. > > Commit 03afc0e25f7f mentiones "issues like [the one above]", but there > don't appear to be further issues. All the paths (shared for SLAB and > SLUB) taking the memory hotplug locks are also taking the slab_mutex, > except kmem_cache_shrink() where 03afc0e25f7f replaced slab_mutex with > get/put_online_mems(). > > We however cannot simply restore slab_mutex in kmem_cache_shrink(), as > SLUB can enters the function from a write to sysfs 'shrink' file, thus > holding kernfs lock, and in kmem_cache_create() the kernfs lock is nested > within slab_mutex. But on closer inspection we don't actually need to > protect kmem_cache_shrink() from hotplug callbacks: While SLUB's > __kmem_cache_shrink() does for_each_kmem_cache_node(), missing a new node > added in parallel hotplug is not fatal, and parallel hotremove does not > free kmem_cache_node's anymore after the previous patch, so use-after free > cannot happen. The per-node shrinking itself is protected by > n->list_lock. Same is true for SLAB, and SLOB is no-op. > > SLAB also doesn't need the memory hotplug locking, which it only gained by > 03afc0e25f7f through the shared paths in slab_common.c. Its memory > hotplug callbacks are also protected by slab_mutex against races with > these paths. The problem of SLUB relying on N_NORMAL_MEMORY doesn't apply > to SLAB, as its setup_kmem_cache_nodes relies on N_ONLINE, and the new > node is already set there during the MEM_GOING_ONLINE callback, so no > special care is needed for SLAB. > > As such, this patch removes all get/put_online_mems() usage by the slab > subsystem. > > Link: https://lkml.kernel.org/r/20210113131634.3671-3-vbabka@suse.cz > Signed-off-by: Vlastimil Babka > Cc: Christoph Lameter > Cc: David Hildenbrand > Cc: David Rientjes > Cc: Joonsoo Kim > Cc: Michal Hocko > Cc: Pekka Enberg > Cc: Qian Cai > Cc: Vladimir Davydov > Signed-off-by: Andrew Morton > Signed-off-by: Linus Torvalds > >> >> From 518a2b83a9c5bd85d74ddabbc36ce5d181a88ed6 Mon Sep 17 00:00:00 2001 >> From: David Hildenbrand >> Date: Tue, 8 Apr 2025 12:16:13 +0200 >> Subject: [PATCH] tmp >> >> Signed-off-by: David Hildenbrand >> --- >> mm/slub.c | 56 ++++--------------------------------------------------- >> 1 file changed, 4 insertions(+), 52 deletions(-) >> >> diff --git a/mm/slub.c b/mm/slub.c >> index b46f87662e71d..afe31149e7f4e 100644 >> --- a/mm/slub.c >> +++ b/mm/slub.c >> @@ -445,14 +445,6 @@ static inline struct kmem_cache_node *get_node(struct kmem_cache *s, int node) >> for (__node = 0; __node < nr_node_ids; __node++) \ >> if ((__n = get_node(__s, __node))) >> -/* >> - * Tracks for which NUMA nodes we have kmem_cache_nodes allocated. >> - * Corresponds to node_state[N_NORMAL_MEMORY], but can temporarily >> - * differ during memory hotplug/hotremove operations. >> - * Protected by slab_mutex. >> - */ >> -static nodemask_t slab_nodes; >> - >> #ifndef CONFIG_SLUB_TINY >> /* >> * Workqueue used for flush_cpu_slab(). >> @@ -3706,10 +3698,9 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, >> if (!slab) { >> /* >> * if the node is not online or has no normal memory, just >> - * ignore the node constraint >> + * ignore the node constraint. >> */ >> - if (unlikely(node != NUMA_NO_NODE && >> - !node_isset(node, slab_nodes))) >> + if (unlikely(node != NUMA_NO_NODE && !node_state(node, N_NORMAL_MEMORY))) >> node = NUMA_NO_NODE; >> goto new_slab; >> } >> @@ -3719,7 +3710,7 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node, >> * same as above but node_match() being false already >> * implies node != NUMA_NO_NODE >> */ >> - if (!node_isset(node, slab_nodes)) { >> + if (!node_state(node, N_NORMAL_MEMORY)) { >> node = NUMA_NO_NODE; >> } else { >> stat(s, ALLOC_NODE_MISMATCH); >> @@ -5623,7 +5614,7 @@ static int init_kmem_cache_nodes(struct kmem_cache *s) >> { >> int node; >> - for_each_node_mask(node, slab_nodes) { >> + for_each_node_state(node, N_NORMAL_MEMORY) { >> struct kmem_cache_node *n; >> if (slab_state == DOWN) { >> @@ -6164,30 +6155,6 @@ static int slab_mem_going_offline_callback(void *arg) >> return 0; >> } >> -static void slab_mem_offline_callback(void *arg) >> -{ >> - struct memory_notify *marg = arg; >> - int offline_node; >> - >> - offline_node = marg->status_change_nid_normal; >> - >> - /* >> - * If the node still has available memory. we need kmem_cache_node >> - * for it yet. >> - */ >> - if (offline_node < 0) >> - return; >> - >> - mutex_lock(&slab_mutex); >> - node_clear(offline_node, slab_nodes); >> - /* >> - * We no longer free kmem_cache_node structures here, as it would be >> - * racy with all get_node() users, and infeasible to protect them with >> - * slab_mutex. >> - */ >> - mutex_unlock(&slab_mutex); >> -} >> - >> static int slab_mem_going_online_callback(void *arg) >> { >> struct kmem_cache_node *n; >> @@ -6229,11 +6196,6 @@ static int slab_mem_going_online_callback(void *arg) >> init_kmem_cache_node(n); >> s->node[nid] = n; >> } >> - /* >> - * Any cache created after this point will also have kmem_cache_node >> - * initialized for the new node. >> - */ >> - node_set(nid, slab_nodes); >> out: >> mutex_unlock(&slab_mutex); >> return ret; >> @@ -6253,8 +6215,6 @@ static int slab_memory_callback(struct notifier_block *self, >> break; >> case MEM_OFFLINE: >> case MEM_CANCEL_ONLINE: >> - slab_mem_offline_callback(arg); >> - break; >> case MEM_ONLINE: >> case MEM_CANCEL_OFFLINE: >> break; >> @@ -6309,7 +6269,6 @@ void __init kmem_cache_init(void) >> { >> static __initdata struct kmem_cache boot_kmem_cache, >> boot_kmem_cache_node; >> - int node; >> if (debug_guardpage_minorder()) >> slub_max_order = 0; >> @@ -6321,13 +6280,6 @@ void __init kmem_cache_init(void) >> kmem_cache_node = &boot_kmem_cache_node; >> kmem_cache = &boot_kmem_cache; >> - /* >> - * Initialize the nodemask for which we will allocate per node >> - * structures. Here we don't need taking slab_mutex yet. >> - */ >> - for_each_node_state(node, N_NORMAL_MEMORY) >> - node_set(node, slab_nodes); >> - >> create_boot_cache(kmem_cache_node, "kmem_cache_node", >> sizeof(struct kmem_cache_node), >> SLAB_HWCACHE_ALIGN | SLAB_NO_OBJ_EXT, 0, 0); >> -- >> 2.48.1 >> >> >> Not sure if there are any races to consider ... just an idea. >> >> -- >> Cheers, >> >> David / dhildenb >> > -- Cheers, David / dhildenb