NetBSD Problem Report #41874

From fair@clock.org  Wed Aug 12 01:30:13 2009
Return-Path: <fair@clock.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id B8A8663C270
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 12 Aug 2009 01:30:13 +0000 (UTC)
Message-Id: <20090812013009.76F5E15F8E5@cesium.clock.org>
Date: Tue, 11 Aug 2009 18:30:09 -0700 (PDT)
From: fair@netbsd.org
Reply-To: fair@netbsd.org
To: gnats-bugs@gnats.NetBSD.org
Subject: in-kernel NFS server hates network interface aliases
X-Send-Pr-Version: 3.95

>Number:         41874
>Category:       kern
>Synopsis:       in-kernel NFS server hates network interface aliases
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 12 01:35:00 +0000 2009
>Last-Modified:  Mon Sep 07 19:45:02 +0000 2009
>Originator:     Erik E. Fair
>Release:        NetBSD 5.0_STABLE
>Organization:
	The NetBSD Project
>Environment:
System: NetBSD digital.clock.org 5.0_STABLE NetBSD 5.0_STABLE (FLAPJACK2) #1: Wed Aug  5 16:42:56 PDT 2009 root@fast.clock.org:/var/obj/sys/arch/sparc64/compile/FLAPJACK2
Architecture: sparc64
Machine: sparc64

total memory = 2048 MB
mainbus0 (root): SUNW,UltraAX-i2 (Netra T1 200): hostid 0xdeadbeef
cpu0 at mainbus0: SUNW,UltraSPARC-IIe @ 500 MHz, UPA id 0
cpu0: 32K instruction (32 b/l), 16K data (32 b/l), 1024K external (64 b/l)

kernel config:

