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 9B834EB64DA for ; Wed, 12 Jul 2023 19:10:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0D1198D000A; Wed, 12 Jul 2023 15:10:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05A228D0002; Wed, 12 Jul 2023 15:10:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E17318D000A; Wed, 12 Jul 2023 15:10:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D0DFF8D0002 for ; Wed, 12 Jul 2023 15:10:14 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A45641C8356 for ; Wed, 12 Jul 2023 19:10:14 +0000 (UTC) X-FDA: 81003900348.16.B97B7BF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf10.hostedemail.com (Postfix) with ESMTP id 54585C001A for ; Wed, 12 Jul 2023 19:10:12 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GM5nYP+h; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689189012; a=rsa-sha256; cv=none; b=uuJL/U2E2fMxFvQgv7uefwGU87NRCS9Zz9WzTui6WnpzEpAnao+LcbiTA/pt+3J4qwAktW 4vKe2L1bEaikaNNAAPPYLDfMOaiAQtwgHaDbNg7FyJtxhkCgo95sn0uQFSL+1RAwMAYD2d +gQ2REQiIQjRQ0WigzFoWYtGGwpq++I= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GM5nYP+h; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf10.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689189012; 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:dkim-signature; bh=LpyHkpVso0b8a+p6JmqDgDKJ26YHuwzqKI5Da7hz1I8=; b=VmHnifWZF6jQ5bSjpeijwnFFUdz0lDh916RzN5s9BgrQaNP6XWefhWdiRCpGmXKCk4FsbS iWTFofEaOyFL70QINOqQ1tHY4Bl/AY8ro6K83oYnPecwppAQWqRK1KD7ijDVBAlbxvM/O3 PwczhyNi3KAAUfnwEZzf9ob1iJUSVV0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689189011; h=from:from: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=LpyHkpVso0b8a+p6JmqDgDKJ26YHuwzqKI5Da7hz1I8=; b=GM5nYP+hR2+/e8j/H63+ZJtci23eA7pD9XBITB8yDFvl9tFfNZInaUAeing8SeU3K+G9dX mlGcB5v3kQXCMVw0QFLN0sGX53u1iHKl5ycoL0xMOoHxYCdtTsEEnF3oAoIiKQizSIinxC JBGtRJn5V3SclkDJk7GCRI7B7wv32zc= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-371-lPU73ZDMOmmTWSWKqE8qyg-1; Wed, 12 Jul 2023 15:10:10 -0400 X-MC-Unique: lPU73ZDMOmmTWSWKqE8qyg-1 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-3158f4d72e9so2709070f8f.1 for ; Wed, 12 Jul 2023 12:10:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689189009; x=1691781009; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=LpyHkpVso0b8a+p6JmqDgDKJ26YHuwzqKI5Da7hz1I8=; b=Qousft2wDqI7VB+M0nQLmoZIIDlHV96K+D+pIjTkWpNlrOOlTeGb6CZ/ElarPYjBZ1 JXq1GeTXsBDmrEr0oVRSKDmlW4kCAlkbXbRnegGZT+j12E/qZG/RZVjMc7P8apy14Hbs P45Dt2pSV2cLNNurVH3aC4Q67NDB0gfFLdnpeAdbxYC9WahLzOeN7aEIcq6DAtfPuqtq Bc4TEubji2J2K+v4Ehz93wjMNrlS1FPH+ymDJMaBHXdiSh7PJfw9P/9vlId+HS+oeR4P kgPk9NUcjcw/6ZrtqdfDo9/4zFDrDvlheSyFm4WYtGrIUK5LULPyKjT07vpGcAHoQxo1 6YfA== X-Gm-Message-State: ABy/qLZBuErc+XMgXgJPkSX1qvi8skaRMyefa/5Plj23qqT1zspJc7bh hwHgbwhh5OSKG/yMMuZGPJ/4BBeklAmfdao+fLW2+E/xjp3+8p/H36MYpLVSpKZgrXpw15tsxr1 P21fcUms9L40= X-Received: by 2002:a5d:664d:0:b0:313:ee2e:dae1 with SMTP id f13-20020a5d664d000000b00313ee2edae1mr16045097wrw.18.1689189009180; Wed, 12 Jul 2023 12:10:09 -0700 (PDT) X-Google-Smtp-Source: APBJJlGMGfFIaXHwBrDx1CqxjskLjhy5sdzusnHEp8jN2HIPDxRD+vAGQJNr4BZ6vOAZC+oUwBNggg== X-Received: by 2002:a5d:664d:0:b0:313:ee2e:dae1 with SMTP id f13-20020a5d664d000000b00313ee2edae1mr16045086wrw.18.1689189008931; Wed, 12 Jul 2023 12:10:08 -0700 (PDT) Received: from ?IPV6:2003:cb:c707:3700:3eea:ace6:5bde:4478? (p200300cbc70737003eeaace65bde4478.dip0.t-ipconnect.de. [2003:cb:c707:3700:3eea:ace6:5bde:4478]) by smtp.gmail.com with ESMTPSA id k8-20020a5d5188000000b00314172ba213sm5718522wrv.108.2023.07.12.12.10.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Jul 2023 12:10:08 -0700 (PDT) Message-ID: <6d24ff50-b463-f2cd-09c8-fb6eb73d5c07@redhat.com> Date: Wed, 12 Jul 2023 21:10:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v1] mm/memory_hotplug: document the signal_pending() check in offline_pages() To: Anshuman Khandual , 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> <6e473d64-fbbc-db12-99ee-d32768d8af85@arm.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <6e473d64-fbbc-db12-99ee-d32768d8af85@arm.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 54585C001A X-Stat-Signature: b6gwqegubm6hw5y1qt76gbt8ia9nn8gr X-HE-Tag: 1689189012-205502 X-HE-Meta: U2FsdGVkX19bwG12RgxN5ybNUwLlOyM4H5NpFUo34UFg8Mptx9M5xZy84cUBRQmeD7G7VtBol31SGDs3llt25v6hS3OKZuEu11Rj7GJrzs/D9kKAet4maYasGObnOZvKVWHkf/bYfb08/OkukZO2O1v9tMN083q2WAq1zZ4n0VNRh8P1Zi2rVOM9pgZJdlP/raDJ5UHz1tq5nUwSu3AK+TW13CSLc6Mxg/jlTn1FVFNJtU3g1go8vur1jg95avT+ABRAPGDED6AQZ7z9+qMHdrklatKwllvSSSOmiLNOzpc7cqKf9lti5fWADpV2o8RPlkiSHcH/0TCWF3cS/Tft0EuqbBBqNjD0UPvQYXjr3FaRFDM0/PaXxWu2QnvxVx+EPkw90y5D//3B7uMlUGyOeQsz2RqqdI+IdQeMD0IRrzW14QQKyYHVcLkdYf7l32sNNfVRl9HpRy5YwyWJvXO2lpKYAauq/eCncU19Gmv87DX5pn8W54o4LBzeXitmjcMZEIJ6cVRn6k0fDQt6HMO8if/M2TMHqtzPiyIT00XGhggd1+Eqq6ARgoub+ybH+K0ZMtgpmYdVXMkdX66YfOlxo+GxvGyts0PDSK9O186YdyYEktJlHI2PU/ZXoT0DHTKNUCuRWsfI1rBlQFYQu9K58R3OAYn0e0r74xegFlW5G6Jr80joKnYgJ1t0pwVByETLeKaQ0Thw+HZdqDFnohrxhSXFAio79Rui6BcVf+nCI4Yp6F6LaYIoak+HcCr8fiVSVM1R0rl9RHKxinuZIldVYf+MHpWjO0Rp0hHA0dWewBUXIVW0TCx/6+6mlz7gi5aHJgXzPpWqdPLnQ4FW3OITOSGVBcofCGeqzkB0Zj1SyFrl3g6tjJOGpIgSeQ4Imp0znWjm1YiqXY1ThoySiKi3vFkSgnfk99AECxWZ/MPB5oK4f5hLWHw+y+/t842CYkxNfLOtvmUaY2i5CCEUIG/ KdFmIXS4 zOSAbaWhxEBiMqLI5wzdFhm+BYLoyR0sKJBiYyNIr7b4sWFcJ3ffIq8cPF70kDzs8MT1uoZTBCbBMIQ0qGqkWxFLPSdvCBaC12s0/23OYYdQHatFMuIbdO6jTPIH/wLpRrWSNEvoP7tsoAZzzmJI1f1ePVxv5tVHFwIN9R0su2vFOMSG3a88E93DHVTFz8QX4gT3h2C34HH+z2x2tH0LZB1SvPuO084NFUJ3knInKMR+Dtqn0GbXwmvpiqyjzLq+/SSjY7i26iNvc7QC7clFpAZ5c82ApUqWE0WG9v56irGyk148zWklXDAFLf8PHLkVdZYE2UDXCh1TFTDrJXKaJ+Oh9R5TKjXePWgdLB4eVWm7+Isi2E2eNtVL5+idU1pNm7kmC+Pt4DXvkpCClgLbskkkzIi6uat3uELFJ2cRX673STk6Rfd+MBU0I4hDlNmO9BTOd7aNJajQypbUYw/qi2Po0yPVpcaWzo+lcGBBGBSbZWhrw5/s3CE2PbJ5qUFRXRtfrvvjyg6z303ewlCb6Bgd1TceKQdK9MQU4 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 12.07.23 08:47, Anshuman Khandual wrote: > > > 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(). See my reply to Michal, while that would be doable it is probably not worth the effort, and we'd still have to stick with the existing handling for quite a while. Thanks! -- Cheers, David / dhildenb