Return-Path: Received: from imap.thunk.org ([74.207.234.97]:46622 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755858AbeDWP4v (ORCPT ); Mon, 23 Apr 2018 11:56:51 -0400 Date: Mon, 23 Apr 2018 11:56:37 -0400 From: "Theodore Y. Ts'o" To: Tetsuo Handa Cc: gregkh@linuxfoundation.org, ben@decadent.org.uk, linux-kernel@vger.kernel.org, stable@vger.kernel.org, jannh@google.com, stable@kernel.org, carnil@debian.org Subject: Re: [PATCH 4.9 75/95] random: set up the NUMA crng instances after the CRNG is fully initialized Message-ID: <20180423155637.GB8194@thunk.org> References: <20180422135210.432103639@linuxfoundation.org> <20180422135213.491879480@linuxfoundation.org> <49fa7d5f484a06f02946afec0688c33849e018de.camel@decadent.org.uk> <20180423071520.GC28186@kroah.com> <201804231921.DGB18791.QOVFLFMJFtSOHO@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201804231921.DGB18791.QOVFLFMJFtSOHO@I-love.SAKURA.ne.jp> Sender: stable-owner@vger.kernel.org List-ID: On Mon, Apr 23, 2018 at 07:21:10PM +0900, Tetsuo Handa wrote: > Greg Kroah-Hartman wrote: > > > I think this can be fixed by backporting commit 4a072c71f49b > > > "random: silence compiler warnings and fix race" but I'm not sure > > > whether that depends on other changes. > > > > According to Tetsuo Handa, it's also causing problems in mainline :( > > > > Ted, any thoughts as to what to do here? > > (Resending because Webmail post was rejected by both stable ML and linux-kernel ML.) > > Subject: random: GFP_KERNEL|__GFP_NOFAIL allocation from IRQ context > > Hello. > > Commit 8ef35c866f8862df ("random: set up the NUMA crng instances after > the CRNG is fully initialized") is causing sleep inside atomic warning > due to GFP_KERNEL|__GFP_NOFAIL allocation from IRQ context. Though it > unlikely sleeps because there will be enough free memory at boot up... > > Please don't backport that patch now. Yes, please hold off on this in the stable queues as well. What we'll probably need to do is call defer the processing to a workqueue in the CONFIG_NUMA case. - Ted