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 3F295EB64D9 for ; Wed, 12 Jul 2023 06:47:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9FAD86B0071; Wed, 12 Jul 2023 02:47:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9AB056B0072; Wed, 12 Jul 2023 02:47:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89A966B0075; Wed, 12 Jul 2023 02:47:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7848B6B0071 for ; Wed, 12 Jul 2023 02:47:20 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4368C1A015A for ; Wed, 12 Jul 2023 06:47:20 +0000 (UTC) X-FDA: 81002028240.16.9960CC6 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf30.hostedemail.com (Postfix) with ESMTP id 738648000F for ; Wed, 12 Jul 2023 06:47:18 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689144438; 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; bh=wecdgtIlzWNujrH/Y7GUGb3WkoEHbGoEQcpILdRRZQY=; b=RDgt0TdQ9rmmrL7RD4EHTw8IQQGzMI+UsXVAvCigS6SnoecrRzeCmHWh+NTK4dovemby75 MnBqX4ilB9jppaHcPH7qque3lycthhdAolnPfdCdHV/r9/NLHxlPqDFARegKhQg3U3BmA/ WxjP5NrhpXEU9QLxF4vLgB+Df/NdI18= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf30.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689144438; a=rsa-sha256; cv=none; b=u2u9TakcSOdr8048rRdClfRKETUA0okquLp0rZXGYL0g3XyPggHGKSQL5sFm9U+F1orRLZ pDOpR1FbN6foyj8Dkl0qPircJL1zMI3J43zbv6ojRCpZ8/aWe2FUsUUE73HdLiQfAkIbc7 nDkv37gJTKJnsAZtDJjAQ4Tp+IyPvKQ= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8F4212F4; Tue, 11 Jul 2023 23:47:59 -0700 (PDT) Received: from [10.162.42.6] (unknown [10.162.42.6]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B9CF93F67D; Tue, 11 Jul 2023 23:47:14 -0700 (PDT) Message-ID: <6e473d64-fbbc-db12-99ee-d32768d8af85@arm.com> Date: Wed, 12 Jul 2023 12:17:11 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v1] mm/memory_hotplug: document the signal_pending() check in offline_pages() Content-Language: en-US To: David Hildenbrand , linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linux-doc@vger.kernel.org, Michal Hocko , Oscar Salvador , Jonathan Corbet , Andrew Morton References: <20230711174050.603820-1-david@redhat.com> From: Anshuman Khandual In-Reply-To: <20230711174050.603820-1-david@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 738648000F X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: s4acboz89crojzuz5dbgz1itib67mdxh X-HE-Tag: 1689144438-260450 X-HE-Meta: U2FsdGVkX1/PBDT702iM+0lA5enscYpLyqHDO5as2slXFqeRpQ0bk0GyNipA6ssyNJl4FOeLtGBt+NRjTv07VRFI8t+GqSg2aKNtpHMo748EJ+eMspuESP9aIUUH+bVrGT+Lasuz1ofDe4/2JiyJVOEcU4KcffILZh3qRb2bW7J8iy/wrHNXs+qGBj1FR7qKqwDuSbJ0plELmxpWhru7vF2cxkQ5xXEJeGp3KvyBRfBDeE+v6cpbMEafDc0oi1IrtPs73Cn9HRLFsssYXsYzboTpulVdQROvUZEpo8ScWzM+LnWhpWShabvNKF7h2x9f/P0HxWzTuQYIdkolu3nntWvM6uAHYkz1BmS47O9s5nymb30mLqMFLjUGKEvotxqCnzDDXokgcMG5BHF492bT9Yql+2MSsgJXK/3wP4GcCTrOz1urou8ssQPM5U7PX08naLKYEATetAsPQ2/KSIGXpXURXQTu4Jo4kP98EaxPbnmJGxM9DI93v25yJ/rX06D292XnMAEgNDOqwGHmJq9Mtmt83NCBoieeeqs5CK8ZgYWmwp6zTThcH3kYNQi9+KWeZxpkI9tkE15OgxKzCml0SfMlQR+PtxaAK1rqb23XYrX6vWdF17/Vx9dfWo52Fx1OAIyw37yPWOGHVEBZz4q1m/y7YRbMP2O5LJdM721dTS5j+wcb/9GF6XP/aI0RgBidFfkPkoGm8YCEvXXzIZyJK7ZrYi+XdCH9N32xnsvBcax5wUuaGtCymT/trGnU8Gcr2HkLPFPGlr7nxjZq1r5A3Jfj9gmetYjZoM15LkrdmcVQwGHcalOOktPJMgzJhAyUtyekE4uqh8KtqABijiKsL8IYBsu5tadvOWSLNNb4x8aBgwmnsZHl2jNFGOnQpLY84Th86QDaW8BeJ9yz32rNkmbFapdzD8KbGZGT38kbOfk7eju/rC1MWTVead40xEAOHdQnF/2RgTydvsub9eO SQaX6eWI /KaZnvpPiW5RZOYOOTbwuHKyE+aue50KzN/S0DEFx9d1gkaO/BktjqPdnAseZu7Y9LUsU3YnHe8LkE13Bf4W+2RieoFYAt6FbBOryhP6+RvuYq4vQ7AWYha6q7PT/qv1bRLVgTv2KITrblayroOsd5FabwfcOo99hsNoyY/o0P4ZC+q0pQ9fgWwJ3cEFJzcDzqNh4B45lsnin98A/zq2qAUUtLOIYDH2EOtzaoq/+E47J4y8H07qXuf7qoWGyHaweHG1XL0T0m45Dq7nnSF8VKwz66i0uEUhK6eYIn/jm6s0pmcLHmKwtCenut8J5U0B6Uoqu0jDlYEVgPTSdO4Vy+xMZUDzuLNEwDbvT 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 7/11/23 23:10, David Hildenbrand wrote: > Let's update the documentation that any signal is sufficient, and > add a comment that not only checking for fatal signals is historical > baggage: changing it now could break existing user space. although > unlikely. > > For example, when an app provides a custom SIGALRM handler and triggers > memory offlining, the timeout cmd would no longer stop memory offlining, > because SIGALRM would no longer be considered a fatal signal. > > Cc: Michal Hocko > Cc: Oscar Salvador > Cc: Jonathan Corbet > Cc: Andrew Morton > Signed-off-by: David Hildenbrand > --- > Documentation/admin-guide/mm/memory-hotplug.rst | 2 +- > mm/memory_hotplug.c | 5 +++++ > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst > index 1b02fe5807cc..bd77841041af 100644 > --- a/Documentation/admin-guide/mm/memory-hotplug.rst > +++ b/Documentation/admin-guide/mm/memory-hotplug.rst > @@ -669,7 +669,7 @@ when still encountering permanently unmovable pages within ZONE_MOVABLE > (-> BUG), memory offlining will keep retrying until it eventually succeeds. > > When offlining is triggered from user space, the offlining context can be > -terminated by sending a fatal signal. A timeout based offlining can easily be > +terminated by sending a signal. A timeout based offlining can easily be > implemented via:: > > % timeout $TIMEOUT offline_block | failure_handling > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index 3f231cf1b410..7cfd13c91568 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -1843,6 +1843,11 @@ int __ref offline_pages(unsigned long start_pfn, unsigned long nr_pages, > do { > pfn = start_pfn; > do { > + /* > + * Historically we always checked for any signal and > + * can't limit it to fatal signals without eventually > + * breaking user space.> + */ Just curious, could 'signal type' to stop memory offline process be considered an ABI and cannot be changed in kernel ever if required ? Just wondering if an additional '!fatal_signal_pending()' check be introduced to warn about support being deprecated, before finally replacing it with fatal_signal_pending(). > if (signal_pending(current)) { > ret = -EINTR; > reason = "signal backoff";