Hi Suzanne,
Sorry about the late reply, I have been offline for a while.
On Sun, Apr 23, 2006 at 04:15:18PM -0700, Suzanne Wood wrote:
> Do you mind explaining what you mean by "don't hold a reference"
> in the places you replace rcu_read_lock() with spin_lock() in
> settings with nested fcheck_files() or files_fdtable() which
> in turn call rcu_dereference()? How, for example, are the
Well, we use different methods of reference counting with
RCU based objects and fd table is one of those. With the
fd table, when you look up a file without holding
the fd table spinlock, the file structure you get may
be getting torn down on another CPU. We can safely
do this only if we *successfully* increment the reference
count of the file structure using atomic_inc_not_zero()
primitive which is based on cmpxchg. If atomic_inc_not_zero()
fails, we assume that the reference count of the file
structure had become zero and is getting destroyed.
If atomic_inc_not_zero() was successful, then we
"hold" a reference to the file structure and it is
safe to access it.
> occurences in proc_readfd() and tid_fd_revalidate() in
> fs/proc/base.c different? tid_fid_revalidate() doesn't make
> a local assignment and has the FASTCALL put_files_struct, but
> is there reasoning that proc_readfd() isn't similar to steal_locks()
> in fs/locks.c?
In both proc_readfd() and tid_fd_revalidate(), we don't access
the file structure itself in the lock-free section. We just
check if the file exists or not in the fd table. Worst case,
we may see state data in /proc.
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]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
