Re: Fw: crash on x86_64 - mm related?

[Kai Makisara]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/