Re: max_fd

[Dipankar Sarma <dipankar@in.ibm.com>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/