On Mon, Jan 29 2018, NeilBrown wrote: > On Thu, Jan 18 2018, Anna Schumaker wrote: > >> On 01/18/2018 01:39 PM, Anna Schumaker wrote: >>> Hi Neil, >>> >>> On 01/08/2018 12:26 AM, NeilBrown wrote: >>>> The SUNRPC credential framework was put together before >>>> Linux has 'struct cred'. Now that we have it, it makes sense to >>>> use it. >>>> This first step just includes a suitable 'struct cred *' pointer >>>> in every 'struct auth_cred' and almost every 'struct rpc_cred'. >>>> >>>> The rpc_cred used for auth_null has a NULL 'struct cred *' as nothing >>>> else really makes sense. >>>> >>>> For rpc_cred, the pointer is reference counted. >>>> For auth_cred it isn't. struct auth_cred are either allocated on >>>> the stack, in which case the thread owns a reference to the auth, >>>> or are part of 'struct generic_cred' in which case gc_base owns the >>>> reference and acred shares it. >> >> This patch is also causing a kernel panic for me if I mount using sec=krb5, run cthon tests, and then unmount. Here is the log message I'm getting: >> >> [ 82.599174] Kernel panic - not syncing: CRED: put_cred_rcu() sees 00000000f5847a57 with usage -1 >> [ 82.599174] >> [ 82.600227] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.15.0-rc7-ANNA+ #14336 >> [ 82.600801] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 >> [ 82.601435] Call Trace: >> [ 82.601639] <IRQ> >> [ 82.601830] dump_stack+0x5c/0x7e >> [ 82.602125] panic+0xdf/0x228 >> [ 82.602383] ? try_to_wake_up+0x24b/0x420 >> [ 82.602853] put_cred_rcu+0x8a/0x90 >> [ 82.603183] rcu_process_callbacks+0x1ab/0x4f0 >> [ 82.603577] __do_softirq+0xcc/0x305 >> [ 82.603881] irq_exit+0xa9/0xb0 >> [ 82.604159] smp_apic_timer_interrupt+0x5b/0x140 >> [ 82.604528] apic_timer_interrupt+0x98/0xa0 >> [ 82.604892] </IRQ> >> [ 82.605133] RIP: 0010:native_safe_halt+0x2/0x10 >> [ 82.605678] RSP: 0018:ffffffff82003ea8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff11 >> [ 82.606619] RAX: 0000000080000000 RBX: 0000000000000000 RCX: 0000000000000000 >> [ 82.607270] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 >> [ 82.608077] RBP: 0000000000000000 R08: 0000000000000002 R09: 000000000001ea40 >> [ 82.609066] R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 >> [ 82.609951] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 >> [ 82.610771] default_idle+0x15/0x120 >> [ 82.611128] do_idle+0x15c/0x1c0 >> [ 82.611371] cpu_startup_entry+0x6a/0x70 >> [ 82.611762] start_kernel+0x445/0x465 >> [ 82.612104] secondary_startup_64+0xa5/0xb0 >> [ 82.612561] Kernel Offset: disabled >> [ 82.612862] ---[ end Kernel panic - not syncing: CRED: put_cred_rcu() sees 00000000f5847a57 with usage -1 >> [ 82.612862] >> > > That's not good. > > I've just read through the patches again and didn't find anything that > could cause this, so I must have missed something. > > You say "This patch is also causing", but I assume it is the whole patch > set rather than just this one patch - is that correct? > > Also, have you run tests without sec=krb5 and not had the error? > > I'll try to set up some more thorough testing myself. I found the problem. The crdestroy for auth_gss takes a new reference on the auth, and then releases it again. As I was calling put_auth() on ->cr_auth before calling crdestrory, it got put twice. I've move the responsibility for calling put_auth() into the crdestroy function. It now passes connectathon with krb5 and krb5p and without, etc. I'll resend the series sometime next week, hopefully after getting some sort of response to the cred-improvement patches I posted. Thanks for your help, NeilBrown
Attachment:
signature.asc
Description: PGP signature
