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 8D8FEC41513 for ; Wed, 9 Aug 2023 17:17:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08C3E8E0001; Wed, 9 Aug 2023 13:17:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 03DB56B0074; Wed, 9 Aug 2023 13:17:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E46498E0001; Wed, 9 Aug 2023 13:17:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D7CD46B0071 for ; Wed, 9 Aug 2023 13:17:50 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 910A241003 for ; Wed, 9 Aug 2023 17:17:50 +0000 (UTC) X-FDA: 81105223500.13.FB08C52 Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf07.hostedemail.com (Postfix) with ESMTP id CE22540017 for ; Wed, 9 Aug 2023 17:17:48 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=WdyDYjZL; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691601468; a=rsa-sha256; cv=none; b=PeLVmXb9wAfpM8Zk+WlRFAP2RUCsAHfYm3GF7j/qUA/AwIyMtQK5pIxrgWxgbj6Fbo0WyS eh9ZqyXaNlbShSL4ZmgUGQAO7iaGzzzVaVTG1L3rcZL+w+Vv0A/oB3EHOKKpX9uAt5ySV4 vCbPkHcgIKPbmT5y1yu/vFjJcXXAEIA= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=WdyDYjZL; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf07.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691601468; 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=8YDBTNJWK8KKeeHFIAMz4iX5py0bAqQkSOpgGSLWNgk=; b=Z+JrdV76gfC2OMA8SoANQ6xwlrPdMxg/RRqWZcZ9YW0il7md+n+uaGGvhy8zxPtjR+n7P+ p/Nu2UVkRJT0MYgs1H48RVsIXxtPISnDBbqbiBt3DXjDdTwDYqt4D2U8hYNdGC30HmQzBy CRQF0SgYeUy2heZgnDSf7YcjfGbsWyg= Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-bcb6dbc477eso4373276.1 for ; Wed, 09 Aug 2023 10:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691601468; x=1692206268; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8YDBTNJWK8KKeeHFIAMz4iX5py0bAqQkSOpgGSLWNgk=; b=WdyDYjZLb5Sxa5LnSyXB50vFmLlpcxX+xLZhUVzCELwnhiJiSrCZs0WCS79/F830zA NL4O2toEICEWlBHISQuSu7VoplHVrKKAj867v7grjUDAry03x580qRSU/mxfo3VWYqKz Z82HHj6MmU5YY2eNLLAF1A/+IfPn7dNjN89eZIJ3dc7vLS2Pqv5KiJeKgivX90Utdz7L zaR5bTv106vvb0UEcMILFYQSSQFGUFfad+JqbKRsz6lA3v+Ar1wa3o6talo4d/Pr3+XU js2Vvork5RG4NV+TSo9P2cokjR1DfCny0FVb6hhP318jmP2NK3t2a1lw4iT/p46+i6gM +phQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691601468; x=1692206268; h=content-transfer-encoding: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=8YDBTNJWK8KKeeHFIAMz4iX5py0bAqQkSOpgGSLWNgk=; b=NC4yPUw6uUo7pF/WBuIZMVxdNFB8p10dVWXDd6teEsdpwv+Ct/s5M/95DvqNdaNJB6 Px52q/J2f+UTsMo/KpmLibodGhXnCAaGJxLETl1d+fmqV7kPiqUt8k06ULM/11pzUG+w fMinNAbc4ueXPtOza4MfxHd/H6nsJyFAgNb6i9iH4N0kXFtD/6M2/1uNDob5QU7zgekW TPlapw9n/ky/4QYWQNGr+ATFodq7fkDZa0LqcqWLH3FWJT3wu2NWiLhxG2bsgHp+DYzJ 5T8fYdpSdie0C3GXz5xmyR/uvsZVn8ooTNMSPUYZgNhPMPkWlj5USL7u5JJ8Crb+TCgX dBlg== X-Gm-Message-State: AOJu0YwuX7zW65kNBPxoj6RLR/aWY68W9LxH4m4vtNpAFCgJPm1cKPcp 0zlncdwudGmjhG3Wy/NDP1HIXStsVDG/3KX5rGpBDw== X-Google-Smtp-Source: AGHT+IH6M+ot6e3xpdDsK6dsLWmOJ5zXROil92xJwlNugiU9TU9M3Tczc/8Fe34U2Cnru1GU2mv2jrRu6dP1b9THkuM= X-Received: by 2002:a25:d114:0:b0:d35:9a48:51b0 with SMTP id i20-20020a25d114000000b00d359a4851b0mr78425ybg.7.1691601467704; Wed, 09 Aug 2023 10:17:47 -0700 (PDT) MIME-Version: 1.0 References: <20230630211957.1341547-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 9 Aug 2023 10:17:34 -0700 Message-ID: Subject: Re: [PATCH v7 0/6] Per-VMA lock support for swap and userfaults To: David Hildenbrand Cc: akpm@linux-foundation.org, willy@infradead.org, hannes@cmpxchg.org, mhocko@suse.com, josef@toxicpanda.com, jack@suse.cz, ldufour@linux.ibm.com, laurent.dufour@fr.ibm.com, michel@lespinasse.org, liam.howlett@oracle.com, jglisse@google.com, vbabka@suse.cz, minchan@google.com, dave@stgolabs.net, punit.agrawal@bytedance.com, lstoakes@gmail.com, hdanton@sina.com, apopple@nvidia.com, peterx@redhat.com, ying.huang@intel.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, viro@zeniv.linux.org.uk, brauner@kernel.org, pasha.tatashin@soleen.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: CE22540017 X-Stat-Signature: iyxidah5ikzqx6oekpo98uinrj8z8ons X-HE-Tag: 1691601468-439996 X-HE-Meta: U2FsdGVkX1/99Zc/Y0y1EYTfPTZAj05qBpt88LB1arisYfiET0WT/YHbzcNjfMqsw/Hm6NG2sOBGD1lhY2NYIht2yXKE9UM+dd2GltfqpdUxe++EAv5u4vmnndzsDf3MMIsoo9Arf4sT1S1OMSf9HXmQwOrlflBi7Qvy5BaZTf2BlNwjoz/GvCCo+KLaPN4xxnAA4++OZeCDRiV0MXjXb2CC2fwlJECgtbCkBE5GfgyNG68tduniYz2/Hx1gflqveoe3qn4cv9GKmeoiMcKsoBh3GsY0itDNOKyv15poCgOPzaNH+kqifwfvxshXpMCrBaO21wGF4I/Vw9vOxua59X2IjCBfiecA9WN2OgyRDiplzg1yl0pjgcmW+2nKnzz5bOf+s8fQe0cWy9RgBqkIjo0l0leH9HoFwKtud38ixUDILeGLxr6kAhAABd3i5qgaISVNkZrnuHrLO03q/T6PR4U/Zw97eaILi8v1F+e6CzEZviycOoU4Ij+uF/00QLHoAQVBId00mzhgQuJOUJGJ2UkOZCQ1dh/qND/cMdkn+r2LSWNasr5xR+pz5Jmldc2U0A7GJgdJ98OeIo/tF9mWcaIiuw+sEIyVexWJWJ378UlZFKlgTEquorVp9aPIXChNhuSeOQGlFyXNFLJGX7c+FtaWEa+I9unvXhoLXLEZzRG0zsjXCE2hQM6QzjrxX9CSWP0d9ZpEDHZyG9ntrIDmCfksqt6JK6sIHh+aDmMpcrvUEI5xntRGXIWHFp676Gb6xx/w+qlg/4++WrChKXRQ34GB8G1seMekFW3/dbwJDzvaejB63iWM/fsnlJ/PcRHf4aN8lpEi67ie5zM9wr0zfazn/ia5iXTMWDrvcghmvsf7jVBR6BpnJdXH8HJUdjoUT89wt/ome78vtgdcwZ7ow+8B2fy82+BNfxNe2zfkeL4hrsJToBA506ikPVLwPcehvNP9eAUX/P3yrJ4AQD5 X7SOB29R iudL4jAdv0D2YRkxGoF67ufcBgL3owJwJr0rcKEOZNWgfWYzMpRxEGzklUricCX/GXHd+H0DRNkfIGRxHMqsj0ZMMLgmVI0Bhl0siKZdtN4rM21SPw8EkuXoXGDWJipJlTjo6oNRb8/0U6wjexvOPFw0CiRHCiHP0d80JGuqdYLabD3Y4tnuZ9gU+vGCCgdDOZ8EuCRke5iPVBXI/gvwBGgso05C00XCEdZ1IYha1in+yPCyceykLkMhZETGUBZXlGYpuNtmLWBZuCPWeN0frilYwQuY8kO7bWiSKdIY1ItxK4HbAbfB8G7na/spd4gHGsRpmBXevJ+xCDPg= 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 Wed, Aug 9, 2023 at 8:22=E2=80=AFAM Suren Baghdasaryan wrote: > > On Wed, Aug 9, 2023 at 7:28=E2=80=AFAM Suren Baghdasaryan wrote: > > > > On Wed, Aug 9, 2023 at 12:49=E2=80=AFAM David Hildenbrand wrote: > > > > > > On 30.06.23 23:19, Suren Baghdasaryan wrote: > > > > When per-VMA locks were introduced in [1] several types of page fau= lts > > > > would still fall back to mmap_lock to keep the patchset simple. Amo= ng them > > > > are swap and userfault pages. The main reason for skipping those ca= ses was > > > > the fact that mmap_lock could be dropped while handling these fault= s and > > > > that required additional logic to be implemented. > > > > Implement the mechanism to allow per-VMA locks to be dropped for th= ese > > > > cases. > > > > First, change handle_mm_fault to drop per-VMA locks when returning > > > > VM_FAULT_RETRY or VM_FAULT_COMPLETED to be consistent with the way > > > > mmap_lock is handled. Then change folio_lock_or_retry to accept vm_= fault > > > > and return vm_fault_t which simplifies later patches. Finally allow= swap > > > > and uffd page faults to be handled under per-VMA locks by dropping = per-VMA > > > > and retrying, the same way it's done under mmap_lock. > > > > Naturally, once VMA lock is dropped that VMA should be assumed unst= able > > > > and can't be used. > > > > > > > > Changes since v6 posted at [2] > > > > - 4/6 replaced the ternary operation in folio_lock_or_retry, > > > > per Matthew Wilcox > > > > - 4/6 changed return code description for __folio_lock_or_retry > > > > per Matthew Wilcox > > > > > > > > Note: patch 3/6 will cause a trivial merge conflict in arch/arm64/m= m/fault.c > > > > when applied over mm-unstable branch due to a patch from ARM64 tree= [3] > > > > which is missing in mm-unstable. > > > > > > > > [1] https://lore.kernel.org/all/20230227173632.3292573-1-surenb@goo= gle.com/ > > > > [2] https://lore.kernel.org/all/20230630020436.1066016-1-surenb@goo= gle.com/ > > > > [3] https://lore.kernel.org/all/20230524131305.2808-1-jszhang@kerne= l.org/ > > > > > > > > Suren Baghdasaryan (6): > > > > swap: remove remnants of polling from read_swap_cache_async > > > > mm: add missing VM_FAULT_RESULT_TRACE name for VM_FAULT_COMPLETE= D > > > > mm: drop per-VMA lock when returning VM_FAULT_RETRY or > > > > VM_FAULT_COMPLETED > > > > mm: change folio_lock_or_retry to use vm_fault directly > > > > mm: handle swap page faults under per-VMA lock > > > > mm: handle userfaults under VMA lock > > > > > > On mm/mm-unstable I get running the selftests: > > > > > > Testing sigbus-wp on shmem... [ 383.215804] mm ffff9666078e5280 task= _size 140737488351232 > > > [ 383.215804] get_unmapped_area ffffffffad03b980 > > > [ 383.215804] mmap_base 140378441285632 mmap_legacy_base 47254353883= 136 > > > [ 383.215804] pgd ffff966608960000 mm_users 1 mm_count 6 pgtables_by= tes 126976 map_count 28 > > > [ 383.215804] hiwater_rss 6183 hiwater_vm 8aa7 total_vm 8aa7 locked_= vm 0 > > > [ 383.215804] pinned_vm 0 data_vm 844 exec_vm 1a4 stack_vm 21 > > > [ 383.215804] start_code 402000 end_code 408f09 start_data 40ce10 en= d_data 40d500 > > > [ 383.215804] start_brk 17fe000 brk 1830000 start_stack 7ffecbbe08e0 > > > [ 383.215804] arg_start 7ffecbbe1c6f arg_end 7ffecbbe1c81 env_start = 7ffecbbe1c81 env_end 7ffecbbe1fe6 > > > [ 383.215804] binfmt ffffffffaf3efe40 flags 80000cd > > > [ 383.215804] ioctx_table 0000000000000000 > > > [ 383.215804] owner ffff96660d4a4000 exe_file ffff966285501a00 > > > [ 383.215804] notifier_subscriptions 0000000000000000 > > > [ 383.215804] numa_next_scan 4295050919 numa_scan_offset 0 numa_scan= _seq 0 > > > [ 383.215804] tlb_flush_pending 0 > > > [ 383.215804] def_flags: 0x0() > > > [ 383.236255] ------------[ cut here ]------------ > > > [ 383.237537] kernel BUG at include/linux/mmap_lock.h:66! > > > [ 383.238897] invalid opcode: 0000 [#1] PREEMPT SMP PTI > > > [ 383.240114] CPU: 37 PID: 1482 Comm: uffd-unit-tests Not tainted 6.= 5.0-rc4+ #68 > > > [ 383.242513] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BI= OS 1.16.2-1.fc38 04/01/2014 > > > [ 383.244936] RIP: 0010:find_vma+0x3a/0x40 > > > [ 383.246200] Code: 48 89 34 24 48 85 c0 74 1c 48 83 c7 40 48 c7 c2 = ff ff ff ff 48 89 e6 e8 a4 29 ba 00 > > > [ 383.251084] RSP: 0000:ffffae3745b6beb0 EFLAGS: 00010282 > > > [ 383.252781] RAX: 0000000000000314 RBX: ffff9666078e5280 RCX: 00000= 00000000000 > > > [ 383.255073] RDX: 0000000000000001 RSI: ffffffffae8f69c3 RDI: 00000= 000ffffffff > > > [ 383.257352] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffa= e3745b6bc48 > > > [ 383.259369] R10: 0000000000000003 R11: ffff9669fff46fe8 R12: 00000= 00044401028 > > > [ 383.261570] R13: ffff9666078e5338 R14: ffffae3745b6bf58 R15: 00000= 00000000400 > > > [ 383.263499] FS: 00007fac671c5740(0000) GS:ffff9669efbc0000(0000) = knlGS:0000000000000000 > > > [ 383.265483] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > [ 383.266847] CR2: 0000000044401028 CR3: 0000000488960006 CR4: 00000= 00000770ee0 > > > [ 383.268532] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000= 00000000000 > > > [ 383.270206] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000= 00000000400 > > > [ 383.271905] PKRU: 55555554 > > > [ 383.272593] Call Trace: > > > [ 383.273215] > > > [ 383.273774] ? die+0x32/0x80 > > > [ 383.274510] ? do_trap+0xd6/0x100 > > > [ 383.275326] ? find_vma+0x3a/0x40 > > > [ 383.276152] ? do_error_trap+0x6a/0x90 > > > [ 383.277072] ? find_vma+0x3a/0x40 > > > [ 383.277899] ? exc_invalid_op+0x4c/0x60 > > > [ 383.278846] ? find_vma+0x3a/0x40 > > > [ 383.279675] ? asm_exc_invalid_op+0x16/0x20 > > > [ 383.280698] ? find_vma+0x3a/0x40 > > > [ 383.281527] lock_mm_and_find_vma+0x3f/0x270 > > > [ 383.282570] do_user_addr_fault+0x1e4/0x660 > > > [ 383.283591] exc_page_fault+0x73/0x170 > > > [ 383.284509] asm_exc_page_fault+0x22/0x30 > > > [ 383.285486] RIP: 0033:0x404428 > > > [ 383.286265] Code: 48 89 85 18 ff ff ff e9 dc 00 00 00 48 8b 15 9f = 92 00 00 48 8b 05 80 92 00 00 48 03 > > > [ 383.290566] RSP: 002b:00007ffecbbe05c0 EFLAGS: 00010206 > > > [ 383.291814] RAX: 0000000044401028 RBX: 00007ffecbbe08e8 RCX: 00007= fac66e93c18 > > > [ 383.293502] RDX: 0000000044400000 RSI: 0000000000000001 RDI: 00000= 00000000000 > > > [ 383.295175] RBP: 00007ffecbbe06c0 R08: 00007ffecbbe05c0 R09: 00007= ffecbbe06c0 > > > [ 383.296857] R10: 0000000000000008 R11: 0000000000000246 R12: 00000= 00000000000 > > > [ 383.298533] R13: 00007ffecbbe08f8 R14: 000000000040ce18 R15: 00007= fac67206000 > > > [ 383.300203] > > > [ 383.300775] Modules linked in: rfkill intel_rapl_msr intel_rapl_co= mmon intel_uncore_frequency_commong > > > [ 383.309661] ---[ end trace 0000000000000000 ]--- > > > [ 383.310795] RIP: 0010:find_vma+0x3a/0x40 > > > [ 383.311771] Code: 48 89 34 24 48 85 c0 74 1c 48 83 c7 40 48 c7 c2 = ff ff ff ff 48 89 e6 e8 a4 29 ba 00 > > > [ 383.316081] RSP: 0000:ffffae3745b6beb0 EFLAGS: 00010282 > > > [ 383.317346] RAX: 0000000000000314 RBX: ffff9666078e5280 RCX: 00000= 00000000000 > > > [ 383.319050] RDX: 0000000000000001 RSI: ffffffffae8f69c3 RDI: 00000= 000ffffffff > > > [ 383.320767] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffa= e3745b6bc48 > > > [ 383.322468] R10: 0000000000000003 R11: ffff9669fff46fe8 R12: 00000= 00044401028 > > > [ 383.324164] R13: ffff9666078e5338 R14: ffffae3745b6bf58 R15: 00000= 00000000400 > > > [ 383.325870] FS: 00007fac671c5740(0000) GS:ffff9669efbc0000(0000) = knlGS:0000000000000000 > > > [ 383.327795] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > > > [ 383.329177] CR2: 0000000044401028 CR3: 0000000488960006 CR4: 00000= 00000770ee0 > > > [ 383.330885] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000= 00000000000 > > > [ 383.332592] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000= 00000000400 > > > [ 383.334287] PKRU: 55555554 > > > > > > > > > Which ends up being > > > > > > VM_BUG_ON_MM(!rwsem_is_locked(&mm->mmap_lock), mm); > > > > > > I did not check if this is also the case on mainline, and if this ser= ies is responsible. > > > > Thanks for reporting! I'm checking it now. > > Hmm. From the code it's not obvious how lock_mm_and_find_vma() ends up > calling find_vma() without mmap_lock after successfully completing > get_mmap_lock_carefully(). lock_mm_and_find_vma+0x3f/0x270 points to > the first invocation of find_vma(), so this is not even the lock > upgrade path... I'll try to reproduce this issue and dig up more but > from the information I have so far this issue does not seem to be > related to this series. This is really weird. I added mmap_assert_locked(mm) calls into get_mmap_lock_carefully() right after we acquire mmap_lock read lock and one of them triggers right after successful mmap_read_lock_killable(). Here is my modified version of get_mmap_lock_carefully(): static inline bool get_mmap_lock_carefully(struct mm_struct *mm, struct pt_regs *regs) { /* Even if this succeeds, make it clear we might have slept */ if (likely(mmap_read_trylock(mm))) { might_sleep(); mmap_assert_locked(mm); return true; } if (regs && !user_mode(regs)) { unsigned long ip =3D instruction_pointer(regs); if (!search_exception_tables(ip)) return false; } if (!mmap_read_lock_killable(mm)) { mmap_assert_locked(mm); <---- generates a BUG return true; } return false; } AFAIKT conditions for mmap_read_trylock() and mmap_read_lock_killable() are checked correctly. Am I missing something? > > > > > > > > > -- > > > Cheers, > > > > > > David / dhildenb > > >