include	"arch/sparc64/conf/std.sparc64"
options 	INCLUDE_CONFIG_FILE	# embed config file in kernel binary
ident 		"FLAPJACK2"
maxusers	64
options 	SUN4U		# sun4u - UltraSPARC
config		netbsd	root on ? type ?
options 	KTRACE
options 	SYSVMSG		# System V message queues
options 	SYSVSEM		# System V semaphores
options 	SYSVSHM		# System V shared memory
options 	P1003_1B_SEMAPHORE	# p1003.1b semaphore support 
options 	USERCONF	# userconf(4) support
options 	SYSCTL_INCLUDE_DESCR	# Include sysctl descriptions in kernel
options 	NFS_BOOT_BOOTPARAM
options 	NFS_BOOT_DHCP
options 	DDB			# kernel dynamic debugger
options 	DDB_HISTORY_SIZE=100	# enable history editing in DDB
options 	DDB_VERBOSE_HELP	# enable verbose online help
options 	DIAGNOSTIC	# extra kernel sanity checking
options 	SCSIVERBOSE
options 	PCIVERBOSE
options 	MIIVERBOSE	# verbose PHY autoconfig messages
options 	COMPAT_43	# 4.3BSD system interfaces
options 	COMPAT_09	# NetBSD 0.9 binary compatibility
options 	COMPAT_10	# NetBSD 1.0 binary compatibility
options 	COMPAT_11	# NetBSD 1.1 binary compatibility
options 	COMPAT_12	# NetBSD 1.2 binary compatibility
options 	COMPAT_13	# NetBSD 1.3 binary compatibility
options 	COMPAT_14	# NetBSD 1.4 binary compatibility
options 	COMPAT_15	# NetBSD 1.5 binary compatibility
options 	COMPAT_16	# NetBSD 1.6 binary compatibility
options 	COMPAT_20	# NetBSD 2.0 binary compatibility
options 	COMPAT_30	# NetBSD 3.0 binary compatibility
options 	COMPAT_40	# NetBSD 4.0 binary compatibility
options 	COMPAT_SUNOS	# SunOS 4.x binary compatibility
options 	COMPAT_SVR4	# SunOS 5.x binary compatibility
options 	COMPAT_SVR4_32	# SunOS 5.x 32-bit binary compatibility -- 64-bit only
options 	COMPAT_NETBSD32	# NetBSD/sparc binary compatibility -- 64-bit only
options 	EXEC_AOUT	# execve(2) support for a.out binaries
options 	EXEC_ELF32	# Exec module for SunOS 5.x binaries.
options		COMPAT_BSDPTY	# /dev/[pt]ty?? ptys.
file-system	FFS		# Berkeley Fast Filesystem
file-system	NFS		# Sun NFS-compatible filesystem client
file-system	KERNFS		# kernel data-structure filesystem
file-system	NULLFS		# NULL layered filesystem
file-system 	OVERLAY		# overlay file system
file-system	MFS		# memory-based filesystem
file-system	FDESC		# user file descriptor filesystem
file-system	PROCFS		# /proc
file-system	CD9660		# ISO 9660 + Rock Ridge file system
file-system	UNION		# union file system
file-system	MSDOSFS		# MS-DOS FAT filesystem(s).
file-system	PTYFS		# /dev/pts/N support
file-system	SMBFS		# experimental - CIFS; also needs nsmb (below)
file-system	TMPFS		# Efficient memory file-system
file-system	PUFFS		# Userspace file systems (e.g. ntfs-3g & sshfs)
options 	NFSSERVER	# Sun NFS-compatible filesystem server
options 	QUOTA		# FFS quotas
options 	SOFTDEP		# FFS soft updates support.
options 	INET		# IP (Internet Protocol) v4
options 	IPSEC		# IP security
options 	IPSEC_ESP	# IP security (encryption part; define w/IPSEC)
options 	IPSEC_NAT_T	# IPsec NAT traversal (NAT-T)
options 	GATEWAY		# packet forwarding ("router switch")
options 	MROUTING	# packet forwarding of multicast packets
options 	PIM		# Protocol Independent Multicast
options 	NETATALK	# AppleTalk (over Ethernet) protocol
options 	NTP		# Network Time Protocol in-kernel support
options 	PPS_SYNC	# Add serial line synchronization for NTP
options 	PFIL_HOOKS	# Add pfil(9) hooks, intended for custom LKMs.
options 	IPFILTER_LOG	# Add ipmon(8) logging for ipfilter device
options 	IPFILTER_LOOKUP	# ippool(8) support
options 	PPP_BSDCOMP	# Add BSD compression to ppp device
options 	PPP_DEFLATE	# Add deflate (libz) compression to ppp device
options 	PPP_FILTER	# Add active filters for ppp (via bpf)
mainbus0 at root
cpu0	at mainbus0
psycho*	at mainbus0				# PCI-based systems
pci0	at psycho0				# FLAPJACK2 built-in
ppb0	at pci0 dev 1 function 1		# FLAPJACK2 built-in
ppb1	at pci0 dev 1 function 0		# FLAPJACK2 built-in
pci1	at ppb0					# FLAPJACK2 built-in
pci2	at ppb1					# FLAPJACK2 built-in
ppb*	at pci?					# `APB' support.
pci*	at ppb?
ebus*	at pci?					# ebus devices
pcons0	at mainbus0				# PROM console
auxio*	at ebus?				# auxio registers
lpt*	at ebus?				# parallel port
clock*	at ebus?
rtc*	at ebus?
timer*	at mainbus0				# sun4c
com*	at ebus?				# `com' driver for `su'
isp*	at pci? dev ? function ?	# Qlogic ISP [12]0x0 SCSI/FibreChannel
esiop0	at pci2 dev 8 function 0	# FLAPJACK2 built-in
esiop1	at pci2 dev 8 function 1	# FLAPJACK2 built-in
scsibus0 at esiop0			# FLAPJACK2 built-in
scsibus1 at esiop1			# FLAPJACK2 built-in
esiop*	at pci? 			# 53C875 and newer ("glm" compatible)
scsibus* at scsi?
sd0	at scsibus0 target 0 lun 0		# FLAPJACK2 built-in
sd1	at scsibus0 target 1 lun 0		# FLAPJACK2 built-in
sd*	at scsibus? target ? lun ?		# SCSI disks
cd*	at scsibus? target ? lun ?		# SCSI CD-ROMs
ses*	at scsibus? target ? lun ?		# SCSI SES/SAF-TE devices
uk*	at scsibus? target ? lun ?		# unknown SCSI
pciide* at pci? dev ? function ? flags 0x0000	# GENERIC pciide driver
aceride* at pci? dev ? function ?	# Acer Lab IDE controllers
atabus* at ata?
atapibus* at atapi?
wd*     at atabus? drive ? flags 0x0000
cd*	at atapibus? drive ? flags 0x0000	# ATAPI CD-ROM drives
sd*	at atapibus? drive ? flags 0x0000	# ATAPI disk drives
uk*	at atapibus? drive ? flags 0x0000	# ATAPI unknown
pseudo-device   accf_data		# "dataready" accept filter
pseudo-device   accf_http		# "httpready" accept filter
pseudo-device	vnd	
pseudo-device	ccd	4
options 	RAID_AUTOCONFIG		# auto-configuration of RAID components
hme*		at pci?	dev ? function ?	# network "hme" compatible
gem*	at pci? dev ? function ?	# Apple GMAC and Sun ERI gigabit enet
tlp*	at pci? dev ? function ?	# DECchip 21x4x and clones
wm*	at pci? dev ? function ?	# Intel 8254x gigabit
bge*	at pci? dev ? function ?	# Broadcom BM570x gigabit Ethernet
acphy*	at mii? phy ?			# Altima AC101 and AMD Am79c874 PHYs
bmtphy* at mii? phy ?			# Broadcom BCM5201 and BCM5202 PHYs
brgphy* at mii? phy ?			# Broadcom BCM5400-family PHYs
ciphy*	at mii? phy ?			# Cicada CS8201 Gig-E PHYs
dmphy*	at mii? phy ?			# Davicom DM9101 PHYs
exphy*	at mii? phy ?			# 3Com internal PHYs
icsphy*	at mii? phy ?			# Integrated Circuit Systems ICS189x
ikphy*	at mii? phy ?			# Intel 82563 PHYs
inphy*	at mii? phy ?			# Intel 82555 PHYs
iophy*	at mii? phy ?			# Intel 82553 PHYs
igphy*	at mii? phy ?			# Intel IGP01E1000
lxtphy*	at mii? phy ?			# Level One LXT-970 PHYs
makphy* at mii? phy ?			# Marvell Semiconductor 88E1000 PHYs
nsphy*	at mii? phy ?			# NS83840 PHYs
nsphyter* at mii? phy ?			# NS83843 PHYs
qsphy*	at mii? phy ?			# Quality Semiconductor QS6612 PHYs
rgephy* at mii? phy ?			# Realtek 8169S/8110S internal PHYs
rlphy*	at mii? phy ?			# Realtek 8139/8201L PHYs
sqphy*	at mii? phy ?			# Seeq 80220/80221/80223 PHYs
tlphy*	at mii? phy ?			# ThunderLAN PHYs
tqphy*	at mii? phy ?			# TDK Semiconductor PHYs
ukphy*	at mii? phy ?			# generic unknown PHYs
ohci*	at pci? dev ? function ?	# Open Host Controller
usb*	at ohci?
uhub*	at usb?
uhub*	at uhub? port ?
uhidev*	at uhub? port ? configuration ? interface ?
ucycom*	at uhidev? reportid ?
uhid*	at uhidev? reportid ?
ulpt*	at uhub? port ? configuration ? interface ?
umodem*	at uhub? port ? configuration ?
ucom*	at umodem?
umass*	at uhub? port ? configuration ? interface ?
wd*	at umass?
uaudio*	at uhub? port ? configuration ?
umidi* at uhub? port ? configuration ?
atu*	at uhub? port ?		# Atmel AT76C50XX based adapters
ral*	at uhub? port ?		# Ralink Technology RT25x0 802.11a/b/g
upl*	at uhub? port ?
ubsa*	at uhub? port ?		# Belkin serial adapter
ucom*	at ubsa? portno ?
uftdi*	at uhub? port ?		# FTDI FT8U100AX serial adapter
ucom*	at uftdi? portno ?
umct*	at uhub? port ?		# MCT USB-RS232 serial adapter
ucom*	at umct? portno ?
uplcom* at uhub? port ? 	# I/O DATA USB-RSAQ2 serial adapter
ucom*	at uplcom? portno ?
uvscom* at uhub? port ? 	# SUNTAC Slipper U VS-10U serial adapter
ucom*	at uvscom? portno ?
uscanner* at uhub? port ?
usscanner* at uhub? port ?
udsbr*	at uhub? port ?
radio*	at udsbr?
ugen*	at uhub? port ?
pseudo-device	loop
pseudo-device	ppp		
pseudo-device	pppoe
pseudo-device	tun		
pseudo-device	tap			# virtual Ethernet
pseudo-device	gre			# generic L3 over IP tunnel
pseudo-device	bpfilter
pseudo-device	agr			# IEEE 802.3ad link aggregation
pseudo-device	ipfilter
pseudo-device	gif			# IPv[46] over IPv[46] tunnel (RFC1933)
audio*		at audiobus?
midi*		at midibus?
options 	WSEMUL_SUN		# sun terminal emulation
options 	WS_DEFAULT_FG=WSCOL_BLACK
options 	WS_DEFAULT_BG=WSCOL_LIGHT_WHITE
options 	WSDISPLAY_COMPAT_USL		# VT handling
options 	WSDISPLAY_COMPAT_RAWKBD		# can get raw scancodes
options 	WSDISPLAY_DEFAULTSCREENS=4
options 	FONT_GALLANT12x22		# PROM font look-alike
alipm*		at pci?
iic*		at alipm?
spdmem*		at iic? addr 0x54
spdmem*		at iic? addr 0x55
spdmem*		at iic? addr 0x56
spdmem*		at iic? addr 0x57
admtemp*	at iic? addr 0x18
pseudo-device 	crypto			# /dev/crypto device
pseudo-device	swcrypto		# software crypto implementation
pseudo-device	pty			# pseudo-ttys (for network, etc.)
pseudo-device	rnd
pseudo-device	clockctl		# user control of clock subsystem
pseudo-device	ksyms			# /dev/ksyms
pseudo-device	fss		4	# file system snapshot device
pseudo-device	lockstat		# lock profiling
options		FILEASSOC		# fileassoc(9) - required for Veriexec 
pseudo-device	veriexec		1
options VERIFIED_EXEC_FP_RMD160
options VERIFIED_EXEC_FP_SHA256
options VERIFIED_EXEC_FP_SHA384
options VERIFIED_EXEC_FP_SHA512
options VERIFIED_EXEC_FP_SHA1
options VERIFIED_EXEC_FP_MD5
pseudo-device   nsmb		# experimental - SMB requester
pseudo-device	drvctl
pseudo-device	putter


