Subject: RE: Strange bad accesses in compat_exit_robust_list (2.6.26, n32 ABI).

From: "Kaz Kylheku" <[email-masked]>
Date: Fri, 25 Sep 2009 16:11:30 -0700

Kaz Kylheku wrote:
> Hi all,
> 
> We made a strange discovery some time ago. After adding some tracing
> printk's to the compat_exit_robust_list function for all the cases
> where fetching the
> robust entry fails, we discovered that, from time to time,
> it's being reported
> for processes that don't even use threads.

Hmm. Maybe a syscall is being misrouted? Perhaps user space is calling
some function that ends up routed to the compat_set_robust_list
entry in the syscall table, causing a junk value to be installed
as the robust list. Hmm. But robust mutexes work on our platform;
so glibc does reach the right syscalls when they are intended.

---

From: "Kaz Kylheku" <[email-masked]>
Date: Fri, 25 Sep 2009 18:05:30 -0700

[email-masked] wrote:
>> where fetching the robust entry fails, we discovered that, from time
>> to time, 
>> it's being reported

I have another hypothesis.

The execve syscall does not appear to deal with the robust
mutex list at all. A process can set up these robust pointers
and then call execv. It gets a new memory map, but the
flush_old_exec function does not clean up the robust list pointer,
which refers to a virtual address in the old address space.

I just confirmed it in fact.

I have a 100% repro for this problem when I do a 
``tar xjf file.tar.bz2'' on my board.

The tar process calls compat_sys_set_robust_list, and then
the bzip2 process encounters the problem in the compat_exit_robust_list.

But the PID is the same!  The tar process has exec-ed
bzip2, and the bzip2 image inherited bad robust pointers from
the time when it was tar.