Hi Martin
On Thu, May 22, 2008 at 2:22 AM, Martin Bill <billk@xxxxxxxxxxxxxxx> wrote:
> Hi all, new newbie here.
>
> I've been studying the sys_open() code and have run into a problem with the
> synchronization using RCU. The code snippet I'm having problems with is in
> get_unused_fd_flags():
>
>> FD_SET(fd, fdt->open_fds);
>> if (flags & O_CLOEXEC)
>> FD_SET(fd, fdt->close_on_exec);
>> else
>> FD_CLR(fd, fdt->close_on_exec);
>
> RCU requires first creating a local copy, updating that copy, updating the
> RCU protected pointer with the local copy and finally deallocating the
> original version after a grace period. This snippet, however, directly
> modifies the shared structure and therefore exposes intermediate states to
> other readers.
>
> I'm assuming it doesn't matter as the fd allocated won't be properly
> accessible until after the syscall has finished and therefore those bits
> won't be actually used until then. Still, I want to know if this really
> violates the RCU mechanic or if I'm missing something.
checking via LXR, to make it short, seems like FD_SET is accessing
this structure:
struct embedded_fd_set {
unsigned long fds_bits[1];
};
http://lxr.linux.no/linux/include/linux/file.h#L26
then, IMHO, everything is clear. "Long" type, AFAIK, in 32 bit and 64
bit x86, can be accessed atomically.
For finer explanation:
http://lxr.linux.no/linux/include/asm-i386/posix_types.h#L51
define __FD_SET(fd,fdsetp) \
__asm__ __volatile__("btsl %1,%0": \
"+m" (*(__kernel_fd_set *) (fdsetp)):"r" ((int) (fd)))
so, I bet it's bitwise operation...should work atomically.
regards,
Mulyadi.
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
