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 1F6A0EB64D7 for ; Tue, 20 Jun 2023 07:12:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E66D8D0003; Tue, 20 Jun 2023 03:12:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 896968D0001; Tue, 20 Jun 2023 03:12:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 75E228D0003; Tue, 20 Jun 2023 03:12:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 650D58D0001 for ; Tue, 20 Jun 2023 03:12:59 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3A54740576 for ; Tue, 20 Jun 2023 07:12:59 +0000 (UTC) X-FDA: 80922259278.24.AACE904 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf27.hostedemail.com (Postfix) with ESMTP id EDE4C40008 for ; Tue, 20 Jun 2023 07:12:56 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dc0g0vdH; spf=pass (imf27.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687245177; 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=sl2grgufuGzfS3XSwpjzJA7IILsYC/N9nHuDHXJPqDQ=; b=WnV3lQw+cocej9mlTr7XUsZZ25wtwz2MFrdq/XWCEhRZAqyEc8UddYkhNBxkHxjDOjXjQ2 ISHqykWvW94C+8jvfmHDEQnCnL+D8O0spZj/quzRZYkCuxJkFauTZXGcboUtA/1ReUSzb2 bZ+n6KlgGxY4qM8sJKEh9H4RJMRAFwU= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dc0g0vdH; spf=pass (imf27.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687245177; a=rsa-sha256; cv=none; b=o9OYcd0hgrr2uDF7DjxATds1OBoQIt2V1LeGpu3LC8zvUbOCsnx4RqfmHFmJ/mJkZEKEoh pvyeNxnCpXUb/770GAH0D7EyJSOXvAmotkp68tqjKNLN0LEOHOsCRLiujLthuQAIM3jILZ h1yPr2FoZVmL7I0p1YWWvf+UwK0dsMM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1687245176; 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=sl2grgufuGzfS3XSwpjzJA7IILsYC/N9nHuDHXJPqDQ=; b=dc0g0vdHzsMayhsMPzUQaiZ/v4OTcnnOnMOgryrSCZssfucSPD6Gjq0g4JU4rXXPIGlH4P KUrxOKerCsH2nJquyGXaXXuKCYEXyhABR+K6T8kBeBjRZKtGkFdFLb/nQmOVqTmSOp/4Ee HIGqrSxBOo8QNyjht4zuKUKWITzujDs= Received: from mail-lj1-f198.google.com (mail-lj1-f198.google.com [209.85.208.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-114-RtMOy18GMwKJguVwg1qSJg-1; Tue, 20 Jun 2023 03:12:54 -0400 X-MC-Unique: RtMOy18GMwKJguVwg1qSJg-1 Received: by mail-lj1-f198.google.com with SMTP id 38308e7fff4ca-2b479d12b31so16376921fa.3 for ; Tue, 20 Jun 2023 00:12:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687245173; x=1689837173; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sl2grgufuGzfS3XSwpjzJA7IILsYC/N9nHuDHXJPqDQ=; b=ZrGQ5EwD0pgGEgcIhFGpio3CQM6YtTbCyl/zOeqLqC+a1TYpnK27DHFDWGkRUwcYpA QIBeDifSV7rPdTNDHRRpLZVaV8SxcdeKJh2DSewpmm6/kfepT5HWXwtoQ95NVXNMJUW3 0lFM+ZrO1Nll4ZxQGLxgB9uGRTPDMCGUmMGIKme6F7b8S0r07TAm7sqQOh8W3XKE0G7y 09NiqSEPoGSBzoyQSlXc3vbWSR51YuUqs7neeNoSpYUrHRCiNEZZB0/s4735mlilcidM YeHcGr0YVeOfFLL7Ippk6Ps8pzWjLxeGiV/4B8tbUt+DbCrSk0R9DB4fik/ujG5ZZnJG npKQ== X-Gm-Message-State: AC+VfDyv3woTdQNKC2AYjqmO2NHU4o6DNi+gQwOVAi8A1BMrXKWidzw7 ANwChN0ybIojTq3Jq78C7fXCOgCMe3NRsZwh07ob7k3x85cLncQGumDD9ENMwoolw3qgxfRCSbC ykrl8+i1pIzc= X-Received: by 2002:a2e:8443:0:b0:2b1:bb66:7b69 with SMTP id u3-20020a2e8443000000b002b1bb667b69mr6470910ljh.32.1687245173360; Tue, 20 Jun 2023 00:12:53 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5UwtHUVNvptYW894cJKPC9dIxSY6AG/GHv9dPoLT1wlZUuP8uibPLIVZY2HwDYi22XCLmmEw== X-Received: by 2002:a2e:8443:0:b0:2b1:bb66:7b69 with SMTP id u3-20020a2e8443000000b002b1bb667b69mr6470893ljh.32.1687245172825; Tue, 20 Jun 2023 00:12:52 -0700 (PDT) Received: from ?IPV6:2003:cb:c739:d200:8745:c520:8bf6:b587? (p200300cbc739d2008745c5208bf6b587.dip0.t-ipconnect.de. [2003:cb:c739:d200:8745:c520:8bf6:b587]) by smtp.gmail.com with ESMTPSA id m7-20020a7bce07000000b003f9b155b148sm4455052wmc.34.2023.06.20.00.12.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 20 Jun 2023 00:12:52 -0700 (PDT) Message-ID: Date: Tue, 20 Jun 2023 09:12:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 To: John Hubbard , Oscar Salvador Cc: Andrew Morton , LKML , linux-mm@kvack.org References: <20230620011719.155379-1-jhubbard@nvidia.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH] mm/memory_hotplug.c: don't fail hot unplug quite so eagerly In-Reply-To: <20230620011719.155379-1-jhubbard@nvidia.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-Rspamd-Queue-Id: EDE4C40008 X-Rspam-User: X-Stat-Signature: qzgbra46hxzdefrrk959rwhd44yj6c6m X-Rspamd-Server: rspam01 X-HE-Tag: 1687245176-907325 X-HE-Meta: U2FsdGVkX1+FM2MkpfU/RrAUrdvLEOhhEprR8nADnMVm6vCX4K6Ylpay6DAhaRpeZpglnEy7WwjR/yrfc8yqaEWIzTqw/s9w8rqSn/QdY6dfSWRuH7pLp27UoBK8zYEBiZSDaFxfpa3f7d7Fxm7KnqFNCWucOA1D/CPHlPGUcE6EL7ln4RlpvezGNfEYD03X03FyAWt5AfUPfN1PWOfa3/DIM46oXNtQpKEejZNnon6CPbJLltOrD/Tqbv05aiYYsSRlbOdFpj6KYX1CstTgBSRqp2LnjYHqEzX/usLdcXEXBgnvtm+lKfOZszyiWhGdBffwdHG5rZF1oqfd7cvLUcc1Da0zu4hGD5kAjAUQaA1Ldkemzj6hcwWBv2jQM5+3ipL2SrlLPRQlCwTPamvhdmvIbziqd0T5xnp8QjBGfOJA3upLg/bgAsq7B2Q1Tl0vmU+g3GwS5SJ0M2KywB5UkXtp7QHfRZQQBsBDLO0a5LGRkirnnfnlk8m81E9iTAB7z3Ube2HaXe2jxvaXAcjEGf4WNQCgWZuCXEduRqr0euv/Hn4GPbGQbhASks97kwKynMTfnh/nFTGzYBBq+4T4+3PlafpLR0xm2mQma/ezMbgiOWmPQE+T51dys/fZyOjUb+wQa6KkYOOPMYhVchgst9gk086y6aPcaXxauflMWRtlnBwKpqs3BWkp6suhXzxJQJ85kpaa55dEPVmhumjnM/W3gXfONsTcj1XpHR3wjfTnByGUwiobfXXpspYdGMSthXDZvD8C0tcVT7TxW20IezMrFZKnQuq69VXXb674DEzNeUXs3CAcJ6R44qB5xmlQx7C2b6ilRLcT8QqX89qBLcHb4EMwRp6/QH/t7FmxUkCLaFagf947AncRKF59Z2zgSttG0yybjWzylZcllfvJUP0CTAFVHjw9tgEHmV2Oi7G+AV3pm2bkwOPOKQHOaHH/lShzuFjAXAZapPNfSys XC7SfNaj dGHs54+jjG2mx2x1fqXaCD8WHq2dxNN2lSfyjV0xz4WfPkApDVyJiuZH3T/86WgeVwI8FGYV43D04WRUdpFkb5/M3Z6ePJsAcYVrKK3ZK8A76rGq9oPwrMTGt3nfvWHRBCIb6deHAM3jHKtEUiZoxgOe03mswqb618UJI9G6enH0MpVAm0wOlxe5Cp5ADH0sRI3kW6ES4qsXDfpnhbYVmOS9Zm+kaLv+uhY3nLXk803vX/hoMfnqsBCM53/YwCJna0vU6rr1zyQto540QNwX0+G0hFCSO0wxLxam9Fx/wcitsWdyVc4q/fG+hk31zzvq6+3UiPFGDStkSzVuL5LMm/TPcR3cZal7nhSrIGU5wiMlzHgVlGMjVRsfdXSKOBs0PNzSE6yR3G3zEp2KRSrD0QE9vgueUvTVj+MPmMWGFCYnMU15MZullF+GnJssfidegezXVhTHAn07gxuy2xTgegvSLSfwDG25ouHYXbmp/Mu8rqRYHxM3aw1qyHmCEkJ6EKjXHQpwSdanl8cYSRBuGnhTCr5JMDEXjxKhI 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 20.06.23 03:17, John Hubbard wrote: > mm/memory_hotplug.c: don't fail hot unplug quite so eagerly > > Some device drivers add memory to the system via memory hotplug. When > the driver is unloaded, that memory is hot-unplugged. Which interfaces are they using to add/remove memory? > > However, memory hot unplug can fail. And these days, it fails a little > too easily, with respect to the above case. Specifically, if a signal is > pending on the process, hot unplug fails. This leads directly to: the > user must reboot the machine in order to unload the driver, and > therefore the device is unusable until the machine is rebooted. Why can't they retry in user space when offlining fails with -EINTR, or re-trigger driver unloading? > > During teardown paths in the kernel, a higher tolerance for failures or > imperfections is often best. That is, it is often better to continue > with the teardown, than to error out too early. > > So in this case, other things (unmovable pages, un-splittable huge > pages) can also cause the above problem. However, those are demonstrably > less common than simply having a pending signal. I've got bug reports > from users who can trivially reproduce this by killing their process > with a "kill -9", for example. > > Fix this by soldering on with memory hot plug, even in the presence of > pending signals. > > Signed-off-by: John Hubbard > --- > mm/memory_hotplug.c | 6 ------ > 1 file changed, 6 deletions(-) > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > index 8e0fa209d533..57a46620a667 100644 > --- a/mm/memory_hotplug.c > +++ b/mm/memory_hotplug.c > @@ -1879,12 +1879,6 @@ int __ref offline_pages(unsigned long start_pfn, unsigned long nr_pages, > do { > pfn = start_pfn; > do { > - if (signal_pending(current)) { > - ret = -EINTR; > - reason = "signal backoff"; > - goto failed_removal_isolated; > - } > - > cond_resched(); > > ret = scan_movable_pages(pfn, end_pfn, &pfn); No, we can't remove that. It's documented behavior that exists precisely for that reason: https://docs.kernel.org/admin-guide/mm/memory-hotplug.html#id21 " 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 implemented via: % timeout $TIMEOUT offline_block | failure_handling " Otherwise, there is no way to stop an userspace-triggered offline operation that loops forever in the kernel. I guess switching to fatal_signal_pending() might help to some degree, it should keep the timeout trick working. But it wouldn't help in your case because where root kills arbitrary processes. I'm not sure if that is something we should be paying attention to. -- Cheers, David / dhildenb