> Gee, thanks. I sat and wrote code side-by-side, and it looks like, even barriers
> won't fix anything, because they don't affect other CPUs.
?! The whole point of memory barriers is that they affect other CPUs.
Maybe you are thinking of compiler barriers?
> ->proc_fops is valid ->proc_fops is valid
> ->pde_users is 0 ->pde_users is 0
> ------------------------------------------------------------
>
>
> if (!pde->proc_fops)
> goto out;
>
> ->proc_fops = NULL;
> if (atomic_read(->pde_users) > 0)
> goto again;
>
> |
> | atomic_inc(->pde_users);
> |
> |
> |
> V
The proc_fops check *before* the atomic_inc is indeed pointless (notice
how I removed it in the patch I sent?). It's the one after the atomic_inc
that prevents this race, but only if there is a memory barrier between the
atomic_inc and the check... because otherwise they could be reordered (i.e.
seen in reverse order by another CPU) giving the race.
> Modules forget to set ->owner sometimes. Also, it's still racy, because
> of the typical
>
> pde = create_proc_entry();
> /*
> *
> * ->owner is NULL here, effectively, PDE without ->owner.
> *
> */
> if (pde)
> pde->owner = THIS_MODULE;
As long as the module calls remove_proc_entry before being unloaded,
this should be ok.
Best wishes,
Duncan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
