All of lore.kernel.org
 help / color / mirror / Atom feed
From: Feng Tang <feng.tang@intel.com>
To: Nick Terrell <terrelln@fb.com>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>,
	X86 ML <x86@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	kernel test robot <oliver.sang@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Possible bug for ZSTD kernel decompressing
Date: Wed, 2 Feb 2022 13:07:27 +0800	[thread overview]
Message-ID: <20220202050727.GA19004@shbuild999.sh.intel.com> (raw)
In-Reply-To: <682F137E-25D6-43F7-88FC-D8C7ECE4517B@fb.com>

Hi Nick,

On Mon, Jan 31, 2022 at 08:31:10PM +0000, Nick Terrell wrote:
> 
> 
> > On Jan 27, 2022, at 8:53 PM, Feng Tang <feng.tang@intel.com> wrote:
> > 
> > Hi All,
> > 
> > Recently 0Day reported a 32bit i386 kernel decompression failure for my
> > patch [1], which essentially increase the kernel data section's size
> > from 19MB to 53MB, with error message:
> > 
> > 	early console in setup code
> > 	early console in extract_kernel
> > 	input_data: 0x05077079
> > 	input_len: 0x00f8a633
> > 	output: 0x01000000
> > 	output_len: 0x045c4328
> > 	kernel_total_size: 0x05040000
> > 	needed_size: 0x05040000
> > 
> > 	Decompressing Linux... 
> > 
> > 	ZSTD-compressed data is corrupt
> > 
> > 	 -- System haltedBUG: kernel hang in boot stage
> > 
> > From debug, it is likely a problem of ZSTD decompression code, as when I
> > reverted my patch and  hacked to increase the size of kernel data
> > section by 32MB, the same error will happen.
> > 
> > Some other hints are:
> > * same i386 config with lz4 and xz algo can boot
> > * X86_64 + zstd also boots fine
> > 
> > This could be reproduced by qemu cmd:
> > 
> > qemu-system-i386 -machine pc -cpu host -enable-kvm -kernel bzImage -m 2048m -smp 4 -serial stdio  --append "earlyprintk=ttyS0,115200 console=ttyS0,115200"
> > 
> > i386 kernel config is attached, and the debug patch as below:
> > ---
> > diff --git a/init/main.c b/init/main.c
> > index 767ee2672176..873f40ddf96e 100644
> > --- a/init/main.c
> > +++ b/init/main.c
> > @@ -162,6 +162,10 @@ static size_t initargs_offs;
> > static char *execute_command;
> > static char *ramdisk_execute_command = "/init";
> > 
> > +#define DT_SIZE		8192000
> > +static unsigned long tbuf[DT_SIZE] = { 1, 2, 3, 4, };
> > +
> > /*
> >  * Used to generate warnings if static_key manipulation functions are used
> >  * before jump_label_init is called.
> > @@ -690,6 +694,11 @@ noinline void __ref rest_init(void)
> > 	struct task_struct *tsk;
> > 	int pid;
> > 
> > +	unsigned long i, j;
> > +	for (i = 0; i < DT_SIZE; i++)
> > +		j += tbuf[i];
> > +	printk("j = 0x%x\n", j);
> > +
> > 	rcu_scheduler_starting();
> > 	/*
> > 	 * We need to spawn init first so that it obtains pid 1, however
> > 
> > Please let me know if you need more info.
> > 
> > [1.] https://lore.kernel.org/lkml/1627456900-42743-1-git-send-email-feng.tang@intel.com/ 
> 
> I've been unable to reproduce this issue using the provided patch + config based on
> Linux v5.17-rc2.
> 
> What version of Linux are you testing on? Zstd was updated in v5.16, so if you're not
> testing on v5.16 or later, can you please re-test on v5.17-rc2?
 
The original report I got is against commit 8cd7c588decf 
"mm/vmscan: throttle reclaim until some writeback completes if congested"
which is post 5.15.

I just retested and the issue can _not_ be reproduced against 5.17-rc2.
Thanks for the check and fix, and sorry for not trying latest kernel.

- Feng

      reply	other threads:[~2022-02-02  5:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-28  4:53 Possible bug for ZSTD kernel decompressing Feng Tang
2022-01-28 18:37 ` Nick Terrell
2022-01-31 20:31 ` Nick Terrell
2022-02-02  5:07   ` Feng Tang [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=20220202050727.GA19004@shbuild999.sh.intel.com \
    --to=feng.tang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=gustavoars@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oliver.sang@intel.com \
    --cc=terrelln@fb.com \
    --cc=x86@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.