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. 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! > st.c did set pages dirty after reading before 2.6.0-test4. It disappeared > when code was rearranged and I don't have any notes about why. Possibly because of issues with hugetlb compound pages: David Gibson raised that issue recently with respect to access_process_vm (page[1].mapping is reused and crashes set_page_dirty), I'm thinking we don't want to add PageCompound tests all over, and have mailed Andrew separately for guidance on that. Hugh - : 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
