On Thu, 31 May 2007 05:56:33 -0600 [EMAIL PROTECTED] (Eric W. Biederman) wrote:
> >> I suspect that is a pretty rare case but it does indeed seem to exist
> >> as a problem.
> >
> > I think so too. But either we have some misunderstanding of the
> > codepaths involved, or the author of the comment
Nick Piggin <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>
>>> However we
>>>could still set_page_dirty of a block device page without buffers
>>>via an mmap.
>>
>>
>> After the page is made dirty via mmap we have:
>> sys_write -> ... -> block_p
Nick Piggin <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>
>>> However we
>>>could still set_page_dirty of a block device page without buffers
>>>via an mmap.
>>
>>
>> After the page is made dirty via mmap we have:
>> sys_write -> ... -> block_p
Eric W. Biederman wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
However we
could still set_page_dirty of a block device page without buffers
via an mmap.
After the page is made dirty via mmap we have:
sys_write -> ... -> block_prepare_write -> ... -> create_empty_buffers.
Yep, that's wha
Nick Piggin <[EMAIL PROTECTED]> writes:
> Nick Piggin wrote:
>> Eric W. Biederman wrote:
>
>>> 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
>>
Nick Piggin <[EMAIL PROTECTED]> 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 i
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_di
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
Nick Piggin wrote:
Eric W. Biederman wrote:
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
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
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
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 ramdi
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
13 matches
Mail list logo
