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 86023E77188 for ; Fri, 10 Jan 2025 15:31:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D7AC6B00C3; Fri, 10 Jan 2025 10:31:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0888D6B00C4; Fri, 10 Jan 2025 10:31:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E449D8D0001; Fri, 10 Jan 2025 10:31:56 -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 C254D6B00C3 for ; Fri, 10 Jan 2025 10:31:56 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 863AFAFCDC for ; Fri, 10 Jan 2025 15:31:56 +0000 (UTC) X-FDA: 82991932632.27.9D6DEAE Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf27.hostedemail.com (Postfix) with ESMTP id 305DD40016 for ; Fri, 10 Jan 2025 15:31:53 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=pH2oRnD+; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=W0nxwvlF; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=pH2oRnD+; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=W0nxwvlF; dmarc=none; spf=pass (imf27.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736523114; a=rsa-sha256; cv=none; b=13oL+Cqij9dx/1kTRhlVkPB4ToJUX6Y9v5HH0GC3IvcE0zlQSaBCGJPmHQb49olMS3H8wC rTIiatEe8ZmjgSOY3P+XgA2d8YKl5r8NP9lcQQO6BD/J7CGYX5lHr78nHobQYtDBENAWKX Af81ONKfir8a/298a92hJjO9S5+iPUE= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=pH2oRnD+; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=W0nxwvlF; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=pH2oRnD+; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=W0nxwvlF; dmarc=none; spf=pass (imf27.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736523114; 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=cOjdXbMeCouUJJMhhxWnsmEBcM7x7lkLxYBOlUoTpPk=; b=pDsnPlnRnckS3S+nVmT5/JdGSff5B8jf1IhUt4oq/IWz/DdjKZ9eElmGCzym4cX68qvM7Y C2PfB7Zd9B7t7P9sAnCUcZd6Ia1IJno+gnLzjXCQ1teCXsthcR4E14YJaa7qDcbC5d68Ib f1f8XHpmIlIB+QTsvhKFfQTRLujOsu8= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 806E11F394; Fri, 10 Jan 2025 15:31:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1736523112; h=from:from:reply-to: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; bh=cOjdXbMeCouUJJMhhxWnsmEBcM7x7lkLxYBOlUoTpPk=; b=pH2oRnD+F+SzYwzOJHA0/uOn8S9GPOM76Xmhwcrk5xmcu6Hx3+65xLC74odbeDBTw5Ali+ iKOLSdNLTB9IcAHhLZNgeRjxR23MhyTAaBTN/nKGCLckNSshsrkt9G5zCl2zC/ueyR8y6j EISMmNuKdZvwWV1vDOFmAH6UBqsSYSE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1736523112; h=from:from:reply-to: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; bh=cOjdXbMeCouUJJMhhxWnsmEBcM7x7lkLxYBOlUoTpPk=; b=W0nxwvlFNSBxIig/hgj1mUPFegRTg2mTgjmmTOwQI/LJ72EEnVexj9l4w1pXwfMqwnZg1D +ZNmLeK8I4+3MzCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1736523112; h=from:from:reply-to: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; bh=cOjdXbMeCouUJJMhhxWnsmEBcM7x7lkLxYBOlUoTpPk=; b=pH2oRnD+F+SzYwzOJHA0/uOn8S9GPOM76Xmhwcrk5xmcu6Hx3+65xLC74odbeDBTw5Ali+ iKOLSdNLTB9IcAHhLZNgeRjxR23MhyTAaBTN/nKGCLckNSshsrkt9G5zCl2zC/ueyR8y6j EISMmNuKdZvwWV1vDOFmAH6UBqsSYSE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1736523112; h=from:from:reply-to: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; bh=cOjdXbMeCouUJJMhhxWnsmEBcM7x7lkLxYBOlUoTpPk=; b=W0nxwvlFNSBxIig/hgj1mUPFegRTg2mTgjmmTOwQI/LJ72EEnVexj9l4w1pXwfMqwnZg1D +ZNmLeK8I4+3MzCQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 56EC013763; Fri, 10 Jan 2025 15:31:52 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id oZzyFGg9gWepCQAAD6G6ig (envelope-from ); Fri, 10 Jan 2025 15:31:52 +0000 Message-ID: <41ebce1a-9cc0-471e-ac20-25efea9a933a@suse.cz> Date: Fri, 10 Jan 2025 16:32:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 15/16] mm: make vma cache SLAB_TYPESAFE_BY_RCU To: Suren Baghdasaryan , akpm@linux-foundation.org Cc: peterz@infradead.org, willy@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@oracle.com, mhocko@suse.com, hannes@cmpxchg.org, mjguzik@gmail.com, oliver.sang@intel.com, mgorman@techsingularity.net, david@redhat.com, peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, lokeshgidra@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, klarasmodin@gmail.com, richard.weiyang@gmail.com, corbet@lwn.net, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com References: <20250109023025.2242447-1-surenb@google.com> <20250109023025.2242447-16-surenb@google.com> From: Vlastimil Babka Content-Language: en-US In-Reply-To: <20250109023025.2242447-16-surenb@google.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 305DD40016 X-Stat-Signature: pbcduy64ycfyh8w846uguo6c1sb3jms1 X-HE-Tag: 1736523113-190274 X-HE-Meta: U2FsdGVkX1+IBhk6yJPNCNrDm/vPdQFsUZHrMZrEnprtEMEM/TMXdkPT+8X5jYIyJXp94/XnYwr0t5BOxtIL47F8tPUN+TabQ4cKlFB4gfW+3rFvg3t+kkILdkeC5y+xT8WeoQEgaKSjq8w/LKCEknnrqmYN6da7rlLq3jdmcIGu9ptE8vssJllpBkJWbiKH8xhCPQMa+3S70K4EFbBuDfeawNVlA8aBa2eAPjsmxGGCXevzHU9cpxEbh65Wez3d4Um7c5H+9j3oPz7oN5nub5KKkrA8PMstrD4My7Y1m+kIhwl2yVXNx7tZYvZ+CAKTXWJkjn58cRQI3gtzVQo5XqwgPj4NlitdR5Biq6yZ/sbDfGwjt2fRQargI3uw7sfjeGb4k59E0I1pZgkEMKhLJIRQ09m/8+0nQwFgjoLV4vMkWL5gmayh7nNj21OUxPB+QIZFf3GhcAgZsH5UaKuD/OIIrNULd4FgOgZRH3QUNm/K9hP1uVTFAN+GVcccIeMn7vq2GD1j+sGpVbBc3hGpGAEpkhxJulgZih3Rij3kaudJpbAQpY1AgRiQidA30w2NVYtoYwf/WxqghAyy0eaCBgs4E7Cj6226n/pom9HfGbjluQa1dQUwe9vGSdwFk4Lvba0pUMWlodkcNvgB+bKBb6elcG62Mz6d1/Lvri4Y+bWSB1QMA9mahJ8H+DYBruGMuA2qPHqoOnvnvabFARTgU58WJzOuTlMRyOsijann7cjng0F6oLfSdTZQXQNsasp28iUoLBYRtbDd4T4MySPHa7wLDRRgk7OFFhU6HfP92B/kmzMot30QS1c+FRTG4x+XUUbqlSZzveD3dYhssIQ0VMt3lbLQnh3UKlC6XywtmX4+a/ZADR21VMiV1VCB0P5rb1vdnNSK1hTx4PyxG3dRIydfJqlKMsbkKPPmRLkdPD4I80YtDdth+G60Av9spdB07HPUaba9c2xlWK9Sdgl sCCTKkCq +aPqtN3dE5UYMt5vH7GvF1f+kC1A29jY9a6KnRcG3Fi7fmTL1in5MnRpHwlMELqk7d76GWZpVMfTa4n42gZJo919g4sICymNYozWuJArvEOcCV9XVIUietcP9OhHSLhrubUfSdWvOtkagEWNTz1UilCMHax0Oai22Wnnme57SproAajSWqkf8rXqU0t37Wm64WvywXkYcU9vW2p8TefeDj4wItGjXhQHMjOv5yboAV/P/yZ0YpK9kgPrIOdgweM1ARudLkK2yvzZRUziqmHM1ditSpPAXS66klahAxjnbcyGWjXTCgoHH2S+c/++36xglR55EGVtQYMX4Hy5g8bo9zIvU3AhKB0cUNdtFaYh8KzXfN9y2C8SBNR6ImsYEflkoxRW+fABBZuTaLMZLaky39ORYoJbXY3DUrg26hOmAB5aJJpY= 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 1/9/25 3:30 AM, Suren Baghdasaryan wrote: > To enable SLAB_TYPESAFE_BY_RCU for vma cache we need to ensure that > object reuse before RCU grace period is over will be detected by > lock_vma_under_rcu(). > Current checks are sufficient as long as vma is detached before it is > freed. The only place this is not currently happening is in exit_mmap(). > Add the missing vma_mark_detached() in exit_mmap(). > Another issue which might trick lock_vma_under_rcu() during vma reuse > is vm_area_dup(), which copies the entire content of the vma into a new > one, overriding new vma's vm_refcnt and temporarily making it appear as > attached. This might trick a racing lock_vma_under_rcu() to operate on > a reused vma if it found the vma before it got reused. To prevent this > situation, we should ensure that vm_refcnt stays at detached state (0) > when it is copied and advances to attached state only after it is added > into the vma tree. Introduce vma_copy() which preserves new vma's > vm_refcnt and use it in vm_area_dup(). Since all vmas are in detached > state with no current readers when they are freed, lock_vma_under_rcu() > will not be able to take vm_refcnt after vma got detached even if vma > is reused. > Finally, make vm_area_cachep SLAB_TYPESAFE_BY_RCU. This will facilitate > vm_area_struct reuse and will minimize the number of call_rcu() calls. > > Signed-off-by: Suren Baghdasaryan Reviewed-by: Vlastimil Babka You could also drop the reset_refcnt parameter of vma_lock_init() now, as the usage in vm_area_dup() should now be just setting 0 over 0. Maybe a VM_WARN_ON if it's not 0 already? And a comment in vm_area_struct definition to consider vma_copy() when adding any new field? > + /* > + * src->shared.rb may be modified concurrently, but the clone > + * will be reinitialized. > + */ > + data_race(memcpy(&dest->shared, &src->shared, sizeof(dest->shared))); The comment makes it sound as if we didn't need to do it at all? But I didn't verify. If we do need it in some cases (i.e. the just allocated vma might have garbage from previous lifetime, but src is well defined and it's a case where it's not reinitialized afterwards) maybe the comment should say? Or if it's either reinitialized later or zeroes at src, we could memset() the zeroes instead of memcpying them, etc.