1. 14 Aug, 2012 16 commits
  2. 13 Aug, 2012 22 commits
  3. 12 Aug, 2012 2 commits
    • Joren Van Onder's avatar
      bnx2x: Fix compiler warnings · f57b07c0
      Joren Van Onder authored
      Fix the following compiler warnings:
      
       - drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2908:3: warning: comparison
         of distinct pointer types lacks a cast [enabled by default]
       - drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:1709:7: warning: comparison
         of distinct pointer types lacks a cast [enabled by default]
      Signed-off-by: default avatarJoren Van Onder <joren.vanonder@gmail.com>
      Acked-By: default avatarYuval Mintz <yuvalmin@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f57b07c0
    • danborkmann@iogearbox.net's avatar
      af_packet: remove BUG statement in tpacket_destruct_skb · 7f5c3e3a
      danborkmann@iogearbox.net authored
      Here's a quote of the comment about the BUG macro from asm-generic/bug.h:
      
       Don't use BUG() or BUG_ON() unless there's really no way out; one
       example might be detecting data structure corruption in the middle
       of an operation that can't be backed out of.  If the (sub)system
       can somehow continue operating, perhaps with reduced functionality,
       it's probably not BUG-worthy.
      
       If you're tempted to BUG(), think again:  is completely giving up
       really the *only* solution?  There are usually better options, where
       users don't need to reboot ASAP and can mostly shut down cleanly.
      
      In our case, the status flag of a ring buffer slot is managed from both sides,
      the kernel space and the user space. This means that even though the kernel
      side might work as expected, the user space screws up and changes this flag
      right between the send(2) is triggered when the flag is changed to
      TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
      will hit the BUG macro. As David suggested, the best solution is to simply
      remove this statement since it cannot be used for kernel side internal
      consistency checks. I've tested it and the system still behaves /stable/ in
      this case, so in accordance with the above comment, we should rather remove it.
      Signed-off-by: default avatarDaniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7f5c3e3a