Received: by 10.223.164.221 with SMTP id h29csp174894wrb; Fri, 3 Nov 2017 07:22:27 -0700 (PDT) X-Google-Smtp-Source: ABhQp+S1Zefs3vgJjnpn2oFFBXgeudgk/oJEeUIlWlZCPPIu04peE+QxpRE/Qob2VHiYmg/6oVhp X-Received: by 10.101.78.10 with SMTP id r10mr7342179pgt.254.1509718947270; Fri, 03 Nov 2017 07:22:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509718947; cv=none; d=google.com; s=arc-20160816; b=KL7tUVMEgzmNgwHZlAK5rKcufRfzGkPie2qYULEB5+YCIpBLxFDl1YODBX+ztBYM7I Lhbuhj2VeBixdoiz9BIat2b2i/rZidSGIhuHv4fM5nibYJu2jRMLfE+4CwsRg27w8PfI yZAOhZ2u1WcPGZfNb7//rz6d2xPiSVQ3npCWf0TowfwR1TO4XNUobGf56QkeIXxBheYe RdX8JR545S2vf/3Lc5QiMNMow63Cwu2/5VnxC+HQERkMFxFaUjnDRBMhWjrWwm9mxtiL WuzHXztBJ3HIhpSBdtzJPYh8hxc+Pgw98Wo8ZqKwlHI7+LEu8oqKPIfsNQTTvonmdbAr U3BQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=uCxjAlw8IAEOzsup9VfFFn193s6lAZMYwMWyzKwLpwM=; b=l3rrCT9vHW98oXZQP/dmNKTGn+nKR6rV5b1K17/vE2ZKJnVwYxNKEv4uO2kGayK2GH VgCJnAWX0BmY3KpvsaD/BaodWjGLGkQpFHBG49fnKUe3coI0nw9QQDZY4gM2E+EbuH81 W0zH21x5yuBT0v+V18OUmgDncvkwRCoUMM2WKYudnUrH/wM+IkGocL0oLylfzn06Ly2W Vc22Gs0vHqKjIPKmoSNqs/cXjdeZ45e/zBmlDBaOhqe2SfaY4VSf90f30nLndiqzchzG 3BSsqWPKSP9WeXF6X7wdvbs7ysLF6RGdOJaKqEeDR4FbVPlICkyZYV+6hRGarrZLr7GZ WHzQ== 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 o12si4479178plg.24.2017.11.03.07.22.14; Fri, 03 Nov 2017 07:22:27 -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 S1754379AbdKCOVk (ORCPT + 95 others); Fri, 3 Nov 2017 10:21:40 -0400 Received: from webclient5.webclient5.de ([136.243.32.179]:40013 "EHLO webclient5.webclient5.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752312AbdKCOVU (ORCPT ); Fri, 3 Nov 2017 10:21:20 -0400 Received: from [10.1.2.4] (unknown [94.101.37.79]) by webclient5.webclient5.de (Postfix) with ESMTPSA id CBF4255832D5; Fri, 3 Nov 2017 15:21:17 +0100 (CET) Subject: Re: [PATCH] firewire-ohci: work around oversized DMA reads on JMicron controllers To: stefanr@s5r6.in-berlin.de Cc: Hector Martin , linux1394-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org References: <20171103112857.12426-1-marcan@marcan.st> From: Clemens Ladisch Message-ID: <554bac12-e021-2541-6812-ae9a4e0c96ba@ladisch.de> Date: Fri, 3 Nov 2017 15:21:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171103112857.12426-1-marcan@marcan.st> Content-Type: text/plain; charset=us-ascii Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at webclient5 X-Virus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hector Martin wrote: > At least some JMicron controllers issue buggy oversized DMA reads when > fetching context descriptors, always fetching 0x20 bytes at once for > descriptors which are only 0x10 bytes long. This is often harmless, but > can cause page faults on modern systems with IOMMUs: > > DMAR: [DMA Read] Request device [05:00.0] fault addr fff56000 [fault reason 06] PTE Read access is not set > firewire_ohci 0000:05:00.0: DMA context IT0 has stopped, error code: evt_descriptor_read > > This works around the problem by always leaving 0x10 padding bytes at > the end of descriptor buffer pages, which should be harmless to do > unconditionally for controllers in case others have the same behavior. > > Signed-off-by: Hector Martin Reviewed-by: Clemens Ladisch > --- > drivers/firewire/ohci.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c > index 8bf89267dc25..d731b413cb2c 100644 > --- a/drivers/firewire/ohci.c > +++ b/drivers/firewire/ohci.c > @@ -1130,7 +1130,13 @@ static int context_add_buffer(struct context *ctx) > return -ENOMEM; > > offset = (void *)&desc->buffer - (void *)desc; > - desc->buffer_size = PAGE_SIZE - offset; > + /* > + * Some controllers, like JMicron ones, always issue 0x20-byte DMA reads > + * for descriptors, even 0x10-byte ones. This can cause page faults when > + * an IOMMU is in use and the oversized read crosses a page boundary. > + * Work around this by always leaving at least 0x10 bytes of padding. > + */ > + desc->buffer_size = PAGE_SIZE - offset - 0x10; > desc->buffer_bus = bus_addr + offset; > desc->used = 0; > From 1583044637121646388@xxx Fri Nov 03 11:36:52 +0000 2017 X-GM-THRID: 1583044637121646388 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread