1. 14 Feb, 2011 1 commit
  2. 13 Feb, 2011 3 commits
  3. 12 Feb, 2011 3 commits
    • Herbert Xu's avatar
      bridge: Replace mp->mglist hlist with a bool · 8a870178
      Herbert Xu authored
      As it turns out we never need to walk through the list of multicast
      groups subscribed by the bridge interface itself (the only time we'd
      want to do that is when we shut down the bridge, in which case we
      simply walk through all multicast groups), we don't really need to
      keep an hlist for mp->mglist.
      
      This means that we can replace it with just a single bit to indicate
      whether the bridge interface is subscribed to a group.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a870178
    • Herbert Xu's avatar
      bridge: Fix timer typo that may render snooping less effective · 24f9cdcb
      Herbert Xu authored
      In a couple of spots where we are supposed to modify the port
      group timer (p->timer) we instead modify the bridge interface
      group timer (mp->timer).
      
      The effect of this is mostly harmless.  However, it can cause
      port subscriptions to be longer than they should be, thus making
      snooping less effective.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      24f9cdcb
    • Herbert Xu's avatar
      bridge: Fix mglist corruption that leads to memory corruption · 6b0d6a9b
      Herbert Xu authored
      The list mp->mglist is used to indicate whether a multicast group
      is active on the bridge interface itself as opposed to one of the
      constituent interfaces in the bridge.
      
      Unfortunately the operation that adds the mp->mglist node to the
      list neglected to check whether it has already been added.  This
      leads to list corruption in the form of nodes pointing to itself.
      
      Normally this would be quite obvious as it would cause an infinite
      loop when walking the list.  However, as this list is never actually
      walked (which means that we don't really need it, I'll get rid of
      it in a subsequent patch), this instead is hidden until we perform
      a delete operation on the affected nodes.
      
      As the same node may now be pointed to by more than one node, the
      delete operations can then cause modification of freed memory.
      
      This was observed in practice to cause corruption in 512-byte slabs,
      most commonly leading to crashes in jbd2.
      
      Thanks to Josef Bacik for pointing me in the right direction.
      Reported-by: default avatarIan Page Hands <ihands@redhat.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b0d6a9b
  4. 11 Feb, 2011 3 commits
  5. 10 Feb, 2011 3 commits
  6. 09 Feb, 2011 8 commits
  7. 08 Feb, 2011 14 commits
  8. 07 Feb, 2011 5 commits