From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dl1-f74.google.com (mail-dl1-f74.google.com [74.125.82.74]) (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 65FFF38E101 for ; Thu, 26 Feb 2026 07:06:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772089576; cv=none; b=c7eIbmnDbUvnp04edTbP6ulMg+FoLYyMi3WtMPHuPZjjh79sZJVlhrfgCcMmkmdR+GqR5vlOWvkakhzE8Qfx8LNCiPlxl/+qYTu7x1ETx7kKdCnqMuGT1oObOeMM54vtLnkY6ztpoVlw0Wwio0t+4HyXaSOVXeuYVYNOAU1KZrg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772089576; c=relaxed/simple; bh=1R7msjHSmTG/2uO3oYIInFkTi1ERP76I/8NVV+UDL1w=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=PIxWD182Mq2ccUQZAbYBMG6oh2zlo8kjk/6vkCp8vtmjJP+dOjLYSIEBgDyww4IryZ4Zs+6O0vQ3KrazGPiR/oK0vsvkVABEGf56rMwqL4IrdeYck5nq8p0m2rb6wLA9EnkSJfZozNAA09enStjq+zYVW+DR2iA76XdGdv3NXio= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--surenb.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=GLwr0cXP; arc=none smtp.client-ip=74.125.82.74 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=flex--surenb.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GLwr0cXP" Received: by mail-dl1-f74.google.com with SMTP id a92af1059eb24-1276e71652fso920488c88.0 for ; Wed, 25 Feb 2026 23:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1772089573; x=1772694373; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=vucVmOFSxssu4W4+hD04IB0isnzzlwVXoGbpC2l+3Iw=; b=GLwr0cXP1leI0GVWJ9lNk52GfIww9JL+A1Vf17tmO+w5fbnDGQiT6Sakg/rHF4qDjo Cenbny35Z57pU54e9/QWmygik3ul/ayGty7TqwUWBkfMhw5x2iq48EuHsSteg1Z1IaSd x/ISsXuNwaqE2eLbu0fmKPi7pHDKlvhjRwgIFPBtN6qrSyQFPUNUaMNMZHwgnpx2C//j VT0zZCXIyMR/470tRdXuDUvmEN63ZzmgEOHiJsDuMDfwYPVJVmwZukQgv/HAEtMDbXHS TY1pxffp4aGNr/v0albCqjsIwjyqz4/EXvc8+iHVl1ZgkvMPAummF4Iu/JwpcqttvNTP STwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772089573; x=1772694373; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=vucVmOFSxssu4W4+hD04IB0isnzzlwVXoGbpC2l+3Iw=; b=v2dJUGWgR2UvEjMwkUt87VoXrR+LjIgck0XWYRzzcU4tQWzSYD/03/16uD/qf866ye lREcKy5xZZBacARZIZGeOduMj5AoOounGqXrcF+/iTajmI9hvh0Gdj+JVMfJsMqgf7My AuyKse5lS+3xk8mZAd5/hSBQWWHHJ+bR6O9vf96eW3M6nW6USajRTOCRNQf4ms5/HCZX 67Z+8QhU7LliN5hpFaouIDYutznQnuZQx4GlrAuAzUXDFLjFGfU3ogckjEX4L40f+Tt/ teAZCFNKpUYlIdZ5K/hXIby37k/99y1EDq30+iFgcro1aPUk/gLI3CQuEDoIAF7Povv5 Ta2g== X-Forwarded-Encrypted: i=1; AJvYcCVP49YO8mJMjBpWiiQD4wBLWlHBHNXgUYczWuwN6nOIiThemdhaMC2QGxq8iejLwZmPD61Z7gGlNz/5mwU=@vger.kernel.org X-Gm-Message-State: AOJu0YwYnNlJ7ZuqIf6XmgeA89aC7T7j++uMXjbTQWesT3ZbHAvoaIyD ik4ewpPE/UEIjQJ3dwNNWqYF7+/rvSFsy5ZFkHK9qubXLDhZdl0geLqg55Go23eEcloG2VAq8NW tl0ZE8g== X-Received: from dlam21-n1.prod.google.com ([2002:a05:701b:2095:10b0:127:89b6:8d2a]) (user=surenb job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7022:60aa:b0:127:3b16:bf4f with SMTP id a92af1059eb24-127869c9ac6mr1332481c88.40.1772089573227; Wed, 25 Feb 2026 23:06:13 -0800 (PST) Date: Wed, 25 Feb 2026 23:06:06 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.53.0.414.gf7e9f6c205-goog Message-ID: <20260226070609.3072570-1-surenb@google.com> Subject: [PATCH v3 0/3] Use killable vma write locking in most places From: Suren Baghdasaryan To: akpm@linux-foundation.org Cc: 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, Liam.Howlett@oracle.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, surenb@google.com Content-Type: text/plain; charset="UTF-8" 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 patchset: 1. free_pgtables() because function should free page tables even if a fatal signal is pending. 2. userfaultd code, where some paths calling vma_start_write() can handle EINTR and some can't without a deeper code refactoring. 3. 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. 4. 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. A cleanup patch is added in the beginning to make later changes more readable. The second patch contains most of the changes and the last patch contains the changes associated with process_vma_walk_lock() error handling. Changes since v2 [1]: - rebased over mm-unstable, per Matthew Wilcox; - removed mpol_rebind_mm() changes since the function operates on a remote mm and incomplete operation can leave unrelated process in an inconsistent state; - moved vma_start_write_killable() inside set_mempolicy_home_node() to avoid locking extra vmas, per Liam R. Howlett - moved vma_start_write_killable() inside __mmap_new_vma() to lock the vma right after it's allocation, per Liam R. Howlett - introduced VMA_MERGE_ERROR_INTR to add EINTR handling for vma_modify() - changed do_mbind() error handling for avoid EINTR overrides; - changed migrate_to_node() error handling for avoid EINTR overrides; - added EINTR handling in queue_pages_range(); - fixed clear_refs_write() error handling which previous verstion broke by skipping some of the cleanup logic; [1] https://lore.kernel.org/all/20260217163250.2326001-1-surenb@google.com/ Suren Baghdasaryan (3): mm/vma: cleanup error handling path in vma_expand() mm: replace vma_start_write() with vma_start_write_killable() mm: use vma_start_write_killable() in process_vma_walk_lock() arch/powerpc/kvm/book3s_hv_uvmem.c | 5 +- arch/s390/kvm/kvm-s390.c | 2 +- fs/proc/task_mmu.c | 5 +- mm/khugepaged.c | 5 +- mm/madvise.c | 4 +- mm/memory.c | 2 + mm/mempolicy.c | 22 +++-- mm/mlock.c | 21 +++-- mm/mprotect.c | 4 +- mm/mremap.c | 4 +- mm/pagewalk.c | 20 +++-- mm/vma.c | 127 ++++++++++++++++++++--------- mm/vma.h | 6 ++ mm/vma_exec.c | 6 +- 14 files changed, 167 insertions(+), 66 deletions(-) base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f -- 2.53.0.414.gf7e9f6c205-goog