PROBLEM: getpid() returning same value as getppid()
in [Kernel]
|
Prev: Change to invalidate_bdev() may break emergency remount R/O
Next: EXOFS: do not manipulate s_dirt directly
From: Sébastien Paumier on 26 May 2010 11:10 Hi, here is a bug that occurs on my kernel 2.6.31-21, maybe with older ones. If a C program contains a function with the constructor attribute that calls getpid(), then, a call to syscall(SYS_fork) produces a son that obtains the same value calling getpid() or getppid(). Best regards, Sébastien Paumier
From: Nick Bowler on 26 May 2010 11:20 On 16:45 Wed 26 May , S�bastien Paumier wrote: > Hi, > here is a bug that occurs on my kernel 2.6.31-21, maybe with older ones. > If a C program contains a function with the constructor attribute that > calls getpid(), then, a call to syscall(SYS_fork) produces a son that > obtains the same value calling getpid() or getppid(). The GNU C library caches the results of getpid, which is probably the cause of your grief. This cache relies on the glibc wrappers for fork and friends, which you have bypassed by using syscall directly. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michal Hocko on 2 Jun 2010 11:10
On Wed 26-05-10 11:16:51, Nick Bowler wrote: > On 16:45 Wed 26 May , S?bastien Paumier wrote: > > Hi, > > here is a bug that occurs on my kernel 2.6.31-21, maybe with older ones. > > If a C program contains a function with the constructor attribute that > > calls getpid(), then, a call to syscall(SYS_fork) produces a son that > > obtains the same value calling getpid() or getppid(). > > The GNU C library caches the results of getpid, which is probably the > cause of your grief. This cache relies on the glibc wrappers for fork > and friends, which you have bypassed by using syscall directly. man page for getpid states that explicitly: NOTES Since glibc version 2.3.4, the glibc wrapper function for getpid() caches PIDs, so as to avoid additional system calls when a process calls getpid() repeatedly. Normally this caching is invisible, but its correct operation relies on support in the wrapper functions for fork(2), vfork(2), and clone(2): if an application bypasses the glibc wrappers for these system calls by using syscall(2), then a call to getpid() in the child will return the wrong value (to be precise: it will return the PID of the parent process). See also clone(2) for discussion of a case where getpid() may return the wrong value even when invoking clone(2) via the glibc wrapper function. > > -- > Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo(a)vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Michal Hocko L3 team SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |