misc/164565: kernel crash when kldunload'ing padlock

[Patrick Lamaiziere]

The following reply was made to PR kern/164565; it has been noted by GNATS.

From: Patrick Lamaiziere <patfbsd at davenulle.org>
To: bug-followup at freebsd.org <bug-followup at freebsd.org>
Cc: Stefan Krueger <stadtkind2 at gmx.de>, pjd at freebsd.org
Subject: Re: misc/164565: kernel crash when kldunload'ing padlock
Date: Sun, 29 Jan 2012 21:17:02 +0100

 --MP_/G4rR5p6WaSeS.e5_cqECYO.
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: 8bit
 Content-Disposition: inline
 
 Le Sun, 29 Jan 2012 19:30:15 GMT,
 Stefan Krueger <stadtkind2 at gmx.de> a écrit :
 
 > The following reply was made to PR kern/164565; it has been noted by
 > GNATS.
 > 
 > From: Stefan Krueger <stadtkind2 at gmx.de>
 > To: bug-followup at FreeBSD.org
 > Cc: Patrick Lamaiziere <patfbsd at davenulle.org>
 > Subject: Re: misc/164565: kernel crash when kldunload'ing padlock
 > Date: Sun, 29 Jan 2012 20:23:20 +0100
 > 
 >  > > Unloading the padlock kernel module makes the kernel crash.
 
 >  I get a backtrace indeed:
 >  
 >  # kldunload padlock
 >  panic: rw lock 0xfffffe00019a2698 not unlocked
 >  cpuid = 0
 >  KDB: stack backtrace:
 >  #0 0xffffffff8049822e at kdb_backtrace+0x5e
 >  #1 0xffffffff80460d57 at panic+0x187
 >  #2 0xffffffff8045fa84 at rw_destroy+0x34
 >  #3 0xffffffff80baa848 at padlock_detach+0x108
 >  #4 0xffffffff804919e4 at device_detach+0x94
 >  #5 0xffffffff80491c80 at devclass_driver_deleted+0x70
 >  #6 0xffffffff80491da1 at devclass_delete_driver+0x51
 >  #7 0xffffffff80491fad at driver_module_handler+0x14d
 >  #8 0xffffffff8044fc05 at module_unload+0x35
 >  #9 0xffffffff8044592b at linker_file_unload+0x16b
 >  #10 0xffffffff80446513 at kern_kldunload+0xf3
 >  #11 0xffffffff8063eea3 at amd64_syscall+0x313
 >  #12 0xffffffff80629f07 at Xfast_syscall+0xf7
 >  Uptime: 31s
 >  Automatic reboot in 15 seconds - press a key on the console to abort
 >  
 >  Padlock is not in use (i.e. I netbooted a freebsd 9.0 kernel into
 >  single-user, so no IPSEC, no GELI, no nothing at that point)
 
 Please try the attached patch.
 
 The rw_wlock at the beginning of padlock_detach() is not unlocked before
 it is destroyed.
 
 I think I've spotted this but forget to report when I did glxsb(4) (it
 is ok in glxsb_detach() and it detachs properly).
 
 I put Pawel Jakub Dawidek in copy.
 
 Thanks, regards.
 
 --MP_/G4rR5p6WaSeS.e5_cqECYO.
 Content-Type: text/plain
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment; filename=patch.txt
 
 --- /usr/src/sys/crypto/via/padlock.c~	2011-09-23 02:51:37.000000000 +0200
 +++ /usr/src/sys/crypto/via/padlock.c	2012-01-29 20:56:05.238878471 +0100
 @@ -158,6 +158,7 @@ padlock_detach(device_t dev)
  		TAILQ_REMOVE(&sc->sc_sessions, ses, ses_next);
  		free(ses, M_PADLOCK);
  	}
 +	rw_wunlock(&sc->sc_sessions_lock);	
  	rw_destroy(&sc->sc_sessions_lock);
  	crypto_unregister_all(sc->sc_cid);
  	return (0);
 
 --MP_/G4rR5p6WaSeS.e5_cqECYO.--