Re: [PATCH] Avoid null-pointer access in w1/slaves/w1_therm

[Thorsten Bschorr]

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 proof-of-concept
workaround. Not unlocking the bus before returning clearly is an
error, I did not extensively test this patch.


> or just increment it while sleeping, which is when it's needed, which
> also looks simpler.
>
>                         if (external_power) {
> +                               int refcnt;
>                                 mutex_unlock(&dev->bus_mutex);
>
> +                               /* prevent the slave from going away */
> +                               atomic_inc(&sl->refcnt);
>                                 sleep_rem = msleep_interruptible(tm);
> +                               refcnt = w1_unref_slave(sl);
> -                               if (sleep_rem != 0)
> +                               if (sleep_rem != 0 || !refcnt)
>                                         return -EINTR;
>
>                                 i = mutex_lock_interruptible(&dev->bus_mutex);
>                                 if (i != 0)
>                                         return i;
>                         } else if (!w1_strong_pullup) {


I like this better than my workaround-patch.

One thought occurred to me when looking at this proposal: wouldn't it
be even better to increase sl->refcnt before unlocking the mutex?
I was asking myself if it is possible that the current thread gets
suspended between mutex_unlock(&dev->bus_mutex); and
atomic_inc(&sl->refcnt); thus leaving another thread the change to
unref the device?
(I'm not that familiar with linux scheduling, so my assumption might be void.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/