> 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.
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.