>Description:
	My NFS server was pressed into service as the house router.

	Some time after adding the necessary network interface aliases, NetBSD
	panic'd, and continued to panic just before getty appeared on console
	at every subsequent reboot.  Starting in single user mode and
	attempting to diagnose which service/program was causing the problem
	yielded this:

112 # nfsd -r -t -u
113 # Aug 10 16:46:07 Reader / writer lock error: rw_vector_enter: locking against myself

lock address : 0x000000000ead0fb8
current cpu  :                  0
current lwp  : 0x000000000ead4860
owner/count  : 0x000000000ead4860 flags    : 0x0000000000000004

panic: lock error
Stopped in pid 186.2 (nfsd) at  netbsd:cpu_Debugger+0x4:        nop

	Turning off NFS service in /etc/rc.conf made the system stable, and
	I needed IP routing a bit more urgently than NFS service.

	I have now installed a replacement router, removed the network
	interface aliases from the NFS server, and turned NFS service back
	on. It appears as stable as it had been before.

>How-To-Repeat:
	1. set up an NFS server with multiple network interfaces and some clients.

	2. add network interface aliases for additional addresses
	(same respective subnets) on two interfaces with the intent
	that the NFS server also route IP packets between those
	two nets, in place of a router.

	3. observe "panic: lock error" on the NFS server console.

	4. curse loudly that you don't need this kind of software
	problem on top of all the other very urgent infrastructure
	failures you're dealing with.

>Fix:


>Audit-Trail:
From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/41874: in-kernel NFS server hates network interface aliases
Date: Wed, 12 Aug 2009 04:25:39 +0200

 On Wed, Aug 12, 2009 at 01:35:00AM +0000, fair@NetBSD.org wrote:
 > [...]
 > 
 > >Description:
 > 	My NFS server was pressed into service as the house router.
 > 
 > 	Some time after adding the necessary network interface aliases, NetBSD
 > 	panic'd, and continued to panic just before getty appeared on console
 > 	at every subsequent reboot.  Starting in single user mode and
 > 	attempting to diagnose which service/program was causing the problem
 > 	yielded this:
 > 
 > 112 # nfsd -r -t -u
 > 113 # Aug 10 16:46:07 Reader / writer lock error: rw_vector_enter: locking against myself
 > 
 > lock address : 0x000000000ead0fb8
 > current cpu  :                  0
 > current lwp  : 0x000000000ead4860
 > owner/count  : 0x000000000ead4860 flags    : 0x0000000000000004
 > 
 > panic: lock error
 > Stopped in pid 186.2 (nfsd) at  netbsd:cpu_Debugger+0x4:        nop

 Did you get a stack trace here ?

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Erik Fair <fair@netbsd.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org,
 kern-bug-people@NetBSD.org,
 gnats-admin@NetBSD.org,
 netbsd-bugs@NetBSD.org
