Hi
16.04.2015, 15:00, "Thorsten Bschorr" :
>> Let's push this patch upstream as a temporal fix until we are ready with the
>> new solution.
>> Thorsten, does it fix your crash?
>
> I'm running David's refcounting-patch for about 3 weeks now on my 3.18.y
> kernel, and did not observe any problems
Hi David
16.04.2015, 06:52, "David Fries" :
> It has not been solved. Evgeniy would like to make use of the sysfs
> device management instead of the current reference counting, however I
> haven't heard any volunteers to do that work. I posted a quick fix
> patch, it was very easy to crash witho
It has not been solved. Evgeniy would like to make use of the sysfs
device management instead of the current reference counting, however I
haven't heard any volunteers to do that work. I posted a quick fix
patch, it was very easy to crash without this patch, it doesn't
completely solve the race c
On Wed, Mar 18, 2015 at 06:18:53PM +0300, Evgeniy Polyakov wrote:
> Hi
>
> 18.03.2015, 07:20, "David Fries" :
> > static void w1_therm_remove_slave(struct w1_slave *sl)
> > {
> > + int refcnt = atomic_sub_return(1, THERM_REFCNT(sl->family_data));
> > + while(refcnt) {
> > + msleep(1000);
> > + r
Hi
18.03.2015, 07:20, "David Fries" :
> static void w1_therm_remove_slave(struct w1_slave *sl)
> {
> + int refcnt = atomic_sub_return(1, THERM_REFCNT(sl->family_data));
> + while(refcnt) {
> + msleep(1000);
> + refcnt = atomic_read(THERM_REFCNT(sl->family_data));
> + }
> kfree(sl->famil
On Sat, Mar 14, 2015 at 11:55:16PM +0300, Evgeniy Polyakov wrote:
> Hi David
>
> 12.03.2015, 03:54, "David Fries" :
> > Would that be removing all four refcnt, w1_slave, w1_master,
> > w1_family, w1_cb_block, or just some of them? It sounds good to me,
> > if that had bugs there would be much mor
Hi David
12.03.2015, 03:54, "David Fries" :
> Would that be removing all four refcnt, w1_slave, w1_master,
> w1_family, w1_cb_block, or just some of them? It sounds good to me,
> if that had bugs there would be much more than just the w1 system
> relying on it. I don't know enough about that sys
On Tue, Mar 10, 2015 at 04:52:00PM +0300, Evgeniy Polyakov wrote:
> Hi
>
> 10.03.2015, 02:09, "David Fries" :
>
> > diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
> > index 1f11a20..39a9e6a 100644
> > --- a/drivers/w1/slaves/w1_therm.c
> > +++ b/drivers/w1/slaves/w1_ther
On Tue, Mar 10, 2015 at 01:34:14AM +0100, Thorsten Bschorr wrote:
> > It looks like your patch runs into dead locks problems:
I was testing reading and removing the slave, I didn't test two
readers, I'll keep that in mind.
For some reason I was thinking it was a try lock after the sleep, it
isn't
Hi
10.03.2015, 02:09, "David Fries" :
> diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c
> index 1f11a20..39a9e6a 100644
> --- a/drivers/w1/slaves/w1_therm.c
> +++ b/drivers/w1/slaves/w1_therm.c
> @@ -59,9 +59,20 @@ MODULE_ALIAS("w1-family-" __stringify(W1_THERM_DS28EA00))
> It looks like your patch runs into dead locks problems:
>
> I have a cron job reading my sensors. If I read the sensors on another
> thread (e.g. via cat), the 2nd thread can produce a dead lock:
>
> * thread 1 has bus & sl lock
> * thread 1 drops bus lock, keeps sl locks and sleeps
> * thread 2
> Oops, sorry, it got lost in the shuffle, here's the first patch again
> (the others were for debugging and increase that time and so wouldn't
> go upstream anyway).
I assumed so.
It looks like your patch runs into dead locks problems:
I have a cron job reading my sensors. If I read the sensor
On Mon, Mar 09, 2015 at 11:47:24PM +0100, Thorsten Bschorr wrote:
> > Here's a different strategy, add a w1_therm family_data specific mutex
> > so w1_therm_remove_slave won't return while another thread is in
> > w1_slave_show. Thoughts?
> >
> > I included three patches, the first is the proposed
> Here's a different strategy, add a w1_therm family_data specific mutex
> so w1_therm_remove_slave won't return while another thread is in
> w1_slave_show. Thoughts?
>
> I included three patches, the first is the proposed fix, the second
> makes it more reproducible (and since my testing doesn't
On Wed, Mar 04, 2015 at 06:36:41PM +0300, ??? ??? wrote:
> Hi David
>
> 02.03.2015, 03:17, "David Fries" :
>
> > You are correct, it would be a race condition if it doesn't increment
> > the refcnt before unlocking the mutex, and it should get the mutex
> > before unref. Here's an update
Hi David
02.03.2015, 03:17, "David Fries" :
> You are correct, it would be a race condition if it doesn't increment
> the refcnt before unlocking the mutex, and it should get the mutex
> before unref. Here's an updated version, I haven't even tried to
> compile it.
>
> What do you think Evgeniy?
On Sun, Mar 01, 2015 at 02:04:53PM +0100, Thorsten Bschorr wrote:
> Hi David,
>
> thanks for your feedback on my first patch, I wasn't aware of checkpatch.pl.
>
> Initially, I had just if-ed the usage of family-data, which did not
> look that nice. I was referring to this proof-of-concept workaro
Hi David,
thanks for your feedback on my first patch, I wasn't aware of checkpatch.pl.
Initially, I had just if-ed the usage of family-data, which did not
look that nice. I was referring to this proof-of-concept workaround in
my initial bug report.
The patch I've submitted is different from my p
On Sun, Mar 01, 2015 at 04:48:22AM +0300, ??? ??? wrote:
> Hi everyone
>
> 28.02.2015, 23:18, "David Fries" :
> > Thanks for preparing the patch, it looks like it will go another
> > round, but that happens to everyone.
>
> Patch itself doesn't solve the problem, it only adds a workaround
Thanks for preparing the patch, it looks like it will go another
round, but that happens to everyone.
To simplify to show a problem,
mutex_lock_interruptible(&dev->bus_mutex);
if (!sl->family_data)
return -ENODEV;
If family_data is NULL, then dev->bus_mutex is left locked. Your
earlier
w1_slave_show unlocks the bus while waiting for the sensor
to convert the temperature. If the sensor gets disconnected
during that time, sl->family_data could get NULL.
Note: the w1_slave pointer inside w1_slave_show is protected by
sysfs-mutex
---
drivers/w1/slaves/w1_therm.c | 6 ++
1 file c
21 matches
Mail list logo
