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 3D28EC38147 for ; Wed, 18 Jan 2023 12:51:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C422D6B0071; Wed, 18 Jan 2023 07:51:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BCB5A6B0072; Wed, 18 Jan 2023 07:51:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A6BF56B007D; Wed, 18 Jan 2023 07:51:18 -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 95A166B0071 for ; Wed, 18 Jan 2023 07:51:18 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 600AA1C24C3 for ; Wed, 18 Jan 2023 12:51:18 +0000 (UTC) X-FDA: 80367905436.07.3866948 Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by imf18.hostedemail.com (Postfix) with ESMTP id DB3041C0007 for ; Wed, 18 Jan 2023 12:51:12 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=DhsG3zM8; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of jannh@google.com designates 209.85.166.41 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674046272; 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=K7Rqiin9Kbad8ru/LcIchuAOUvYmmUjlYJik2JJBLXA=; b=SpkEjMZPelPU0wQEIztbkz2HL6FyTsVuxAEv+ZXVxY6u4qiZuB4sOs3Qyh5qTmjgxEwAA5 rMccZYcTJ20KEarnFXyBar/Oe3pg8TYQIXlLZNGptAnToei+NdfY8mWWV9NHQuyl6vqBfl Dd8BSb9hPOyLv5ZVTjwFNMOQqU8bmGU= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=DhsG3zM8; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf18.hostedemail.com: domain of jannh@google.com designates 209.85.166.41 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674046272; a=rsa-sha256; cv=none; b=EgzVVAQPWvb2kESMfV17oR4IbNrAHT1UvnjyszA7PD+q8X4uBvq2ozGmIX+HV7BSfjpVeW oG6N7WOKIpJhBPbRCtomgM16UWULbmnhdoVr0ajKiorL4rjSNlJLjQSpvphg1PGX/Exre6 HRydP98mZixxLYHcKiB12vlOF57VVBs= Received: by mail-io1-f41.google.com with SMTP id y69so1844218iof.3 for ; Wed, 18 Jan 2023 04:51:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=K7Rqiin9Kbad8ru/LcIchuAOUvYmmUjlYJik2JJBLXA=; b=DhsG3zM8wnA8HofZfhQ4706XMhy790XGUqogcXCqHX85Tk8zZYxt5jMYu+eLJpJd0W WeZPMkDrbovMJNBWiALe2hNQO8RzVtnNL439Lg2lNDDkCN2JbO2/orikCzbM4nXJ7Ric pxfkouKT613poEWiZM0/S3Q0O76EFSePCk6Wx7nVSwD2fTxP6JpqrPF+F0bbjgoXhdSo JRONC1h0hiGS5i3GPDsY5q0sJr2GonkT+Yc4S8N+6WB4gZtHvq+jv8OZ5eQyCbLl1GpR opC+QyjARoxP8394hD2OHnWQsI8rTlz89//+DOWhBL6cmnhWRNKu2nd1HuPty+PyYUI0 rVjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=K7Rqiin9Kbad8ru/LcIchuAOUvYmmUjlYJik2JJBLXA=; b=E3mrdU/Cbf+7cwr2EFTsSxp2f9OSdn8KujmPVi8GWEaau2MPPhC/QCGYzdP2ub0+zP x1hGcS62iDRG18G7dNvNOY17Z3XY27AzUclyC8IHLREfb2i8N2FDZp3ZWx4Z3iokdKG1 FjQkTkllORW7ByZZo5XiFTDX3dm4yUnmNfi/ik6JCiwpBOmhyxxuyftufg5iqNZsITfu +J0VvWyCfjtt2T56d4UDUr0qq+xidnFzJ0RFg2Jjr1yvOAx26dyCH+Kl6tKM3ywyVmDh GLxMvjDvENqOoDWLZMxg8H1xoOdPH0LxWftYFVqNjTrj3qYq58/ukd93dLvnAEqsEBr9 3fGg== X-Gm-Message-State: AFqh2kroPJqmkankbg/5PAp9UVdeUXm81E/+A1zxDeBs1BTkf/QXfdNt AJ839FfE/kuEkGvqxpzAtWTIw4778wIaiNYr4EWB7A== X-Google-Smtp-Source: AMrXdXubEhuDA02ILCkh7B1Dp3y4Bt1fmHskBAwMDp3qrJV2IDmWe32RqObGG2ZP8z4nawtc1f2Tp/05rwFtfOAFxMY= X-Received: by 2002:a02:c884:0:b0:39e:9d33:a47 with SMTP id m4-20020a02c884000000b0039e9d330a47mr496380jao.58.1674046267428; Wed, 18 Jan 2023 04:51:07 -0800 (PST) MIME-Version: 1.0 References: <20230109205336.3665937-1-surenb@google.com> <20230109205336.3665937-28-surenb@google.com> In-Reply-To: <20230109205336.3665937-28-surenb@google.com> From: Jann Horn Date: Wed, 18 Jan 2023 13:50:31 +0100 Message-ID: Subject: Re: [PATCH 27/41] mm/mmap: prevent pagefault handler from racing with mmu_notifier registration To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, paulmck@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, hughlynch@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: DB3041C0007 X-Stat-Signature: wp6r7o4c51s5pzymfj6hwfqr7dyawamo X-HE-Tag: 1674046272-812752 X-HE-Meta: U2FsdGVkX1/PlOZkbfjyJqtE2gld4YF9XnNkwtUAbi+Snrpqxk9nsI7Bc6BZNsjwVmN2iR0HC8Y9jEQSLtRy7hTcHdkuPpobX0Z54gRMPFtY5XB5FkIbWyB5Neio8/FxxrmDIEOB3Ga2rlQRhLg/3cvUVMxBEjvj20/ix70+ZUnqaaUsJrqirsXkyG5uttSU5/azViy93y3ck/Xq+IbmzK9RTRfw2VCQz7JVnT5h473aIAyRsjTau6kC0yFVVr9nYOF7xQ7oDciuD/T9VyqbAxAKV59/yejXn5nYh8molV03dTucHkKpBAG14dNwnOCO7awOfzJ7+baMxypDBnf5yMToWbGxwHXWd057nSRP69VhTjTv8caJNT61ab+pALcnKDWeloXxnnsetMHBoUzaKVqMEciHIfmKlMvIJi2CF0ZFcJxG5NNDnPT5JU5GSXN/XAUiCxjPa3HLtmefcJaTM+JqE6LVr16ydJR7S3XYrXr/mk9lmYECqDM8dVwHecH7+scNlVXuoV8yzZAGIi9u5ftojIi/givhg5I1eBxbHsJVCnXqAwJ5hrKRVBWqyyyavPSKw8BWS2c3O5cErBrwxJxqmTbpSfRK4UrLNwykra4KfjDU9OEgwDEl+ggbx4hOIUV2I1FL84dlacwvaXZNIiwCEGhUzQ5uGb/X63LJ6myBLqv79eVtQtaDvYxxgHJ1/tU0ND+1oM5/z4f87fabGy4F3ZvZK+o/5MjB1qHGNFm7pyvHXvK4HnjwN4R12EkkvuMaCUrlxGzNJisQpYHTUCDzJY4nZp6chdTlfqlPrOJmSQQ50D4/GOgpTqUwNm4372JZWk634+9i+3JH0+xaDwSY+dU5fc9S5owbiTDzPj9azrfxtKXTf4EVhsayKxOIbN1d1JW/egGzSOdk/K1ImNMyLAAvFatnJr0jh6Y5TmtUQ82judc6fVDgwE9QqrHcOlrKrezi3IabAuTtaQF tAAClOjR FFFJlBSeiHVsD998gL4p+6B077hTTzpMYNOocPj766CL9q7BbGO0p/6rEsg== 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 Mon, Jan 9, 2023 at 9:54 PM Suren Baghdasaryan wrote: > Page fault handlers might need to fire MMU notifications while a new > notifier is being registered. Modify mm_take_all_locks to write-lock all > VMAs and prevent this race with fault handlers that would hold VMA locks. > VMAs are locked before i_mmap_rwsem and anon_vma to keep the same > locking order as in page fault handlers. > > Signed-off-by: Suren Baghdasaryan > --- > mm/mmap.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/mm/mmap.c b/mm/mmap.c > index 30c7d1c5206e..a256deca0bc0 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -3566,6 +3566,7 @@ static void vm_lock_mapping(struct mm_struct *mm, struct address_space *mapping) > * of mm/rmap.c: > * - all hugetlbfs_i_mmap_rwsem_key locks (aka mapping->i_mmap_rwsem for > * hugetlb mapping); > + * - all vmas marked locked The existing comment above says that this is an *ordered* listing of which locks are taken. > * - all i_mmap_rwsem locks; > * - all anon_vma->rwseml > * > @@ -3591,6 +3592,7 @@ int mm_take_all_locks(struct mm_struct *mm) > mas_for_each(&mas, vma, ULONG_MAX) { > if (signal_pending(current)) > goto out_unlock; > + vma_write_lock(vma); > if (vma->vm_file && vma->vm_file->f_mapping && > is_vm_hugetlb_page(vma)) > vm_lock_mapping(mm, vma->vm_file->f_mapping); Note that multiple VMAs can have the same ->f_mapping, so with this, the lock ordering between VMA locks and the mapping locks of hugetlb VMAs is mixed: If you have two adjacent hugetlb VMAs with the same ->f_mapping, then the following operations happen: 1. lock VMA 1 2. lock mapping of VMAs 1 and 2 3. lock VMA 2 4. [second vm_lock_mapping() is a no-op] So for VMA 1, we ended up taking the VMA lock first, but for VMA 2, we took the mapping lock first. The existing code has one loop per lock type to ensure that the locks really are taken in the specified order, even when some of the locks are associated with multiple VMAs. If we don't care about the ordering between these two, maybe that's fine and you just have to adjust the comment; but it would be clearer to add a separate loop for the VMA locks. > @@ -3677,6 +3679,7 @@ void mm_drop_all_locks(struct mm_struct *mm) > if (vma->vm_file && vma->vm_file->f_mapping) > vm_unlock_mapping(vma->vm_file->f_mapping); > } > + vma_write_unlock_mm(mm); > > mutex_unlock(&mm_all_locks_mutex); > } > -- > 2.39.0 >