8d:c708:c8ce%4]) with mapi id 15.20.9654.014; Thu, 26 Feb 2026 17:43:14 +0000 Date: Thu, 26 Feb 2026 12:43:08 -0500 From: "Liam R. Howlett" To: Suren Baghdasaryan Cc: akpm@linux-foundation.org, willy@infradead.org, david@kernel.org, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, lorenzo.stoakes@oracle.com, baolin.wang@linux.alibaba.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, vbabka@suse.cz, jannh@google.com, rppt@kernel.org, mhocko@suse.com, pfalcato@suse.de, kees@kernel.org, maddy@linux.ibm.com, npiggin@gmail.com, mpe@ellerman.id.au, chleroy@kernel.org, borntraeger@linux.ibm.com, frankja@linux.ibm.com, imbrenda@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com, svens@linux.ibm.com, gerald.schaefer@linux.ibm.com, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, "Ritesh Harjani (IBM)" Subject: Re: [PATCH v3 2/3] mm: replace vma_start_write() with vma_start_write_killable() Message-ID: Mail-Followup-To: "Liam R. Howlett" , Suren Baghdasaryan , akpm@linux-foundation.org, willy@infradead.org, david@kernel.org, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, lorenzo.stoakes@oracle.com, baolin.wang@linux.alibaba.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, vbabka@suse.cz, jannh@google.com, rppt@kernel.org, mhocko@suse.com, pfalcato@suse.de, kees@kernel.org, maddy@linux.ibm.com, npiggin@gmail.com, mpe@ellerman.id.au, chleroy@kernel.org, borntraeger@linux.ibm.com, frankja@linux.ibm.com, imbrenda@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com, svens@linux.ibm.com, gerald.schaefer@linux.ibm.com, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, "Ritesh Harjani (IBM)" References: <20260226070609.3072570-1-surenb@google.com> <20260226070609.3072570-3-surenb@google.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260226070609.3072570-3-surenb@google.com> User-Agent: NeoMutt/20250510 X-ClientProxiedBy: YT4PR01CA0285.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:109::23) To PH0PR10MB5777.namprd10.prod.outlook.com (2603:10b6:510:128::16) Precedence: bulk X-Mailing-List: linux-s390@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: PH0PR10MB5777:EE_|DS0PR10MB7936:EE_ X-MS-Office365-Filtering-Correlation-Id: 5feda253-dec4-4280-43f8-08de755e8440 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|366016|1800799024|7416014|376014|7053199007; X-Microsoft-Antispam-Message-Info: CR5pbkATy7SpACb+prRbph/a4bLziUukxLdtd+T0NsCUR5thUUvPtmAhhK7kZzEANI4G9TaW9NbKGjmIRM7JpoRetJz3jtYJ4p8ukcRKA38R3W3n+zlvSlRhTpNrash20htJ9bPlIXbraxwCWq2TdY3ke2R9PGfXsfh14QC7cy4EheC200XQyl/9ld9HOZ9JVjf/q4HNK6EJy2gpeEddjeXaRzQhQYfE2r0NForu5Kv1ZJtu9ZANdI0LYIOf8kdIkKKXvXyoYfsfqEyf+nfZ6g0Dy0EFdaIpDQ1TOKbFGrP95dTfb7Mr3g+91/C+S2kCZglK8mNTY4qbPvhfOEV2ULQ4EXeED7HEKqfWOXUYSwPK/jKwW3dSaG7LDg8oVRRQAkLMP2lUike4DFuMLeC5b198/0ru0+p0F0x5H5tUr1J5xEx6ozKS4YyPm6zzJK32GOyxtOTXD5fYJyAYRcgeCi1DR/+rV7cmPsgr2WeYPbyU5MmWRHCyOKjxzrMgjzJJtZBztddEXv/VA3a6cowogkDATFNp8HGHh7t2cEcNgcj9NvJXear3uTlexoeaQybLY2oqXILvzAaSLl+uNehTpej/vRuilb7cGbeXKOedhg6+2DV8yplGAe26FbCZFAOLOX2KVX7F3KMmg3BNFD0QppV0+a83QdegXutHWDWJDohlC+i/uDTRkrwUdWPcuhO/4xIgTGsYxWkTkmCiafmgagwwPucc0QH4D8s8Li5A4+Q= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR10MB5777.namprd10.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(366016)(1800799024)(7416014)(376014)(7053199007);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bIIhh6Y5Xjn+n8lG1od371knysP7232voONkThq9BDK0866pJY1aU5Q0oET+?= =?us-ascii?Q?gXuwX8tyCrTKhhsd/uMeGIRwDiQIyLhfKqreHDwTuBIJaJmfYudeARGoaHoG?= =?us-ascii?Q?70iAsHrw2Vmw3eb3p/hSTdhKpdqldh/EjpUEAZpcXkFVgSwYeX4UnGrPjtOI?= =?us-ascii?Q?OSEaL7cmjw/XKIDuY1V+7P42mi06X9cc6jHbdzXi92A6Ly5sDyNlqOO+f35e?= =?us-ascii?Q?Ff6cDaQ22VElxhPs7tHEuC/Rx/esLUC11VnUoRoTxyMVz/HIDm/vZ2yOP1A7?= =?us-ascii?Q?7n1XnT9FvnQAcLN7TQoomY421sweNV/+XsLsj14goTosMR5nFeEXb9Da52QN?= =?us-ascii?Q?yuIlLCmTnckgSq2ZPzVlHhl0xz+hwlgYlamPYebaUAIbYN0dILaKq8Fe9Ad7?= =?us-ascii?Q?XJgFF7rrdkClrpTLJOrHD8U8lJMSJynvuWJ405+fk7RzipjAzIkVAyhQvs+d?= =?us-ascii?Q?tLf+bEddwSa0mZKE2O/64xF6nFC5JdUJCIfEsBr5sYYiK4+pyG0a5JtYUXvX?= =?us-ascii?Q?GV1fMpzxlLroX6uIbK+E6fekuTK+RrfU4YlOBm06XKjzsRxeImn8yeNASMzT?= =?us-ascii?Q?bXW6y7f3NNlDO6hVczkro5O1iiqJ2KU30WAV6Dh0ndVTe74/1QAIb87W3FI3?= =?us-ascii?Q?SeOJhod2BczCLN+Dq6Y+qccRVNED38JYckG53Z0UhzxqQc8UywUoobmLbAeq?= =?us-ascii?Q?zMZusLepAjw8CuZ3qAKyvIJ2W/xGXcYuko9KoslTNOXBGgO2cNj0jB2p7npM?= =?us-ascii?Q?NRHrrQoPCfTJaXZvp41fY+XIdEiZJCuSMtMgy3/nFpzzM+z+HPW8oUxiN96L?= =?us-ascii?Q?GvJsYyZQfW8m3arUIxOUpytp68TALWjtMQLkAo8WBHx4nc5vYDHlXFsmg8eh?= =?us-ascii?Q?dQabL9RfVZB4QnTrNfG8EBUoifh4LM/4CDmEC3unSOp2PzK8q6pqr2ALKSCh?= =?us-ascii?Q?ZnmbZ/SmFgmYDMG5tOu0m75Ur0cIaxTXoBtMwwpuB7pfDKVRXxaqx8pxhbik?= =?us-ascii?Q?BXl1lPgGXZU5e7M18PKBABvLX+tOag9v8ZIbvImU4DoUlcvNO8cxnlNMXBwb?= =?us-ascii?Q?JmtbNsQ5f/af+SsbUKI+ZEZJ551s+LS6ux6oThJI6YbdgtraaMVVOUoVMwBA?= =?us-ascii?Q?87mA1eeTKVFHqctCfe1pavbOv9z+i9TESegtERsXRbrg4irJi7+k3eSqldtF?= =?us-ascii?Q?EMX3Xaunbz2kEBXHH6KDEoC64iN30pLFhIiBPYGUemTVRbxUbUIW2g/llAv/?= =?us-ascii?Q?GnvKQ4p0sjAFNDqie8Ng4ZoSD1rIPEyPsMwaIk7CthRvA1opbBfmhX3Bre+r?= =?us-ascii?Q?eD3aBhNtaf64EGrwzFfXFPC4PsOu1VJYQScghwabzj5gYAsdG61x1Z1ZGuHZ?= =?us-ascii?Q?mFzpquXhFal4JnfUjNNacs6LxRFoWYA7pkayVSgYC/B3HBGJ+nD2g+ToS1jb?= =?us-ascii?Q?+onJ1bVgz0R1iPY2nu0jn6T7s9km76eIwjExKvHFPZcjKqqwit+t95vRygyF?= =?us-ascii?Q?5Aetgu8NGwX8BJnO8u3uAT1WFoq6xxnVl7JgEJ9yUlUkPdquvQZtpEI5Tlrh?= =?us-ascii?Q?XHBu37TaZI8nPwKVExjN9lhxtUEzddRdzAXz5t6mhe2K48rRybNZMBKEOhLP?= =?us-ascii?Q?FND12GeuquEiuNSVp6MkGtQkMuv4kIBH2ql673TnZKIygtnBYYqgbZI2v0Qw?= =?us-ascii?Q?dZcnWkT2C4ytBQ3khHTZzKkAu5GQOO6GvHMbiTLrDn1jHpwXnuaJ3vnbuUje?= =?us-ascii?Q?g3nP2FUKew=3D=3D?= X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: JvxbmQhePx0aD1Zcr6H7VapiQFKC8aS7u4JdA36KeHUikcQCw5gf8HLYY/pypFzGyqaOtBJsL1+zS4CEQwjyduumv+d+I9IXNEVAUq5tsmwEw+DDMDTowog++BKuWJ0USV9sJFByW0E2mTciE0HaqyHlIt5pUg4LG/yBAuA38UHxfMbdG4Hnm/oXmskw/y6eOcKH5IUn2VzWYUcASNkZ4hHVvckPGzObNEt7MxtKZeXR9oZeumwLAuAyoYznqYrFFTIEeejL0uKOIL8qiPjPsNSHUG9BOJL9FGTBCclgYgT7P6I2n2a0HSRQF6Y1wwfoddeh+wPaNZmjkkSjKpS+goxl+p3artFPAVlRHkQNeSQ82GwQgG7pWGnaN3BdkXRoWicmUtkm40QUNNJUPMqMS1Am9AZ89okb10yxVml2bulYGBDbRRREAMCfK5JMTlSJzKfMt8iYPAiPZzkUSA87rwDDqmhpFhio85pmFSPjN8WPj3ok31bcnFegfpBtdYAnAUd61/TGMrc5t/RmC5rm5EoxDt9h7I/o6SPku3E0IZdRQvp8Pbij8KHCZEOTCSpRZV8pxN2nwD8WcDnTVonIiD7J6HUG1IvdVNPYVjQ+RpM= X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5feda253-dec4-4280-43f8-08de755e8440 X-MS-Exchange-CrossTenant-AuthSource: PH0PR10MB5777.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2026 17:43:14.3289 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 0/Z2td3OUCDW2wFEwSbN2sOqT2XoAy0k9k4d8dPCJw1AKnVSgpRlGf/F/+H2lHsk0dCkwdXCG1tYnYW7kcP56w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR10MB7936 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-02-26_02,2026-02-26_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 suspectscore=0 spamscore=0 bulkscore=0 adultscore=0 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2602130000 definitions=main-2602260161 X-Authority-Analysis: v=2.4 cv=BKK+bVQG c=1 sm=1 tr=0 ts=69a0863b b=1 cx=c_pps a=zPCbziy225d3KhSqZt3L1A==:117 a=zPCbziy225d3KhSqZt3L1A==:17 a=6eWqkTHjU83fiwn7nKZWdM+Sl24=:19 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=kj9zAlcOel0A:10 a=HzLeVaNsDn8A:10 a=GoEa3M9JfhUA:10 a=VkNPw1HP01LnGYTKEx00:22 a=Mpw57Om8IfrbqaoTuvik:22 a=GgsMoib0sEa3-_RKJdDe:22 a=1XWaLZrsAAAA:8 a=JfrnYn6hAAAA:8 a=pGLkceISAAAA:8 a=yPCof4ZbAAAA:8 a=p-90_2tMuphpnIqHMSUA:9 a=CjuIK1q_8ugA:10 a=1CNFftbPRP8L7MoqJWF3:22 cc=ntf awl=host:12261 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMjI2MDE2MSBTYWx0ZWRfXz1RoPGnnfDLr i/OMjf5eZ3Bt/46yyHMNhCNTSAYevsTgad2HxD9Gd8IQJO1+WLJ3KYAhgQdx36dsv/yC4IvlLyP OLxZqwTNjxIS2RF/P9dQa8iYOtGBPUqvSYvn5Sv56WooPloC3QdHjEEEci5qCfHciJXsrshEpMy RvaFNjJ2hlZAEjTV0KkWyfyrt/RQCdYhk3LA4SyAZstQBKvGGkFTOF47qb2GXpcwwyz/21k/yue HjWfg2qhNuvyUP72ZvtQbYsPEfXC8HTSdkIU5m6Z+gX+VElDrcjF8/fCwSYS6oglFl8gNF29eM3 AGTjRcLQPoDvy6aoxLho8oLz5187ARPwrJZJmceGlXVQXb3nKL8uH/zjdtt9+c/OYtlRI0O9tC3 enlZXL3x/NajPRFBWjxktVugVmYQxM6L083fZ3s4DIHl7vMvCMeG7ajopzwUe8jeTxUy25oZCIV TDOjuzl8tIr2YOtexlEyIIEIWyCw96lAVgNModkw= X-Proofpoint-ORIG-GUID: MPMCU-7bT0OaDXbrHLS3pAVEb32mp5S9 X-Proofpoint-GUID: MPMCU-7bT0OaDXbrHLS3pAVEb32mp5S9 X-DKIM: signer='oracle.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-DKIM: signer='oracle.onmicrosoft.com' status='pass' reason='' X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://docs.mxroute.com/docs/expert-spam-filtering.html --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: vmg.target] 0.0 URIBL_DBL_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to dbl.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [URIs: vmg.target] 0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [172.234.253.10 listed in zen.spamhaus.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 * Suren Baghdasaryan [260226 02:06]: > Now that we have vma_start_write_killable() we can replace most of the > vma_start_write() calls with it, improving reaction time to the kill > signal. > > There are several places which are left untouched by this patch: > > 1. free_pgtables() because function should free page tables even if a > fatal signal is pending. > > 2. process_vma_walk_lock(), which requires changes in its callers and > will be handled in the next patch. > > 3. userfaultd code, where some paths calling vma_start_write() can > handle EINTR and some can't without a deeper code refactoring. > > 4. mpol_rebind_mm() which is used by cpusset controller for migrations > and operates on a remote mm. Incomplete operations here would result > in an inconsistent cgroup state. > > 5. vm_flags_{set|mod|clear} require refactoring that involves moving > vma_start_write() out of these functions and replacing it with > vma_assert_write_locked(), then callers of these functions should > lock the vma themselves using vma_start_write_killable() whenever > possible. > > Suggested-by: Matthew Wilcox > Signed-off-by: Suren Baghdasaryan > Reviewed-by: Ritesh Harjani (IBM) # powerpc Some nits below, but lgtm. Reviewed-by: Liam R. Howlett > --- > arch/powerpc/kvm/book3s_hv_uvmem.c | 5 +- > mm/khugepaged.c | 5 +- > mm/madvise.c | 4 +- > mm/memory.c | 2 + > mm/mempolicy.c | 8 ++- > mm/mlock.c | 21 +++++-- > mm/mprotect.c | 4 +- > mm/mremap.c | 4 +- > mm/vma.c | 93 +++++++++++++++++++++--------- > mm/vma_exec.c | 6 +- > 10 files changed, 109 insertions(+), 43 deletions(-) > > diff --git a/arch/powerpc/kvm/book3s_hv_uvmem.c b/arch/powerpc/kvm/book3s_hv_uvmem.c > index 5fbb95d90e99..0a28b48a46b8 100644 > --- a/arch/powerpc/kvm/book3s_hv_uvmem.c > +++ b/arch/powerpc/kvm/book3s_hv_uvmem.c > @@ -410,7 +410,10 @@ static int kvmppc_memslot_page_merge(struct kvm *kvm, > ret = H_STATE; > break; > } > - vma_start_write(vma); > + if (vma_start_write_killable(vma)) { > + ret = H_STATE; > + break; > + } > /* Copy vm_flags to avoid partial modifications in ksm_madvise */ > vm_flags = vma->vm_flags; > ret = ksm_madvise(vma, vma->vm_start, vma->vm_end, > diff --git a/mm/khugepaged.c b/mm/khugepaged.c > index 1dd3cfca610d..6c92e31ee5fb 100644 > --- a/mm/khugepaged.c > +++ b/mm/khugepaged.c > @@ -1141,7 +1141,10 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a > if (result != SCAN_SUCCEED) > goto out_up_write; > /* check if the pmd is still valid */ > - vma_start_write(vma); > + if (vma_start_write_killable(vma)) { > + result = SCAN_FAIL; > + goto out_up_write; > + } > result = check_pmd_still_valid(mm, address, pmd); > if (result != SCAN_SUCCEED) > goto out_up_write; > diff --git a/mm/madvise.c b/mm/madvise.c > index c0370d9b4e23..ccdaea6b3b15 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -173,7 +173,9 @@ static int madvise_update_vma(vm_flags_t new_flags, > madv_behavior->vma = vma; > > /* vm_flags is protected by the mmap_lock held in write mode. */ > - vma_start_write(vma); > + if (vma_start_write_killable(vma)) > + return -EINTR; > + > vm_flags_reset(vma, new_flags); > if (set_new_anon_name) > return replace_anon_vma_name(vma, anon_name); > diff --git a/mm/memory.c b/mm/memory.c > index 07778814b4a8..691062154cf5 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -379,6 +379,8 @@ void free_pgd_range(struct mmu_gather *tlb, > * page tables that should be removed. This can differ from the vma mappings on > * some archs that may have mappings that need to be removed outside the vmas. > * Note that the prev->vm_end and next->vm_start are often used. > + * We don't use vma_start_write_killable() because page tables should be freed > + * even if the task is being killed. > * > * The vma_end differs from the pg_end when a dup_mmap() failed and the tree has > * unrelated data to the mm_struct being torn down. > diff --git a/mm/mempolicy.c b/mm/mempolicy.c > index 0e5175f1c767..90939f5bde02 100644 > --- a/mm/mempolicy.c > +++ b/mm/mempolicy.c > @@ -1784,7 +1784,8 @@ SYSCALL_DEFINE4(set_mempolicy_home_node, unsigned long, start, unsigned long, le > return -EINVAL; > if (end == start) > return 0; > - mmap_write_lock(mm); > + if (mmap_write_lock_killable(mm)) > + return -EINTR; > prev = vma_prev(&vmi); > for_each_vma_range(vmi, vma, end) { > /* > @@ -1801,13 +1802,16 @@ SYSCALL_DEFINE4(set_mempolicy_home_node, unsigned long, start, unsigned long, le > err = -EOPNOTSUPP; > break; > } > + if (vma_start_write_killable(vma)) { > + err = -EINTR; > + break; > + } > new = mpol_dup(old); > if (IS_ERR(new)) { > err = PTR_ERR(new); > break; > } > > - vma_start_write(vma); > new->home_node = home_node; > err = mbind_range(&vmi, vma, &prev, start, end, new); > mpol_put(new); > diff --git a/mm/mlock.c b/mm/mlock.c > index 2f699c3497a5..c562c77c3ee0 100644 > --- a/mm/mlock.c > +++ b/mm/mlock.c > @@ -420,7 +420,7 @@ static int mlock_pte_range(pmd_t *pmd, unsigned long addr, > * Called for mlock(), mlock2() and mlockall(), to set @vma VM_LOCKED; > * called for munlock() and munlockall(), to clear VM_LOCKED from @vma. > */ > -static void mlock_vma_pages_range(struct vm_area_struct *vma, > +static int mlock_vma_pages_range(struct vm_area_struct *vma, > unsigned long start, unsigned long end, vm_flags_t newflags) > { > static const struct mm_walk_ops mlock_walk_ops = { > @@ -441,7 +441,9 @@ static void mlock_vma_pages_range(struct vm_area_struct *vma, > */ > if (newflags & VM_LOCKED) > newflags |= VM_IO; > - vma_start_write(vma); > + if (vma_start_write_killable(vma)) > + return -EINTR; > + > vm_flags_reset_once(vma, newflags); > > lru_add_drain(); > @@ -452,6 +454,7 @@ static void mlock_vma_pages_range(struct vm_area_struct *vma, > newflags &= ~VM_IO; > vm_flags_reset_once(vma, newflags); > } > + return 0; > } > > /* > @@ -501,10 +504,12 @@ static int mlock_fixup(struct vma_iterator *vmi, struct vm_area_struct *vma, > */ > if ((newflags & VM_LOCKED) && (oldflags & VM_LOCKED)) { > /* No work to do, and mlocking twice would be wrong */ > - vma_start_write(vma); > + ret = vma_start_write_killable(vma); > + if (ret) > + goto out; > vm_flags_reset(vma, newflags); > } else { > - mlock_vma_pages_range(vma, start, end, newflags); > + ret = mlock_vma_pages_range(vma, start, end, newflags); > } > out: > *prev = vma; > @@ -733,9 +738,13 @@ static int apply_mlockall_flags(int flags) > > error = mlock_fixup(&vmi, vma, &prev, vma->vm_start, vma->vm_end, > newflags); > - /* Ignore errors, but prev needs fixing up. */ > - if (error) > + /* Ignore errors except EINTR, but prev needs fixing up. */ > + if (error) { > + if (error == -EINTR) > + return error; > + > prev = vma; > + } > cond_resched(); > } > out: > diff --git a/mm/mprotect.c b/mm/mprotect.c > index c0571445bef7..49dbb7156936 100644 > --- a/mm/mprotect.c > +++ b/mm/mprotect.c > @@ -765,7 +765,9 @@ mprotect_fixup(struct vma_iterator *vmi, struct mmu_gather *tlb, > * vm_flags and vm_page_prot are protected by the mmap_lock > * held in write mode. > */ > - vma_start_write(vma); > + error = vma_start_write_killable(vma); > + if (error < 0) > + goto fail; > vm_flags_reset_once(vma, newflags); > if (vma_wants_manual_pte_write_upgrade(vma)) > mm_cp_flags |= MM_CP_TRY_CHANGE_WRITABLE; > diff --git a/mm/mremap.c b/mm/mremap.c > index 2be876a70cc0..aef1e5f373c7 100644 > --- a/mm/mremap.c > +++ b/mm/mremap.c > @@ -1286,7 +1286,9 @@ static unsigned long move_vma(struct vma_remap_struct *vrm) > return -ENOMEM; > > /* We don't want racing faults. */ > - vma_start_write(vrm->vma); > + err = vma_start_write_killable(vrm->vma); > + if (err) > + return err; > > /* Perform copy step. */ > err = copy_vma_and_data(vrm, &new_vma); > diff --git a/mm/vma.c b/mm/vma.c > index bb4d0326fecb..9f2664f1d078 100644 > --- a/mm/vma.c > +++ b/mm/vma.c > @@ -530,6 +530,13 @@ __split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma, > if (err) > goto out_free_vmi; > > + err = vma_start_write_killable(vma); > + if (err) > + goto out_free_mpol; > + err = vma_start_write_killable(new); > + if (err) > + goto out_free_mpol; > + > err = anon_vma_clone(new, vma, VMA_OP_SPLIT); > if (err) > goto out_free_mpol; > @@ -540,9 +547,6 @@ __split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma, > if (new->vm_ops && new->vm_ops->open) > new->vm_ops->open(new); > > - vma_start_write(vma); > - vma_start_write(new); > - > init_vma_prep(&vp, vma); > vp.insert = new; > vma_prepare(&vp); > @@ -895,16 +899,22 @@ static __must_check struct vm_area_struct *vma_merge_existing_range( > } > > /* No matter what happens, we will be adjusting middle. */ > - vma_start_write(middle); > + err = vma_start_write_killable(middle); > + if (err) > + goto abort; > > if (merge_right) { > - vma_start_write(next); > + err = vma_start_write_killable(next); > + if (err) > + goto abort; > vmg->target = next; > sticky_flags |= (next->vm_flags & VM_STICKY); > } > > if (merge_left) { > - vma_start_write(prev); > + err = vma_start_write_killable(prev); > + if (err) > + goto abort; > vmg->target = prev; > sticky_flags |= (prev->vm_flags & VM_STICKY); > } > @@ -1155,10 +1165,12 @@ int vma_expand(struct vma_merge_struct *vmg) > struct vm_area_struct *next = vmg->next; > bool remove_next = false; > vm_flags_t sticky_flags; > - int ret = 0; > + int ret; > > mmap_assert_write_locked(vmg->mm); > - vma_start_write(target); > + ret = vma_start_write_killable(target); > + if (ret) > + return ret; > > if (next && target != next && vmg->end == next->vm_end) > remove_next = true; > @@ -1187,6 +1199,9 @@ int vma_expand(struct vma_merge_struct *vmg) > * we don't need to account for vmg->give_up_on_mm here. > */ > if (remove_next) { > + ret = vma_start_write_killable(next); > + if (ret) > + return ret; > ret = dup_anon_vma(target, next, &anon_dup); > if (ret) > return ret; > @@ -1197,10 +1212,8 @@ int vma_expand(struct vma_merge_struct *vmg) > return ret; > } > > - if (remove_next) { > - vma_start_write(next); > + if (remove_next) > vmg->__remove_next = true; > - } > if (commit_merge(vmg)) > goto nomem; > > @@ -1233,6 +1246,7 @@ int vma_shrink(struct vma_iterator *vmi, struct vm_area_struct *vma, > unsigned long start, unsigned long end, pgoff_t pgoff) > { > struct vma_prepare vp; > + int err; > > WARN_ON((vma->vm_start != start) && (vma->vm_end != end)); > > @@ -1244,7 +1258,11 @@ int vma_shrink(struct vma_iterator *vmi, struct vm_area_struct *vma, > if (vma_iter_prealloc(vmi, NULL)) > return -ENOMEM; > > - vma_start_write(vma); > + err = vma_start_write_killable(vma); > + if (err) { > + vma_iter_free(vmi); > + return err; > + } Could avoid allocating here by reordering the lock, but this is fine. > > init_vma_prep(&vp, vma); > vma_prepare(&vp); > @@ -1434,7 +1452,9 @@ static int vms_gather_munmap_vmas(struct vma_munmap_struct *vms, > if (error) > goto end_split_failed; > } > - vma_start_write(next); > + error = vma_start_write_killable(next); > + if (error) > + goto munmap_gather_failed; > mas_set(mas_detach, vms->vma_count++); > error = mas_store_gfp(mas_detach, next, GFP_KERNEL); > if (error) > @@ -1828,12 +1848,17 @@ static void vma_link_file(struct vm_area_struct *vma, bool hold_rmap_lock) > static int vma_link(struct mm_struct *mm, struct vm_area_struct *vma) > { > VMA_ITERATOR(vmi, mm, 0); > + int err; > > vma_iter_config(&vmi, vma->vm_start, vma->vm_end); > if (vma_iter_prealloc(&vmi, vma)) > return -ENOMEM; > > - vma_start_write(vma); > + err = vma_start_write_killable(vma); > + if (err) { > + vma_iter_free(&vmi); > + return err; > + } Ditto here, ordering would mean no freeing. > vma_iter_store_new(&vmi, vma); > vma_link_file(vma, /* hold_rmap_lock= */false); > mm->map_count++; > @@ -2215,9 +2240,8 @@ int mm_take_all_locks(struct mm_struct *mm) > * is reached. > */ > for_each_vma(vmi, vma) { > - if (signal_pending(current)) > + if (signal_pending(current) || vma_start_write_killable(vma)) > goto out_unlock; > - vma_start_write(vma); > } > > vma_iter_init(&vmi, mm, 0); > @@ -2522,6 +2546,11 @@ static int __mmap_new_vma(struct mmap_state *map, struct vm_area_struct **vmap) > if (!vma) > return -ENOMEM; > > + /* Lock the VMA since it is modified after insertion into VMA tree */ > + error = vma_start_write_killable(vma); > + if (error) > + goto free_vma; > + There's no way this is going to fail, right? > vma_iter_config(vmi, map->addr, map->end); > vma_set_range(vma, map->addr, map->end, map->pgoff); > vm_flags_init(vma, map->vm_flags); > @@ -2552,8 +2581,6 @@ static int __mmap_new_vma(struct mmap_state *map, struct vm_area_struct **vmap) > WARN_ON_ONCE(!arch_validate_flags(map->vm_flags)); > #endif > > - /* Lock the VMA since it is modified after insertion into VMA tree */ > - vma_start_write(vma); > vma_iter_store_new(vmi, vma); > map->mm->map_count++; > vma_link_file(vma, map->hold_file_rmap_lock); > @@ -2864,6 +2891,7 @@ int do_brk_flags(struct vma_iterator *vmi, struct vm_area_struct *vma, > unsigned long addr, unsigned long len, vm_flags_t vm_flags) > { > struct mm_struct *mm = current->mm; > + int err = -ENOMEM; > > /* > * Check against address space limits by the changed size > @@ -2908,7 +2936,10 @@ int do_brk_flags(struct vma_iterator *vmi, struct vm_area_struct *vma, > vma_set_range(vma, addr, addr + len, addr >> PAGE_SHIFT); > vm_flags_init(vma, vm_flags); > vma->vm_page_prot = vm_get_page_prot(vm_flags); > - vma_start_write(vma); > + if (vma_start_write_killable(vma)) { > + err = -EINTR; > + goto mas_store_fail; > + } I'd rather have another label saying write lock failed. Really, this will never fail though (besides syzbot..) > if (vma_iter_store_gfp(vmi, vma, GFP_KERNEL)) > goto mas_store_fail; > > @@ -2928,7 +2959,7 @@ int do_brk_flags(struct vma_iterator *vmi, struct vm_area_struct *vma, > vm_area_free(vma); > unacct_fail: > vm_unacct_memory(len >> PAGE_SHIFT); > - return -ENOMEM; > + return err; > } > > /** > @@ -3089,7 +3120,7 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address) > struct mm_struct *mm = vma->vm_mm; > struct vm_area_struct *next; > unsigned long gap_addr; > - int error = 0; > + int error; > VMA_ITERATOR(vmi, mm, vma->vm_start); > > if (!(vma->vm_flags & VM_GROWSUP)) > @@ -3126,12 +3157,14 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address) > > /* We must make sure the anon_vma is allocated. */ > if (unlikely(anon_vma_prepare(vma))) { > - vma_iter_free(&vmi); > - return -ENOMEM; > + error = -ENOMEM; > + goto free; > } > > /* Lock the VMA before expanding to prevent concurrent page faults */ > - vma_start_write(vma); > + error = vma_start_write_killable(vma); > + if (error) > + goto free; > /* We update the anon VMA tree. */ > anon_vma_lock_write(vma->anon_vma); > > @@ -3160,6 +3193,7 @@ int expand_upwards(struct vm_area_struct *vma, unsigned long address) > } > } > anon_vma_unlock_write(vma->anon_vma); > +free: > vma_iter_free(&vmi); > validate_mm(mm); > return error; > @@ -3174,7 +3208,7 @@ int expand_downwards(struct vm_area_struct *vma, unsigned long address) > { > struct mm_struct *mm = vma->vm_mm; > struct vm_area_struct *prev; > - int error = 0; > + int error; > VMA_ITERATOR(vmi, mm, vma->vm_start); > > if (!(vma->vm_flags & VM_GROWSDOWN)) > @@ -3205,12 +3239,14 @@ int expand_downwards(struct vm_area_struct *vma, unsigned long address) > > /* We must make sure the anon_vma is allocated. */ > if (unlikely(anon_vma_prepare(vma))) { > - vma_iter_free(&vmi); > - return -ENOMEM; > + error = -ENOMEM; > + goto free; > } > > /* Lock the VMA before expanding to prevent concurrent page faults */ > - vma_start_write(vma); > + error = vma_start_write_killable(vma); > + if (error) > + goto free; > /* We update the anon VMA tree. */ > anon_vma_lock_write(vma->anon_vma); > > @@ -3240,6 +3276,7 @@ int expand_downwards(struct vm_area_struct *vma, unsigned long address) > } > } > anon_vma_unlock_write(vma->anon_vma); > +free: > vma_iter_free(&vmi); > validate_mm(mm); > return error; > diff --git a/mm/vma_exec.c b/mm/vma_exec.c > index 8134e1afca68..a4addc2a8480 100644 > --- a/mm/vma_exec.c > +++ b/mm/vma_exec.c > @@ -40,6 +40,7 @@ int relocate_vma_down(struct vm_area_struct *vma, unsigned long shift) > struct vm_area_struct *next; > struct mmu_gather tlb; > PAGETABLE_MOVE(pmc, vma, vma, old_start, new_start, length); > + int err; > > BUG_ON(new_start > new_end); > > @@ -55,8 +56,9 @@ int relocate_vma_down(struct vm_area_struct *vma, unsigned long shift) > * cover the whole range: [new_start, old_end) > */ > vmg.target = vma; > - if (vma_expand(&vmg)) > - return -ENOMEM; > + err = vma_expand(&vmg); > + if (err) > + return err; > > /* > * move the page tables downwards, on failure we rely on > -- > 2.53.0.414.gf7e9f6c205-goog > > From - Thu Feb 26 18:34:58 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id iPsUErCRoGl1qxEAYBR5ng (envelope-from ) for ; Thu, 26 Feb 2026 18:32:16 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Thu, 26 Feb 2026 18:32:16 +0000 Received: from sea.lore.kernel.org ([172.234.253.10]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vvg9n-000000056DW-2muF for hi@josie.lol; Thu, 26 Feb 2026 18:32:16 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sea.lore.kernel.org (Postfix) with ESMTP id 458AC3358A1D for ; Thu, 26 Feb 2026 17:23:39 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 61EC13290A0; Thu, 26 Feb 2026 17:23:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="fNjhrGYm" X-Original-To: linux-s390@vger.kernel.org Received: from mail-qt1-f173.google.com (mail-qt1-f173.google.com [209.85.160.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 232873290DA for ; Thu, 26 Feb 2026 17:23:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.160.173 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772126615; cv=pass; b=kUzivVNDs1512dvCa6gghuPCxXvtyEtOfLnNVjExadq5a5MAm/lYM4qoC1u3aOuu6bKW8K9mDx3mfhLGkKEv5ejunl1yMniZv+z4Z+4oqrt18DrQLuTYVzJI6cM9LJrfqBSctUNB1cqJIxhfEDuVaVtBARVZMNiPXlejst6eEZk= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772126615; c=relaxed/simple; bh=zN1A0NVoCrNndk1h7brwP4PDvP8PmvZiG+Q9N3TyOjI=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Content-Type; b=oRt9TPMYcPtiKqP00eGRQMzPOFn2ELnSjHIjul3V1wZVeG157f3WlNw6e94p073+HCLO+iu2akCk7UfZdd84USf/2NJ4jVrl3Anjsqg3iCJGpNoQcORjQkWPKIp5HCpa+stV5DK4HsC8MmFLfOo0+b1eA9ZcOsghqdejaKmpF6A= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=fNjhrGYm; arc=pass smtp.client-ip=209.85.160.173 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Received: by mail-qt1-f173.google.com with SMTP id d75a77b69052e-5033b64256dso734371cf.0 for ; Thu, 26 Feb 2026 09:23:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772126613; cv=none; d=google.com; s=arc-20240605; b=GipjFyKsZE6Tu5fdoTY3e4t64lA3llZMSAoZYEOt4eYO1EjeSox6hoqseiB9acfmTc ckTH4zfFnEqh+XSrA34xsha45fWHm0PaI9Y54PePoOtWVooptsDNBhul71ZsDvxh5xkq bO5OQbwj67qHHnSCWJZJGSRgALDIjcW86jZ6DbWrLZxQXs0IwcuWYf5Xuxvg98nS4/z1 4SXgnMUB36yM0WxEJGAysXTATpqNYbNJutmC8cRVCn2BspNo992mmVUVk5kHKpdXYKkP 9asTTUyGg6NtSmoH/KixjoRqTfNSFbAIrf8taMqDliebGgyLcKTsiar/uYb9AHG2HjTD Qteg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=FynKKhlWalFQKKrs3ZP5yNMAhsIr6fWHYQm9TKDGe4A=; fh=PxZXT93Fh3QAf6oPXly2/vdn//6qynIiMOjh04von9E=; b=V808gKvj8kScaCUPsn5F/QTiF4GOjQ4L0PbRuDu8hdElsSVsqhKjM8kIgrCgp3pJ1Q NlzmGHXoRfakaUZwCPdh37VDNydiGuPM0Q4KepoPjHx2c9J9mZyZL29nmKccq8y7vy1w KS/2PAh4PsyE39wA8fivg9skKePV4YID54Y0Jt2/Sofw1fWo/xybZ1U313sRgOe3cQyX 0PaTRls45T6gFXDjBb6eQz6qv9SM6Ob2Kyu6/558FocoqNJdxcuYf1p8C5cyvAmVGy01 uHHmEf4UE3aDFKPa8jg7kGFiSzPO0GmC8BklsLtpklhYq8/7Stz4mFbyO0jS5tJpfTCU mrrA==; darn=vger.kernel.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772126613; x=1772731413; darn=vger.kernel.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FynKKhlWalFQKKrs3ZP5yNMAhsIr6fWHYQm9TKDGe4A=; b=fNjhrGYmxWL/YvzTLQjN5I8tbQIsTwhB5AZcbt+xKgVJv7BpVOMppvdGMgoTSVX7Za Sv/8EL6RNO0WbR8pK9cfM8rRHzbM0poFvzkJ0Q78MWj3x/qRR652mwVmVoL4KAxrc1Z3 iSMsurK8ZnETiVfLLcYbgMYtvitEoGN0GZzq6m1PRH0VOm0RwcTq67hhdgRsn1wE6ecF YXY+oijCE6Pp429gC8WJA5oppjEYYyDpEexm0b9zlNA2aytoiGR/ptaHTEMo8zfRbNfh KD+FV9EhJLV+ZaK4PUFFmZLyXEHzQpX1VdJ6JZid0uQjg0KWWp9QhqzY+qINiDENV3o7 RjYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772126613; x=1772731413; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=FynKKhlWalFQKKrs3ZP5yNMAhsIr6fWHYQm9TKDGe4A=; b=emLRVgot5no7MVSCzCQLcwDOHhn/09VKox9kGZ56UrdezZ0vq+TJdrm7L1yKVy+nI/ /exsCH8i5NElEpnFW2cRR2ULuzU/2FU0WRRPIvuz6X+pZKV9KKzyeWrCi9HoXMl05LIO cJ7jPlqeZ/xwyC4m66ZdKk9Ha5vYw9SH6Cni+F2wEhlrtFhL5g1j/dk1HNPU6m73hhbU 1Q4qu+j2+zkDl4Xdu0wp+wbVHZzlNcu+thJNplA77rwNjYFav7vbke14rPVfmhc6xiyA hPfyJkzEyWcOUUmBviMfareHrSmTsDaLc83R+UKkFRpueB7SOapumL/dmO7zTMwchSvB RDCw== X-Forwarded-Encrypted: i=1; AJvYcCWluuFT/2WiD2+3XRdv0K83C9LBkJS8SX1CFJh9xmhgUbE7PdWML8LaHKl1qsikPdZFb7P9mv/Y/Mkw@vger.kernel.org X-Gm-Message-State: AOJu0YzsZTmxVtAiuIEGn/KQ86PXh4pWd4K53+kt2dNBeZ38FPKK8JbF A3BeF2rRzS/z6sCeQOKcxF89n3mtSu2nSeGaVByhN2T4A/O5ARmhovZ54uFr4FD62pf+W8jL2fo lH5s0XLg7JZ/AKj12qQ+nfURWyU+JdbNPITZMtBnj X-Gm-Gg: ATEYQzwDdLSAez0hyH4753NYlnbi1Jwet5UzT6KyD0/uHovvjvujdFjIBQihHzZny9w G9lzFYeGdlv/DWv2XnYI40sMupBhZtAGadFUKpIXkl56Y4jvEH8HOoMsPwyOtS91oYOcYTnr7Zc Ffig/C5ET85sNmypsZZnmk7qU8Aq3GAeYPQdbwqUZexQ3dpoVwOUJtzEAtEoLDGabztYIvsd03H ii0Ni41FTbVCvPrKalrnMWohBm5YPP5HHYgrvGIyE6DZXTqIIMAsEOeNZ6fowWA74pscY3ZqgWQ hm6c9S7KUIst52Zu1nGsTqtyMogoGZ2QGtwx7GnLBC1l4w78 X-Received: by 2002:ac8:7fca:0:b0:4f1:a61a:1e8 with SMTP id d75a77b69052e-507441ca8aamr14889431cf.10.1772126612071; Thu, 26 Feb 2026 09:23:32 -0800 (PST) Precedence: bulk X-Mailing-List: linux-s390@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20260226070609.3072570-1-surenb@google.com> <20260226070609.3072570-2-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 26 Feb 2026 09:23:19 -0800 X-Gm-Features: AaiRm51NlioHOecXqmKgqusOoAstD_F3nrG3Ao8qrpHVfKsEfdkgNePW1BjyYWA Message-ID: Subject: Re: [PATCH v3 1/3] mm/vma: cleanup error handling path in vma_expand() To: "Liam R. Howlett" , Suren Baghdasaryan , akpm@linux-foundation.org, willy@infradead.org, david@kernel.org, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, lorenzo.stoakes@oracle.com, baolin.wang@linux.alibaba.com, npache@redhat.com, ryan.roberts@arm.com, dev.jain@arm.com, baohua@kernel.org, lance.yang@linux.dev, vbabka@suse.cz, jannh@google.com, rppt@kernel.org, mhocko@suse.com, pfalcato@suse.de, kees@kernel.org, maddy@linux.ibm.com, npiggin@gmail.com, mpe@ellerman.id.au, chleroy@kernel.org, borntraeger@linux.ibm.com, frankja@linux.ibm.com, imbrenda@linux.ibm.com, hca@linux.ibm.com, gor@linux.ibm.com, agordeev@linux.ibm.com, svens@linux.ibm.com, gerald.schaefer@linux.ibm.com, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-DKIM: signer='google.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-Spam-Score: -7.1 (-------) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://docs.mxroute.com/docs/expert-spam-filtering.html --- Content analysis details: (-7.1 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [172.234.253.10 listed in zen.spamhaus.org] 0.0 RCVD_IN_DNSWL_BLOCKED RBL: ADMINISTRATOR NOTICE: The query to DNSWL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block for more information. [172.234.253.10 listed in list.dnswl.org] -7.5 USER_IN_DEF_DKIM_WL From: address is in the default DKIM welcome-list 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager -0.0 DKIMWL_WL_MED DKIMwl.org - Medium trust sender SpamTally: Final spam score: -70 On Thu, Feb 26, 2026 at 8:43=E2=80=AFAM Liam R. Howlett wrote: > > * Suren Baghdasaryan [260226 02:06]: > > vma_expand() error handling is a bit confusing with "if (ret) return re= t;" > > mixed with "if (!ret && ...) ret =3D ...;". Simplify the code to check > > for errors and return immediately after an operation that might fail. > > This also makes later changes to this function more readable. > > > > No functional change intended. > > > > Suggested-by: Jann Horn > > Signed-off-by: Suren Baghdasaryan > > This looks the same as v2, so I'll try again ;) Sorry, missed adding it. So again, thank you very much! > > Reviewed-by: Liam R. Howlett > > > --- > > mm/vma.c | 12 ++++++++---- > > 1 file changed, 8 insertions(+), 4 deletions(-) > > > > diff --git a/mm/vma.c b/mm/vma.c > > index be64f781a3aa..bb4d0326fecb 100644 > > --- a/mm/vma.c > > +++ b/mm/vma.c > > @@ -1186,12 +1186,16 @@ int vma_expand(struct vma_merge_struct *vmg) > > * Note that, by convention, callers ignore OOM for this case, so > > * we don't need to account for vmg->give_up_on_mm here. > > */ > > - if (remove_next) > > + if (remove_next) { > > ret =3D dup_anon_vma(target, next, &anon_dup); > > - if (!ret && vmg->copied_from) > > + if (ret) > > + return ret; > > + } > > + if (vmg->copied_from) { > > ret =3D dup_anon_vma(target, vmg->copied_from, &anon_dup)= ; > > - if (ret) > > - return ret; > > + if (ret) > > + return ret; > > + } > > > > if (remove_next) { > > vma_start_write(next); > > -- > > 2.53.0.414.gf7e9f6c205-goog > > > > > From - Thu Feb 26 18:34:58 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id kIcABuKRoGmQ/REAYBR5ng (envelope-from ) for ; Thu, 26 Feb 2026 18:33:06 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Thu, 26 Feb 2026 18:33:06 +0000 Received: from sto.lore.kernel.org ([172.232.135.74]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vvgAb-000000057mo-04bM for hi@josie.lol; Thu, 26 Feb 2026 18:33:06 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sto.lore.kernel.org (Postfix) with ESMTP id 01E3030BBC66 for ; Thu, 26 Feb 2026 18:22:11 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CDD973290D4; Thu, 26 Feb 2026 18:21:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bsbernd.com header.i=@bsbernd.com header.b="roZ+vNt6"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="sRVsOAT9" X-Original-To: io-uring@vger.kernel.org Received: from flow-a5-smtp.messagingengine.com (flow-a5-smtp.messagingengine.com [103.168.172.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9CA63859FB; Thu, 26 Feb 2026 18:21:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=103.168.172.140 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772130077; cv=none; b=sVRra5aOttwZxkyyL1iY/aiElMzPWmZDTwNxpFC/8mtW5TI4l8BamUEBZsBZxvjBdpAYU2krHZq0a29qwkmTDSsLKqgJmH8X4ImnHsihFwa4isVYf9OR3MLLaJkWbE6NQMSUbTiLP+qoUty5uF9wapyZlEh4VosC/RmnWQRnACQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772130077; c=relaxed/simple; bh=0760ZwAb8gP27bNWhrqS7T+pszXz5ydGwfCzeHtsqX0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=E3RGg15i9bnmU6xNb8irjCUNconRGAjZ71q7QhlX2sBQj6lWKxdkFN0QqZn6iJWt+y+WV05l8SV5h/ZoIyIdDE5Jq7jmx/H/LqI5BxLPpebT9PUZ/Am6GAY4aOpft24esoms07vvlMUQ1QxGMCNqdrK/9g0KdlYlFl9B54yLV1E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=bsbernd.com; spf=pass smtp.mailfrom=bsbernd.com; dkim=pass (2048-bit key) header.d=bsbernd.com header.i=@bsbernd.com header.b=roZ+vNt6; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=sRVsOAT9; arc=none smtp.client-ip=103.168.172.140 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=bsbernd.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bsbernd.com Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailflow.phl.internal (Postfix) with ESMTP id ABB381380157; Thu, 26 Feb 2026 13:21:14 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Thu, 26 Feb 2026 13:21:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsbernd.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1772130074; x=1772137274; bh=zkqCOdOrNzRqBUjjik6XUnLzVjkT1f4fb6bQWYuvWeM=; b= roZ+vNt6O0pKpy3C0TJ5JVOTwJg9bw9OA7E0NPkbFoe1x9cpqRw5U0g1lAY7Xc7u ppD4jAIvztq+MxSRgqJeHbNxSROVHr+WNR8IV+cGvgkjyErVLUgB9oqNE1ON9Abo 3PMBcSM5zCfvIlkk03yLt0LBLBgAsv1qEiM2Dj2qTo9w9zn0oujgGc3Ip8Oi9fbU YhdW6GrwEEWC/SURlBQebhjydLgOdW0IWy1rya7VLsCA0hbwkDG7P6FZ1j+/4L+k uw6xD6B/n0BEJse9vEjpadXpPvTpheZRI7pOJXTHlyGP31ycOqXwrS1WtMRBQBNP vrkMg7AKIlleK9B66xD2cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1772130074; x= 1772137274; bh=zkqCOdOrNzRqBUjjik6XUnLzVjkT1f4fb6bQWYuvWeM=; b=s RVsOAT9S1glR6g5J9MnE8SKJqEUGIG3cwcc3jeZSxB2OfkjJzCDDYhCW9P6R9D0m /8w0QMBYhfb0yXWZwRHWFyLJ7sj5nZrBxf4ZnBmfDgxGtHJsEStP1MlewlfQivqv HSCuSVWmDiHTNAii4Tz5dnG4rwODwhIZ7XGaozobeEzxntaqpW0SEDa4XXtzBAjY TyfV3OWO5IP9B5C6mSP+lIrjIPFUgBW7bZQWBEU7yJewfP9OphneZtlSngIHR0mb 1r5csWJoI6qqrjq6nsr6ZJdHLgRQVhY3u35PbGuJXqm3a7XSDxhUmbEMk2LNr1tr 0ugkdp8qOTdyzBtrOwInQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvgeeijeehucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeeuvghrnhgu ucfutghhuhgsvghrthcuoegsvghrnhgusegsshgsvghrnhgurdgtohhmqeenucggtffrrg htthgvrhhnpeefgeegfeffkeduudelfeehleelhefgffehudejvdfgteevvddtfeeiheef lefgvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe gsvghrnhgusegsshgsvghrnhgurdgtohhmpdhnsggprhgtphhtthhopedutddpmhhouggv pehsmhhtphhouhhtpdhrtghpthhtohepjhhorghnnhgvlhhkohhonhhgsehgmhgrihhlrd gtohhmpdhrtghpthhtoheprgigsghovgeskhgvrhhnvghlrdgukhdprhgtphhtthhopehm ihhklhhoshesshiivghrvgguihdrhhhupdhrtghpthhtoheptghsrghnuggvrhesphhurh gvshhtohhrrghgvgdrtghomhdprhgtphhtthhopehkrhhishhmrghnsehsuhhsvgdruggv pdhrtghpthhtohepihhoqdhurhhinhhgsehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtg hpthhtoheprghsmhhlrdhsihhlvghntggvsehgmhgrihhlrdgtohhmpdhrtghpthhtohep gihirghosghinhhgrdhlihesshgrmhhsuhhnghdrtghomhdprhgtphhtthhopehsrghfih hnrghskhgrrhesghhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: i5c2e48a5:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 26 Feb 2026 13:21:10 -0500 (EST) Message-ID: Date: Thu, 26 Feb 2026 19:21:07 +0100 Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 19/25] fuse: add io-uring kernel-managed buffer ring To: Joanne Koong Cc: axboe@kernel.dk, miklos@szeredi.hu, csander@purestorage.com, krisman@suse.de, io-uring@vger.kernel.org, asml.silence@gmail.com, xiaobing.li@samsung.com, safinaskar@gmail.com, linux-fsdevel@vger.kernel.org References: <20260116233044.1532965-1-joannelkoong@gmail.com> <20260116233044.1532965-20-joannelkoong@gmail.com> <2f14fb1a-0ee2-4d86-98be-ed6112ed706d@bsbernd.com> <7ccf7574-42d4-4094-9b84-eb223e73188e@bsbernd.com> From: Bernd Schubert Content-Language: en-US, de-DE, fr In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-DKIM: signer='bsbernd.com' status='pass' reason='' DKIMCheck: Server passes DKIM test, 0 Spam score X-DKIM: signer='messagingengine.com' status='pass' reason='' X-Spam-Score: 0.4 (/) X-Spam-Report: Spam detection software, running on the system "witcher.mxrouting.net", has performed the tests listed below against this email. Information: https://docs.mxroute.com/docs/expert-spam-filtering.html --- Content analysis details: (0.4 points) --- pts rule name description ---- ---------------------- ----------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: messagingengine.com] 0.0 URIBL_DBL_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to dbl.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [URIs: messagingengine.com] 0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [172.232.135.74 listed in zen.spamhaus.org] 1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to zen.spamhaus.org was blocked due to usage of an open resolver. See https://www.spamhaus.org/returnc/pub/ [URIs: messagingengine.com] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager SpamTally: Final spam score: 4 On 2/26/26 00:42, Joanne Koong wrote: > On Wed, Feb 25, 2026 at 9:55 AM Bernd Schubert wrote: >> On 1/28/26 22:44, Bernd Schubert wrote: >>> On 1/17/26 00:30, Joanne Koong wrote: >>>> diff --git a/fs/fuse/dev_uring.c b/fs/fuse/dev_uring.c >>>> @@ -940,6 +1188,7 @@ static int fuse_uring_commit_fetch(struct io_uring_cmd *cmd, int issue_flags, >>>> unsigned int qid = READ_ONCE(cmd_req->qid); >>>> struct fuse_pqueue *fpq; >>>> struct fuse_req *req; >>>> + bool send; >>>> >>>> err = -ENOTCONN; >>>> if (!ring) >>>> @@ -990,7 +1239,12 @@ static int fuse_uring_commit_fetch(struct io_uring_cmd *cmd, int issue_flags, >>>> >>>> /* without the queue lock, as other locks are taken */ >>>> fuse_uring_prepare_cancel(cmd, issue_flags, ent); >>>> - fuse_uring_commit(ent, req, issue_flags); >>>> + >>>> + err = fuse_uring_headers_prep(ent, ITER_SOURCE, issue_flags); >>>> + if (err) >>>> + fuse_uring_req_end(ent, req, err); >>>> + else >>>> + fuse_uring_commit(ent, req, issue_flags); >>>> >>>> /* >>>> * Fetching the next request is absolutely required as queued >>>> @@ -998,7 +1252,9 @@ static int fuse_uring_commit_fetch(struct io_uring_cmd *cmd, int issue_flags, >>>> * and fetching is done in one step vs legacy fuse, which has separated >>>> * read (fetch request) and write (commit result). >>>> */ >>>> - if (fuse_uring_get_next_fuse_req(ent, queue)) >>>> + send = fuse_uring_get_next_fuse_req(ent, queue, issue_flags); >>>> + fuse_uring_headers_cleanup(ent, issue_flags); >>>> + if (send) >>>> fuse_uring_send(ent, cmd, 0, issue_flags); >>>> return 0; >> >> >> Hello Joanne, >> >> couldn't it call fuse_uring_headers_cleanup() before the >> fuse_uring_get_next_fuse_req()? I find it a bit confusing that it firsts >> gets the next request and then cleans up the buffer from the previous >> request. > > Hi Bernd, > > Thanks for taking a look. > > The fuse_uring_headers_cleanup() call has to happen after the > fuse_uring_get_next_fuse_req() call because > fuse_uring_get_next_fuse_req() copies payload to the header, so we > can't yet relinquish the refcount on the headers buffer / clean it up > yet. I can add a comment about this to make this more clear. I only found time right now and already super late (or early) here. I guess that is fuse_uring_copy_to_ring -> copy_header_to_ring, but why can it then call fuse_uring_headers_cleanup() -> io_uring_fixed_index_put(). I.e. doesn't it put buffer it just copied to? Why not the sequence of err = fuse_uring_headers_prep(ent, ITER_SOURCE, issue_flags); fuse_uring_commit(ent, req, issue_flags); fuse_uring_headers_cleanup(ent, issue_flags); And then fuse_uring_get_next_fuse_req() does another fuse_uring_headers_prep() with ITER_DEST? > >> >> As I understand it, the the patch basically adds the feature of 0-byte >> payloads. Maybe worth mentioning in the commit message? > > Hmm I'm not really sure I am seeing where the 0-byte payload gets > added. On the server side, they don't receive payloads that are > 0-bytes. If there is no next fuse request to send, then nothing gets > sent. But maybe I'm not interpreting your comment about 0-byte > payloads correctly? There is fuse_uring_req_has_payload() and fuse_uring_select_buffer()/fuse_uring_next_req_update_buffer() using that function. When a request doesn't have a payload the ring entries runs without a payload - effectively that introduces 0-byte payloads, doesn't it? > >> I also wonder if it would be worth to document as code comment that >> fuse_uring_ent_assign_req / fuse_uring_next_req_update_buffer are >> allowed to fail for a buffer upgrade (i.e. 0 to max-payload). At least > > Good idea, I'll add a comment about this. > >> the current comment of "Fetching the next request is absolutely >> required" is actually not entirely true anymore. >> > > I don't think this patch introduces new behavior on this front. > fuse_uring_get_next_fuse_req() is still called to fetch the next > request AFAICS. > It still does, but if the request didn't have a payload it might not have a buffer and if it didn't have a buffer and doesn't manage to get a buffer, it doesn't handle a request - that a bit change of 'commit-and-fetch always fetches a new request if there is any request queued'. Thanks, Bernd From - Thu Feb 26 18:42:24 2026 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: Delivered-To: hi@josie.lol Received: from witcher.mxrouting.net by witcher.mxrouting.net with LMTP id cFBcOAuUoGl5mRAAYBR5ng (envelope-from ) for ; Thu, 26 Feb 2026 18:42:19 +0000 Return-path: Envelope-to: hi@josie.lol Delivery-date: Thu, 26 Feb 2026 18:42:20 +0000 Received: from sto.lore.kernel.org ([172.232.135.74]) by witcher.mxrouting.net with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98) (envelope-from ) id 1vvgJW-00000005PC7-342C for hi@josie.lol; Thu, 26 Feb 2026 18:42:19 +0000 Received: from smtp.subspace.kernel.org (conduit.subspace.kernel.org [100.90.174.1]) by sto.lore.kernel.org (Postfix) with ESMTP id 4969D301980F for ; Thu, 26 Feb 2026 18:26:03 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 21CCF3ED10A; Thu, 26 Feb 2026 18:25:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Kvj7Jna6" X-Original-To: linux-s390@vger.kernel.org Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BECC83DA7DF for ; Thu, 26 Feb 2026 18:25:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=pass smtp.client-ip=209.85.160.177 ARC-Seal:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772130304; cv=pass; b=e8gx4j3QyeRpGREYkDYaETxokdA7Img5fddexvgZfHB1pP9km1KmfeAGS79gfGbfsTOPFJghMmtSk9m7VEAscU6KMJfNss3/DPeWuKViqzVNT1ZwIeiRccCSmkAZ3tlcz5FlU4Cm/FejxdZFGfxRvAAzColHFD1DiCn3YLNMats= ARC-Message-Signature:i=2; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772130304; c=relaxed/simple; bh=RkOElQg3CI5L6VuXrmSVXhu5vFUi5hGqRopNPO/xOxw=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=F1nt1OssnxYLqdiZS74Tjskjpf6hJ04NxzY9xg3IAUM88DIkmhWgcOOP4qHeEUccORKCFhY1aWYl7Ilf0DbKqoM3k/w38IWVNMdhYUKPKvz3tL0bid1e2rQQZaKKrCzIgj89VCh7tbWwZtWCz+DZqFIUdYNr2r8EZFKC8ydMFWM= ARC-Authentication-Results:i=2; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Kvj7Jna6; arc=pass smtp.client-ip=209.85.160.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp