From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com [209.85.128.51]) (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 58F841A9F83 for ; Thu, 23 Apr 2026 07:17:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776928665; cv=none; b=QC3n+MM7DXfcaIn9gpA30D2Lh5kI130oLH7pFL1xwzzUZN9zEXbY+6j7Jr8SXzvelgPaM0P08mhdLmDBWU+er0dKggngDz+1qvYC5NiZ2bsF27p0dDyQSZgLllvEYZDCaYSvFbEuuDQBIAx53X0pPPRt+o/6Gu0e9CLt77qDVdM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776928665; c=relaxed/simple; bh=nhZO7p+duwhLX6A2m2HeZh3GaJKb0tTzl8V56uanqdI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EALmmC2DEyf/eecwdiPq/8gKSZydG0e10CXM65BqQk5Imqb3ea420f0rOj6c912D7ziqmeAP9QNZ2EvTSJQaOTONoEoPnwUaJlRRPAdPL3hO5PPkOx9tZTJ82A/bjDlIE4Eiff/Gj69vUqn7UXZdmMuFq0IoY689dmqLnEacCm4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=PLEAYBcU; arc=none smtp.client-ip=209.85.128.51 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="PLEAYBcU" Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-488b0e1b870so102749465e9.2 for ; Thu, 23 Apr 2026 00:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1776928662; x=1777533462; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=7pt8k19vyvcqDIr8XmsEkmZnWHbLVSULR09dmEZb914=; b=PLEAYBcUtlm9zw1FItuNBRDY1QHGdy8P/N/HNda26/1oAYanzrQ4VtsTyMM71eaPmZ W4GodvKodBpvIu8m+b9rW0/3n+B7cWRAkvAOdF5JkwYgxM+LLPX+lUAdUdOOsNuabFRX csRHEVc8LjvXXhAhFc5Eg0NEc3tYzLtmXjbPKivVh9JFbG5rJ04nlb2X8RnTi7Uz/Q00 kRhHusiHuLuizBawtsm8MNKoJuZjLZ0pSnlMx/0MC67xk3KnKtIjqKkBwrV+BmnIuyn2 sQrCsvZs3D6f1rDZM6L1KeHsPrti4Yd0IppllTyaxdRDmT9lx4DoBw2RbgTHwEINNBRv 9f1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776928662; x=1777533462; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7pt8k19vyvcqDIr8XmsEkmZnWHbLVSULR09dmEZb914=; b=VkhM6uzN9AsS1L6PJUjX62qe2rgnpcQvLdOpfoZxTUN9fQlaq6h0WZvHXRoYhrJIVl 0JZSRkne4Q+Em5/E5NSquic/cK5ow8i8QFGQO742S3rBr7qBRg9cg93sciekkpvv87N/ wWFzBTBZH35UWXoQBFlmnGGD6xSo6Mgo1NUKdDsgGHE04WDkwNlnEy9RKtUBj8WmrhS8 9dKl7LaBq2iRIY/rjtX2gi4Pj/Pj7KU/jgh/GZ716cGgUxnD/i32t72Aa1V30/1Izuo1 PRt5qpLPo/t3rO3LohQCgr8Iq5u+3eeOjy4ZBV5GaEbxiRh2YmkpWMPxCEtraplJyjCD yz1A== X-Forwarded-Encrypted: i=1; AFNElJ/CPd2bNywrhSyglcPBY7Aij5f0gRGCNfmu5tZbr2ZjhDr134pncKLDvDcr/5KBROB8jCYlgsiIz90gPG8=@vger.kernel.org X-Gm-Message-State: AOJu0YwTBcN1ibmiO/JhXMtpDE75HS1lB8wBtA3j3YNtS1FlxGofM2Yw YLGSvvuFcMH4YAmOQVIuqPlKWrQNctoKeiv8L2TYqtJLm+6ZzfRUBTCGzqvOeWfeRLs= X-Gm-Gg: AeBDievKP1WF9FUavxEXay6Yrsr0YvGObOZyHUqsVJwUa0MWA4ke/QJ7bmFfKyK50u/ SrT7E+J/ixuZQ7N2v8iWRwM2Yphnx/vDZUwlJwUWb8uAT9YUed2IVn9oM3xeMi9rUyFU86o4ZFm nxw9ryb90291qCc7a9M0twlQjQryWIDZ1o/832iWI2KdQPPBvIkgizR8kit4Er6lRj7269jr6+Z Ta5/2g3dzow9snHv2Ky9aU4x9GyV85Em0eA99YqQE+mNU51l28zaY3i0Sx++sI7BNjh5BjMFhMz 5MFZZKGzaV1r7MhLMoLyNMlrh/hhbRk7RaLgRNyHY0HzriR5socJg9OEMY6fZndtnTWz2VpPtIr XOQSdbBQ4gfZPDNB0vgYBUyvcSnr63Wx4vOTYDR/pOVrIlij2FztMF+qeJ1y5Q1ZSLv6brnyCV8 Fo7z409vgzbRpxmOXtatg5ol/9yjEvSqJLlBAED/x6tCXPN9WYKQTs53RJdg== X-Received: by 2002:a05:600c:37c4:b0:48a:5501:7995 with SMTP id 5b1f17b1804b1-48a55017b71mr161954475e9.18.1776928661638; Thu, 23 Apr 2026 00:17:41 -0700 (PDT) Received: from localhost (109-81-17-171.rct.o2.cz. [109.81.17.171]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48a5499b0edsm187793265e9.14.2026.04.23.00.17.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2026 00:17:41 -0700 (PDT) Date: Thu, 23 Apr 2026 09:17:39 +0200 From: Michal Hocko To: Minchan Kim Cc: Christian Brauner , akpm@linux-foundation.org, david@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, surenb@google.com, timmurray@google.com Subject: Re: [RFC 3/3] mm: process_mrelease: introduce PROCESS_MRELEASE_REAP_KILL flag Message-ID: References: <20260413223948.556351-1-minchan@kernel.org> <20260413223948.556351-4-minchan@kernel.org> <20260416-planktont-abwinken-b9499483b939@brauner> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Mon 20-04-26 14:47:04, Minchan Kim wrote: > On Fri, Apr 17, 2026 at 09:04:31AM +0200, Michal Hocko wrote: > > On Thu 16-04-26 23:30:09, Minchan Kim wrote: > > > If I send the SIGKILL first to satisfy the process_mrelease() requirement, > > > we immediately run into the scheduling race condition where the victim can > > > enter the exit path before the reaper can set the flag. > > > > Why don't you just grab the mm before you send the signal and then continue > > with reaping? You just want to avoid a race where the victim manages to > > process fatal signal, start its exit path and mrelease path losing that > > race so you rely on the exit path, right? > > The problem is that process_mrelease() operates on a task obtained from a pidfd. > > Once the victim process receives the SIGKILL and enters the exit path (exit_mm), > the kernel sets task->mm to NULL. > > Even if we could somehow hold a reference to the mm_struct beforehand, > process_mrelease() would still fail because mm_struct via task returns NULL > after exit_mm() has been called. > > Therefore, we cannot simply "grab the mm" before sending the signal and expect > process_mrelease() to work after the victim starts exiting. I do not follow. Why cannot you simply do this diff --git a/mm/oom_kill.c b/mm/oom_kill.c index 5c6c95c169ee..b80a96f5460a 100644 --- a/mm/oom_kill.c +++ b/mm/oom_kill.c @@ -1241,9 +1241,14 @@ SYSCALL_DEFINE2(process_mrelease, int, pidfd, unsigned int, flags) if (task_will_free_mem(p)) reap = true; else { + if (flags & PROCESS_MRELEASE_REAP_KILL) { + } else { + /* send SIGKILL */ + reap = true; /* Error only if the work has not been done already */ - if (!mm_flags_test(MMF_OOM_SKIP, mm)) - ret = -EINVAL; + if (!mm_flags_test(MMF_OOM_SKIP, mm)) + ret = -EINVAL; + } } task_unlock(p); -- Michal Hocko SUSE Labs