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

[ebiederm@xmission.com (Eric W. Biederman)]

Nick Piggin <nickpiggin@yahoo.com.au> writes:

> Eric W. Biederman wrote:
>> The problem:  When we are trying to free buffers try_to_free_buffers
>> will look at ramdisk pages with clean buffer heads and remove the
>> dirty bit from the page.  Resulting in ramdisk pages with data that
>> get removed from the page cache.  Ouch!
>>
>> Buffer heads appear on ramdisk pages when a filesystem calls getblk,
>> which through a series of function calls eventually calls
>> init_page_buffers.
>>
>> So to fix the mismatch between buffer head state and page state this
>> patch modifies init_page_buffers to transfer the dirty bit from the
>> page to the buffer heads like we currently do for the uptodate bit.
>
> Ouch indeed!
>
> But can we ever have a dirty page at init_page_buffers-time?

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.

> I would have thought we can fix this simply by removing the
> broken ramdisk_set_page_dirty (as far as the comment goes, we
> set CAP_NO_ACCT_DIRTY anyway, so the normal set_page_dirty
> should handle everything properly, no?).

No.  I don't know where accounting comes into play.  I didn't
trace that path.  But if we have a non-dirty ramdisk page with
buffers (basically a hole in the middle or at the end of the ramdisk).
We need to set the buffer dirty bits when we write to it.

So I don't see how it would make sense to reuse the generic
set_page_dirty, and handling all of the logic in set_page_dirty
to dirty the buffer heads seemed to have made the most sense.

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