Subject: Re: kern/41874: in-kernel NFS server hates network interface aliases
Date: Tue, 11 Aug 2009 21:52:10 -0700

 Yes, but this is not a GENERIC kernel, nor does it have DEBUG defined;  
 it's all just hex numbers. That's why I didn't include it or the  
 registers in the problem report.

 	Erik <fair@netbsd.org>

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Erik Fair <fair@netbsd.org>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
        netbsd-bugs@netbsd.org
Subject: Re: kern/41874: in-kernel NFS server hates network interface aliases
Date: Wed, 12 Aug 2009 12:21:41 +0200

 On Tue, Aug 11, 2009 at 09:52:10PM -0700, Erik Fair wrote:
 > Yes, but this is not a GENERIC kernel, nor does it have DEBUG defined;  
 > it's all just hex numbers. That's why I didn't include it or the  
 > registers in the problem report.

 ddb can't read the symbol table on sparc64 ?
 Anyway you should be able to map it back to functions names with gdb,
 isn't it ? the interesting part is what tried to take the lock.

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Martin Husemann <martin@duskware.de>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: Erik Fair <fair@netbsd.org>, gnats-bugs@netbsd.org,
	kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/41874: in-kernel NFS server hates network interface aliases
Date: Wed, 12 Aug 2009 12:27:50 +0200

 On Wed, Aug 12, 2009 at 12:21:41PM +0200, Manuel Bouyer wrote:
 > ddb can't read the symbol table on sparc64 ?

 Of course it can.

 Martin

From: "Erik E. Fair" <fair@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/41874: in-kernel NFS server hates network interface aliases 
Date: Wed, 12 Aug 2009 11:55:36 -0700

 112 # nfsd -r -t -u
 113 # Aug 10 16:46:07 Reader / writer lock error: rw_vector_enter: locking against myself

 lock address : 0x000000000ead0fb8
 current cpu  :                  0
 current lwp  : 0x000000000ead4860
 owner/count  : 0x000000000ead4860 flags    : 0x0000000000000004

 panic: lock error
 Stopped in pid 186.2 (nfsd) at  netbsd:cpu_Debugger+0x4:        nop
 db> trace
 lockdebug_abort(ead0fb8, 1812320, 1385f58, 147b240, d207f40, 18a0400) at netbsd: lockdebug_abort+0x24
 rw_vector_enter(ead0fb8, 1, 0, 1, 0, eb8d018) at netbsd:rw_vector_enter+0x188
 vlockmgr(ead0fb8, 2, ead4860, ead4864, 0, 1896110) at netbsd:vlockmgr+0x13c
 VOP_LOCK(ead0eb0, 2, 2, eb8d270, d1e7da4, 0) at netbsd:VOP_LOCK+0x58
 vn_lock(ead0eb0, 20002, eb8d3b0, 4, 8000, d1e7f30) at netbsd:vn_lock+0xf0
 ufs_lookup(0, 0, c, 7fff, 1, 2) at netbsd:ufs_lookup+0x9d0
 VOP_LOOKUP(ead0eb0, eb8d9a0, eb8d9c8, 1485600, eb8d558, 0) at netbsd:VOP_LOOKUP+0xa0
 lookup(eb8d978, 0, eb8d568, 20, d2282e0, 0) at netbsd:lookup+0x2b0
 nfs_namei(0, eb8da00, 2, e96a800, 4105b70, eb8da48) at netbsd:nfs_namei+0x234
 nfsrv_lookup(2, e96a800, ead4860, eb8db58, eb8da78, 4105b70) at netbsd:nfsrv_lookup+0x270
 nfssvc_nfsd(0, 40dffbe0, ead4860, eb8a000, 0, 1896110) at netbsd:nfssvc_nfsd+0x1a0
 sys_nfssvc(0, eb8ddc0, eb8de00, 1, 2029c0, 0) at netbsd:sys_nfssvc+0x27c
 syscall_plain(eb8ded0, 2, 4073fe88, eb8ddc0, 1, 4073fe88) at netbsd:syscall_plain+0x134
 ?(4, 40dffbe0, fffffffffffffff8, 0, 40dffbe0, 0) at 0x1008c98
 db> show regs
 No such command: regs
 db> show reg
 tstate      0x1d000603
 pc          0x1302424   cpu_Debugger+0x4
 npc         0x1302428   cpu_Debugger+0x8
 ipl         0
 y           0
 g0          0
 g1          0x1
 g2          0x92
 g3          0xe0006000
 g4          0x1fe020003fd
 g5          0x1fe020003f8
 g6          0
 g7          0x101350
 o0          0x14af5b0   copyright+0x5e5c0
 o1          0xeb8cef8
 o2          0
 o3          0
 o4          0xeb8cef8
 o5          0
 o6          0xeb8c5a1
 o7          0x1223b28   panic+0x208
 l0          0
 l1          0x28
 l2          0x20e320000020
 l3          0
 l4          0
 l5          0
 l6          0
 l7          0xdf3ec0000
 i0          0x1c1400000
 i1          0x1c1418000
 i2          0xd20fb2000
 i3          0
 i4          0
 i5          0
 i6          0xe3b800000
 i7          0x100
 f0          0
 f2          0
 f4          0
 f6          0
 f8          0
 f10         0
 f12         0
 f14         0
 f16         0
 f18         0
 f20         0
 f22         0
 f24         0
 f26         0
 f28         0
 f30         0
 f32         0
 f34         0
 f36         0
 f38         0
 f40         0
 f42         0
 f44         0
 f46         0
 f48         0
 f50         0
 f52         0
 f54         0
 f56         0
 f58         0
 f60         0
 f62         0
 fsr         0
 gsr         0
 netbsd:cpu_Debugger+0x4:        nop

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/41874: in-kernel NFS server hates network interface
	aliases
