* max_fd
@ 2005-09-23 12:37 Pablo Fernandez
2005-09-23 15:55 ` max_fd Dipankar Sarma
0 siblings, 1 reply; 6+ messages in thread
From: Pablo Fernandez @ 2005-09-23 12:37 UTC (permalink / raw)
To: linux-kernel
Hi
What happend to files_struct.max_fd? Is it safe to use
files_fdtable(files_struct).max_fds?
thanks,
Pablo Fernandez
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: max_fd
2005-09-23 12:37 max_fd Pablo Fernandez
@ 2005-09-23 15:55 ` Dipankar Sarma
2005-09-23 17:03 ` max_fd Frank van Maarseveen
0 siblings, 1 reply; 6+ messages in thread
From: Dipankar Sarma @ 2005-09-23 15:55 UTC (permalink / raw)
To: Pablo Fernandez; +Cc: linux-kernel
On Fri, Sep 23, 2005 at 02:37:51PM +0200, Pablo Fernandez wrote:
> Hi
>
> What happend to files_struct.max_fd? Is it safe to use
> files_fdtable(files_struct).max_fds?
No.
Just do -
struct fdtable *fdt;
rcu_read_lock();
fdt = files_fdtable(files_struct);
if (fdt->max_fds......
...
rcu_read_unlock();
If you are updating the fd table, then acuire the file_lock
instead of rcu_read_lock/unlock.
Thanks
Dipankar
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: max_fd
2005-09-23 15:55 ` max_fd Dipankar Sarma
@ 2005-09-23 17:03 ` Frank van Maarseveen
2005-09-23 17:26 ` max_fd Dipankar Sarma
0 siblings, 1 reply; 6+ messages in thread
From: Frank van Maarseveen @ 2005-09-23 17:03 UTC (permalink / raw)
To: Dipankar Sarma; +Cc: Pablo Fernandez, linux-kernel
On Fri, Sep 23, 2005 at 09:25:10PM +0530, Dipankar Sarma wrote:
> On Fri, Sep 23, 2005 at 02:37:51PM +0200, Pablo Fernandez wrote:
> > Hi
> >
> > What happend to files_struct.max_fd? Is it safe to use
> > files_fdtable(files_struct).max_fds?
>
> No.
>
> Just do -
>
> struct fdtable *fdt;
>
> rcu_read_lock();
> fdt = files_fdtable(files_struct);
> if (fdt->max_fds......
> ...
> rcu_read_unlock();
In include/linux/file.h I see this:
#define files_fdtable(files) (rcu_dereference((files)->fdt))
looks better to me unless you really want to update the
struct fdtable.
--
Frank
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: max_fd
2005-09-23 17:03 ` max_fd Frank van Maarseveen
@ 2005-09-23 17:26 ` Dipankar Sarma
2005-09-23 18:40 ` max_fd Frank van Maarseveen
0 siblings, 1 reply; 6+ messages in thread
From: Dipankar Sarma @ 2005-09-23 17:26 UTC (permalink / raw)
To: Frank van Maarseveen; +Cc: Pablo Fernandez, linux-kernel
On Fri, Sep 23, 2005 at 07:03:45PM +0200, Frank van Maarseveen wrote:
> On Fri, Sep 23, 2005 at 09:25:10PM +0530, Dipankar Sarma wrote:
> > On Fri, Sep 23, 2005 at 02:37:51PM +0200, Pablo Fernandez wrote:
> > Just do -
> >
> > struct fdtable *fdt;
> >
> > rcu_read_lock();
> > fdt = files_fdtable(files_struct);
> > if (fdt->max_fds......
> > ...
> > rcu_read_unlock();
>
> In include/linux/file.h I see this:
>
> #define files_fdtable(files) (rcu_dereference((files)->fdt))
>
> looks better to me unless you really want to update the
> struct fdtable.
I would much rather have it my way :)
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.
I would advise sticking to the same convention everywhere.
Thanks
Dipankar
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: max_fd
2005-09-23 17:26 ` max_fd Dipankar Sarma
@ 2005-09-23 18:40 ` Frank van Maarseveen
2005-09-23 18:46 ` max_fd Dipankar Sarma
0 siblings, 1 reply; 6+ messages in thread
From: Frank van Maarseveen @ 2005-09-23 18:40 UTC (permalink / raw)
To: Dipankar Sarma; +Cc: Frank van Maarseveen, Pablo Fernandez, linux-kernel
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...
--
Frank
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: max_fd
2005-09-23 18:40 ` max_fd Frank van Maarseveen
@ 2005-09-23 18:46 ` Dipankar Sarma
0 siblings, 0 replies; 6+ messages in thread
From: Dipankar Sarma @ 2005-09-23 18:46 UTC (permalink / raw)
To: Frank van Maarseveen; +Cc: Pablo Fernandez, linux-kernel
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-09-23 18:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-23 12:37 max_fd Pablo Fernandez
2005-09-23 15:55 ` max_fd Dipankar Sarma
2005-09-23 17:03 ` max_fd Frank van Maarseveen
2005-09-23 17:26 ` max_fd Dipankar Sarma
2005-09-23 18:40 ` max_fd Frank van Maarseveen
2005-09-23 18:46 ` max_fd Dipankar Sarma
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.