Unloading the padlock kernel module makes the kernel crash. dmesg: CPU: VIA Nano X2 L4050 @ 1.4 GHz (1400.09-MHz K8-class CPU) Origin = "CentaurHauls" Id = 0x6fc Family = 6 Model = f Stepping = 12 Features=0xbfc9fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x8863a9<SSE3,MON,VMX,EST,TM2,SSSE3,CX16,xTPR,SSE4.1,POPCNT> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> VIA Padlock Features=0x1ec33dcc<RNG,AES,AES-CTR,SHA1,SHA256,RSA> TSC: P-state invariant How-To-Repeat: kldunload padlock
Le Sat, 28 Jan 2012 09:56:38 GMT, Stefan Krüger <stadtkind2@gmx.de> a écrit : > Unloading the padlock kernel module makes the kernel crash. Do you have a panic or there is just a crash without information? If it panics, a back trace would be helpful, see http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html Are you using padlock (ipsec?) when unloading? Regards.
> > Unloading the padlock kernel module makes the kernel crash. > Do you have a panic or there is just a crash without information? > If it panics, a back trace would be helpful, see > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html > Are you using padlock (ipsec?) when unloading? > Regards. Hi Patrick, thanks for fast reply. 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) I'm pretty sure I could get a crashdump if you need one. Regards
Le Sun, 29 Jan 2012 19:30:15 GMT, Stefan Krueger <stadtkind2@gmx.de> a écrit : > The following reply was made to PR kern/164565; it has been noted by > GNATS. > > From: Stefan Krueger <stadtkind2@gmx.de> > To: bug-followup@FreeBSD.org > Cc: Patrick Lamaiziere <patfbsd@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.
On Sun, 29 Jan 2012, Patrick Lamaiziere wrote: > Le Sun, 29 Jan 2012 19:30:15 GMT, > Stefan Krueger <stadtkind2@gmx.de> a écrit : > > > The following reply was made to PR kern/164565; it has been noted by > > GNATS. > > > > From: Stefan Krueger <stadtkind2@gmx.de> > > To: bug-followup@FreeBSD.org > > Cc: Patrick Lamaiziere <patfbsd@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. > --- /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); Hi Patrick, thanks for your patch! It works, no more panics when kldunload'ing padlock :)
For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open"
Keyword: crash – in lieu of summary line prefix: [panic] * bulk change for the keyword * summary lines may be edited manually (not in bulk). Keyword descriptions and search interface: <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>
The commit 1b0909d51a8a (OpenCrypto: Convert sessions to opaque handles instead of integers) removed the sc_sessions_lock in struct padlock_softc. Then the patch is not needed any more. I believe this issue no longer persists. Closing. Also CC the author Conrad of the above commit.