Re: 2.6.16-rc regression: m68k CONFIG_RMW_INSNS=n compile broken

From: Dipankar Sarma
Date: Mon Mar 06 2006 - 11:47:09 EST


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