Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Dec 2009 15:13:15 +0100 (CET)
From:      Manuel Schiller <mala@hinterbergen.de>
To:        FreeBSD-gnats-submit@FreeBSD.org
Cc:        Manuel Schiller <mala@hinterbergen.de>
Subject:   sparc64/142102: FreeBSD 8.0 kernel panics on sparc64 when accessing NFS
Message-ID:  <20091228141315.8D83B5C04@router.hinter.bergen2>
Resent-Message-ID: <200912281430.nBSEU1se073510@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         142102
>Category:       sparc64
>Synopsis:       FreeBSD 8.0 kernel panics on sparc64 when accessing NFS
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-sparc64
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Dec 28 14:30:01 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Manuel Schiller
>Release:        FreeBSD 8.0-RELEASE-p1 sparc64
>Organization:
(none)
>Environment:
System: FreeBSD router.hinter.bergen2 8.0-RELEASE-p1 FreeBSD 8.0-RELEASE-p1 #4: Mon Dec 28 11:53:32 CET 2009 root@router.hinter.bergen2:/usr/obj/usr/src/sys/FENCHURCH sparc64


	The machine is a SUN Netra T1 running FreeBSD 8.0. The kernel
	configuration is almost what ships as GENERIC, only a few unneeded NIC
	drivers have been removed, and KDB and DDB have been enabled.

>Description:
	The kernel panics due to an unaligned memory access in the NFS server
	code. I could trace the problem to the statement on line 209 of
	sys/nfsserver/nfs_fha.c which does not satify the alignment requirements
	which sparc64 imposes.

	The backtrace I get from my kernel is below (sorry, kgdb does not work
	properly on sparc64, so I have to use the in-kernel backtrace...):

	panic: trap: memory address not aligned
	cpuid = 0
	KDB: stack backtrace:
	panic() at panic+0x1c8
	trap() at trap+0x4d0
	-- memory address not aligned sfar=0xd6663424 sfsr=0x40029 %o7=0xc051b86c --
	fha_assign() at fha_assign+0x140
	svc_run_internal() at svc_run_internal+0x71c
	svc_thread_start() at svc_thread_start+0x8
	fork_exit() at fork_exit+0x80
	fork_trampoline() at fork_trampoline+0x8
	Uptime: 1m12s
	Dumping 512 MB (2 chunks)
	  chunk at 0: 268435456 bytes |\

	If you need anything or want something tested, please let me know.

>How-To-Repeat:
	Enable the NFS server options in /etc/rc.d on a sparc64 machine
	and try to mount any NFS share from a different machine.

>Fix:
	Replace the assignment on line 209 of sys/nfsserver/nfs_fha.c
	with a call to memcpy, i.e. something like:

	memcpy(&i->fh, &fh.fh_generic.fh_fid.fid_data,
			sizeof(const u_int64_t *));

	This is ugly, but will work for all architectures, regardless of
	alignment constraints imposed. This is likely to be a little
	slower than the original code, but I doubt the difference will be
	noticeable (we're talking about different ways to copy eight
	bytes, so the code would have to be called in a very tight loop
	for things to become noticeably slower).

	The issue with the original assignment is that the structs in
	question do not satisfy the alignment contstraints on sparc64
	for reading a pointer from fid_data. Instead of playing with
	the struct to get the alignment right, it seemed safer to me to
	use a memcpy here, since in future modifications of the struct,
	the alignment constraints are most likely not at the front of the
	mind of the person doing the modification.

	The change has been tested on sparc64 for half a day, and things
	seem to be running smoothly.
>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091228141315.8D83B5C04>