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 - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html