From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 12 Aug 2014 13:24:33 +0530 From: Amit Shah To: Greg KH Cc: stable@vger.kernel.org, Amos Kong , Virtualization List , linux-kernel@vger.kernel.org, Rusty Russell Subject: Re: [3.16 stable PATCH 1/2] virtio: rng: delay hwrng_register() till driver is ready Message-ID: <20140812075433.GN4184@grmbl.mre> References: <76f5c012de1f6adeb1f8c105db5dc21a6e99fbc4.1407827215.git.amit.shah@redhat.com> <20140812074135.GB22911@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140812074135.GB22911@kroah.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: On (Tue) 12 Aug 2014 [15:41:35], Greg KH wrote: > On Tue, Aug 12, 2014 at 12:36:54PM +0530, Amit Shah wrote: > > Instead of calling hwrng_register() in the probe routing, call it in the > > scan routine. This ensures that when hwrng_register() is successful, > > and it requests a few random bytes to seed the kernel's pool at init, > > we're ready to service that request. > > > > This will also enable us to remove the workaround added previously to > > check whether probe was completed, and only then ask for data from the > > host. The revert follows in the next commit. > > > > There's a slight behaviour change here on unsuccessful hwrng_register(). > > Previously, when hwrng_register() failed, the probe() routine would > > fail, and the vqs would be torn down, and driver would be marked not > > initialized. Now, the vqs will remain initialized, driver would be > > marked initialized as well, but won't be available in the list of RNGs > > available to hwrng core. To fix the failures, the procedure remains the > > same, i.e. unload and re-load the module, and hope things succeed the > > next time around. > > > > Signed-off-by: Amit Shah > > Signed-off-by: Rusty Russell > > (cherry picked from commit 5c06273401f2eb7b290cadbae18ee00f8f65e893) > > Signed-off-by: Amit Shah > > > > Conflicts: > > drivers/char/hw_random/virtio-rng.c > > > > Context conflict due to not backporting two commits that changed > > struct layout. > > What is this "Conflicts:" stuff for? I don't need that... To note the patch didn't cherry-pick as-is; anyway, sent a v2 without that text. Thanks, Amit