From: Phillip Susi <psusi@cfl.rr.com>
To: Peter Bier <peter_bier@web.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: miniroot ramdisk corruption during intense memory usage
Date: Wed, 28 Mar 2007 10:50:18 -0400 [thread overview]
Message-ID: <460A80AA.8050505@cfl.rr.com> (raw)
In-Reply-To: <909027047@web.de>
Peter Bier wrote:
> The following sympthom occured in a variant of the Knoppix-like linux appliance.
>
> I get a corrupted miniroot ramdisk filesystem under kernel version 2.6.19.1 under intense memory usage during early startup of the system.
>
> In the course of a lengthy investigation of this behavior, I found out that the memory pages containing the miniroot ramdisk are freed during the initial installation
>
> process due to a memory shortage. It turned out, that shrink_active_list() calls pagevec_strip(), which in turn calls try_to_release_page() which finally calls try_to_free_buffers() which drops the corresponding buffers; if this succeeds, it seems to cause the page to become freed later.
>
> This causes pointers of indirect blocks of the filesystem of the miniroot ramdisk to be replaced by zero-filled pages later in the the system's history.
>
> I fixed this by adding a new flag PG_ramdisk in the include file page-flags.h, setting the flag during ramdisk loading in ramdisk_commit_write() and checking for the flag in try_to_free_buffers() and retruning 0 as result immediately without freeing the buffers.
>
> I am not aware if that is the adequate way to solve the problem or if there is a solution that requires fewer and more localized changes of the system, avoiding to give the ramdisk pages a specific treatment
>
>
>
>
>
> I did not observe this problem prior to kernel version 2.6.19.1, but I'm not sure whether ths was simply caused by coincidental circumstances during startup.
The ramdisk driver already marks the pages as "do not discard". Maybe
you should investigate why that is no longer being respected?
prev parent reply other threads:[~2007-03-28 14:56 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-28 12:05 miniroot ramdisk corruption during intense memory usage Peter Bier
2007-03-28 14:50 ` Phillip Susi [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=460A80AA.8050505@cfl.rr.com \
--to=psusi@cfl.rr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peter_bier@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox