[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Linux 5.13-rc6 regression to 5.12.x: kernel OOM and panic during kernel boot in low memory Xen VM's (256MB assigned memory).

  • To: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Sander Eikelenboom <linux@xxxxxxxxxxxxxx>, Rasmus Villemoes <linux@xxxxxxxxxxxxxxxxxx>
  • From: Rasmus Villemoes <rasmus.villemoes@xxxxxxxxx>
  • Date: Thu, 17 Jun 2021 17:37:25 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=prevas.dk; dmarc=pass action=none header.from=prevas.dk; dkim=pass header.d=prevas.dk; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YT85gP+YFDJ5ychGyvNL82kun+NGGvSQi4A8qTsyAT8=; b=Jn6IFoWJfr+zFnIgc8XwjnBTU0TkPecvTEejS773agklIsIOBhksDQeOQTuRWM6BFhP6zocssXx/chE/9xIPdQfk1KO3Ya9mKrXwjh+cjDU1JxT4ChayuxWg6fnuLiPCPJHfYQ45uRXsqJ31CFvGVTJ4Xebzra51V2hcNH5EJKq5CaIzRctMuRJeHc0RUC52SFekSyfKXJoowm1qoNhQ19uDV7CtPucV1+TDinqJKzSu3vQkczE+egxtRSKy7DamA+3JgbFmUKYpjN7yLBV1rStuEb3JXPSK507s83SCxiTDrI9hpXRAfvSHpEvtNFdLtYrZwaAh5ILkBWaO+8Vmng==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QC4dW4HGsfDhQi0lzjYmgPTDbo7QHaySiMf+5R5Xubfhhq46X2UhlK8Mxm97X6KzEmFedPCpEDMdTaoEjuiYyGoWJtqHDpU525RuLJ1bQukq95i7xGL+JxO4F9NlnMi8KFH7uBN/QTtSuG+r2ephKjXslhSDqmI4qQmLgwHyb18PMMsfbJ4G4liDM+rYhIODNWYuo/W6xydMuVG1Ir1sSUZ7DbGnK8GjipUbGnZzIujKYl/mi9pv4G1izOCHdap/FCwi3OIdUBwDweielzSMhPBL5y3E4ZXPLAzTodNHVVnXBP62YIhJGt5VVqPonE8NDEmsbvDcE/oNA8qi1lb6gQ==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=prevas.dk;
  • Cc: linux-kernel <linux-kernel@xxxxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 17 Jun 2021 15:37:42 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 17/06/2021 17.01, Linus Torvalds wrote:
> On Thu, Jun 17, 2021 at 2:26 AM Sander Eikelenboom <linux@xxxxxxxxxxxxxx> 
> wrote:
>> I just tried to upgrade and test the linux kernel going from the 5.12 kernel 
>> series to 5.13-rc6 on my homeserver with Xen, but ran in some trouble.
>> Some VM's boot fine (with more than 256MB memory assigned), but the smaller 
>> (memory wise) PVH ones crash during kernel boot due to OOM.
>> Booting VM's with 5.12(.9) kernel still works fine, also when dom0 is 
>> running 5.13-rc6 (but it has more memory assigned, so that is not 
>> unexpected).
> Adding Rasmus to the cc, because this looks kind of like the async
> roofs population thing that caused some other oom issues too.

Yes, that looks like the same issue.

> Rasmus? Original report here:
> https://lore.kernel.org/lkml/ee8bf04c-6e55-1d9b-7bdb-25e6108e8e1e@xxxxxxxxxxxxxx/
> I do find it odd that we'd be running out of memory so early..

Indeed. It would be nice to know if these also reproduce with
initramfs_async=0 on the command line.

But what is even more curious is that in the other report
it seemed to trigger with _more_ memory - though I may be misreading
what Oliver was telling me:

> please be noted that we use 'vmalloc=512M' for both parent and this
> since it's ok on parent but oom on this commit, we want to send this
> to show the potential problem of the commit on some cases.
> we also tested by changing to use 'vmalloc=128M', it will succeed.

Those tests were done in a VM with 16G memory, and then he also wrote

> we also tried to follow exactly above steps to test on
> some local machine (8G memory), but cannot reproduce.

Are there some special rules for what memory pools PID1 versus the
kworker threads can dip into?

Side note: I also had a ppc64 report with different symptoms (the
initramfs was corrupted), but that turned out to also reproduce with
e7cb072eb98 reverted, so that is likely unrelated. But just FTR that
thread is here:




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.