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.5 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 1DD48C433DF for ; Wed, 24 Jun 2020 13:08:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 01B1320786 for ; Wed, 24 Jun 2020 13:08:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390698AbgFXNIe (ORCPT ); Wed, 24 Jun 2020 09:08:34 -0400 Received: from foss.arm.com ([217.140.110.172]:47520 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728843AbgFXNIe (ORCPT ); Wed, 24 Jun 2020 09:08:34 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3C4F51F1; Wed, 24 Jun 2020 06:08:33 -0700 (PDT) Received: from [10.57.9.128] (unknown [10.57.9.128]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E89FE3F6CF; Wed, 24 Jun 2020 06:08:31 -0700 (PDT) Subject: Re: [RFC PATCH] perf/smmuv3: Fix shared interrupt handling To: Will Deacon Cc: mark.rutland@arm.com, tuanphan@os.amperecomputing.com, john.garry@huawei.com, linux-kernel@vger.kernel.org, shameerali.kolothum.thodi@huawei.com, harb@amperecomputing.com, linux-arm-kernel@lists.infradead.org References: <20200624125045.GC6270@willie-the-truck> From: Robin Murphy Message-ID: Date: Wed, 24 Jun 2020 14:08:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200624125045.GC6270@willie-the-truck> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-06-24 13:50, Will Deacon wrote: > On Wed, Jun 24, 2020 at 12:48:14PM +0100, Robin Murphy wrote: >> On 2020-04-08 17:49, Robin Murphy wrote: >>> IRQF_SHARED is dangerous, since it allows other agents to retarget the >>> IRQ's affinity without migrating PMU contexts to match, breaking the way >>> in which perf manages mutual exclusion for accessing events. Although >>> this means it's not realistically possible to support PMU IRQs being >>> shared with other drivers, we *can* handle sharing between multiple PMU >>> instances with some explicit affinity bookkeeping and manual interrupt >>> multiplexing. >>> >>> RCU helps us handle interrupts efficiently without having to worry about >>> fine-grained locking for relatively-theoretical race conditions with the >>> probe/remove/CPU hotplug slow paths. The resulting machinery ends up >>> looking largely generic, so it should be feasible to factor out with a >>> "system PMU" base class for similar multi-instance drivers. >>> >>> Signed-off-by: Robin Murphy >>> --- >>> >>> RFC because I don't have the means to test it, and if the general >>> approach passes muster then I'd want to tackle the aforementioned >>> factoring-out before merging anything anyway. >> >> Any comments on whether it's worth pursuing this? > > Sorry, I don't really get the problem that it's solving. Is there a crash > log somewhere I can look at? If all the users of the IRQ are managed by > this driver, why is IRQF_SHARED dangerous? Because as-is, multiple PMU instances may make different choices about which CPU they associate with, change the shared IRQ affinity behind each others' backs, and break the "IRQ handler runs on event->cpu" assumption that perf core relies on for correctness. I'm not sure how likely it would be to actually crash rather than just lead to subtle nastiness, but wither way it's not good, and since people seem to be tempted to wire up system PMU instances this way we could do with a general approach for dealing with it. Robin. 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.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 85FD4C433E0 for ; Wed, 24 Jun 2020 13:10:35 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 4B984206C3 for ; Wed, 24 Jun 2020 13:10:35 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nEt4P/n2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4B984206C3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Tgisi1gpMkefXrt6hYz3nAKLv7vXWi4W97TE+tRAuuw=; b=nEt4P/n2MSO+AfbinFuu+6Huq zkO60fr1QOojS0q7B+tkEEZegxEx4gG5349g0MpMTVypDu9slVnbc9+H1eUl2xEQm89h8nGSFaVs7 ampwOeraQLCSeSNkT8aOq21B1QXy32rhF4CWRejWRJeX/mEqHiKvPT4WV5mjPoBNFYroUXEnyQcai Iygxob9pDzM5+qpKY6IAL8lKPfyMnz/sdqSs9gl6Q0/goiX2gkAaFBQO1dsV072Kjt3ABWN5YpcJ3 xJFyXZ/yvn9gskdkS4R69GNF4QQajGMGp7WMdVgUS/ZQG73yd+NRF6zZjhetesg5ywkVXDwqILuFh OuI4I2OxA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo58m-0004GZ-Bo; Wed, 24 Jun 2020 13:08:36 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo58j-0004F2-Qz for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2020 13:08:34 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3C4F51F1; Wed, 24 Jun 2020 06:08:33 -0700 (PDT) Received: from [10.57.9.128] (unknown [10.57.9.128]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E89FE3F6CF; Wed, 24 Jun 2020 06:08:31 -0700 (PDT) Subject: Re: [RFC PATCH] perf/smmuv3: Fix shared interrupt handling To: Will Deacon References: <20200624125045.GC6270@willie-the-truck> From: Robin Murphy Message-ID: Date: Wed, 24 Jun 2020 14:08:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200624125045.GC6270@willie-the-truck> Content-Language: en-GB X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mark.rutland@arm.com, tuanphan@os.amperecomputing.com, john.garry@huawei.com, linux-kernel@vger.kernel.org, shameerali.kolothum.thodi@huawei.com, harb@amperecomputing.com, linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020-06-24 13:50, Will Deacon wrote: > On Wed, Jun 24, 2020 at 12:48:14PM +0100, Robin Murphy wrote: >> On 2020-04-08 17:49, Robin Murphy wrote: >>> IRQF_SHARED is dangerous, since it allows other agents to retarget the >>> IRQ's affinity without migrating PMU contexts to match, breaking the way >>> in which perf manages mutual exclusion for accessing events. Although >>> this means it's not realistically possible to support PMU IRQs being >>> shared with other drivers, we *can* handle sharing between multiple PMU >>> instances with some explicit affinity bookkeeping and manual interrupt >>> multiplexing. >>> >>> RCU helps us handle interrupts efficiently without having to worry about >>> fine-grained locking for relatively-theoretical race conditions with the >>> probe/remove/CPU hotplug slow paths. The resulting machinery ends up >>> looking largely generic, so it should be feasible to factor out with a >>> "system PMU" base class for similar multi-instance drivers. >>> >>> Signed-off-by: Robin Murphy >>> --- >>> >>> RFC because I don't have the means to test it, and if the general >>> approach passes muster then I'd want to tackle the aforementioned >>> factoring-out before merging anything anyway. >> >> Any comments on whether it's worth pursuing this? > > Sorry, I don't really get the problem that it's solving. Is there a crash > log somewhere I can look at? If all the users of the IRQ are managed by > this driver, why is IRQF_SHARED dangerous? Because as-is, multiple PMU instances may make different choices about which CPU they associate with, change the shared IRQ affinity behind each others' backs, and break the "IRQ handler runs on event->cpu" assumption that perf core relies on for correctness. I'm not sure how likely it would be to actually crash rather than just lead to subtle nastiness, but wither way it's not good, and since people seem to be tempted to wire up system PMU instances this way we could do with a general approach for dealing with it. Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel