search for: hwrng_init

...* > + * Hold rng_mutex here so we serialize in case they set_current_rng > + * on rng again immediately. > + */ > + mutex_lock(&rng_mutex); > + if (rng) > + kref_put(&rng->ref, cleanup_rng); > + mutex_unlock(&rng_mutex); > +} > + > static inline int hwrng_init(struct hwrng *rng) > { > if (rng->init) { > @@ -113,12 +167,6 @@ static inline int hwrng_init(struct hwrng *rng) > return 0; > } > > -static inline void hwrng_cleanup(struct hwrng *rng) > -{ > - if (rng && rng->cleanup) > - rng->cleanup(rng);...

...* > + * Hold rng_mutex here so we serialize in case they set_current_rng > + * on rng again immediately. > + */ > + mutex_lock(&rng_mutex); > + if (rng) > + kref_put(&rng->ref, cleanup_rng); > + mutex_unlock(&rng_mutex); > +} > + > static inline int hwrng_init(struct hwrng *rng) > { > if (rng->init) { > @@ -113,12 +167,6 @@ static inline int hwrng_init(struct hwrng *rng) > return 0; > } > > -static inline void hwrng_cleanup(struct hwrng *rng) > -{ > - if (rng && rng->cleanup) > - rng->cleanup(rng);...

Amos Kong <akong at redhat.com> writes: > We got a warning in boot stage when above set_current_rng() is executed, > it can be fixed by init rng->ref in hwrng_init(). > > > @@ -166,6 +169,8 @@ static inline int hwrng_init(struct hwrng *rng) > if (current_quality > 0 && !hwrng_fill) > start_khwrngd(); > > + kref_init(&rng->ref); > + > return 0; > } OK, I folded this fix o...

Amos Kong <akong at redhat.com> writes: > We got a warning in boot stage when above set_current_rng() is executed, > it can be fixed by init rng->ref in hwrng_init(). > > > @@ -166,6 +169,8 @@ static inline int hwrng_init(struct hwrng *rng) > if (current_quality > 0 && !hwrng_fill) > start_khwrngd(); > > + kref_init(&rng->ref); > + > return 0; > } OK, I folded this fix o...

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My original was pain, Rusty posted a real fix. This patchset fixed two issue in v1, and tested by my 6+ cases. | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: |

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My original was pain, Rusty posted a real fix. This patchset fixed two issue in v1, and tested by my 6+ cases. | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: |

...} + +static void put_rng(struct hwrng *rng) +{ + /* + * Hold rng_mutex here so we serialize in case they set_current_rng + * on rng again immediately. + */ + mutex_lock(&rng_mutex); + if (rng) + kref_put(&rng->ref, cleanup_rng); + mutex_unlock(&rng_mutex); +} + static inline int hwrng_init(struct hwrng *rng) { if (rng->init) { @@ -113,12 +167,6 @@ static inline int hwrng_init(struct hwrng *rng) return 0; } -static inline void hwrng_cleanup(struct hwrng *rng) -{ - if (rng && rng->cleanup) - rng->cleanup(rng); -} - static int rng_dev_open(struct inode *inode,...

...} + +static void put_rng(struct hwrng *rng) +{ + /* + * Hold rng_mutex here so we serialize in case they set_current_rng + * on rng again immediately. + */ + mutex_lock(&rng_mutex); + if (rng) + kref_put(&rng->ref, cleanup_rng); + mutex_unlock(&rng_mutex); +} + static inline int hwrng_init(struct hwrng *rng) { if (rng->init) { @@ -113,12 +167,6 @@ static inline int hwrng_init(struct hwrng *rng) return 0; } -static inline void hwrng_cleanup(struct hwrng *rng) -{ - if (rng && rng->cleanup) - rng->cleanup(rng); -} - static int rng_dev_open(struct inode *inode,...

...ys We have the opportunity to make the third option suck less if we can get this right. > virtio's probe() has to finish before communication with the host can > start. If a virtio-rng device is the only hwrng in the system (very > likely in a guest), it's almost guaranteed that hwrng_init() won't be > called after hwrng_register() completes (as it would have already been > called and the virtio-rng device will have become the current_rng). Well, I'm confused. virtio-rng has no init function defined. So hwrng_init() will just return zero. I think the basic question...

...ys We have the opportunity to make the third option suck less if we can get this right. > virtio's probe() has to finish before communication with the host can > start. If a virtio-rng device is the only hwrng in the system (very > likely in a guest), it's almost guaranteed that hwrng_init() won't be > called after hwrng_register() completes (as it would have already been > called and the virtio-rng device will have become the current_rng). Well, I'm confused. virtio-rng has no init function defined. So hwrng_init() will just return zero. I think the basic question...

...} + +static void put_rng(struct hwrng *rng) +{ + /* + * Hold rng_mutex here so we serialize in case they set_current_rng + * on rng again immediately. + */ + mutex_lock(&rng_mutex); + if (rng) + kref_put(&rng->ref, cleanup_rng); + mutex_unlock(&rng_mutex); +} + static inline int hwrng_init(struct hwrng *rng) { if (rng->init) { @@ -110,13 +170,9 @@ static inline int hwrng_init(struct hwrng *rng) if (current_quality > 0 && !hwrng_fill) start_khwrngd(); - return 0; -} + kref_init(&rng->ref); -static inline void hwrng_cleanup(struct hwrng *rng) -{ - if (r...

...} + +static void put_rng(struct hwrng *rng) +{ + /* + * Hold rng_mutex here so we serialize in case they set_current_rng + * on rng again immediately. + */ + mutex_lock(&rng_mutex); + if (rng) + kref_put(&rng->ref, cleanup_rng); + mutex_unlock(&rng_mutex); +} + static inline int hwrng_init(struct hwrng *rng) { if (rng->init) { @@ -110,13 +170,9 @@ static inline int hwrng_init(struct hwrng *rng) if (current_quality > 0 && !hwrng_fill) start_khwrngd(); - return 0; -} + kref_init(&rng->ref); -static inline void hwrng_cleanup(struct hwrng *rng) -{ - if (r...

...t their randomness added to the system each > > time they're switched in, but devices that don't have the init > > callback don't contribute to system randomness more than once. The > > weirdness is resolved here by using the randomness each time > > hwrng_init() is attempted, irrespective of the existence of the > > device's ->init() callback. > > All applied to crypto. Thanks! Thanks, Herbert. I didn't mention it, but pls queue it up for 3.16. Amit

...t their randomness added to the system each > > time they're switched in, but devices that don't have the init > > callback don't contribute to system randomness more than once. The > > weirdness is resolved here by using the randomness each time > > hwrng_init() is attempted, irrespective of the existence of the > > device's ->init() callback. > > All applied to crypto. Thanks! Thanks, Herbert. I didn't mention it, but pls queue it up for 3.16. Amit

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My hotplug tests: | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: | guest) # dd if=/dev/random of=/dev/null & | hotunplug rng device from qemu monitor | | test

When I hotunplug a busy virtio-rng device or try to access hwrng attributes in non-smp guest, it gets stuck. My hotplug tests: | test 0: | hotunplug rng device from qemu monitor | | test 1: | guest) # dd if=/dev/hwrng of=/dev/null & | hotunplug rng device from qemu monitor | | test 2: | guest) # dd if=/dev/random of=/dev/null & | hotunplug rng device from qemu monitor | | test

...this patch. You're basically saying the ->init() should be called unconditionally for each hwrng. If that's what driver authors assumed, that's not what is happening if there is more than one driver in the system. I think you should be changing the code a few lines up to make sure hwrng_init() is called once for each driver. > My version was more conservative while this one keeps the bug from the > current kernels. Huh? What do you mean by "keeps the bug from the current kernels." ? Besides, you're second patch isn't actually doing any ->init to get the h...

...this patch. You're basically saying the ->init() should be called unconditionally for each hwrng. If that's what driver authors assumed, that's not what is happening if there is more than one driver in the system. I think you should be changing the code a few lines up to make sure hwrng_init() is called once for each driver. > My version was more conservative while this one keeps the bug from the > current kernels. Huh? What do you mean by "keeps the bug from the current kernels." ? Besides, you're second patch isn't actually doing any ->init to get the h...

Amos Kong <akong at redhat.com> writes: > I started a QEMU (non-smp) guest with one virtio-rng device, and read > random data from /dev/hwrng by dd: > > # dd if=/dev/hwrng of=/dev/null & > > In the same time, if I check hwrng attributes from sysfs by cat: > > # cat /sys/class/misc/hw_random/rng_* > > The cat process always gets stuck with slow backend (5

Amos Kong <akong at redhat.com> writes: > I started a QEMU (non-smp) guest with one virtio-rng device, and read > random data from /dev/hwrng by dd: > > # dd if=/dev/hwrng of=/dev/null & > > In the same time, if I check hwrng attributes from sysfs by cat: > > # cat /sys/class/misc/hw_random/rng_* > > The cat process always gets stuck with slow backend (5