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

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

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