Date: Sun, 16 Aug 2009 05:26:03 +0000

 On Wed, Aug 12, 2009 at 07:00:09PM +0000, Erik E. Fair wrote:
  >  VOP_LOCK(ead0eb0, 2, 2, eb8d270, d1e7da4, 0) at netbsd:VOP_LOCK+0x58
  >  vn_lock(ead0eb0, 20002, eb8d3b0, 4, 8000, d1e7f30) at netbsd:vn_lock+0xf0
  >  ufs_lookup(0, 0, c, 7fff, 1, 2) at netbsd:ufs_lookup+0x9d0
  >  VOP_LOOKUP(ead0eb0, eb8d9a0, eb8d9c8, 1485600, eb8d558, 0) at netbsd:VOP_LOOKUP+0xa0
  >  lookup(eb8d978, 0, eb8d568, 20, d2282e0, 0) at netbsd:lookup+0x2b0
  >  nfs_namei(0, eb8da00, 2, e96a800, 4105b70, eb8da48) at netbsd:nfs_namei+0x234
  >  nfsrv_lookup(2, e96a800, ead4860, eb8db58, eb8da78, 4105b70) at netbsd:nfsrv_lookup+0x270
  >  nfssvc_nfsd(0, 40dffbe0, ead4860, eb8a000, 0, 1896110) at netbsd:nfssvc_nfsd+0x1a0

 ... how on earth can interface aliases cause it to croak in namei?

 -- 
 David A. Holland
 dholland@netbsd.org

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
        fair@NetBSD.org
