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=-9.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable 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 42E63C433E1 for ; Mon, 3 Aug 2020 06:52:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 11493206E9 for ; Mon, 3 Aug 2020 06:52:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=metafoo.de header.i=@metafoo.de header.b="V8KsFb9I" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726795AbgHCGw7 (ORCPT ); Mon, 3 Aug 2020 02:52:59 -0400 Received: from www381.your-server.de ([78.46.137.84]:38470 "EHLO www381.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725933AbgHCGw6 (ORCPT ); Mon, 3 Aug 2020 02:52:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=metafoo.de; s=default2002; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID; bh=pVK4/IazJnPOxJcn8CRUWY1PQenU0p/gHIhF+5bYTg8=; b=V8KsFb9IPUQzD/Krwqf6eJr2pH mNBF/s18CWwow44ZowV2SofT1FggnqSXIPnJM5xj8BgAPA68eRFkLh1yLUm43lvdCDnKRfJQxwn3C Mnn14jJARyz7AZbId7uIpp1SERYTlDhbMefWndcJC4cU8/qUkhYl/aq+jaWuhzHG1oGyFeAP1NTTe bEdOugANVxMR7AinXWe22ZAbqB2xrcl+lrTc0AhfKsSrlMwiyuRKV5JMwlK7o4chkTw4qLOCWIN1G DB6/KFahmWLJ+gtN4Z2Hx1gsvmGNNGZTQEaowhgtImdvYamGTonOkt1EcwEChO9eWQg7iIVeIPKTP EkqBKpzg==; Received: from sslproxy02.your-server.de ([78.47.166.47]) by www381.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1k2UL8-0002u4-M8; Mon, 03 Aug 2020 08:52:54 +0200 Received: from [2001:a61:2517:6d01:9e5c:8eff:fe01:8578] by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k2UL8-000C4J-GN; Mon, 03 Aug 2020 08:52:54 +0200 Subject: Re: [PATCH] iio: trigger: sysfs: Disable irqs before calling iio_trigger_poll() To: Christian Eggers Cc: Jonathan Cameron , stable@vger.kernel.org, Hartmut Knaack , Peter Meerwald-Stadler , linux-iio@vger.kernel.org, linux-kernel@vger.kernel.org References: <20200727145714.4377-1-ceggers@arri.de> <2272098.D4WoNcAbr4@n95hx1g2> <2443aad4-b631-bfe7-e79c-2cb585685a1e@metafoo.de> <4871626.01MspNxQH7@n95hx1g2> From: Lars-Peter Clausen Message-ID: Date: Mon, 3 Aug 2020 08:52:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <4871626.01MspNxQH7@n95hx1g2> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Authenticated-Sender: lars@metafoo.de X-Virus-Scanned: Clear (ClamAV 0.102.4/25892/Sun Aug 2 17:01:36 2020) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On 8/3/20 8:44 AM, Christian Eggers wrote: > Hi Lars, > > On Monday, 3 August 2020, 08:37:43 CEST, Lars-Peter Clausen wrote: >> The sysfs IIO trigger uses irq_work to schedule the iio_trigger_poll() >> and the promise of irq_work is that the callback will run in hard IRQ >> context. That's the whole point of it. >> >> irq_work_run_list(), which shows up in your callgraph, has as >> BUG_ON(!irqs_disabled())[1], so we should never even get to calling >> iio_trigger_poll() if IRQs where not disabled at this point. That's the >> same condition that triggers the WARN_ON() in __handle_irq_event_percpu. > is my patch sufficient, or would you prefer a different solution? The code in normal upstream is correct, there is no need to patch it since iio_sysfs_trigger_work() always runs with IRQs disabled. > >> Are you using a non-upstream kernel? Maybe a RT kernel? > I use v5.4.-rt That explains it. Have a look at 0200-irqwork-push-most-work-into-softirq-context.patch. The right fix for this issue is to add the following snippet to the RT patchset. diff --git a/drivers/iio/trigger/iio-trig-sysfs.c b/drivers/iio/trigger/iio-trig-sysfs.c --- a/drivers/iio/trigger/iio-trig-sysfs.c +++ b/drivers/iio/trigger/iio-trig-sysfs.c @@ -161,6 +161,7 @@ static int iio_sysfs_trigger_probe(int id)      iio_trigger_set_drvdata(t->trig, t);      init_irq_work(&t->work, iio_sysfs_trigger_work); +    t->work.flags = IRQ_WORK_HARD_IRQ;      ret = iio_trigger_register(t->trig);      if (ret)