From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754831AbYKJJ7W (ORCPT ); Mon, 10 Nov 2008 04:59:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754200AbYKJJ7O (ORCPT ); Mon, 10 Nov 2008 04:59:14 -0500 Received: from aeryn.fluff.org.uk ([87.194.8.8]:58243 "EHLO kira.home.fluff.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754007AbYKJJ7N (ORCPT ); Mon, 10 Nov 2008 04:59:13 -0500 Date: Mon, 10 Nov 2008 09:58:37 +0000 From: Ben Dooks To: Henrique de Moraes Holschuh Cc: Ben Dooks , linux-kernel@vger.kernel.org, drzeus-mmc@drzeus.cx, sdhci-devel@list.drzeus.cx Subject: Re: [patch 6/7] SDHCI: Check DMA for overruns at end of transfer Message-ID: <20081110095837.GA18631@fluff.org.uk> References: <20081103200944.099353331@fluff.org.uk> <20081103201010.820070757@fluff.org.uk> <20081103211200.GA10721@khazad-dum.debian.net> <20081103211625.GG14806@trinity.fluff.org> <20081104012840.GA16742@khazad-dum.debian.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081104012840.GA16742@khazad-dum.debian.net> X-Disclaimer: These are my own opinions, so there! User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 03, 2008 at 11:28:40PM -0200, Henrique de Moraes Holschuh wrote: > On Mon, 03 Nov 2008, Ben Dooks wrote: > > On Mon, Nov 03, 2008 at 07:12:00PM -0200, Henrique de Moraes Holschuh wrote: > > > Maybe I didn't understand it right, but if the DMA controller could overrun > > > a buffer, don't you ALSO need to add defensive padding (i.e. increase the > > > buffer) to make sure nothing important gets overrun? > > > > This is only generated by problems elsewhere in the driver, such as > > getting the timeout clock wrong. It is here just as a precaution and > > as an aide to debugging, it should not trigger in normal circumstances. > > Then why is it just a WARN_ON, since you had a rogue DMA operation > overwriting unknown kernel memory? Seems like an outright BUG_ON to me. It is a problem, but it doesn't kill the entire system. We could print it at a higher level. The WARN_ON()/BUG_ON() where not appropriate, as we do not need a whole stack backtrace, and I belive the mmc block thread somehow seems to manage to keep running even with an OOPS. > > There is a seperate problem where the DMA buffer is passed from the stack > > which is, IIRC, a complete no-no under Linux. > > Can't say much on that. I just found it strange that something as damaging > as an overrun was only getting a WARN_ON and no defensive measure. If it is > not going to happen normally, it might not require a defensive buffer, but > once it happens, it looks like one must reboot ASAP from what you said... -- Ben (ben@fluff.org, http://www.fluff.org/) 'a smiley only costs 4 bytes'