Messages in this thread | | | Date | Fri, 2 Dec 2005 21:46:51 +0200 (EET) | From | Kai Makisara <> | Subject | Re: Fw: crash on x86_64 - mm related? |
| |
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/
| |