Re: Fw: crash on x86_64 - mm related?

[Hugh Dickins <hugh@veritas.com>]

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
-
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/