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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B5A7C43331 for ; Fri, 27 Mar 2020 08:35:56 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 185B020705 for ; Fri, 27 Mar 2020 08:35:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 185B020705 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jHkSe-0002zs-Er; Fri, 27 Mar 2020 08:35:28 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1jHkSd-0002zn-CM for xen-devel@lists.xenproject.org; Fri, 27 Mar 2020 08:35:27 +0000 X-Inumbo-ID: e82d691a-7005-11ea-8920-12813bfff9fa Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id e82d691a-7005-11ea-8920-12813bfff9fa; Fri, 27 Mar 2020 08:35:26 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 7D2B4AE72; Fri, 27 Mar 2020 08:35:25 +0000 (UTC) To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , Igor Druzhinin References: <20200326091918.12388-1-jgross@suse.com> <20200326091918.12388-4-jgross@suse.com> <260d0f20-a424-3708-3ab7-6d8c89247a2a@citrix.com> <7a9cff0b-4c8f-899a-3fae-8a703bc90125@suse.com> From: Jan Beulich Message-ID: <859b4b9e-d839-0961-6c09-4c6aebefe9e4@suse.com> Date: Fri, 27 Mar 2020 09:35:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <7a9cff0b-4c8f-899a-3fae-8a703bc90125@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [Xen-devel] [PATCH v8 3/5] xen: don't process rcu callbacks when holding a rcu_read_lock() X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: Stefano Stabellini , Julien Grall , Wei Liu , Andrew Cooper , Ian Jackson , George Dunlap , xen-devel@lists.xenproject.org Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" On 27.03.2020 09:10, Jürgen Groß wrote: > On 27.03.20 00:24, Igor Druzhinin wrote: >> On 26/03/2020 09:19, Juergen Gross wrote: >>> Some keyhandlers are calling process_pending_softirqs() while holding >>> a rcu_read_lock(). This is wrong, as process_pending_softirqs() might >>> activate rcu calls which should not happen inside a rcu_read_lock(). >>> >>> For that purpose modify process_pending_softirqs() to not allow rcu >>> callback processing when a rcu_read_lock() is being held. >>> >>> Signed-off-by: Juergen Gross >>> Reviewed-by: Jan Beulich >>> --- >>> V3: >>> - add RCU_SOFTIRQ to ignore in process_pending_softirqs_norcu() >>>    (Roger Pau Monné) >>> >>> V5: >>> - block rcu processing depending on rch_read_lock() being held or not >>>    (Jan Beulich) >> >> Juergen, >> >> Our BVT revealed a likely problem with this commit in that form. >> Since 12509bbeb9e ("rwlocks: call preempt_disable() when taking a rwlock") >> preemption is disabled after taking cpu_maps which will block RCU >> callback processing inside rcu_barrier itself. This will result in > > Why would that block RCU callback processing? > > RCU callbacks should be blocked only if a rcu lock is being held. > > Did I miss something in my patches? Igor, are you perhaps running without "rcu: add assertions to debug build"? I think this actually fixes what you describe. Without it rcu_barrier(), in its second loop, calling process_pending_softirqs(), would cause the RCU softirq to not be invoked anymore with preemption disabled. Of course the title of this change doesn't reflect this at all. Jürgen, as an aside, while looking at the code again, I think the comment near the end of process_pending_softirqs() would now rather belong at its very beginning; should have spotted this while reviewing. Jan