Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750988AbVLBTqo (ORCPT ); Fri, 2 Dec 2005 14:46:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750993AbVLBTqn (ORCPT ); Fri, 2 Dec 2005 14:46:43 -0500 Received: from fep01-0.kolumbus.fi ([193.229.0.41]:63410 "EHLO fep01-app.kolumbus.fi") by vger.kernel.org with ESMTP id S1750988AbVLBTqm (ORCPT ); Fri, 2 Dec 2005 14:46:42 -0500 Date: Fri, 2 Dec 2005 21:46:51 +0200 (EET) From: Kai Makisara X-X-Sender: makisara@kai.makisara.local To: Hugh Dickins cc: James Bottomley , Linus Torvalds , Ryan Richter , Andrew Morton , linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org Subject: Re: Fw: crash on x86_64 - mm related? In-Reply-To: Message-ID: References: <20051129092432.0f5742f0.akpm@osdl.org> <1133468882.5232.14.camel@mulgrave> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1795 Lines: 41 On Fri, 2 Dec 2005, Hugh Dickins wrote: > On Fri, 2 Dec 2005, Kai Makisara wrote: > > On Fri, 2 Dec 2005, Hugh Dickins wrote: > > I include at the end of this message the patch I sent to linux-scsi > > earlier. It should clarify what are the useful parts of the later patch. > > Thanks, yes. I'll leave out updating the verstr[], > I think that should be sent by you alone. > > > I think the release_buffering() call at the end of st_read must say 1. All > > returns use the same path (except the one returning -ERESTARTSYS). > > Okay, if you insist. Yes, all those returns pass that way, but if it > actually did some reading into the memory, it called read_tape, which > did the effective release_buffering immediately after st_do_scsi. > > But perhaps I'm misreading it, and even if not, someone will come > along and "correct" it later, or change things around and make my > not-dirty assumption wrong. > Your analysis is correct. It is not necessary or useful to use dirtied = 1 at the end of st_read(). It has been a long time since I introduced release_buffering() into st.c and I did not read all of the code now. > It's just that after seeing how sg.c is claiming to dirty even readonly > memory, I'm excessively averse to saying we've dirtied memory we haven't. > My hangup, I'll get over it! > Please don't. I have a very conservative attitude to these things: my priority is to make sure that the data is correct even if it is not the fastest code. I will happily let others point out when I am too conservative. -- Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/