J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote:
> > > > No. I started bisecting, and it does appear to be a regression from the
> > > > cred patches, but at some point in the middle there it hangs on boot (a
> > > > softlockup report blames a spinlock in set_groups).
> > >
> > > Do you remember which patch you were at?
>
> More precisely:
> - The last working commit is b6dff3ec... "CRED: Separate task
> security context from task_struct".
> - The first commit exhibiting the permissions problem is
> a6f76f2... "CRED: Make execve() take advantage of
> copy-on-write credentials".
I presume by 'first' you mean 'latest'.
> - The 9 commits in between (from f1752eec to d84f4f9) result in
> a soft lookup on boot.
I think the problem may be that f1752eec removes the lock initialisation for
init_cred from the INIT_CRED() macro:
- .lock = __SPIN_LOCK_UNLOCKED(p.lock), \
but doesn't add it to the out of line init_cred:
+struct cred init_cred = {
+ .usage = ATOMIC_INIT(3),
+ .securebits = SECUREBITS_DEFAULT,
+ .cap_inheritable = CAP_INIT_INH_SET,
+ .cap_permitted = CAP_FULL_SET,
+ .cap_effective = CAP_INIT_EFF_SET,
+ .cap_bset = CAP_INIT_BSET,
+ .user = INIT_USER,
+ .group_info = &init_groups,
+};
Can you try adding:
.lock = __SPIN_LOCK_UNLOCKED(init_cred.lock),
to that and also add:
spin_lock_init(&pcred->lock);
into copy_creds() see if the problem goes away?
I'm a bit surprised that lockdep doesn't bark at this one - I thought it
checked for lock initialisation.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
