On Fri, Sep 23, 2005 at 08:40:56PM +0200, Frank van Maarseveen wrote:
> On Fri, Sep 23, 2005 at 10:56:53PM +0530, Dipankar Sarma wrote:
> >
> > Well, the main reason is that if that code is somehow copied
> > by to a lock-free critical section, it could cause problems.
> > If you dereference ->fdt multiple times in a lock-free
> > section, you could see two different pointers due to
> > a concurrent update.
>
> thanks for the explanation. This raises a lot of other questions. What
> if max_fds is updated by RCU right after obtaining it...
If you are updating it, you hold the lock. That way you can't
be racing with another update. Secondly, changing max_fds
would require allocating a new fdtable structure and
updating ->fdt to point to the new structure, all under
the files_struct lock. The lock-free readers may see the
older fdtable which is kept around until the RCU grace
period is over. That makes it safe.
Thanks
Dipankar
-
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]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |