Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4511726imm; Fri, 18 May 2018 06:23:51 -0700 (PDT) X-Google-Smtp-Source: AB8JxZozndlLO+1nd+e5tR0dzkbptmydOAJ1pZ5Vd0oGvzjJIR7QfRbW6We7ysVc9+wX2Fi2sZc8 X-Received: by 2002:a62:32c6:: with SMTP id y189-v6mr9381467pfy.241.1526649831100; Fri, 18 May 2018 06:23:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526649831; cv=none; d=google.com; s=arc-20160816; b=sUvztnMmv/7xMB4a6t3Bcd0BOD5nJMcM3EAEK+XnA+i++GaHIx133cbjJWnEleEBP9 A17TuKfxuN4P+ceHvviA+r75qm/Xa6kS9KSDkSp7WZZE1AG03EQ28pwqz48QCvFXbVPw dE72PWlypqFdaOjIB4zF6L9YEtWW8o0dCvDDPLclxGdhxpIWpEH5ckyqcv7z0UKs57hg 33ayHgN6ArQpYH8DZkfx6dosLFtSk+od5OV05RNaOTu0xKUZGSoF955raxLCp7FG5tT5 OjBrSFxqnQXaV/wkjc+5feF+s7r5QqjZMdg+bnoUqJsNaYbX0FV9sAHaJLLlaWCiWJmQ c0Bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=NQ3aAM1ebdB6dANrlKPQAlovXGo0745IbfAai2YYAEw=; b=OwYU7nFme8tnYtg9WUfNuffI7pmk4SN3epVlbNc8p5oMnnxC2TWwc8KP9Yb+KF2uYD W0cqP5JDB96WQWA/KWAOs3CNQwLKI97P/bOnlHmcvhnOMRcJ8ggsn7YdqTbHdJ+h9Vm5 QZqj7qlJkgszT5O03RYvzJvuroL6xKVDbzLJ/9NW/lFqBK0TAkEkQVqapYHklVpVEB2x NTlLMaRc+S4sZP9nn9ewB/G5yf6nIrYM1PmhRipRKrH81QV/6PcfSRAEGziXVeNVYOQZ PPu9dtEPy2tsxuDbLGVLZpEHG/x2Au7cdGdHoeoHWfldgmgdkgCU2LxgrEbMHu4SyxHb 2rCQ== 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 i13-v6si2985828pgn.83.2018.05.18.06.23.36; Fri, 18 May 2018 06:23:51 -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 S1752366AbeERNWx (ORCPT + 99 others); Fri, 18 May 2018 09:22:53 -0400 Received: from verein.lst.de ([213.95.11.211]:59129 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752223AbeERNWt (ORCPT ); Fri, 18 May 2018 09:22:49 -0400 Received: by newverein.lst.de (Postfix, from userid 2407) id 7A0992BD7C; Fri, 18 May 2018 15:27:31 +0200 (CEST) Date: Fri, 18 May 2018 15:27:31 +0200 From: "hch@lst.de" To: Alexey Brodkin Cc: "hch@lst.de" , "deanbo422@gmail.com" , "linux-sh@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "nios2-dev@lists.rocketboards.org" , "linux-xtensa@linux-xtensa.org" , "linux-m68k@lists.linux-m68k.org" , "linux-alpha@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" , "iommu@lists.linux-foundation.org" , "green.hu@gmail.com" , "openrisc@lists.librecores.org" , "linux-arm-kernel@lists.infradead.org" , "monstr@monstr.eu" , "linux-parisc@vger.kernel.org" , "linux-c6x-dev@linux-c6x.org" , "linux-arch@vger.kernel.org" , "sparclinux@vger.kernel.org" Subject: Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation Message-ID: <20180518132731.GA31125@lst.de> References: <20180511075945.16548-1-hch@lst.de> <20180511075945.16548-3-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 18, 2018 at 01:03:46PM +0000, Alexey Brodkin wrote: > Note mmc_get_dma_dir() is just "data->flags & MMC_DATA_WRITE ? DMA_TO_DEVICE : DMA_FROM_DEVICE". > I.e. if we're preparing for sending data dma_noncoherent_map_sg() will have DMA_TO_DEVICE which > is quite OK for passing to dma_noncoherent_sync_sg_for_device() but in case of reading we'll have > DMA_FROM_DEVICE which we'll pass to dma_noncoherent_sync_sg_for_device() in dma_noncoherent_map_sg(). > > I'd say this is not entirely correct because IMHO arch_sync_dma_for_cpu() is supposed to only be used > in case of DMA_FROM_DEVICE and arch_sync_dma_for_device() only in case of DMA_TO_DEVICE. arc overrides the dir paramter of the dma_sync_single_for_device/ dma_sync_single_for_cpu calls. My patches dropped that, and I have restored that, and audit for the other architectures is pending. That being said the existing arc code still looks rather odd as it didn't do the same thing for the scatterlist versions of the calls. I've thrown in a few patches into my new tree to make the sg versions make the normal calls, and to clean up the area a bit. > You seem to lost an offset in the page so if we happen to have a buffer not aligned to > a page boundary then we were obviously corrupting data outside our data :) Oops! Thank you for all the debugging!