From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751343AbVLDJ3N (ORCPT ); Sun, 4 Dec 2005 04:29:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751342AbVLDJ3N (ORCPT ); Sun, 4 Dec 2005 04:29:13 -0500 Received: from fep30-0.kolumbus.fi ([193.229.0.32]:14144 "EHLO fep30-app.kolumbus.fi") by vger.kernel.org with ESMTP id S1751340AbVLDJ3M (ORCPT ); Sun, 4 Dec 2005 04:29:12 -0500 Date: Sun, 4 Dec 2005 11:29:19 +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 On Fri, 2 Dec 2005, Hugh Dickins wrote: > On Fri, 2 Dec 2005, Kai Makisara wrote: > > On Fri, 2 Dec 2005, Hugh Dickins wrote: > > > > > 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. > > I'm not certain which way you're directing me now: a conservative > attitude suggests we play safe at the end of st_read, by saying we might > somehow have dirtied memory there, perhaps if someone changes sequence. > You should do what you think is best. One of the driver maintainers tasks is to look at the changes and ask questions if there is something suspicious. I asked and you pointed out that this time my concern was not valid. During this discussion you have mentioned good arguments favouring both choices. Peformancewise we are talking about a rather theoretical issue: in a production server this issue might be relevant a few times a year. My current suggestion is to use the value 1 (to minimise the possibility of bugs due to future changes). If you want, you can add a comment saying that using 1 is not strictly necessary with the current design. > As I presently, incompletely have it, to maintain more similarity with > sg.c, I've actually moved away from "dirtied" to "rw" READ or WRITE, > and it will look odd to put WRITE at the end of st_read. > It might be best to use naming that does not bind the purpose of the parameter to any "abstract" (i.e., read or write) activity when the purpose is to tell the function that the buffer contents may have been altered. > I'm giving up for the evening, and probably won't have a chance to do > more until Sunday - the PageCompound issue still under discussion too. > > Hugh > -- Kai