From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adrian Hunter Subject: Re: [PATCH V13 07/10] mmc: block: blk-mq: Add support for direct completion Date: Thu, 9 Nov 2017 17:33:03 +0200 Message-ID: <44da3008-8dfd-01e4-39c1-15df20cef0e2@intel.com> References: <1509715220-31885-1-git-send-email-adrian.hunter@intel.com> <1509715220-31885-8-git-send-email-adrian.hunter@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org To: Linus Walleij Cc: Ulf Hansson , linux-mmc , linux-block , linux-kernel , Bough Chen , Alex Lemberg , Mateusz Nowak , Yuliy Izrailov , Jaehoon Chung , Dong Aisheng , Das Asutosh , Zhangfei Gao , Sahitya Tummala , Harjani Ritesh , Venu Byravarasu , Shawn Lin , Christoph Hellwig List-Id: linux-mmc@vger.kernel.org On 09/11/17 14:34, Linus Walleij wrote: > On Thu, Nov 9, 2017 at 8:27 AM, Adrian Hunter wrote: >> On 08/11/17 11:28, Linus Walleij wrote: >>> On Fri, Nov 3, 2017 at 2:20 PM, Adrian Hunter wrote: >>> >>>> For blk-mq, add support for completing requests directly in the ->done >>>> callback. That means that error handling and urgent background operations >>>> must be handled by recovery_work in that case. >>>> >>>> Signed-off-by: Adrian Hunter >>> >>> I tried enabling this on my MMC host (mmci) but I got weird >>> DMA error messages when I did. >>> >>> I guess this has not been tested on a non-DMA-coherent >>> system? >> >> I don't see what DMA-coherence has to do with anything. >> >> Possibilities: >> - DMA unmapping doesn't work in an atomic context >> - requests' DMA operations have to be synchronized with each other > > So since MMCI need the post_req() hook called with > an error code to properly tear down any DMA operations, > I was worried that maybe your error path is not doing this > (passing an error code or calling in the right order). > > I had a bunch of fallouts in my own patch set relating > to that. > >>> I think I might be seeing this because the .pre and .post >>> callbacks need to be strictly sequenced, and this is >>> maybe not taken into account here? >> >> I looked at mmci but that did not seem to be the case. >> >>> Isn't there as risk >>> that the .post callback of the next request is called before >>> the .post callback of the previous request has returned >>> for example? >> >> Of course, the requests are treated as independent. If the separate DMA >> operations require synchronization, that is for the host driver to fix. > > They are treated as independent by the block layer but > it is the subsystems duty to serialize them for the hardware, > > MMCI strictly requires that pre/post hooks per request > happen in the right order, so if you have prepared a second > request after submitting the first, and the first fails, you have > to back out by unpreparing the second one before unpreparing > the first. It is also the only host driver requireing to be passed > an error code in the last parameter to the post hook in > order to work properly. > > I think your patch set handles that nicely though, because I > haven't seen any errors, it's just when we do this direct > completion I see problems. If a request gets an error, then we always do the post_req before starting another request, so the driver can assume that the first request finished successfully if it is asked to do post_req on the second request. So the driver does have enough information to keep the DMA unmapping in order if necessary.