Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp2761948imm; Sun, 5 Aug 2018 11:33:47 -0700 (PDT) X-Google-Smtp-Source: AAOMgpdbDmSAg4r+S+u8DvT9aEKgjMbDzyr9WoJqcPXI087ABoKd9A+c5S8doW/IZpr/GQw4xsSd X-Received: by 2002:a17:902:7446:: with SMTP id e6-v6mr11355715plt.161.1533494027150; Sun, 05 Aug 2018 11:33:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533494027; cv=none; d=google.com; s=arc-20160816; b=XD1N2jWIOgnvMKEP7rSTRR12IbepqPwKF7XK3emnkOTcCyaR18+zOnnO4eTuxAc62H MTBu/5/WkN+p3h3np4uUompO2jTLyhIf7abn/sb6PDtWKOY0IbFnHfo/m4l7UMMMVUYl Qx6KId5XBfrE9vc45fFBjFqD1aGh975BgUAwZxeh5QUNKOGHxe7+bB0T/lvR6LwVx5ti sePxN36fqOMiGcrwZJ775ZlxVX9lYLYq1Dup7FJq6O9pMbIvLNSL2RxwBURfKOt4iV1K N2HXWM1AFQZtTLpReVzWz09VETJKTwQehvumXM1EsaUDqKWedu/9IGNypvtnB5DNKrLG Cg/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=rx+VEUcfHrPCsCxNIqMHTr3J/ctmDvihznTPtYDpUd4=; b=zNXUdcCztz2G1zA3MtgTU1u3bwz03BXtuWeFXcUsCqHnhdUuia5GV5i6e/bA3EJsVQ LF+vracso8WwN6uUknuedr51CaGb10gmmmhzexbkQPyR11qN7coBjn12aHFsxqEKUSm5 uaz3D2yVAG62xo9jxADNfCmQ4N2eTFMVFFARP26NCxvNE1ZfNgqPIpZWq5mLtEBO66L1 d4kDNKXRyp8rKMelyOihfH/CCY4UWDSzVED3nkfoIXnEEFv3MPpjLwhO1p/+5cjXwtd4 34CE5SCYd+Sq5ZeicSEJc+aOBCERoVEgoyvf81qljb+TOfZ7ukE0mJgD9V8yCSMQvBbt 2Guw== 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 p1-v6si10218348pfe.150.2018.08.05.11.33.19; Sun, 05 Aug 2018 11:33:47 -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 S1726666AbeHEUhV (ORCPT + 99 others); Sun, 5 Aug 2018 16:37:21 -0400 Received: from netrider.rowland.org ([192.131.102.5]:56947 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726447AbeHEUhV (ORCPT ); Sun, 5 Aug 2018 16:37:21 -0400 Received: (qmail 29800 invoked by uid 500); 5 Aug 2018 14:31:53 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 5 Aug 2018 14:31:53 -0400 Date: Sun, 5 Aug 2018 14:31:53 -0400 (EDT) From: Alan Stern X-X-Sender: stern@netrider.rowland.org To: Guenter Roeck cc: Greg Kroah-Hartman , , Subject: Re: [PATCH] USB: OHCI: ohci-sm501: complete URBs in BH context In-Reply-To: <20180804191956.GA5639@roeck-us.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 4 Aug 2018, Guenter Roeck wrote: > On Sat, Aug 04, 2018 at 10:50:15AM -0400, Alan Stern wrote: > > On Fri, 3 Aug 2018, Guenter Roeck wrote: > > > > > Testing an USB drive connected to ohci-sm501 results in a large number > > > of runtime warnings. > > > > > > WARNING: CPU: 0 PID: 0 at ./include/linux/dma-mapping.h:541 > > > hcd_buffer_free+0x148/0x178 > > > Modules linked in: > > > > > > CPU: 0 PID: 0 Comm: swapper Not tainted 4.18.0-rc7-00014-g7ec386e4c991-dirty > > > PC is at hcd_buffer_free+0x148/0x178 > > > PR is at hcd_buffer_free+0x66/0x178 > > > PC : 8c26cbb0 SP : 8c481da8 SR : 400080f1 > > > TEA : c00c8fe0 > > > R0 : 000000f0 R1 : 000000f0 R2 : 8f9bb890 R3 : 00000000 > > > R4 : 8f9c8800 R5 : 00001004 R6 : b07c6000 R7 : 007c6000 > > > R8 : 00001004 R9 : 8f9bb814 R10 : 8c388104 R11 : 007c6000 > > > R12 : b07c6000 R13 : 8f875680 R14 : 00000000 > > > MACH: 000002fe MACL: 0000017c GBR : 00000000 PR : 8c26cace > > > > > > Call trace: > > > [<(ptrval)>] usb_hcd_unmap_urb_for_dma+0xf4/0x13c > > > [<(ptrval)>] arch_local_save_flags+0x0/0x8 > > > [<(ptrval)>] __usb_hcd_giveback_urb+0x2e/0xdc > > > [<(ptrval)>] arch_local_save_flags+0x0/0x8 > > > [<(ptrval)>] finish_urb+0x8a/0x164 > > > [<(ptrval)>] arch_local_save_flags+0x0/0x8 > > > [<(ptrval)>] printk+0x0/0x48 > > > [<(ptrval)>] ohci_work.part.11+0x150/0x41c > > > [<(ptrval)>] td_done.isra.4+0x0/0x11c > > > [<(ptrval)>] vprintk_default+0x14/0x20 > > > [<(ptrval)>] arch_local_save_flags+0x0/0x8 > > > [<(ptrval)>] ohci_irq+0x20c/0x314 > > > [<(ptrval)>] usb_hcd_irq+0x16/0x28 > > > > > > Code analysis shows that interrupts are indeed disabled in ohci_irq(). > > > Handle the situation by setting the HCD_BH flag in the ohci-sm501 driver. > > > With this flag set, urbs are released in a tasklet and not by the > > > interrupt handler. > > > > > > Fixes: f54aab6ebcecd ("usb: ohci-sm501 driver") > > > Signed-off-by: Guenter Roeck > > > > Unfortunately, one must not simply turn on this flag. Doing so will > > violate some of the documented requirements for scheduling of periodic > > transfers. Significantly deeper changes to the OHCI driver are > > necessary before the flag is set. > > > > Well, it was worth a try. Note that I did try to figure out if there are > any pitfalls when setting HCD_BH, but I didn't find anything. Reminds me > of Hitchhiker through the Galaxy for some reason. The interactions are pretty subtle, and the descriptions are hidden in the kerneldoc for usb_submit_urb and usb_unlink_urb. ehci-hcd, for example, required a number of non-obvious changes when it was converted to use HCD_BH. If anyone wants to write something similar for ohci-hcd I'll be happy to review it, but I don't want to write it myself. (Besides, speeding up the time spent in interrupt handling seems less urgent for OHCI, which runs much slower than EHCI and is not getting used very much in new hardware.) Another way to attack this problem would be to allow DMA unmapping in interrupt context. I have never understood why DMA mapping is okay with this but unmapping isn't. Alan Stern