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