From patchwork Wed Jun 22 21:36:53 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Xu X-Patchwork-Id: 12891500 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 25B19CCA479 for ; Wed, 22 Jun 2022 21:37:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A3C868E00F7; Wed, 22 Jun 2022 17:37:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 83B3A8E00F6; Wed, 22 Jun 2022 17:37:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DC148E00F7; Wed, 22 Jun 2022 17:37:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 534A48E00E7 for ; Wed, 22 Jun 2022 17:37:17 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 2E3FD8077B for ; Wed, 22 Jun 2022 21:37:17 +0000 (UTC) X-FDA: 79607182914.24.2042A6D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf21.hostedemail.com (Postfix) with ESMTP id B62DF1C00AC for ; Wed, 22 Jun 2022 21:37:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655933825; 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=gOKc2ikh4vL40/zpc4P3kwwtd9Sh2ixHRUheDMcVbAY=; b=dWcoKCH7z68xZrg0CD8dviRnLJL/Jyn1kyYf8iV0JN5RYEjR0Vf0UVGe0iy+pEWZHXwB3K swnrKwhLaDbz++v7tvl8A1VCTh7fSORvzdMsNOvI+dl5UWIWreK6DpFg9ELQ+Jdk7846aU 2Qssm3QQnOtAEs2El2PXptFIFpHxZJk= Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-198-P1P2R_iaNjezvMRN5DATNQ-1; Wed, 22 Jun 2022 17:37:04 -0400 X-MC-Unique: P1P2R_iaNjezvMRN5DATNQ-1 Received: by mail-il1-f198.google.com with SMTP id s6-20020a056e021a0600b002d8fcba296aso8029270ild.20 for ; Wed, 22 Jun 2022 14:37:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=gOKc2ikh4vL40/zpc4P3kwwtd9Sh2ixHRUheDMcVbAY=; b=2jGDXChGzdiq6erWuT+v601WF/0cxiM8goRGPotXfruU6FAF5+oEf7ousXOC4QgCbw 6K9hCb1SAW6aLgPk9O/FdwC6fIhIhPxYN7s351ertvlBf1dlbLnTuNo1yyqhhoPP2Fwd cdxnmVus0JS2rmLgs6yG/lH84r++4KSPNW8NjiOCzd6c69vu2AilJGeW8XxxYWPN88Jd 3qOcfCIyu3vLCy/g5VqumkOk/QUOiGaaQI8C3XLZvCOK33G2ldCkL3Y3miFOBenhkigc JdMKOZJcQ3AhkLMJb4nwJhXhtDTULTnFyGGAROuvTHgjneM5A/Au3SsG0ANVyiBAqt84 ADJw== X-Gm-Message-State: AJIora9dpHhYDG6EIhDnlbYa6PrOhNNZUerPo4E2wVnc9lmE04wc7ZAI OFp9yzaM6V8lAV+EweucGn5mXgRFoVzcaT1Lw68m89oQ0hHq7P4HgVSWSpPkKpAuNvex8i3b7cZ wGTILKjBrvbc= X-Received: by 2002:a05:6602:2a42:b0:65a:eb90:2a12 with SMTP id k2-20020a0566022a4200b0065aeb902a12mr2846098iov.73.1655933823947; Wed, 22 Jun 2022 14:37:03 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t/8cXtBj2IFYSYh/9eeCC/nf69NJ99ofpl9KFVNDHUyqPHOLaFoA3xbf+adONapZRIiJVl6Q== X-Received: by 2002:a05:6602:2a42:b0:65a:eb90:2a12 with SMTP id k2-20020a0566022a4200b0065aeb902a12mr2846084iov.73.1655933823672; Wed, 22 Jun 2022 14:37:03 -0700 (PDT) Received: from localhost.localdomain (cpec09435e3e0ee-cmc09435e3e0ec.cpe.net.cable.rogers.com. [99.241.198.116]) by smtp.gmail.com with ESMTPSA id g7-20020a0566380c4700b00339d892cc89sm1510446jal.83.2022.06.22.14.37.01 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Wed, 22 Jun 2022 14:37:02 -0700 (PDT) From: Peter Xu To: kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: peterx@redhat.com, Paolo Bonzini , Andrew Morton , David Hildenbrand , "Dr . David Alan Gilbert" , Andrea Arcangeli , Linux MM Mailing List , Sean Christopherson Subject: [PATCH 1/4] mm/gup: Add FOLL_INTERRUPTIBLE Date: Wed, 22 Jun 2022 17:36:53 -0400 Message-Id: <20220622213656.81546-2-peterx@redhat.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20220622213656.81546-1-peterx@redhat.com> References: <20220622213656.81546-1-peterx@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-type: text/plain ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655933834; a=rsa-sha256; cv=none; b=svblLF8zl7sTC53+msqCe/wpo6jJcH0Bu58Talr3aj+r/GHRx+6r1goXWiVc9UOhMz+Xm0 FO229gk1kwJDu5Gi5JhReV5ZRcxwPaFdK6O35IcEAKbMrAd5Od8mAqFSSM31WFlTMAek1r 7jg6s267QQNiKv7hkcE5erhQBjdw5e4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1655933834; 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=gOKc2ikh4vL40/zpc4P3kwwtd9Sh2ixHRUheDMcVbAY=; b=EDYaw2M1g1d4IMtwdWIQOHxnnGUvMzcQL+l4jp4r/QhgKkW09rK7MQXpll5Y/Li9LtAarW g2VOTyWTnlwONvgsIM6NfWjwesKquUOYJZn3C2+dtkqNyqIBbZLgHyjpB1pK6NKneqv2Rh tsRUmiN0bpf+WS5yfcnYThGgBvIF1Hs= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dWcoKCH7; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf21.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-Rspam-User: X-Rspamd-Queue-Id: B62DF1C00AC Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dWcoKCH7; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf21.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com X-Stat-Signature: 9d851zc8aykes879kw5n9rxmjpwgnpqy X-Rspamd-Server: rspam09 X-HE-Tag: 1655933832-366101 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: We have had FAULT_FLAG_INTERRUPTIBLE but it was never applied to GUPs. One issue with it is that not all GUP paths are able to handle signal delivers besides SIGKILL. That's not ideal for the GUP users who are actually able to handle these cases, like KVM. KVM uses GUP extensively on faulting guest pages, during which we've got existing infrastructures to retry a page fault at a later time. Allowing the GUP to be interrupted by generic signals can make KVM related threads to be more responsive. For examples: (1) SIGUSR1: which QEMU/KVM uses to deliver an inter-process IPI, e.g. when the admin issues a vm_stop QMP command, SIGUSR1 can be generated to kick the vcpus out of kernel context immediately, (2) SIGINT: which can be used with interactive hypervisor users to stop a virtual machine with Ctrl-C without any delays/hangs, (3) SIGTRAP: which grants GDB capability even during page faults that are stuck for a long time. Normally hypervisor will be able to receive these signals properly, but not if we're stuck in a GUP for a long time for whatever reason. It happens easily with a stucked postcopy migration when e.g. a network temp failure happens, then some vcpu threads can hang death waiting for the pages. With the new FOLL_INTERRUPTIBLE, we can allow GUP users like KVM to selectively enable the ability to trap these signals. Signed-off-by: Peter Xu Reviewed-by: John Hubbard --- include/linux/mm.h | 1 + mm/gup.c | 33 +++++++++++++++++++++++++++++---- 2 files changed, 30 insertions(+), 4 deletions(-) diff --git a/include/linux/mm.h b/include/linux/mm.h index bc8f326be0ce..ebdf8a6b86c1 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -2941,6 +2941,7 @@ struct page *follow_page(struct vm_area_struct *vma, unsigned long address, #define FOLL_SPLIT_PMD 0x20000 /* split huge pmd before returning */ #define FOLL_PIN 0x40000 /* pages must be released via unpin_user_page */ #define FOLL_FAST_ONLY 0x80000 /* gup_fast: prevent fall-back to slow gup */ +#define FOLL_INTERRUPTIBLE 0x100000 /* allow interrupts from generic signals */ /* * FOLL_PIN and FOLL_LONGTERM may be used in various combinations with each diff --git a/mm/gup.c b/mm/gup.c index 551264407624..ad74b137d363 100644 --- a/mm/gup.c +++ b/mm/gup.c @@ -933,8 +933,17 @@ static int faultin_page(struct vm_area_struct *vma, fault_flags |= FAULT_FLAG_WRITE; if (*flags & FOLL_REMOTE) fault_flags |= FAULT_FLAG_REMOTE; - if (locked) + if (locked) { fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_KILLABLE; + /* + * We should only grant FAULT_FLAG_INTERRUPTIBLE when we're + * (at least) killable. It also mostly means we're not + * with NOWAIT. Otherwise ignore FOLL_INTERRUPTIBLE since + * it won't make a lot of sense to be used alone. + */ + if (*flags & FOLL_INTERRUPTIBLE) + fault_flags |= FAULT_FLAG_INTERRUPTIBLE; + } if (*flags & FOLL_NOWAIT) fault_flags |= FAULT_FLAG_ALLOW_RETRY | FAULT_FLAG_RETRY_NOWAIT; if (*flags & FOLL_TRIED) { @@ -1322,6 +1331,22 @@ int fixup_user_fault(struct mm_struct *mm, } EXPORT_SYMBOL_GPL(fixup_user_fault); +/* + * GUP always responds to fatal signals. When FOLL_INTERRUPTIBLE is + * specified, it'll also respond to generic signals. The caller of GUP + * that has FOLL_INTERRUPTIBLE should take care of the GUP interruption. + */ +static bool gup_signal_pending(unsigned int flags) +{ + if (fatal_signal_pending(current)) + return true; + + if (!(flags & FOLL_INTERRUPTIBLE)) + return false; + + return signal_pending(current); +} + /* * Please note that this function, unlike __get_user_pages will not * return 0 for nr_pages > 0 without FOLL_NOWAIT @@ -1403,11 +1428,11 @@ static __always_inline long __get_user_pages_locked(struct mm_struct *mm, * Repeat on the address that fired VM_FAULT_RETRY * with both FAULT_FLAG_ALLOW_RETRY and * FAULT_FLAG_TRIED. Note that GUP can be interrupted - * by fatal signals, so we need to check it before we + * by fatal signals of even common signals, depending on + * the caller's request. So we need to check it before we * start trying again otherwise it can loop forever. */ - - if (fatal_signal_pending(current)) { + if (gup_signal_pending(flags)) { if (!pages_done) pages_done = -EINTR; break;