1. 02 5月, 2008 2 次提交
  2. 09 4月, 2008 1 次提交
    • D
      [NET]: Undo code bloat in hot paths due to print_mac(). · 21f644f3
      David S. Miller 提交于
      If print_mac() is used inside of a pr_debug() the compiler
      can't see that the call is redundant so still performs it
      even of pr_debug() ends up being a nop.
      
      So don't use print_mac() in such cases in hot code paths,
      use MAC_FMT et al. instead.
      
      As noted by Joe Perches, pr_debug() could be modified to
      handle this better, but that is a change to an interface
      used by the entire kernel and thus needs to be validated
      carefully.  This here is thus the less risky fix for
      2.6.25
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      21f644f3
  3. 08 4月, 2008 1 次提交
  4. 17 3月, 2008 2 次提交
    • C
      virtio: fix race in enable_cb · 4265f161
      Christian Borntraeger 提交于
      There is a race in virtio_net, dealing with disabling/enabling the callback.
      I saw the following oops:
      
      kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:218!
      illegal operation: 0001 [#1] SMP
      Modules linked in: sunrpc dm_mod
      CPU: 2 Not tainted 2.6.25-rc1zlive-host-10623-gd358142-dirty #99
      Process swapper (pid: 0, task: 000000000f85a610, ksp: 000000000f873c60)
      Krnl PSW : 0404300180000000 00000000002b81a6 (vring_disable_cb+0x16/0x20)
                 R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:3 PM:0 EA:3
      Krnl GPRS: 0000000000000001 0000000000000001 0000000010005800 0000000000000001
                 000000000f3a0900 000000000f85a610 0000000000000000 0000000000000000
                 0000000000000000 000000000f870000 0000000000000000 0000000000001237
                 000000000f3a0920 000000000010ff74 00000000002846f6 000000000fa0bcd8
      Krnl Code: 00000000002b819a: a7110001           tmll    %r1,1
                 00000000002b819e: a7840004           brc     8,2b81a6
                 00000000002b81a2: a7f40001           brc     15,2b81a4
                >00000000002b81a6: a51b0001           oill    %r1,1
                 00000000002b81aa: 40102000           sth     %r1,0(%r2)
                 00000000002b81ae: 07fe               bcr     15,%r14
                 00000000002b81b0: eb7ff0380024       stmg    %r7,%r15,56(%r15)
                 00000000002b81b6: a7f13e00           tmll    %r15,15872
      Call Trace:
      ([<000000000fa0bcd0>] 0xfa0bcd0)
       [<00000000002b8350>] vring_interrupt+0x5c/0x6c
       [<000000000010ab08>] do_extint+0xb8/0xf0
       [<0000000000110716>] ext_no_vtime+0x16/0x1a
       [<0000000000107e72>] cpu_idle+0x1c2/0x1e0
      
      The problem can be triggered with a high amount of host->guest traffic.
      I think its the following race:
      
      poll says netif_rx_complete
      poll calls enable_cb
      enable_cb opens the interrupt mask
      a new packet comes, an interrupt is triggered----\
      enable_cb sees that there is more work           |
      enable_cb disables the interrupt                 |
             .                                         V
             .                            interrupt is delivered
             .                            skb_recv_done does atomic napi test, ok
       some waiting                       disable_cb is called->check fails->bang!
             .
      poll would do napi check
      poll would do disable_cb
      
      The fix is to let enable_cb not disable the interrupt again, but expect the
      caller to do the cleanup if it returns false. In that case, the interrupt is
      only disabled, if the napi test_set_bit was successful.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (cleaned up doco)
      4265f161
    • A
      virtio: Enable netpoll interface for netconsole logging · da74e89d
      Amit Shah 提交于
      Add a new poll_controller handler that the netpoll interface needs.
      
      This enables netconsole logging from a kvm guest over the virtio
      net interface.
      Signed-off-by: NAmit Shah <amitshah@gmx.net>
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      da74e89d
  5. 24 2月, 2008 1 次提交
  6. 06 2月, 2008 1 次提交
    • C
      virtio net: fix oops on interface-up · 370076d9
      Christian Borntraeger 提交于
      I got the following oops during interface ifup. Unfortunately its not
      easily reproducable so I cant say for sure that my fix fixes this
      problem, but I am confident and I think its correct anyway:
      
         <2>kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:234!
          <4>illegal operation: 0001 [#1] PREEMPT SMP
          <4>Modules linked in:
          <4>CPU: 0 Not tainted 2.6.24zlive-guest-07293-gf1ca1512-dirty #91
          <4>Process swapper (pid: 0, task: 0000000000800938, ksp: 000000000084ddb8)
          <4>Krnl PSW : 0404300180000000 0000000000466374 (vring_disable_cb+0x30/0x34)
          <4>           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:0 CC:3 PM:0 EA:3
          <4>Krnl GPRS: 0000000000000001 0000000000000001 0000000010003800 0000000000466344
          <4>           000000000e980900 00000000008848b0 000000000084e748 0000000000000000
          <4>           000000000087b300 0000000000001237 0000000000001237 000000000f85bdd8
          <4>           000000000e980920 00000000001137c0 0000000000464754 000000000f85bdd8
          <4>Krnl Code: 0000000000466368: e3b0b0700004        lg      %r11,112(%r11)
          <4>           000000000046636e: 07fe                bcr     15,%r14
          <4>           0000000000466370: a7f40001            brc     15,466372
          <4>          >0000000000466374: a7f4fff6            brc     15,466360
          <4>           0000000000466378: eb7ff0500024        stmg    %r7,%r15,80(%r15)
          <4>           000000000046637e: a7f13e00            tmll    %r15,15872
          <4>           0000000000466382: b90400ef            lgr     %r14,%r15
          <4>           0000000000466386: a7840001            brc     8,466388
          <4>Call Trace:
          <4>([<000201500f85c000>] 0x201500f85c000)
          <4> [<0000000000466556>] vring_interrupt+0x72/0x88
          <4> [<00000000004801a0>] kvm_extint_handler+0x34/0x44
          <4> [<000000000010d22c>] do_extint+0xbc/0xf8
          <4> [<0000000000113f98>] ext_no_vtime+0x16/0x1a
          <4> [<000000000010a182>] cpu_idle+0x216/0x238
          <4>([<000000000010a162>] cpu_idle+0x1f6/0x238)
          <4> [<0000000000568656>] rest_init+0xaa/0xb8
          <4> [<000000000084ee2c>] start_kernel+0x3fc/0x490
          <4> [<0000000000100020>] _stext+0x20/0x80
          <4>
          <4> <0>Kernel panic - not syncing: Fatal exception in interrupt
          <4>
      
      After looking at the code and the dump I think the following scenario
      happened: Ifup was running on cpu2 and the interrupt arrived on cpu0.
      Now virtnet_open on cpu 2 managed to execute napi_enable and disable_cb
      but did not execute rx_schedule. Meanwhile on cpu 0 skb_recv_done was
      called by vring_interrupt, executed netif_rx_schedule_prep, which
      succeeded and therefore called disable_cb. This triggered the BUG_ON,
      as interrupts were already disabled by cpu 2.
      
      I think the proper solution is to make the call to disable_cb depend on
      the atomic update of NAPI_STATE_SCHED by using netif_rx_schedule_prep
      in the same way as skb_recv_done.
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      370076d9
  7. 04 2月, 2008 11 次提交
  8. 19 11月, 2007 2 次提交
  9. 12 11月, 2007 1 次提交
  10. 23 10月, 2007 1 次提交
    • R
      Net driver using virtio · 296f96fc
      Rusty Russell 提交于
      The network driver uses two virtqueues: one for input packets and one
      for output packets.  This has nice locking properties (ie. we don't do
      any for recv vs send).
      
      TODO:
      	1) Big packets.
      	2) Multi-client devices (maybe separate driver?).
      	3) Resolve freeing of old xmit skbs (Christian Borntraeger)
      Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: netdev@vger.kernel.org
      296f96fc