search for: hwrng_attr_

...ult: cat process will get stuck, it will return if we kill dd process. We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c, they are protected by rng_mutex. I try to workaround this issue by undelay(100) after mutex_unlock() in rng_dev_read(). This gives chance for hwrng_attr_*_show() to get mutex. This patch also contains some cleanup, moving some code out of mutex protection. Do you have some suggestion? Thanks. diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index aa30a25..fa69020 100644 --- a/drivers/char/hw_random/core.c +++ b/drivers/...

...ult: cat process will get stuck, it will return if we kill dd process. We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c, they are protected by rng_mutex. I try to workaround this issue by undelay(100) after mutex_unlock() in rng_dev_read(). This gives chance for hwrng_attr_*_show() to get mutex. This patch also contains some cleanup, moving some code out of mutex protection. Do you have some suggestion? Thanks. diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index aa30a25..fa69020 100644 --- a/drivers/char/hw_random/core.c +++ b/drivers/...

...oesn't mean we shouldn't fix the issue here...) > We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c, > they are protected by rng_mutex. I try to workaround this issue by undelay(100) > after mutex_unlock() in rng_dev_read(). This gives chance for hwrng_attr_*_show() > to get mutex. > > This patch also contains some cleanup, moving some code out of mutex > protection. > > Do you have some suggestion? Thanks. > > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c > index aa30a25..fa69020 100644...

...oesn't mean we shouldn't fix the issue here...) > We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c, > they are protected by rng_mutex. I try to workaround this issue by undelay(100) > after mutex_unlock() in rng_dev_read(). This gives chance for hwrng_attr_*_show() > to get mutex. > > This patch also contains some cleanup, moving some code out of mutex > protection. > > Do you have some suggestion? Thanks. > > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c > index aa30a25..fa69020 100644...

...ult: cat process will get stuck, it will return if we kill dd process. We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c, they are protected by rng_mutex. I try to workaround this issue by undelay(100) after mutex_unlock() in rng_dev_read(). This gives chance for hwrng_attr_*_show() to get mutex. This patch also contains some cleanup, moving some code out of mutex protection. Do you have some suggestion? Thanks. diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index aa30a25..fa69020 100644 --- a/drivers/char/hw_random/core.c +++ b/drivers/...

...he issue here...) Completely agree :-) > > We have some static variables (eg, current_rng, data_avail, etc) in hw_random/core.c, > > they are protected by rng_mutex. I try to workaround this issue by undelay(100) > > after mutex_unlock() in rng_dev_read(). This gives chance for hwrng_attr_*_show() > > to get mutex. > > > > This patch also contains some cleanup, moving some code out of mutex > > protection. > > > > Do you have some suggestion? Thanks. > > > > > > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_rand...