Re: [PATCH 1/3] Preserve the dirty bit in init_page_buffers

[Eric W. Biederman]

Nick Piggin <nickpiggin@xxxxxxxxxxxx> writes:

>> Definitely, and it was a royal pain to trace the bug that this
>> caused.  An initial ramdisk having pieces disappear after mkfs
>> is called can look like the entire machine is dying.
>>
>> When we initialize the ramdisk by writing to /dev/ram0 usually in
>> init/do_mounts_rd.c we don't allocate buffer heads but we do set
>> the dirty bit, and the page is in the page cache.  So when we
>> later call getblk it reuses the same page and then calls
>> init_page_buffers.
>
> Hmm, the comment above grow_dev_buffers indicates this should
> not happen. But contrary to the comment, it doesn't go BUG
> unless you're attaching dirty buffers to a page with dirty
> buffers.
>
> I suspect this happens more frequently with rd.c, because unlike
> block_dev.c, it does not create dirty buffers in prepare_write.
> However it could still happen in block_dev.c via mmaped memory,
> as I said earlier.
>
> I'm not saying this patch 1/3 is wrong, but we would at least
> need to revise some comments. The grow_dev_buffers comment looks
> like one of Andrew's. Maybe he can shed some more light on this?

Good question.  It sounds like you are correct.

Either we need to fix those comments or find the root
cause for the need to call cancel_dirty_page in try_to_free_buffers
and fix that.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/