linux-mips-bounce@xxxxxxxxxxxxxx wrote: > 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.
