From: "H. Peter Anvin" <hpa@zytor.com>
To: Yinghai Lu <yinghai@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@elte.hu>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
"Daniel M. Weeks" <dan@danweeks.net>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] initramfs: Support initrd that is bigger then 2G.
Date: Thu, 19 Jun 2014 21:29:43 -0700 [thread overview]
Message-ID: <53A3B8B7.70806@zytor.com> (raw)
In-Reply-To: <1403230336-10444-1-git-send-email-yinghai@kernel.org>
On 06/19/2014 07:12 PM, Yinghai Lu wrote:
> When initrd (compressed or not) is used, kernel report data corrupted
> with /dev/ram0.
>
> The root cause:
> During initramfs checking, if it is initrd, it will be transferred to
> /initrd.image with sys_write.
> sys_write only support 2G-4K write, so if the initrd ram is more than
> that, /initrd.image will not complete at all.
>
> Add local sys_write_large to loop calling sys_write to workaround the
> problem.
>
> Also need to use that in write_buffer path for cpio that have file is
> more than file.
That sentence doesn't make sense.
> At the same time, we don't need to worry about sys_read/sys_write in
> do_mounts_rd.c::crd_load. As decompressor will have fill/flush that
> means it will allocate buffer and buffer is smaller than 2G.
>
> Test with uncompressed initrd, and compressed with gz, bz2, lzma,xz,
> lzop.
>
> Signed-off-by: Yinghai Lu <yinghai@kernel.org>
I would call this function xwrite(), which is usually called in userspace.
It would be nice in order to support very large initrd/initramfs, to
free the memory as it becomes available instead of requiring two copies
of the data in memory at the same time.
Otherwise,
Acked-by: H. Peter Anvin <hpa@zytor.com>
-hpa
next prev parent reply other threads:[~2014-06-20 4:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-20 2:12 [PATCH] initramfs: Support initrd that is bigger then 2G Yinghai Lu
2014-06-20 4:29 ` H. Peter Anvin [this message]
2014-06-20 5:02 ` Yinghai Lu
2014-06-20 5:07 ` H. Peter Anvin
2014-06-20 16:03 ` Yinghai Lu
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=53A3B8B7.70806@zytor.com \
--to=hpa@zytor.com \
--cc=akpm@linux-foundation.org \
--cc=dan@danweeks.net \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=yinghai@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.