Subject: Re: kern/41874: in-kernel NFS server hates network interface aliases
Date: Sun, 16 Aug 2009 12:26:23 +0200

 On Sun, Aug 16, 2009 at 05:30:04AM +0000, David Holland wrote:
 > The following reply was made to PR kern/41874; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: kern/41874: in-kernel NFS server hates network interface
 > 	aliases
 > Date: Sun, 16 Aug 2009 05:26:03 +0000
 > 
 >  On Wed, Aug 12, 2009 at 07:00:09PM +0000, Erik E. Fair wrote:
 >   >  VOP_LOCK(ead0eb0, 2, 2, eb8d270, d1e7da4, 0) at netbsd:VOP_LOCK+0x58
 >   >  vn_lock(ead0eb0, 20002, eb8d3b0, 4, 8000, d1e7f30) at netbsd:vn_lock+0xf0
 >   >  ufs_lookup(0, 0, c, 7fff, 1, 2) at netbsd:ufs_lookup+0x9d0
 >   >  VOP_LOOKUP(ead0eb0, eb8d9a0, eb8d9c8, 1485600, eb8d558, 0) at netbsd:VOP_LOOKUP+0xa0
 >   >  lookup(eb8d978, 0, eb8d568, 20, d2282e0, 0) at netbsd:lookup+0x2b0
 >   >  nfs_namei(0, eb8da00, 2, e96a800, 4105b70, eb8da48) at netbsd:nfs_namei+0x234
 >   >  nfsrv_lookup(2, e96a800, ead4860, eb8db58, eb8da78, 4105b70) at netbsd:nfsrv_lookup+0x270
 >   >  nfssvc_nfsd(0, 40dffbe0, ead4860, eb8a000, 0, 1896110) at netbsd:nfssvc_nfsd+0x1a0
 >  
 >  ... how on earth can interface aliases cause it to croak in namei?

 FWIW, I have a 5.0_STABLE/i386 NFS server running with interface
 aliases. 

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: "Erik E. Fair" <fair@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, netbsd-bugs@netbsd.org
Subject: Re: kern/41874: in-kernel NFS server hates network interface aliases 
Date: Sun, 16 Aug 2009 09:38:25 -0700

 	Date: Sun, 16 Aug 2009 05:30:04 +0000 (UTC)
 	From: David Holland <dholland-bugs@netbsd.org>

 	 ... how on earth can interface aliases cause it to croak in namei?

 I don't know - I merely observe & report the problem behavior, and the only
 change to system configuration that I presume caused it.

 It is important to note that the NFS server was routing IP packets between
 two interfaces, in addition to serving up NFS - the interface alias addresses
 were those of my house router on two physically separate networks which the
 NFS server also had its own interfaces and addresses on; This is not merely
 a matter of an NFS server with one or more additional interface aliases.

 Further, now that I have a dedicated router deployed once again and the
 interface alias addresses have been removed from the NFS server (and its NFS
 services turned back on), it is stable once again. So, I think there is a
 pretty strong circumstantial case linking this particular configuration change
 and the subsequent locking panics.

 	Erik <fair@netbsd.org>

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/41874: in-kernel NFS server hates network interface
	aliases
Date: Sun, 16 Aug 2009 17:39:20 +0000

 On Sun, Aug 16, 2009 at 04:40:03PM +0000, Erik E. Fair wrote:
  > So, I think there is a pretty strong circumstantial case linking
  > this particular configuration change and the subsequent locking
  > panics.

 Sure; it just doesn't make any sense.

 -- 
 David A. Holland
 dholland@netbsd.org

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, fair@netbsd.org
Subject: Re: kern/41874: in-kernel NFS server hates network interface aliases
Date: Sun, 16 Aug 2009 20:34:50 +0100

 On Sun, Aug 16, 2009 at 05:40:04PM +0000, David Holland wrote:
 > The following reply was made to PR kern/41874; it has been noted by GNATS.
 > 
 > From: David Holland <dholland-bugs@netbsd.org>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: kern/41874: in-kernel NFS server hates network interface
 > 	aliases
 > Date: Sun, 16 Aug 2009 17:39:20 +0000
 > 
 >  On Sun, Aug 16, 2009 at 04:40:03PM +0000, Erik E. Fair wrote:
 >   > So, I think there is a pretty strong circumstantial case linking
 >   > this particular configuration change and the subsequent locking
 >   > panics.
 >  
 >  Sure; it just doesn't make any sense.

 Maybe the problem is that there is a code path in NFS that is failing to
 release the lock ?
 Only when the same process tries to acquire it does the 'locking
 against myself' trap happen - other processes will just sleep.

 	David

 -- 
 David Laight: david@l8s.co.uk

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, fair@netbsd.org
Subject: Re: kern/41874: in-kernel NFS server hates network interface
	aliases
Date: Mon, 7 Sep 2009 19:42:36 +0000

 On Sun, Aug 16, 2009 at 07:40:05PM +0000, David Laight wrote:
  > > > So, I think there is a pretty strong circumstantial case linking
  > > > this particular configuration change and the subsequent locking
  > > > panics.
  > >  
  > >  Sure; it just doesn't make any sense.
  >  
  >  Maybe the problem is that there is a code path in NFS that is failing to
  >  release the lock ?
  >  Only when the same process tries to acquire it does the 'locking
  >  against myself' trap happen - other processes will just sleep.

 Yeah, but why would interface aliases tickle it? That's the part that
 doesn't make sense.

 -- 
 David A. Holland
 dholland@netbsd.org

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.