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 9D4ABC0219B for ; Tue, 11 Feb 2025 18:21:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3BAD06B007B; Tue, 11 Feb 2025 13:21:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 36BE76B0082; Tue, 11 Feb 2025 13:21:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 232C46B0085; Tue, 11 Feb 2025 13:21:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 08EB46B007B for ; Tue, 11 Feb 2025 13:21:01 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DE0BB1A07D9 for ; Tue, 11 Feb 2025 18:20:59 +0000 (UTC) X-FDA: 83108480280.11.DBDBBE3 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf06.hostedemail.com (Postfix) with ESMTP id 8D10D18000B for ; Tue, 11 Feb 2025 18:20:57 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Q40V6VAR; spf=pass (imf06.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739298057; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Uq8RN33m3WARUzg85WSDqlMASYQXVJgEf+b4oq1+yoo=; b=zH7GehOUIqECl2fmjbbYRAuadWwKF409Oc26JPphwxKFAwIeHEop1USMft5CNyiSEHWO19 BpvnQp7CdPHFFfujoqoIlTDCq0xv2sUNYhZ/qAUo110OcFbVJrut5yerccDx7MRRNlK2sh bkpm7mwCt82MvVEBYHZ+IyfocN84UsA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739298057; a=rsa-sha256; cv=none; b=LUP6vYi8vSC9+Nmnm0m4IoUQ4NU1jcFNETqVuof68icooAnvxUto+b/t0GcFNRAZCy/GcW 9SgPmJSUvDS6l6jRPsOFb2c5Q4U528ykJVvh9fZKMXSUdGXnu5P6HRilSJ+bUnAvI+E42L P0o+evr59Yw/2muR9A7pzTTF5BNx6Fs= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Q40V6VAR; spf=pass (imf06.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 0D119A40BDB; Tue, 11 Feb 2025 18:19:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 092C3C4CEDD; Tue, 11 Feb 2025 18:20:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739298056; bh=BwSdJG1qEJ5lEgTCCL0KL5wh2iaU3ANvXOSfLUO/pcg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Q40V6VARP9HS+qSSiQamUqzvCGGtIFWRf+E9o8RKRgYt8LVDpKJl/ZLDAPvMGzOVD zbT8n6ARq6iGZaQwIAh8rOuRkZuwCM43OIDur2tqv5pyhD6DF/GGJgLZA8Ii/qB7l4 041zMtvgMJgBQ2yNCxnZOYcYPJbQUG0SDnORDtPtxCBOPVDSfqWLYLmzpFE10XXjgr p9XMri0TsSkX3fluWvycmbh609jern9FMQRo3/F8cOJWIeWwF3YFXqM3eWY20LQmIW 0yYCAqpkrvOuhXe03mt5Pf95HOPQEAgh/4ITBT2HMv7R753tRvReIjVr3gg9cx6eNf p8rGQNGMqjJtQ== From: SeongJae Park To: Lorenzo Stoakes Cc: SeongJae Park , Andrew Morton , "Liam R. Howlett" , Davidlohr Bueso , Shakeel Butt , linux-kernel@vger.kernel.org, linux-mm@kvack.org, "Lai, Yi" , Naresh Kamboju , Arnd Bergmann Subject: Re: [PATCH mm-unstable] mm/madvise: handle MADV_{HWPOISON,SOFT_OFFLINE} from madvise_unlock() Date: Tue, 11 Feb 2025 10:20:53 -0800 Message-Id: <20250211182053.3639-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <2f448f7b-1da7-4099-aa9e-0179d47fde40@lucifer.local> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 8D10D18000B X-Rspamd-Server: rspam07 X-Stat-Signature: zbdihutrbch4fi1c51u49uey3kdtozox X-HE-Tag: 1739298057-610030 X-HE-Meta: U2FsdGVkX1/1a869bu1q9qCV/O8H72kUec2xs2A71QLSt8qW134nM59GkNGtekmKl+YH6e+hDQNKfEyGpOOu1tJPjpwx4CVdt86zmMU8E0zEpYdcEZMpXGUZpe7XduKE5GVlGT6gmLUzEW8ldALCMacFualsCEIDvTpVqW1gNuAdWCl47GuD3+E0/cQ9xA2rinn9qB946r4kHYXEQqFBad8tHYD3HHlttTU/liWO3vrTeVFV4HcXI8VFFTenQvyvTrwfMEQ5+kgd1dP/+q+ctqo0s5t5a2uPcfSIAvjRUa+pzAaZUBFVvyBUreKaleXtN30UbPz/NDiw0kzGpa3TpdbtHXdJUDSX7QgW2LmQCddmq4D9E0+Kjjggw6RrmlRNB+5QN864DPZe57UucNtzVvotpfGrBWoSBfFhTZxX6XbXnrXqwO0I4ylARxLRdzovL04UWhwWq6Bu1N3RiQ6zsV7iifLenZ1kLi2EYzIja80NFlAhjFbd7AVo7CR9Tg+vYcgXvQX58axH9I3IcD7cR3Kry/83EPy3jjf8Ri4Z22axa5ukMigUHFYWQUvy8eOUS3D6OGHtbvuebdh24tA5Yvvw3LL/6NKMidkyoaipd8P9YVaKFiDjF7pi3yu+i/Fg/LCecfGzpph4uig62LOn93V/q/wrk9K/0MjIcl/TMPjUbz5LTo3BjTr5EpZ17w0mbDE123CfD8yPC8sLC06jhVsB2qZH3b6rsX+qHbUv2jQ/NATi3LDJvwXU8RFCcBc2+JStghLkpuUkRpr1w09jBe+rEfAtsD6MMGx8JaE1QO/YdYaoM9HNnazMuIP6Qqmgqkb5KZeHznxEgCixHxzqc6X3bFdZbrSX+RtxSEVovQi4TVRyuWDF7u9J3pqfiTi7gQzPnKUGd8bBG0CNECCx5YBq+loWz9onC7V3H9UmOWNcSpXQf8t3ljxHrzkbtBzHqTOxZme7VBKTo+Tm5pD AynQe9qi XInua2ptPr86DoMxEem5dFZzlgFVGiZA4GdLIiAXK3E6mGLyWBnGLAZGN3749GLzwsYkTpP2BDRhpiEFt+wB1Jex7s5+o1abUXczRN9T4DVbmUB7YzG7rxWq0To1noMW+FrF/zAcxgR+vsSESKU1+Q7FsVQjB3M6wV3UQte3YTFP8KPS6beMZH25eFEPlaRHYePO7xN/Uh8plu+EHPTtCCs6wQYOfC1MrB2THGjN9HajoyOYr7kPxpayDOKF37FPEghdZjdsMUWShZfMatlOwP+A7WLybROLTmov+2+533O0oeaQGZhF/j2/J6zacfdbGrVF79Jl2TfJZkxX5TODKjgUg6NmtpcgcZEJT1OIxsA1oHVEmc16Kj5xAX1hH/YoDeInE 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: List-Subscribe: List-Unsubscribe: On Tue, 11 Feb 2025 10:51:41 +0000 Lorenzo Stoakes wrote: > +cc Naresh, Arnd for another reports/discussion of the same issue [0] while > lore/lei is broken. > > Hi, > > Lore breaking means I missed this :) thankfully you cc'd me (_this_ is why I am > so adament about people following get_maintainer.pl procedure btw) so I was able > to now notice + reply :) > > This is totally my bad for missing this on review, so mea culpa. No worry, your reviews are always very helpful! > > [0]:https://lwn.net/ml/linux-mm/CA+G9fYt5QwJ4_F8fJj7jx9_0Le9kOVSeG38ox9qnKqwsrDdvHQ@mail.gmail.com/ > > On Mon, Feb 10, 2025 at 10:32:01PM -0800, SeongJae Park wrote: > > madvise_lock() does nothing for MADV_HWPOSION and MADV_SOFT_OFFLINE > > behavior, but madvise_unlock() does mmap_lock unlocking regardless of > > the behavior. [...] > > mm/madvise.c | 6 +++++- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > > > diff --git a/mm/madvise.c b/mm/madvise.c > > index b5ef8e03d8b0..b8969457f3ef 100644 > > --- a/mm/madvise.c > > +++ b/mm/madvise.c > > @@ -1577,7 +1577,6 @@ int madvise_set_anon_name(struct mm_struct *mm, unsigned long start, > > > > static int madvise_lock(struct mm_struct *mm, int behavior) > > { > > - > > #ifdef CONFIG_MEMORY_FAILURE > > if (behavior == MADV_HWPOISON || behavior == MADV_SOFT_OFFLINE) > > return 0; > > @@ -1595,6 +1594,11 @@ static int madvise_lock(struct mm_struct *mm, int behavior) > > > > static void madvise_unlock(struct mm_struct *mm, int behavior) > > { > > +#ifdef CONFIG_MEMORY_FAILURE > > + if (behavior == MADV_HWPOISON || behavior == MADV_SOFT_OFFLINE) > > + return; > > +#endif > > I agree this fixes the issue but this is horrible. let's abstract this please > rather than doing the same crap that already existed, only now twice. I agree abstracting this is a better idea. > > > + > > if (madvise_need_mmap_write(behavior)) > > mmap_write_unlock(mm); > > else > > > > base-commit: 8bf30f9d23eb5040d37e6e712789cee8e71e1577 > > -- > > 2.39.5 > > I attach a fix-patch concept for something I think that'd be nicer, do with > it what thy wilt! :P sorry I don't mean to be 'one of those' maintainers > who copy/pastes code + demands somebody do it (by no means do I do so), but > since this is so small I feel it's kind of quicker for me to do it this > way. > > Obviously take it or leave it/adapt it/etc. This is compile-tested only... I further ran the repro program and confirmed this fixes the issue :) > > ----8<---- > From 9fce3e47bf0fff2a2291be66002af346cdbca665 Mon Sep 17 00:00:00 2001 > From: Lorenzo Stoakes > Date: Tue, 11 Feb 2025 10:44:26 +0000 > Subject: [PATCH] mm/madvise: fix madvise_[un]lock() issue > > We are asymmetric in our locking/unlocking in the case of memory failure > madvise() behaviour options, correct this and abstract the memory failure > check. > > Signed-off-by: Lorenzo Stoakes Reviewed-by: SeongJae Park Tested-by: SeongJae Park Thanks, SJ [...]