Date: Wed, 20 Dec 2017 09:14:07 -0800 From: John Baldwin <jhb@freebsd.org> To: David Chisnall <theraven@freebsd.org> Cc: Eugene Grosbein <eugen@grosbein.net>, Konstantin Belousov <kostikbel@gmail.com>, Conrad Meyer <cem@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r326758 - in head/sys/i386: conf include Message-ID: <1839614.eNG2DjLqvF@ralph.baldwin.cx> In-Reply-To: <68FECEF0-014E-4741-BE96-680E9338557B@FreeBSD.org> References: <201712110432.vBB4WbnE021090@repo.freebsd.org> <1705b795-46ca-bb27-6ba7-fab4eeed0aba@FreeBSD.org> <68FECEF0-014E-4741-BE96-680E9338557B@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, December 20, 2017 09:59:26 AM David Chisnall wrote: > On 16 Dec 2017, at 18:05, John Baldwin <jhb@FreeBSD.org> wrote: > >=20 > > When I build a FreeBSD/mips64 kernel with clang, > > _any_ simple NFS op triggers a kernel stack overflow. Kernels comp= iled > > with GCC do not. >=20 > That is not my experience. I haven=E2=80=99t tried a MIPS64 kernel b= uilt with clang, but with in-tree gcc I get kernel panics as soon as I = try to use NFS, unless I use Stacey=E2=80=99s patches that increase the= kernel stack size. I have primarily been using modern GCC for GCC once that was working, b= ut at least when running a MALTA64 kernel under qemu I was not triggering pan= ics even with old GCC. With the in-tree clang 5.0 or with CHERI clang, jus= t doing an 'ls' of a NFS directory or even a tab-complete of a path that is on NFS reliably triggers a kernel stack overflow for MALTA64 in qemu= . With Stacey's kstack pages, a clang kernel does survive, but those are = not in stock FreeBSD which is where I have been testing this. --=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1839614.eNG2DjLqvF>