Nick Piggin <[EMAIL PROTECTED]> writes: > Eric W. Biederman wrote: >> Nick Piggin <[EMAIL PROTECTED]> writes: > >>>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.
Yes. What I meant was I had not looked at the implications of accounting, so I had not looked to see if I could use a generic set_dirty_page. I only got as far as recognizing that __set_page_dirty_no_writeback as not the appropriate function to use because we need to handle buffer heads. >> 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. I did not look at that part in detail. I only realized ramdisk_set_dirty_page needed to be modified upon a final review of my code, as it was not a case I actually hit. Just skimming through it again quickly I don't see a reason at this point to preserve a separate set_dirty_page for the ramdisk code. Eric - 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/
