Eric W. Biederman wrote:
Nick Piggin <[email protected]> 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.
Hmm, so this would be a problem for block_dev.c as well, then?
Because it would be possible to have a dirty block dev page
have its buffers reclaimed and then reinitialised via
init_page_buffers, AFAIKS.
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.
Accounting is done in set_page_dirty.
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.
That's what the generic set_page_dirty does. What I want to know
is why *doesn't* it make sense to reuse the generic set_page_dirty?
Unless there is a good reason, then reusing is better than writing
your own.
--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
