Received: by 2002:a4a:311b:0:0:0:0:0 with SMTP id k27-v6csp4796837ooa; Tue, 14 Aug 2018 10:40:40 -0700 (PDT) X-Google-Smtp-Source: AA+uWPx3U1wDkk+37fuhCd7MGapU1/kd3nUBSJKzirDulrxbqtMFFRvLmdsZGYXpM31Invc0TnXh X-Received: by 2002:a63:6a45:: with SMTP id f66-v6mr21234749pgc.81.1534268440578; Tue, 14 Aug 2018 10:40:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534268440; cv=none; d=google.com; s=arc-20160816; b=IRPgPNCQU4e3oWJMXgSdArQEn2FiDqVMguNPF07F06klPMdVmYcaFg72FSAea1jYdc Boqq13eeQMsQdoc+TaO2SgCpC/ExYon66DNgD8gMK/CvjPI/a03qqL2+XdRSMm5FJmsM Z6h1LH0ecRWQDDfTAX4lUnTwqzgw+hNaUAn7q4SskuICRH0ySsNKXNnxZJ8ZVZohP10Q zbn2FauB7asSAmwsYPj4N5p4oXQPcAeeQfvA6JhYnsAWZJRYopGSZ72Rri3g8L/Kj/pN OO9XDhSXSLbh6PHQo1UgkFYPRmObR2kUNZADyGVjIgHI+BH9UoN0ML3lyDKQ0soTMowJ b96Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=yMRU/NKGvAKE8rEdjyGVvOv9TFil2pVrH5C1XlEkgWc=; b=QclvqTJgbZwfNluEaLPRR7BiKr2vvER5hU9T+pSuS85QKy31ZFZ/uSzoTKNMSn7JHb jeL0daKYaN7g0CpHNUjZe57WL9cUWQ2wwD0Ysju6nv3eUWExzQT+l40BwMH76VDYd0w5 i0bMhzulih/3JaPQ3ZFAceW+Oc1txn6OiwpaSsxnsFVkSoFhL+WQiUbErtuIrqaY/Y6h jhn1TfVse32oocSez5gtWuf+1dOZT8EMUxlmIYgMzGenT1aIpmtzG/HukaALbT+itCBb bVZ+O0+WVgMnB+erknVusfB+isA3g5+LN1QpDZke521YOjHCwYQwX5coOD6VNtrnQAK1 Rkmg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g12-v6si16198084pla.403.2018.08.14.10.40.25; Tue, 14 Aug 2018 10:40:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388730AbeHNU1p (ORCPT + 99 others); Tue, 14 Aug 2018 16:27:45 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:58506 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729689AbeHNU1p (ORCPT ); Tue, 14 Aug 2018 16:27:45 -0400 Received: from localhost (unknown [194.244.16.108]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id F13FED20; Tue, 14 Aug 2018 17:39:34 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Mauro Carvalho Chehab , Alan Stern , Eric Dumazet , Ingo Molnar , Linus Torvalds Subject: [PATCH 4.9 006/107] Mark HI and TASKLET softirq synchronous Date: Tue, 14 Aug 2018 19:16:29 +0200 Message-Id: <20180814171521.226864314@linuxfoundation.org> X-Mailer: git-send-email 2.18.0 In-Reply-To: <20180814171520.883143803@linuxfoundation.org> References: <20180814171520.883143803@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.9-stable review patch. If anyone has any objections, please let me know. ------------------ From: Linus Torvalds commit 3c53776e29f81719efcf8f7a6e30cdf753bee94d upstream. Way back in 4.9, we committed 4cd13c21b207 ("softirq: Let ksoftirqd do its job"), and ever since we've had small nagging issues with it. For example, we've had: 1ff688209e2e ("watchdog: core: make sure the watchdog_worker is not deferred") 8d5755b3f77b ("watchdog: softdog: fire watchdog even if softirqs do not get to run") 217f69743681 ("net: busy-poll: allow preemption in sk_busy_loop()") all of which worked around some of the effects of that commit. The DVB people have also complained that the commit causes excessive USB URB latencies, which seems to be due to the USB code using tasklets to schedule USB traffic. This seems to be an issue mainly when already living on the edge, but waiting for ksoftirqd to handle it really does seem to cause excessive latencies. Now Hanna Hawa reports that this issue isn't just limited to USB URB and DVB, but also causes timeout problems for the Marvell SoC team: "I'm facing kernel panic issue while running raid 5 on sata disks connected to Macchiatobin (Marvell community board with Armada-8040 SoC with 4 ARMv8 cores of CA72) Raid 5 built with Marvell DMA engine and async_tx mechanism (ASYNC_TX_DMA [=y]); the DMA driver (mv_xor_v2) uses a tasklet to clean the done descriptors from the queue" The latency problem causes a panic: mv_xor_v2 f0400000.xor: dma_sync_wait: timeout! Kernel panic - not syncing: async_tx_quiesce: DMA error waiting for transaction We've discussed simply just reverting the original commit entirely, and also much more involved solutions (with per-softirq threads etc). This patch is intentionally stupid and fairly limited, because the issue still remains, and the other solutions either got sidetracked or had other issues. We should probably also consider the timer softirqs to be synchronous and not be delayed to ksoftirqd (since they were the issue with the earlier watchdog problems), but that should be done as a separate patch. This does only the tasklet cases. Reported-and-tested-by: Hanna Hawa Reported-and-tested-by: Josef Griebichler Reported-by: Mauro Carvalho Chehab Cc: Alan Stern Cc: Greg Kroah-Hartman Cc: Eric Dumazet Cc: Ingo Molnar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- kernel/softirq.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) --- a/kernel/softirq.c +++ b/kernel/softirq.c @@ -79,12 +79,16 @@ static void wakeup_softirqd(void) /* * If ksoftirqd is scheduled, we do not want to process pending softirqs - * right now. Let ksoftirqd handle this at its own rate, to get fairness. + * right now. Let ksoftirqd handle this at its own rate, to get fairness, + * unless we're doing some of the synchronous softirqs. */ -static bool ksoftirqd_running(void) +#define SOFTIRQ_NOW_MASK ((1 << HI_SOFTIRQ) | (1 << TASKLET_SOFTIRQ)) +static bool ksoftirqd_running(unsigned long pending) { struct task_struct *tsk = __this_cpu_read(ksoftirqd); + if (pending & SOFTIRQ_NOW_MASK) + return false; return tsk && (tsk->state == TASK_RUNNING); } @@ -324,7 +328,7 @@ asmlinkage __visible void do_softirq(voi pending = local_softirq_pending(); - if (pending && !ksoftirqd_running()) + if (pending && !ksoftirqd_running(pending)) do_softirq_own_stack(); local_irq_restore(flags); @@ -351,7 +355,7 @@ void irq_enter(void) static inline void invoke_softirq(void) { - if (ksoftirqd_running()) + if (ksoftirqd_running(local_softirq_pending())) return; if (!force_irqthreads) {