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=-0.7 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 528FEC35666 for ; Sun, 23 Feb 2020 12:10:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2545820656 for ; Sun, 23 Feb 2020 12:10:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726592AbgBWMKP (ORCPT ); Sun, 23 Feb 2020 07:10:15 -0500 Received: from funyu.konbu.org ([51.15.241.64]:49500 "EHLO funyu.konbu.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726023AbgBWMKP (ORCPT ); Sun, 23 Feb 2020 07:10:15 -0500 Received: from tungsten (237.203.49.163.rev.vmobile.jp [163.49.203.237]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by funyu.konbu.org (Postfix) with ESMTPSA id 997CE28096F; Sun, 23 Feb 2020 12:10:09 +0000 (UTC) Date: Sun, 23 Feb 2020 21:10:04 +0900 From: Boris ARZUR To: Antti =?iso-8859-1?Q?Sepp=E4l=E4?= Cc: Guenter Roeck , linux-usb@vger.kernel.org, Greg Kroah-Hartman , Minas Harutyunyan , William Wu , Dmitry Torokhov , Douglas Anderson Subject: Re: [PATCH] usb: dwc2: extend treatment for incomplete transfer Message-ID: <20200223121004.GA21618@tungsten> References: <20200210213906.GA24079@roeck-us.net> <20200211054953.GA2401@tungsten> <20200211161522.GA1894@roeck-us.net> <20200215053647.GA10345@tungsten> <20200219211056.GA829@roeck-us.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-usb-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-usb@vger.kernel.org Hi Antti, >we should be aligning the data[0] pointer inside the struct instead. I believe you are correct. Now, I checked to see at runtime if temp->data was aligned and it was. I cannot tell you why :) That code is copy-paste from the tegra-ehci driver. >with the alignment hacks altogether and hit the issue with a heavier I feel bad about the alignment hacks as well, and would like the original allocation from the URB thing to be aligned... no additional kmalloc, no memcpy. Is there a reason why we shouldn't try to fix that? >pointer are separate and no corruptions should occur. The corruptions themselves are bad, and should be cured. Thanks, Boris. Antti Seppälä wrote: >Hi Guenter, > >On Wed, 19 Feb 2020 at 23:11, Guenter Roeck wrote: >> >> Yes, those patches didn't address the core problem. Can you test with the >> attached two patches ? >> >> Thanks, >> Guenter > >I took a look at your patch (usb: dwc2: Simplify DMA alignment code) >and I don't believe it is correct. > >The patch re-introduces the dma_aligned_buffer struct and takes some >care to align the beginning of the struct to dma cache lines. However >we should be aligning the data[0] pointer inside the struct instead. >With the code in the patch data[0] gets pushed to be at an offset from >the alignment by kmalloc_ptr and old_xfer_buffer pointers. In other >words data[0] is now not aligned to dma cache boundaries. > >Reviewing the code got me thinking that what if we stopped playing >with the alignment hacks altogether and hit the issue with a heavier >hammer instead? Attached you can find a new patch that introduces a >list to keep track of the allocations. The code then looks up the >entry from the list when it is time to restore the original pointer. >This way the allocations for the aligned dma area and the original >pointer are separate and no corruptions should occur. > >Thoughts, comments? I should note that the patch has received only >light testing and not very thorough thinking. I can prepare a proper >patch to be sent inline if the idea seems worth exploring further. > >-- >Antti