Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley
	Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United
	Kingdom.
	Registered in England and Wales under Company Registration No. 3798903
From: David Howells <dhowells@redhat.com>
In-Reply-To: <20090103184921.GB20166@fieldses.org>
References: <20090103184921.GB20166@fieldses.org> <20090102051905.GC1073@fieldses.org> <20090101235332.GA31840@fieldses.org> <24959.1230694093@redhat.com> <20081230134248.GA30124@lst.de> <21275.1230736542@redhat.com> <29449.1230859152@redhat.com> <32481.1230897578@redhat.com> <20090102164505.GA10465@fieldses.org> 
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: dhowells@redhat.com, Christoph Hellwig <hch@lst.de>, jmorris@namei.org,
       linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] CRED: Fix regression in cap_capable() as shown up by sys_faccessat() [ver #2]
Date: Mon, 05 Jan 2009 13:11:01 +0000
Message-ID: <18074.1231161061@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1785
Lines: 57

J. Bruce Fields <bfields@fieldses.org> 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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/