| Message ID | 20220527025535.3953665-3-pasha.tatashin@soleen.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Allow to kexec with initramfs larger than 2G | expand |
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? Another concern is if 2G is enough. If we can foresee it might need be enlarged again in a near future, LONG_MAX certainly is not a good value, but a little bigger multiple of 2G can be better? > > Increase the size to 4G, and make it obvious by having a new macro > that specifies the maximum file size supported by kexec_file_load() > syscall: KEXEC_FILE_SIZE_MAX. > > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> > --- > kernel/kexec_file.c | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > index 8347fc158d2b..f00cf70d82b9 100644 > --- a/kernel/kexec_file.c > +++ b/kernel/kexec_file.c > @@ -31,6 +31,9 @@ > > static int kexec_calculate_store_digests(struct kimage *image); > > +/* Maximum size in bytes for kernel/initrd files. */ > +#define KEXEC_FILE_SIZE_MAX min_t(s64, 4LL << 30, SSIZE_MAX) > + > /* > * Currently this is the only default function that is exported as some > * architectures need it to do additional handlings. > @@ -223,11 +226,12 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd, > const char __user *cmdline_ptr, > unsigned long cmdline_len, unsigned flags) > { > - int ret; > + ssize_t ret; > void *ldata; > > ret = kernel_read_file_from_fd(kernel_fd, 0, &image->kernel_buf, > - INT_MAX, NULL, READING_KEXEC_IMAGE); > + KEXEC_FILE_SIZE_MAX, NULL, > + READING_KEXEC_IMAGE); > if (ret < 0) > return ret; > image->kernel_buf_len = ret; > @@ -247,7 +251,7 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd, > /* It is possible that there no initramfs is being loaded */ > if (!(flags & KEXEC_FILE_NO_INITRAMFS)) { > ret = kernel_read_file_from_fd(initrd_fd, 0, &image->initrd_buf, > - INT_MAX, NULL, > + KEXEC_FILE_SIZE_MAX, NULL, > READING_KEXEC_INITRAMFS); > if (ret < 0) > goto out; > -- > 2.36.1.124.g0e6072fb45-goog >
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. > > Another concern is if 2G is enough. If we can foresee it might need be > 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. Thanks, Pasha > > > > > Increase the size to 4G, and make it obvious by having a new macro > > that specifies the maximum file size supported by kexec_file_load() > > syscall: KEXEC_FILE_SIZE_MAX. > > > > Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> > > --- > > kernel/kexec_file.c | 10 +++++++--- > > 1 file changed, 7 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > > index 8347fc158d2b..f00cf70d82b9 100644 > > --- a/kernel/kexec_file.c > > +++ b/kernel/kexec_file.c > > @@ -31,6 +31,9 @@ > > > > static int kexec_calculate_store_digests(struct kimage *image); > > > > +/* Maximum size in bytes for kernel/initrd files. */ > > +#define KEXEC_FILE_SIZE_MAX min_t(s64, 4LL << 30, SSIZE_MAX) > > + > > /* > > * Currently this is the only default function that is exported as some > > * architectures need it to do additional handlings. > > @@ -223,11 +226,12 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd, > > const char __user *cmdline_ptr, > > unsigned long cmdline_len, unsigned flags) > > { > > - int ret; > > + ssize_t ret; > > void *ldata; > > > > ret = kernel_read_file_from_fd(kernel_fd, 0, &image->kernel_buf, > > - INT_MAX, NULL, READING_KEXEC_IMAGE); > > + KEXEC_FILE_SIZE_MAX, NULL, > > + READING_KEXEC_IMAGE); > > if (ret < 0) > > return ret; > > image->kernel_buf_len = ret; > > @@ -247,7 +251,7 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd, > > /* It is possible that there no initramfs is being loaded */ > > if (!(flags & KEXEC_FILE_NO_INITRAMFS)) { > > ret = kernel_read_file_from_fd(initrd_fd, 0, &image->initrd_buf, > > - INT_MAX, NULL, > > + KEXEC_FILE_SIZE_MAX, NULL, > > READING_KEXEC_INITRAMFS); > > if (ret < 0) > > goto out; > > -- > > 2.36.1.124.g0e6072fb45-goog > > >
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
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c index 8347fc158d2b..f00cf70d82b9 100644 --- a/kernel/kexec_file.c +++ b/kernel/kexec_file.c @@ -31,6 +31,9 @@ static int kexec_calculate_store_digests(struct kimage *image); +/* Maximum size in bytes for kernel/initrd files. */ +#define KEXEC_FILE_SIZE_MAX min_t(s64, 4LL << 30, SSIZE_MAX) + /* * Currently this is the only default function that is exported as some * architectures need it to do additional handlings. @@ -223,11 +226,12 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd, const char __user *cmdline_ptr, unsigned long cmdline_len, unsigned flags) { - int ret; + ssize_t ret; void *ldata; ret = kernel_read_file_from_fd(kernel_fd, 0, &image->kernel_buf, - INT_MAX, NULL, READING_KEXEC_IMAGE); + KEXEC_FILE_SIZE_MAX, NULL, + READING_KEXEC_IMAGE); if (ret < 0) return ret; image->kernel_buf_len = ret; @@ -247,7 +251,7 @@ kimage_file_prepare_segments(struct kimage *image, int kernel_fd, int initrd_fd, /* It is possible that there no initramfs is being loaded */ if (!(flags & KEXEC_FILE_NO_INITRAMFS)) { ret = kernel_read_file_from_fd(initrd_fd, 0, &image->initrd_buf, - INT_MAX, NULL, + KEXEC_FILE_SIZE_MAX, NULL, READING_KEXEC_INITRAMFS); if (ret < 0) goto out;
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. Increase the size to 4G, and make it obvious by having a new macro that specifies the maximum file size supported by kexec_file_load() syscall: KEXEC_FILE_SIZE_MAX. Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com> --- kernel/kexec_file.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-)