On 10/25/2016 01:26 AM, Michael Cree wrote: > On Mon, Oct 24, 2016 at 08:13:22PM -0700, Richard Henderson wrote: >> On 10/24/2016 01:59 PM, Helge Deller wrote: >>> Does it only happens for __copy_user() ? >>> If yes, I assume the problem happens because of __copy_tofrom_user_nocheck() in >>> uaccess.h is always inlined. Maybe un-inlining helps? >>> Or, the inline-assembly for jsr/bsr needs tweeking ? >> >> Indeed. Try changing #ifdef MODULE above __copy_tofrom_user_nocheck to #if 1. > > Thanks, that indeed fixes it. > > While I have your ears (or eyes since this is email) I have been > running the ltp tests and noted some syscall test failures. The sendmsg > call fails with a segfault instead of returning EFAULT, when one passes > in a NULL for the message arg. When the test is run under gdb it > reports the segfault in the libc sendmsg function at the instruction > immediately following the syscall instruction and that instruction is a > move of a register to another register, not a memory access. Would I > be correct in surmising that the segfault actually occurred in kernel > code but gets reported at the instruction following the syscall > instruction in user space? That would be my assumption. > (But looking at the kernel source for > sys_sendmsg it looks to me that the msg argument is properly checked > before being accessed so why a segfault should occur is not > obvious...) Indeed, I don't see anything wrong with copy_msghdr_from_user. > > (I see fstatfs also segfaults when passed a bad pointer but that's > because libc does not pass the bad address to the kernel, but > passes the address of a temporary buffer from which libc then > copies back into the bad address, thus kaboom instead of EFAULT. > C'est la vie.) Yep. > > And while I mention gdb, it no longer works on Alpha since version > 7.10. Richard, would you be able to take a look at the bug report: > https://sourceware.org/bugzilla/show_bug.cgi?id=19061 Ah, yes. I'll put that on my to-do list. > And while I mention libc I am seeing (rather rare) random segfaults > in programs such as cp, tar, install and dpkg ever since the upgrade > to glibc 2.23 (or maybe it was 2.24). I am struggling to get a > backtrace because it only happens very occassionally (but often enough > that it is almost impossible for a build and install of large software > packages such as libreoffice to complete without failure at some > random point) and when I rerun the failing program manually it then > always works. I'll keep trying to narrow this one down. Hmm. I don't recall having seen such a thing. But then, I can't recall the last time I did anything more than test glibc in situ, which doesn't show these sorts of things. Perhaps I should do a test install to a sysroot or something... r~ -- 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
