Re: Fw: crash on x86_64 - mm related?

[Hugh Dickins <hugh@veritas.com>]

On Sun, 8 Jan 2006, Linus Torvalds wrote:
> 
> Code like that should use "set_page_dirty()", which does the appropriate 
> callbacks to the filesystem for that page. I wonder if the bug is simply 
> because the ST code just sets the dirty bit without telling anybody else 
> about it...

Yes, it should be using set_page_dirty_lock(), and that is already known
about (I have patches for this and similar sg.c, but the sg.c case is
tougher and not yet finished); but entirely irrelevant to Ryan's case.

Quite apart from the fact that he's doing backups to tape (not dirtying
the memory from this driver), you'll find that it even passes dirty 0
when reading into the memory (another bug; whereas sg.c conversely says
it's always dirtying when it isn't).  So there's no point in Ryan
fiddling with the SetPageDirty.

It's an intriguing problem because it's signature is so regular,
and I've spent many hours trying to work out how it might come about,
but unsuccessfully so far.  Your adjustment to the put_page_testzero
BUG_ON was a good idea, but it still hasn't shone a light.  I'm
keeping quiet until I find something useful to add.

Perhaps we just need a few more people to add sgl[i].page = NULL ;)

Hugh