Messages in this thread | | | Date | Wed, 8 Jun 2011 14:34:29 -0700 (PDT) | From | David Rientjes <> | 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()?
| |