netdev
[Top] [All Lists]

Re: Fwd: [2.6] ethertap and af_inet.c assertion failures

To: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Subject: Re: Fwd: [2.6] ethertap and af_inet.c assertion failures
From: Tommy Christensen <tommy.christensen@xxxxxxxxx>
Date: Sat, 15 Jan 2005 21:20:42 +0100
Cc: simon.roscic@xxxxxxxxx, netdev@xxxxxxxxxxx, davem@xxxxxxxxxxxxx
In-reply-to: <20050115183023.GA31211@xxxxxxxxxxxxxxxxxxx>
References: <E1Cpo1q-0007lI-00@xxxxxxxxxxxxxxxxxxxxxxxx> <41E942AF.3030202@xxxxxxxxx> <20050115183023.GA31211@xxxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
Herbert Xu wrote:
On Sat, Jan 15, 2005 at 05:19:59PM +0100, Tommy Christensen wrote:

Shouldn't there be a check for skb_shared as well? Or are the
callers of netlink_unicast/broadcast supposed to avoid this.


Had anyone been using shared skb's here before they would've got into
trouble a long time ago with calls such as skb_orphan in the path.

Even if they managed to do that and not notice then the pskb_expand_head
call in netlink_trim would've likely caught it as well.

Well, pskb_expand_head was added recently and isn't even always called.

Have a look at audit_log_drain() in kernel/audit.c. This code does:
  skb_get
  netlink_unicast
  ...
  kfree_skb

This is working just fine - until one day an over-sized skb comes along
and hits the BUG in pskb_expand_head ...

That particular example can easily be solved by re-arranging the code a
bit (I'll send a patch to someone).

Still, regarding netlink, I think the safe approach is to either handle
or disallow shared skb's. Anything in-between could appear to be working,
and then suddenly blow up on your production system. </paranoia>

-Tommy

<Prev in Thread] Current Thread [Next in Thread>