Messages in this thread | | | Date | Wed, 11 Oct 2006 21:36:22 -0500 | From | Eric Sandeen <> | Subject | Re: 2.6.18 ext3 panic. |
| |
Badari Pulavarty wrote:
> Here is what I think is happening.. > > journal_unmap_buffer() - cleaned the buffer, since its outside EOF, but > its a part of the same page. So it remained on the page->buffers > list. (at this time its not part of any transaction). > > Then, ordererd_commit_write() called journal_dirty_data() and we added > all these buffers to BJ_SyncData list. (at this time buffer is clean - > not dirty). > > Now msync() called __set_page_dirty_buffers() and dirtied *all* the > buffers attached to this page. > > journal_submit_data_buffers() got around to this buffer and tried to > submit the buffer...
This seems about right, but one thing bothers me in the traces; it seems like there is some locking that is missing. In http://people.redhat.com/esandeen/traces/eric_ext3_oops1.txt for example, it looks like journal_dirty_data gets started, but then the buffer_head is acted on by journal_unmap_buffer, which decides this buffer is part of the running transaction, past EOF, and clears mapped, dirty, etc. Then journal_dirty_data picks up again, decides that the buffer is not on the right list (now BJ_None) and puts it back on BJ_SyncData. Then it gets picked up by journal_submit_data_buffers and submitted, and oops.
Talking with Stephen, it seemed like the page lock should synchronize these threads, but I've found that we can get to journal_dirty_data acting on the buffer heads w/o having the page locked...
I'm still digging, and, er, grasping at straws here... Am I off base?
-Eric
> Andrew is right - only option for us to check the filesize in the > write out path and skip the buffers beyond EOF. > > Thanks, > Badari >
- 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/
| |