Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502

Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502

[Herbert Xu]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

Guys, please CC netdev on issues like this.

On Tue, May 17, 2005 at 05:43:00PM +0000, Chris Wright wrote:
> 
> This has some issues w.r.t. truesize and socket buffer space.  The trim
> is done to keep accounting sane, so we'd either have to trim ourselves
> or take into account the change in size.  And ultimately, we'd still get
> trimmed by netlink, so the GFP issue is still there.  Ideally, gfp_any()
> would really be _any_

The trimming is completely optional.  That is, if the allocation fails
nothing bad will happen.  So the solution is to simply use GFP_ATOMIC.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[-- Attachment #2: p --]
[-- Type: text/plain, Size: 277 bytes --]

--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -673,7 +673,7 @@ int netlink_unicast(struct sock *ssk, st
 	int err;
 	long timeo;
 
-	skb = netlink_trim(skb, gfp_any());
+	skb = netlink_trim(skb, GFP_ATOMIC);
 
 	timeo = sock_sndtimeo(ssk, nonblock);
 retry:

Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502

[Chris Wright]

* Herbert Xu (herbert@gondor.apana.org.au) wrote:
> Guys, please CC netdev on issues like this.

Sorry Herbert, we hadn't yet concluded that it's not an issue that we
need to resolve within audit.

> On Tue, May 17, 2005 at 05:43:00PM +0000, Chris Wright wrote:
> > 
> > This has some issues w.r.t. truesize and socket buffer space.  The trim
> > is done to keep accounting sane, so we'd either have to trim ourselves
> > or take into account the change in size.  And ultimately, we'd still get
> > trimmed by netlink, so the GFP issue is still there.  Ideally, gfp_any()
> > would really be _any_
> 
> The trimming is completely optional.  That is, if the allocation fails
> nothing bad will happen.  So the solution is to simply use GFP_ATOMIC.

Well, it does more pressure on atomic pool (for those cases that
GFP_KERNEL would have sufficed).

thanks,
-chris

Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502

[David Woodhouse]

On Wed, 2005-05-18 at 10:00 -0700, Chris Wright wrote:
> * Herbert Xu (herbert@gondor.apana.org.au) wrote:
> > Guys, please CC netdev on issues like this.
> 
> Sorry Herbert, we hadn't yet concluded that it's not an issue that we
> need to resolve within audit.

I suspect that it _is_ an issue we can resolve entirely within audit
code. See the patch I posted half an hour or so ago to the linux-audit
list. If we agree on that approach, I'll do the equivalent for the git
tree either later this evening or tomorrow.

I've reverted your recent change to put audit messages directly into
skbs "in order to eliminate the extra copy", on the basis that it
blatantly wasn't having that effect anyway. Now we copy from the
audit_buffer into an optimally-sized skb which netlink_trim() won't have
to mangle. I've also removed the skb_get() immediately before
netlink_send() which always made me unhappy.

-- 
dwmw2

Re: 2.6.12-rc4-mm2 - sleeping function called from invalid context at mm/slab.c:2502

[Herbert Xu]

On Wed, May 18, 2005 at 06:52:35PM +0100, David Woodhouse wrote:
> 
> I've reverted your recent change to put audit messages directly into
> skbs "in order to eliminate the extra copy", on the basis that it
> blatantly wasn't having that effect anyway. Now we copy from the
> audit_buffer into an optimally-sized skb which netlink_trim() won't have
> to mangle. I've also removed the skb_get() immediately before
> netlink_send() which always made me unhappy.

Even if the audit code is never going to call netlink_unicast with
spin locks held, we simply cannot assume that for all current and
future users of netlink_unicast.

As a consequence we can't use gfp_any() in netlink_unicast.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt