On Sun, Sep 26, 2010 at 12:34 AM, Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote: > I noticed that Tomoyo doesn't build on Alpha because Tomoyo tries to > call sys_getpid() and sys_getppid(). That's a bug in Tomoyo, but when I > looked at why Alpha is different I found that the implementation of > getxpid() hasn't been kept in sync getppid() for other architectures and > is presumably now incorrect. > > sys_getppid(): > rcu_read_lock(); > pid = task_tgid_vnr(current->real_parent); > rcu_read_unlock(); > > task_tgid_vnr(current->real_parent) expands through various inline > functions to: > > pid_nr_ns(current->real_parent->group_leader->pids[PIDTYPE_PID].pid, > current->nsproxy->pid_ns) > > sys_getxpid(): > /* See linux/kernel/timer.c sys_getppid for discussion > about this loop. */ > ldq $3, TASK_GROUP_LEADER($2) > ldq $4, TASK_REAL_PARENT($3) > ldl $0, TASK_TGID($2) > 1: ldl $1, TASK_TGID($4) > #ifdef CONFIG_SMP > mov $4, $5 > mb > ldq $3, TASK_GROUP_LEADER($2) > ldq $4, TASK_REAL_PARENT($3) > cmpeq $4, $5, $5 > beq $5, 1b > #endif > > The comment is obviously out-of-date. This isn't following RCU protocol > and it isn't namespace-aware. I think it needs to be turned into a > wrapper for the generic code. > > Ben. > > -- > Ben Hutchings > Once a job is fouled up, anything done to improve it makes it worse. Hi Ben, Al, I recently looked at this gentoo bug -- https://bugs.gentoo.org/show_bug.cgi?id=405829 and then came across this email and the two patches. They seem possibly related. It looks like Al said he thought he had a better way of fixing the problem, but then I'm not sure if his patches surfaced or not. Also possibly related, Tobias and Michael have seen some RCU stalls with recent kernels. Looks like getxpid needs an update? Thanks, Matt -- To unsubscribe from this list: send the line "unsubscribe linux-alpha" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
