1. 20 12月, 2012 1 次提交
  2. 19 12月, 2012 3 次提交
  3. 18 12月, 2012 6 次提交
  4. 16 12月, 2012 2 次提交
  5. 15 12月, 2012 4 次提交
    • T
      cpts: Fix build error caused by include of plat/clock.h · e133b539
      Tony Lindgren 提交于
      Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock)
      mistakenly included plat/clock.h that should not be included by drivers
      even if it exists.
      
      Otherwise we get the following error with at least omap2plus_defconfig:
      
      drivers/net/ethernet/ti/cpts.c:30:24: error: plat/clock.h: No such file or directory
      
      Signed-off-by: Tony Lindgren <tony@atomide.com
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e133b539
    • K
      bonding: do not cancel works in bond_uninit() · cfb6f99d
      Konstantin Khlebnikov 提交于
      Bonding initializes these works in bond_open() and cancels in bond_close(),
      thus in bond_uninit() they are already canceled but may be unitialized yet.
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Nikolay Aleksandrov <nikolay@redhat.com>
      Cc: Jay Vosburgh <fubar@us.ibm.com>
      Cc: Andy Gospodarek <andy@greyhouse.net>
      Cc: netdev@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cfb6f99d
    • K
      stmmac: fix platform driver unregistering · 493682b8
      Konstantin Khlebnikov 提交于
      This patch fixes platform device drivers unregistering and adds proper error
      handing on module loading.
      Signed-off-by: NKonstantin Khlebnikov <khlebnikov@openvz.org>
      Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
      Cc: netdev@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      493682b8
    • J
      tuntap: fix ambigious multiqueue API · 4008e97f
      Jason Wang 提交于
      The current multiqueue API is ambigious which may confuse both user and LSM to
      do things correctly:
      
      - Both TUNSETIFF and TUNSETQUEUE could be used to create the queues of a tuntap
        device.
      - TUNSETQUEUE were used to disable and enable a specific queue of the
        device. But since the state of tuntap were completely removed from the queue,
        it could be used to attach to another device (there's no such kind of
        requirement currently, and it needs new kind of LSM policy.
      - TUNSETQUEUE could be used to attach to a persistent device without any
        queues. This kind of attching bypass the necessary checking during TUNSETIFF
        and may lead unexpected result.
      
      So this patch tries to make a cleaner and simpler API by:
      
      - Only allow TUNSETIFF to create queues.
      - TUNSETQUEUE could be only used to disable and enabled the queues of a device,
        and the state of the tuntap device were not detachd from the queues when it
        was disabled, so TUNSETQUEUE could be only used after TUNSETIFF and with the
         same device.
      
      This is done by introducing a list which keeps track of all queues which were
      disabled. The queue would be moved between this list and tfiles[] array when it
      was enabled/disabled. A pointer of the tun_struct were also introdued to track
      the device it belongs to when it was disabled.
      
      After the change, the isolation between management and application could be done
      through: TUNSETIFF were only called by management software and TUNSETQUEUE were
      only called by application.For LSM/SELinux, the things left is to do proper
      check during tun_set_queue() if needed.
      Signed-off-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4008e97f
  6. 14 12月, 2012 1 次提交
    • E
      tuntap: dont use skb after netif_rx_ni(skb) · 49974420
      Eric Dumazet 提交于
      On Wed, 2012-12-12 at 23:16 -0500, Dave Jones wrote:
      > Since todays net merge, I see this when I start openvpn..
      >
      > general protection fault: 0000 [#1] PREEMPT SMP
      > Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack nf_conntrack ip6table_filter ip6_tables xfs iTCO_wdt iTCO_vendor_support snd_emu10k1 snd_util_mem snd_ac97_codec coretemp ac97_bus microcode snd_hwdep snd_seq pcspkr snd_pcm snd_page_alloc snd_timer lpc_ich i2c_i801 snd_rawmidi mfd_core snd_seq_device snd e1000e soundcore emu10k1_gp gameport i82975x_edac edac_core vhost_net tun macvtap macvlan kvm_intel kvm binfmt_misc nfsd auth_rpcgss nfs_acl lockd sunrpc btrfs libcrc32c zlib_deflate firewire_ohci sata_sil firewire_core crc_itu_t radeon i2c_algo_bit drm_kms_helper ttm drm i2c_core floppy
      > CPU 0
      > Pid: 1381, comm: openvpn Not tainted 3.7.0+ #14                  /D975XBX
      > RIP: 0010:[<ffffffff815b54a4>]  [<ffffffff815b54a4>] skb_flow_dissect+0x314/0x3e0
      > RSP: 0018:ffff88007d0d9c48  EFLAGS: 00010206
      > RAX: 000000000000055d RBX: 6b6b6b6b6b6b6b4b RCX: 1471030a0180040a
      > RDX: 0000000000000005 RSI: 00000000ffffffe0 RDI: ffff8800ba83fa80
      > RBP: ffff88007d0d9cb8 R08: 0000000000000000 R09: 0000000000000000
      > R10: 0000000000000000 R11: 0000000000000101 R12: ffff8800ba83fa80
      > R13: 0000000000000008 R14: ffff88007d0d9cc8 R15: ffff8800ba83fa80
      > FS:  00007f6637104800(0000) GS:ffff8800bf600000(0000) knlGS:0000000000000000
      > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > CR2: 00007f563f5b01c4 CR3: 000000007d140000 CR4: 00000000000007f0
      > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      > Process openvpn (pid: 1381, threadinfo ffff88007d0d8000, task ffff8800a540cd60)
      > Stack:
      >  ffff8800ba83fa80 0000000000000296 0000000000000000 0000000000000000
      >  ffff88007d0d9cc8 ffffffff815bcff4 ffff88007d0d9ce8 ffffffff815b1831
      >  ffff88007d0d9ca8 00000000703f6364 ffff8800ba83fa80 0000000000000000
      > Call Trace:
      >  [<ffffffff815bcff4>] ? netif_rx+0x114/0x4c0
      >  [<ffffffff815b1831>] ? skb_copy_datagram_from_iovec+0x61/0x290
      >  [<ffffffff815b672a>] __skb_get_rxhash+0x1a/0xd0
      >  [<ffffffffa03b9538>] tun_get_user+0x418/0x810 [tun]
      >  [<ffffffff8135f468>] ? delay_tsc+0x98/0xf0
      >  [<ffffffff8109605c>] ? __rcu_read_unlock+0x5c/0xa0
      >  [<ffffffffa03b9a41>] tun_chr_aio_write+0x81/0xb0 [tun]
      >  [<ffffffff81145011>] ? __buffer_unlock_commit+0x41/0x50
      >  [<ffffffff811db917>] do_sync_write+0xa7/0xe0
      >  [<ffffffff811dc01f>] vfs_write+0xaf/0x190
      >  [<ffffffff811dc375>] sys_write+0x55/0xa0
      >  [<ffffffff81705540>] tracesys+0xdd/0xe2
      > Code: 41 8b 44 24 68 41 2b 44 24 6c 01 de 29 f0 83 f8 03 0f 8e a0 00 00 00 48 63 de 49 03 9c 24 e0 00 00 00 48 85 db 0f 84 72 fe ff ff <8b> 03 41 89 46 08 b8 01 00 00 00 e9 43 fd ff ff 0f 1f 40 00 48
      > RIP  [<ffffffff815b54a4>] skb_flow_dissect+0x314/0x3e0
      >  RSP <ffff88007d0d9c48>
      > ---[ end trace 6d42c834c72c002e ]---
      >
      >
      > Faulting instruction is
      >
      >    0:	8b 03                	mov    (%rbx),%eax
      >
      > rbx is slab poison (-20) so this looks like a use-after-free here...
      >
      >                         flow->ports = *ports;
      >  314:   8b 03                   mov    (%rbx),%eax
      >  316:   41 89 46 08             mov    %eax,0x8(%r14)
      >
      > in the inlined skb_header_pointer in skb_flow_dissect
      >
      > 	Dave
      >
      
      commit 96442e42 (tuntap: choose the txq based on rxq) added
      a use after free.
      
      Cache rxhash in a temp variable before calling netif_rx_ni()
      Reported-by: NDave Jones <davej@redhat.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Acked-by: NJason Wang <jasowang@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      49974420
  7. 13 12月, 2012 2 次提交
  8. 12 12月, 2012 16 次提交
  9. 11 12月, 2012 5 次提交