On 2015-12-20, at 3:18 PM, Helge Deller wrote: >>> Nevertheless, it may happen anytime if people forget, that we will see a >>> "copy" there again, so IMHO it's probably safer to include the workaround in >>> kernel too. >> >> >> The current patch assumes regs->gr[source_reg] is restored. > > Yes and no. > > The real problem we actually faced is, that the glibc() syscall function > uses %r28 (aka the return value of the syscall) as "source_reg". > That's the reason why we failed with "ENOSYS" in the end, because when we returned > (before my patch) from the first syscall we returned -ERESTARTSYS > in %r28 (which is basically correct), but then the "copy %r28,%r20" in > userspace moved "-ERESTARTSYS" back into %r20, jumped into the kernel, and the > kernel (correctly) reported back "ENOSYS" since there is no such syscall > number with the value of "-ERESTARTSYS". > The problem: %r28 is of course not one of the registers which is being restored. > Quite complicated... I hope I could explain it somewhat...? So, the patch doesn't work and we need to fix glibc. The only other solution is to load %r20 into %r28 and restore %r28 on a syscall restart. Dave -- John David Anglin dave.anglin@xxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
