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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6024CCA47C for ; Tue, 7 Jun 2022 18:41:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352035AbiFGSlj (ORCPT ); Tue, 7 Jun 2022 14:41:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37526 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1352647AbiFGSjE (ORCPT ); Tue, 7 Jun 2022 14:39:04 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B0A63184863; Tue, 7 Jun 2022 10:58:28 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 255CEB81F38; Tue, 7 Jun 2022 17:58:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7E30EC36AFE; Tue, 7 Jun 2022 17:58:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654624699; bh=WjlPiW19crEYmsn/usMNLrHWV8DmX3Lja2fcB7x66uQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=l1lxFBtXd9M5LJtVJ882+sbE++xBs+pTst6un4fpc8cFy6nsdZ41pFIPzjjn/2Jaj KDUi6bZyEvUlh9GD9dhoaRxEJeZguRMVmx5lyouThdHpxXBRgseDGZcZjMzNaUTNf+ LLLOgVp0++Lg2hKZ61+MvN0Vokb+l6lEGoyw0l2f29el5b1SDw1GK+PcSnmycZQRhj JZ5ctQsjsIBs2Je3ZbOq1iPoGQOzROrfPTdHDFEeI7MZuhYUfn4SmEyVO9MzklqDiT BTumA2sH5Yk4D8D63/816hY5UKAs7uPNh4TpuZbsamNbFkqqtAZE3ADSGo2OPy0MSi 22B9xqVMIe2vQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christian Borntraeger , Alexander Gordeev , Claudio Imbrenda , Heiko Carstens , Sasha Levin , frankja@linux.ibm.com, gor@linux.ibm.com, kvm@vger.kernel.org, linux-s390@vger.kernel.org Subject: [PATCH AUTOSEL 5.15 48/51] s390/gmap: voluntarily schedule during key setting Date: Tue, 7 Jun 2022 13:55:47 -0400 Message-Id: <20220607175552.479948-48-sashal@kernel.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220607175552.479948-1-sashal@kernel.org> References: <20220607175552.479948-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Christian Borntraeger [ Upstream commit 6d5946274df1fff539a7eece458a43be733d1db8 ] With large and many guest with storage keys it is possible to create large latencies or stalls during initial key setting: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 18-....: (2099 ticks this GP) idle=54e/1/0x4000000000000002 softirq=35598716/35598716 fqs=998 (t=2100 jiffies g=155867385 q=20879) Task dump for CPU 18: CPU 1/KVM R running task 0 1030947 256019 0x06000004 Call Trace: sched_show_task rcu_dump_cpu_stacks rcu_sched_clock_irq update_process_times tick_sched_handle tick_sched_timer __hrtimer_run_queues hrtimer_interrupt do_IRQ ext_int_handler ptep_zap_key The mmap lock is held during the page walking but since this is a semaphore scheduling is still possible. Same for the kvm srcu. To minimize overhead do this on every segment table entry or large page. Signed-off-by: Christian Borntraeger Reviewed-by: Alexander Gordeev Reviewed-by: Claudio Imbrenda Link: https://lore.kernel.org/r/20220530092706.11637-2-borntraeger@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin --- arch/s390/mm/gmap.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/arch/s390/mm/gmap.c b/arch/s390/mm/gmap.c index d63c0ccc5ccd..4ce3a2f01c91 100644 --- a/arch/s390/mm/gmap.c +++ b/arch/s390/mm/gmap.c @@ -2601,6 +2601,18 @@ static int __s390_enable_skey_pte(pte_t *pte, unsigned long addr, return 0; } +/* + * Give a chance to schedule after setting a key to 256 pages. + * We only hold the mm lock, which is a rwsem and the kvm srcu. + * Both can sleep. + */ +static int __s390_enable_skey_pmd(pmd_t *pmd, unsigned long addr, + unsigned long next, struct mm_walk *walk) +{ + cond_resched(); + return 0; +} + static int __s390_enable_skey_hugetlb(pte_t *pte, unsigned long addr, unsigned long hmask, unsigned long next, struct mm_walk *walk) @@ -2623,12 +2635,14 @@ static int __s390_enable_skey_hugetlb(pte_t *pte, unsigned long addr, end = start + HPAGE_SIZE - 1; __storage_key_init_range(start, end); set_bit(PG_arch_1, &page->flags); + cond_resched(); return 0; } static const struct mm_walk_ops enable_skey_walk_ops = { .hugetlb_entry = __s390_enable_skey_hugetlb, .pte_entry = __s390_enable_skey_pte, + .pmd_entry = __s390_enable_skey_pmd, }; int s390_enable_skey(void) -- 2.35.1