On Mon, Mar 06, 2006 at 08:13:41AM -0800, Suzanne Wood wrote:
> Thank you very much.
> > > struct file fastcall *fget_light(unsigned int fd, int *fput_needed)
> > > {
> > > struct file *file;
> > > struct files_struct *files = current->files;
> > >
> > > *fput_needed = 0;
> > > if (likely((atomic_read(&files->count) == 1))) {
> > > file = fcheck_files(files, fd);
> > > } else {
>
> > This means that the fd table is not shared between threads. So,
> > there can't be any race and no need to protect using
> > rcu_read_lock()/rcu_read_unlock().
>
> Then why call fcheck_files() with the rcu_dereference() which would flag
> an automated check for the need to mark a read-side critical section?
> Would it make sense to introduce the function that doesn't? The goal of
> keeping the kernel small is balanced with clarity. The inconsistency of
> how fcheck_files() is used within a single function (fget_light()) was
> my opening question.
Because rcu_dereference() hurts only alpha and we don't care about
alpha :-)
Just kidding!
Good point about automated checkers. However, this isn't an
uncommon thing in multi-threaded programs - can't the checker
rules be written to take into account sharing and non-sharing of
the object in question ?
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]
