1. 23 3月, 2011 35 次提交
  2. 22 3月, 2011 5 次提交
    • E
      veth: Fix the byte counters · 675071a2
      Eric W. Biederman 提交于
      Commit 44540960 "veth: move loopback logic to common location" introduced
      a bug in the packet counters.  I don't understand why that happened as it
      is not explained in the comments and the mut check in dev_forward_skb
      retains the assumption that skb->len is the total length of the packet.
      
      I just measured this emperically by setting up a veth pair between two
      noop network namespaces setting and attempting a telnet connection between
      the two.  I saw three packets in each direction and the byte counters were
      exactly 14*3 = 42 bytes high in each direction.  I got the actual
      packet lengths with tcpdump.
      
      So remove the extra ETH_HLEN from the veth byte count totals.
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      675071a2
    • E
      macvlan: Fix use after free of struct macvlan_port. · d5cd9244
      Eric W. Biederman 提交于
      When the macvlan driver was extended to call unregisgter_netdevice_queue
      in 23289a37, a use after free of struct
      macvlan_port was introduced.  The code in dellink relied on unregister_netdevice
      actually unregistering the net device so it would be safe to free macvlan_port.
      
      Since unregister_netdevice_queue can just queue up the unregister instead of
      performing the unregiser immediately we free the macvlan_port too soon and
      then the code in macvlan_stop removes the macaddress for the set of macaddress
      to listen for and uses memory that has already been freed.
      
      To fix this add a reference count to track when it is safe to free the macvlan_port
      and move the call of macvlan_port_destroy into macvlan_uninit which is guaranteed
      to be called after the final macvlan_port_close.
      Signed-off-by: NEric W. Biederman <ebiederm@aristanetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5cd9244
    • J
      can: c_can: Do basic c_can configuration _before_ enabling the interrupts · 4f2d56c4
      Jan Altenberg 提交于
      I ran into some trouble while testing the SocketCAN driver for the BOSCH
      C_CAN controller. The interface is not correctly initialized, if I put
      some CAN traffic on the line, _while_ the interface is being started
      (which means: the interface doesn't come up correcty, if there's some RX
      traffic while doing 'ifconfig can0 up').
      
      The current implementation enables the controller interrupts _before_
      doing the basic c_can configuration. I think, this should be done the
      other way round.
      
      The patch below fixes things for me.
      Signed-off-by: NJan Altenberg <jan@linutronix.de>
      Acked-by: NKurt Van Dijck <kurt.van.dijck@eia.be>
      Acked-by: NWolfgang Grandegger <wg@grandegger.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f2d56c4
    • V
      i2c-pxa2xx: Don't clear isr bits too early · 97491ba3
      Vasily Khoruzhick 提交于
      isr is passed later into i2c_pxa_irq_txempty and
      i2c_pxa_irq_rxfull and they may use some other bits
      than irq sources.
      Signed-off-by: NVasily Khoruzhick <anarsoul@gmail.com>
      Signed-off-by: NBen Dooks <ben-linux@fluff.org>
      97491ba3
    • J
      Reduce sequential pointer derefs in scsi_error.c and reduce size as well · 0bf8c869
      Jesper Juhl 提交于
      This patch reduces the number of sequential pointer derefs in
      drivers/scsi/scsi_error.c
      
      This has been submitted a number of times over a couple of years.  I
      believe this version adresses all comments it has gathered over time.
      Please apply or reject with a reason.
      
      The benefits are:
      
       - makes the code easier to read.  Lots of sequential derefs of the same
         pointers is not easy on the eye.
      
       - theoretically at least, just dereferencing the pointers once can
         allow the compiler to generally slightly faster code, so in theory
         this could also be a micro speed optimization.
      
       - reduces size of object file (tiny effect: on x86-64, in at least one
         configuration, the text size decreased from 9439 bytes to 9400)
      
       - removes some pointless (mostly trailing) whitespace.
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0bf8c869