Date: Fri, 17 Oct 2014 11:21:07 -0700 From: Xin Li <delphij@delphij.net> To: John Baldwin <jhb@freebsd.org>, freebsd-hackers@freebsd.org Cc: Navdeep Parhar <np@freebsd.org> Subject: Re: panic in ivy_rng_store() when compiled with -O0 Message-ID: <54415E13.4000203@delphij.net> In-Reply-To: <2533199.DHZybpy49d@ralph.baldwin.cx> References: <54384ABD.5080806@FreeBSD.org> <2533199.DHZybpy49d@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10/17/14 08:53, John Baldwin wrote: > On Friday, October 10, 2014 02:08:13 PM Navdeep Parhar wrote: >> I built my kernel + modules (head as of today) with -O0 and now >> it panics during boot. I did bump up KSTACK_PAGES significantly >> so that's not the problem. I'm going to take out the RNG device >> next and see if I can get past this. >> >> Regards, Navdeep >> >> Fatal trap 9: general protection fault while in kernel mode cpuid >> = 0; apic id = 00 instruction pointer = 0x20:0xffffffff814ac661 >> stack pointer = 0x28:0xfffffe01ed6c6930 frame pointer >> = 0x28:0xfffffe01ed6c6960 code segment = base 0x0, limit >> 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 current >> process = 14 (rand_harvestq) [ thread pid 14 tid 100017 ] >> Stopped at ivy_rng_store+0x31: movq %rdi,(%rdi) db> >> bt Tracing pid 14 tid 100017 td 0xfffff800042c84c0 >> ivy_rng_store() at ivy_rng_store+0x31/frame 0xfffffe01ed6c6960 >> random_ivy_read() at random_ivy_read+0x78/frame >> 0xfffffe01ed6c6990 live_entropy_sources_feed() at >> live_entropy_sources_feed+0x73/frame 0xfffffe01ed6c69d0 >> random_kthread() at random_kthread+0x224/frame >> 0xfffffe01ed6c6a30 fork_exit() at fork_exit+0x14a/frame >> 0xfffffe01ed6c6ab0 fork_trampoline() at fork_trampoline+0xe/frame >> 0xfffffe01ed6c6ab0 --- trap 0, rip = 0, rsp = 0xfffffe01ed6c6b70, >> rbp = 0 --- > > Can you 'p $rdi'? movq %rdi,(%rdi) is obviously wrong (%rdi holds the result from rdrand), which I believed to be a compiler bug in register allocation. Navdeep have committed a change to mark 'tmp' input+output, which does fix the output but I'm not 100% sure if that's right, as 'tmp' is not considered an input of the inline assembler block, and this may break compile on other compilers, but for now it's better than previous situation. Speaking for the compiler issue, Dimitry have reported this upstream at: http://llvm.org/bugs/show_bug.cgi?id=21273 There is a suggestion in the reply, that change 'tmp' to early clobber would workaround the issue, like: Index: ivy.c =================================================================== - --- ivy.c (revision 273195) +++ ivy.c (working copy) @@ -79,7 +79,7 @@ "2:\n\t" "mov %2,%1\n\t" /* *buf = tmp */ "3:" - - : "+q" (retry), "=m" (*buf), "+q" (tmp) : : "cc"); + : "+q" (retry), "=m" (*buf), "=&q" (tmp) : : "cc"); return (retry); #else /* __GNUCLIKE_ASM */ return (0); A glance at the resulting assembler seems sane but I haven't got some time to carefully review the result yet. Cheers, - -- Xin LI <delphij@delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUQV4TAAoJEJW2GBstM+ns2BsP/0xOr27EWZ21ypSLxw9p0cnJ cEPVdi7ewOL3MM8Op91Ek30BFKsogM/JQWSYp9GCwyO5O1t7eGrCVCxUObkXWgZF wzSSvGGz4vkLoIcs22bXzfkkWeyMBxL/M0qlTYLT1hq/co5ARRy2XQ2kHp/zfn/0 xFumeoEaBdRAt9LKHdW/NYqyc6FPRilclftNgMQMYyQKehb5oNlj2WLST7ol9gHm VCZE2CfiHkLGxG8sW9QN8Si98jTjs7wPsVM/FBJBC8ABcIyf2urnx+vMcx5QGH/r cKWDqyX6coCGQ1mSTEitoU2E3PuGgEqFkzbctxA/mRVCw+f2XIzdyw86ImaOqOJH 6fP6WZnffV82WdgJEaNWI6EB8wuvS2Ic7tZUuKJU0KYCwU8E9hYAsUuzdWF76zm7 X8TU4LWfsX24CglJ/bNEHpWbCAXjQAblYxK7P1W1ppfHSm4pnBZWL7XADlDVAiYT GaVVVEX9pUQJC4lX84C+UvoBFHWnwyLzecMDGNEFaCey+KFkyaCHf2vaK/KK5Tzb oprFA9V9nl6P5ZvAU8EWnFsKZUh1y/8+C2d26m8kMYkp2IGex8zV9ivOh/WKhdSK 8oz3QlPq+A49SfZkK6HafTa4HTBgkkr22/Xh+MACbIdpV3lskSGZD+IRq8BKbVm/ sJh9aJMRPpQ/FfHWNnCF =aLJ0 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54415E13.4000203>