linux-kernel - Re: 3.0.0-rc2-git1 -- BUG: sleeping function called from invalid context at mm/slub.c:847

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 8 Jun 2011 14:34:29 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Matt Mackall <mpm@...enic.com>, David Howells <dhowells@...hat.com>
cc:	Miles Lane <miles.lane@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Pekka Enberg <penberg@...nel.org>,
	John Johansen <john.johansen@...onical.com>
Subject: Re: 3.0.0-rc2-git1 -- BUG: sleeping function called from invalid
 context at mm/slub.c:847

On Wed, 8 Jun 2011, Matt Mackall wrote:

> > Not sure why this ever actually worked with apparmor if prepare_creds() 
> > does an unconditional GFP_KERNEL allocation since this codepath hasn't 
> > changed in at least a year and we're holding a spinlock from setrlimit.  
> > John?
> 
> Probably a lack of people enabling (and using!) both apparmor and
> might_sleep. I don't this would be caught by a randconfig boot test.
> 

Right, CONFIG_DEBUG_SPINLOCK_SLEEP isn't enabled by default even though 
CONFIG_DEBUG_KERNEL is.  We should probably just allow prepare_creds() to 
take a gfp_t argument just like security_prepare_creds() and change 
existing callers to use GFP_KERNEL with the exception of those using 
setrlimit where we're always holding the spinlock.  

Documentation/security/credentials.txt says this:

	To alter the current process's credentials, a function should first prepare a
	new set of credentials by calling:

        	struct cred *prepare_creds(void);   

	this locks current->cred_replace_mutex and then allocates and constructs a
	duplicate of the current process's credentials, returning with the mutex still
	held if successful.  It returns NULL if not successful (out of memory).

although that mutex doesn't exist.  David, any downsides to passing the 
gfp_t into prepare_creds()?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/