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:
> > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/