All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baoquan He <bhe@redhat.com>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Sasha Levin <sashal@kernel.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	rburanyi@google.com, Greg Thelen <gthelen@google.com>,
	viro@zeniv.linux.org.uk,
	kexec mailing list <kexec@lists.infradead.org>,
	linux-fsdevel@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] kexec_file: Increase maximum file size to 4G
Date: Wed, 8 Jun 2022 08:28:31 +0800	[thread overview]
Message-ID: <Yp/tL5F7TFdwk8Sj@MiWiFi-R3L-srv> (raw)
In-Reply-To: <CA+CK2bC5U5j1xkZKuOETANo1=PPpbJn2mKYOa2fK1GLFib0ibw@mail.gmail.com>

On 06/07/22 at 12:02pm, Pasha Tatashin wrote:
> On Sun, Jun 5, 2022 at 10:56 PM Baoquan He <bhe@redhat.com> wrote:
> >
> > On 05/27/22 at 02:55am, Pasha Tatashin wrote:
> > > In some case initrd can be large. For example, it could be a netboot
> > > image loaded by u-root, that is kexec'ing into it.
> > >
> > > The maximum size of initrd is arbitrary set to 2G. Also, the limit is
> > > not very obvious because it is hidden behind a generic INT_MAX macro.
> > >
> > > Theoretically, we could make it LONG_MAX, but it is safer to keep it
> > > sane, and just increase it to 4G.
> >
> > Do we need to care about 32bit system where initramfs could be larger
> > than 2G? On 32bit system, SSIZE_MAX is still 2G, right?
> 
> Yes, on 32-bit SSIZE_MAX is still 2G, so we are safe to keep 32-bit
> systems run exactly as today.
> 
> #define KEXEC_FILE_SIZE_MAX    min_t(s64, 4LL << 30, SSIZE_MAX)
> Is meant to protect against running over the 2G limit on 32-bit systems.

OK. In fact I was wrong. I386 doesn't have kexec_file loading support.

> 
> >
> > Another concern is if 2G is enough. If we can foresee it might need be
                          ~~ 4G, typo
> > enlarged again in a near future, LONG_MAX certainly is not a good
> > value, but a little bigger multiple of 2G can be better?
> 
> This little series enables increasing the max value above 2G, but
> still keeps it within a sane size i.e. 4G, If 4G seems too small, I
> can change it to 8G or 16G instead of 4G.

Just raising to try to discuss if 4G is enough. I have no knowledge
about how much is enough, and we don't need to guess, if you think 4G is
enough according to information you get, that's OK. We can wait a while
to see if other people have words about the vlaue. If no, then 4G is a
good one.

Thanks
Baoquan


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: Sasha Levin <sashal@kernel.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	rburanyi@google.com, Greg Thelen <gthelen@google.com>,
	viro@zeniv.linux.org.uk,
	kexec mailing list <kexec@lists.infradead.org>,
	linux-fsdevel@vger.kernel.org,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/2] kexec_file: Increase maximum file size to 4G
Date: Wed, 8 Jun 2022 08:28:31 +0800	[thread overview]
Message-ID: <Yp/tL5F7TFdwk8Sj@MiWiFi-R3L-srv> (raw)
In-Reply-To: <CA+CK2bC5U5j1xkZKuOETANo1=PPpbJn2mKYOa2fK1GLFib0ibw@mail.gmail.com>

On 06/07/22 at 12:02pm, Pasha Tatashin wrote:
> On Sun, Jun 5, 2022 at 10:56 PM Baoquan He <bhe@redhat.com> wrote:
> >
> > On 05/27/22 at 02:55am, Pasha Tatashin wrote:
> > > In some case initrd can be large. For example, it could be a netboot
> > > image loaded by u-root, that is kexec'ing into it.
> > >
> > > The maximum size of initrd is arbitrary set to 2G. Also, the limit is
> > > not very obvious because it is hidden behind a generic INT_MAX macro.
> > >
> > > Theoretically, we could make it LONG_MAX, but it is safer to keep it
> > > sane, and just increase it to 4G.
> >
> > Do we need to care about 32bit system where initramfs could be larger
> > than 2G? On 32bit system, SSIZE_MAX is still 2G, right?
> 
> Yes, on 32-bit SSIZE_MAX is still 2G, so we are safe to keep 32-bit
> systems run exactly as today.
> 
> #define KEXEC_FILE_SIZE_MAX    min_t(s64, 4LL << 30, SSIZE_MAX)
> Is meant to protect against running over the 2G limit on 32-bit systems.

OK. In fact I was wrong. I386 doesn't have kexec_file loading support.

> 
> >
> > Another concern is if 2G is enough. If we can foresee it might need be
                          ~~ 4G, typo
> > enlarged again in a near future, LONG_MAX certainly is not a good
> > value, but a little bigger multiple of 2G can be better?
> 
> This little series enables increasing the max value above 2G, but
> still keeps it within a sane size i.e. 4G, If 4G seems too small, I
> can change it to 8G or 16G instead of 4G.

Just raising to try to discuss if 4G is enough. I have no knowledge
about how much is enough, and we don't need to guess, if you think 4G is
enough according to information you get, that's OK. We can wait a while
to see if other people have words about the vlaue. If no, then 4G is a
good one.

Thanks
Baoquan


  reply	other threads:[~2022-06-08  0:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-27  2:55 [PATCH v2 0/2] Allow to kexec with initramfs larger than 2G Pasha Tatashin
2022-05-27  2:55 ` Pasha Tatashin
2022-05-27  2:55 ` [PATCH v2 1/2] fs/kernel_read_file: Allow to read files up-to ssize_t Pasha Tatashin
2022-05-27  2:55   ` Pasha Tatashin
2022-06-06  2:45   ` Baoquan He
2022-06-06  2:45     ` Baoquan He
2022-06-07 15:52     ` Pasha Tatashin
2022-06-07 15:52       ` Pasha Tatashin
2022-06-08  0:57       ` Baoquan He
2022-06-08  0:57         ` Baoquan He
2022-06-08  0:58   ` Baoquan He
2022-06-08  0:58     ` Baoquan He
2022-05-27  2:55 ` [PATCH v2 2/2] kexec_file: Increase maximum file size to 4G Pasha Tatashin
2022-05-27  2:55   ` Pasha Tatashin
2022-06-06  2:56   ` Baoquan He
2022-06-06  2:56     ` Baoquan He
2022-06-07 16:02     ` Pasha Tatashin
2022-06-07 16:02       ` Pasha Tatashin
2022-06-08  0:28       ` Baoquan He [this message]
2022-06-08  0:28         ` Baoquan He

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=Yp/tL5F7TFdwk8Sj@MiWiFi-R3L-srv \
    --to=bhe@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=gthelen@google.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=rburanyi@google.com \
    --cc=sashal@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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.