1. 05 9月, 2012 3 次提交
    • S
      xfrm: Workaround incompatibility of ESN and async crypto · 3b59df46
      Steffen Klassert 提交于
      ESN for esp is defined in RFC 4303. This RFC assumes that the
      sequence number counters are always up to date. However,
      this is not true if an async crypto algorithm is employed.
      
      If the sequence number counters are not up to date on sequence
      number check, we may incorrectly update the upper 32 bit of
      the sequence number. This leads to a DOS.
      
      We workaround this by comparing the upper sequence number,
      (used for authentication) with the upper sequence number
      computed after the async processing. We drop the packet
      if these numbers are different.
      
      To do this, we introduce a recheck function that does this
      check in the ESN case.
      Signed-off-by: NSteffen Klassert <steffen.klassert@secunet.com>
      Acked-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3b59df46
    • E
      l2tp: fix a lockdep splat · 37159ef2
      Eric Dumazet 提交于
      Fixes following lockdep splat :
      
      [ 1614.734896] =============================================
      [ 1614.734898] [ INFO: possible recursive locking detected ]
      [ 1614.734901] 3.6.0-rc3+ #782 Not tainted
      [ 1614.734903] ---------------------------------------------
      [ 1614.734905] swapper/11/0 is trying to acquire lock:
      [ 1614.734907]  (slock-AF_INET){+.-...}, at: [<ffffffffa0209d72>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
      [ 1614.734920]
      [ 1614.734920] but task is already holding lock:
      [ 1614.734922]  (slock-AF_INET){+.-...}, at: [<ffffffff815fce23>] tcp_v4_err+0x163/0x6b0
      [ 1614.734932]
      [ 1614.734932] other info that might help us debug this:
      [ 1614.734935]  Possible unsafe locking scenario:
      [ 1614.734935]
      [ 1614.734937]        CPU0
      [ 1614.734938]        ----
      [ 1614.734940]   lock(slock-AF_INET);
      [ 1614.734943]   lock(slock-AF_INET);
      [ 1614.734946]
      [ 1614.734946]  *** DEADLOCK ***
      [ 1614.734946]
      [ 1614.734949]  May be due to missing lock nesting notation
      [ 1614.734949]
      [ 1614.734952] 7 locks held by swapper/11/0:
      [ 1614.734954]  #0:  (rcu_read_lock){.+.+..}, at: [<ffffffff81592801>] __netif_receive_skb+0x251/0xd00
      [ 1614.734964]  #1:  (rcu_read_lock){.+.+..}, at: [<ffffffff815d319c>] ip_local_deliver_finish+0x4c/0x4e0
      [ 1614.734972]  #2:  (rcu_read_lock){.+.+..}, at: [<ffffffff8160d116>] icmp_socket_deliver+0x46/0x230
      [ 1614.734982]  #3:  (slock-AF_INET){+.-...}, at: [<ffffffff815fce23>] tcp_v4_err+0x163/0x6b0
      [ 1614.734989]  #4:  (rcu_read_lock){.+.+..}, at: [<ffffffff815da240>] ip_queue_xmit+0x0/0x680
      [ 1614.734997]  #5:  (rcu_read_lock_bh){.+....}, at: [<ffffffff815d9925>] ip_finish_output+0x135/0x890
      [ 1614.735004]  #6:  (rcu_read_lock_bh){.+....}, at: [<ffffffff81595680>] dev_queue_xmit+0x0/0xe00
      [ 1614.735012]
      [ 1614.735012] stack backtrace:
      [ 1614.735016] Pid: 0, comm: swapper/11 Not tainted 3.6.0-rc3+ #782
      [ 1614.735018] Call Trace:
      [ 1614.735020]  <IRQ>  [<ffffffff810a50ac>] __lock_acquire+0x144c/0x1b10
      [ 1614.735033]  [<ffffffff810a334b>] ? check_usage+0x9b/0x4d0
      [ 1614.735037]  [<ffffffff810a6762>] ? mark_held_locks+0x82/0x130
      [ 1614.735042]  [<ffffffff810a5df0>] lock_acquire+0x90/0x200
      [ 1614.735047]  [<ffffffffa0209d72>] ? l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
      [ 1614.735051]  [<ffffffff810a69ad>] ? trace_hardirqs_on+0xd/0x10
      [ 1614.735060]  [<ffffffff81749b31>] _raw_spin_lock+0x41/0x50
      [ 1614.735065]  [<ffffffffa0209d72>] ? l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
      [ 1614.735069]  [<ffffffffa0209d72>] l2tp_xmit_skb+0x172/0xa50 [l2tp_core]
      [ 1614.735075]  [<ffffffffa014f7f2>] l2tp_eth_dev_xmit+0x32/0x60 [l2tp_eth]
      [ 1614.735079]  [<ffffffff81595112>] dev_hard_start_xmit+0x502/0xa70
      [ 1614.735083]  [<ffffffff81594c6e>] ? dev_hard_start_xmit+0x5e/0xa70
      [ 1614.735087]  [<ffffffff815957c1>] ? dev_queue_xmit+0x141/0xe00
      [ 1614.735093]  [<ffffffff815b622e>] sch_direct_xmit+0xfe/0x290
      [ 1614.735098]  [<ffffffff81595865>] dev_queue_xmit+0x1e5/0xe00
      [ 1614.735102]  [<ffffffff81595680>] ? dev_hard_start_xmit+0xa70/0xa70
      [ 1614.735106]  [<ffffffff815b4daa>] ? eth_header+0x3a/0xf0
      [ 1614.735111]  [<ffffffff8161d33e>] ? fib_get_table+0x2e/0x280
      [ 1614.735117]  [<ffffffff8160a7e2>] arp_xmit+0x22/0x60
      [ 1614.735121]  [<ffffffff8160a863>] arp_send+0x43/0x50
      [ 1614.735125]  [<ffffffff8160b82f>] arp_solicit+0x18f/0x450
      [ 1614.735132]  [<ffffffff8159d9da>] neigh_probe+0x4a/0x70
      [ 1614.735137]  [<ffffffff815a191a>] __neigh_event_send+0xea/0x300
      [ 1614.735141]  [<ffffffff815a1c93>] neigh_resolve_output+0x163/0x260
      [ 1614.735146]  [<ffffffff815d9cf5>] ip_finish_output+0x505/0x890
      [ 1614.735150]  [<ffffffff815d9925>] ? ip_finish_output+0x135/0x890
      [ 1614.735154]  [<ffffffff815dae79>] ip_output+0x59/0xf0
      [ 1614.735158]  [<ffffffff815da1cd>] ip_local_out+0x2d/0xa0
      [ 1614.735162]  [<ffffffff815da403>] ip_queue_xmit+0x1c3/0x680
      [ 1614.735165]  [<ffffffff815da240>] ? ip_local_out+0xa0/0xa0
      [ 1614.735172]  [<ffffffff815f4402>] tcp_transmit_skb+0x402/0xa60
      [ 1614.735177]  [<ffffffff815f5a11>] tcp_retransmit_skb+0x1a1/0x620
      [ 1614.735181]  [<ffffffff815f7e93>] tcp_retransmit_timer+0x393/0x960
      [ 1614.735185]  [<ffffffff815fce23>] ? tcp_v4_err+0x163/0x6b0
      [ 1614.735189]  [<ffffffff815fd317>] tcp_v4_err+0x657/0x6b0
      [ 1614.735194]  [<ffffffff8160d116>] ? icmp_socket_deliver+0x46/0x230
      [ 1614.735199]  [<ffffffff8160d19e>] icmp_socket_deliver+0xce/0x230
      [ 1614.735203]  [<ffffffff8160d116>] ? icmp_socket_deliver+0x46/0x230
      [ 1614.735208]  [<ffffffff8160d464>] icmp_unreach+0xe4/0x2c0
      [ 1614.735213]  [<ffffffff8160e520>] icmp_rcv+0x350/0x4a0
      [ 1614.735217]  [<ffffffff815d3285>] ip_local_deliver_finish+0x135/0x4e0
      [ 1614.735221]  [<ffffffff815d319c>] ? ip_local_deliver_finish+0x4c/0x4e0
      [ 1614.735225]  [<ffffffff815d3ffa>] ip_local_deliver+0x4a/0x90
      [ 1614.735229]  [<ffffffff815d37b7>] ip_rcv_finish+0x187/0x730
      [ 1614.735233]  [<ffffffff815d425d>] ip_rcv+0x21d/0x300
      [ 1614.735237]  [<ffffffff81592a1b>] __netif_receive_skb+0x46b/0xd00
      [ 1614.735241]  [<ffffffff81592801>] ? __netif_receive_skb+0x251/0xd00
      [ 1614.735245]  [<ffffffff81593368>] process_backlog+0xb8/0x180
      [ 1614.735249]  [<ffffffff81593cf9>] net_rx_action+0x159/0x330
      [ 1614.735257]  [<ffffffff810491f0>] __do_softirq+0xd0/0x3e0
      [ 1614.735264]  [<ffffffff8109ed24>] ? tick_program_event+0x24/0x30
      [ 1614.735270]  [<ffffffff8175419c>] call_softirq+0x1c/0x30
      [ 1614.735278]  [<ffffffff8100425d>] do_softirq+0x8d/0xc0
      [ 1614.735282]  [<ffffffff8104983e>] irq_exit+0xae/0xe0
      [ 1614.735287]  [<ffffffff8175494e>] smp_apic_timer_interrupt+0x6e/0x99
      [ 1614.735291]  [<ffffffff81753a1c>] apic_timer_interrupt+0x6c/0x80
      [ 1614.735293]  <EOI>  [<ffffffff810a14ad>] ? trace_hardirqs_off+0xd/0x10
      [ 1614.735306]  [<ffffffff81336f85>] ? intel_idle+0xf5/0x150
      [ 1614.735310]  [<ffffffff81336f7e>] ? intel_idle+0xee/0x150
      [ 1614.735317]  [<ffffffff814e6ea9>] cpuidle_enter+0x19/0x20
      [ 1614.735321]  [<ffffffff814e7538>] cpuidle_idle_call+0xa8/0x630
      [ 1614.735327]  [<ffffffff8100c1ba>] cpu_idle+0x8a/0xe0
      [ 1614.735333]  [<ffffffff8173762e>] start_secondary+0x220/0x222
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      37159ef2
    • A
      netrom: copy_datagram_iovec can fail · 6cf5c951
      Alan Cox 提交于
      Check for an error from this and if so bail properly.
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6cf5c951
  2. 04 9月, 2012 5 次提交
    • W
      mISDN: fix possible memory leak in hfcmulti_init() · 9fef7685
      Wei Yongjun 提交于
      hc has been allocated in this function and missing free it before
      leaving from some error handling cases.
      
      spatch with a semantic match is used to found this problem.
      (http://coccinelle.lip6.fr/)
      Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9fef7685
    • E
      fq_codel: dont reinit flow state · b379135c
      Eric Dumazet 提交于
      When fq_codel builds a new flow, it should not reset codel state.
      
      Codel algo needs to get previous values (lastcount, drop_next) to get
      proper behavior.
      Signed-off-by: NDave Taht <dave.taht@gmail.com>
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Acked-by: NDave Taht <dave.taht@bufferbloat.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b379135c
    • B
      net: usbnet: fix softirq storm on suspend · 85e87870
      Bjørn Mork 提交于
      Suspending an open usbnet device results in constant
      rescheduling of usbnet_bh.
      
      commit 65841fd5 "usbnet: handle remote wakeup asap"
      refactored the usbnet_bh code to allow sharing the
      urb allocate and submit code with usbnet_resume. In
      this process, a test for, and immediate return on,
      ENOLINK from rx_submit was unintentionally dropped.
      
      The rx queue will not grow if rx_submit fails,
      making usbnet_bh reschedule itself.  This results
      in a softirq storm if the error is persistent.
      rx_submit translates the usb_submit_urb error
      EHOSTUNREACH into ENOLINK, so this is an expected
      and persistent error for a suspended device. The
      old code tested for this condition and avoided
      rescheduling.  Putting this test back.
      
      Cc: <stable@vger.kernel.org> # v3.5
      Cc: Ming Lei <ming.lei@canonical.com>
      Cc: Oliver Neukum <oneukum@suse.de>
      Signed-off-by: NBjørn Mork <bjorn@mork.no>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      85e87870
    • T
      sctp: Don't charge for data in sndbuf again when transmitting packet · 4c3a5bda
      Thomas Graf 提交于
      SCTP charges wmem_alloc via sctp_set_owner_w() in sctp_sendmsg() and via
      skb_set_owner_w() in sctp_packet_transmit(). If a sender runs out of
      sndbuf it will sleep in sctp_wait_for_sndbuf() and expects to be waken up
      by __sctp_write_space().
      
      Buffer space charged via sctp_set_owner_w() is released in sctp_wfree()
      which calls __sctp_write_space() directly.
      
      Buffer space charged via skb_set_owner_w() is released via sock_wfree()
      which calls sk->sk_write_space() _if_ SOCK_USE_WRITE_QUEUE is not set.
      sctp_endpoint_init() sets SOCK_USE_WRITE_QUEUE on all sockets.
      
      Therefore if sctp_packet_transmit() manages to queue up more than sndbuf
      bytes, sctp_wait_for_sndbuf() will never be woken up again unless it is
      interrupted by a signal.
      
      This could be fixed by clearing the SOCK_USE_WRITE_QUEUE flag but ...
      
      Charging for the data twice does not make sense in the first place, it
      leads to overcharging sndbuf by a factor 2. Therefore this patch only
      charges a single byte in wmem_alloc when transmitting an SCTP packet to
      ensure that the socket stays alive until the packet has been released.
      
      This means that control chunks are no longer accounted for in wmem_alloc
      which I believe is not a problem as skb->truesize will typically lead
      to overcharging anyway and thus compensates for any control overhead.
      Signed-off-by: NThomas Graf <tgraf@suug.ch>
      CC: Vlad Yasevich <vyasevic@redhat.com>
      CC: Neil Horman <nhorman@tuxdriver.com>
      CC: David Miller <davem@davemloft.net>
      Acked-by: NVlad Yasevich <vyasevich@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4c3a5bda
    • E
      net: sock_edemux() should take care of timewait sockets · e812347c
      Eric Dumazet 提交于
      sock_edemux() can handle either a regular socket or a timewait socket
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e812347c
  3. 03 9月, 2012 2 次提交
    • L
      Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6 · 5b716ac7
      Linus Torvalds 提交于
      Pull CIFS fixes from Steve French.
      
      * 'for-next' of git://git.samba.org/sfrench/cifs-2.6:
        CIFS: Fix cifs_do_create error hadnling
        cifs: print error code if smb signature verification fails
        CIFS: Fix log messages in packet checking for SMB2
        CIFS: Protect i_nlink from being negative
      5b716ac7
    • L
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net · 0b1a34c9
      Linus Torvalds 提交于
      Pull networking fixes from David Miller:
      
       1) NLA_PUT* --> nla_put_* conversion got one case wrong in
          nfnetlink_log, fix from Patrick McHardy.
      
       2) Missed error return check in ipw2100 driver, from Julia Lawall.
      
       3) PMTU updates in ipv4 were setting the expiry time incorrectly, fix
          from Eric Dumazet.
      
       4) SFC driver erroneously reversed src and dst when reporting filters
          via ethtool.
      
       5) Memory leak in CAN protocol and wrong setting of IRQF_SHARED in
          sja1000 can platform driver, from Alexey Khoroshilov and Sven
          Schmitt.
      
       6) Fix multicast traffic scaling regression in ipv4_dst_destroy, only
          take the lock when we really need to.  From Eric Dumazet.
      
       7) Fix non-root process spoofing in netlink, from Pablo Neira Ayuso.
      
       8) CWND reduction in TCP is done incorrectly during non-SACK recovery,
          fix from Yuchung Cheng.
      
       9) Revert netpoll change, and fix what was actually a driver specific
          problem.  From Amerigo Wang.  This should cure bootup hangs with
          netconsole some people reported.
      
      10) Fix xen-netfront invoking __skb_fill_page_desc() with a NULL page
          pointer.  From Ian Campbell.
      
      11) SIP NAT fix for expectiontation creation, from Pablo Neira Ayuso.
      
      12) __ip_rt_update_pmtu() needs RCU locking, from Eric Dumazet.
      
      13) Fix usbnet deadlock on resume, can't use GFP_KERNEL in this
          situation.  From Oliver Neukum.
      
      14) The davinci ethernet driver triggers an OOPS on removal because it
          frees an MDIO object before unregistering it.  Fix from Bin Liu.
      
      * git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (41 commits)
        net: qmi_wwan: add several new Gobi devices
        fddi: 64 bit bug in smt_add_para()
        net: ethernet: fix kernel OOPS when remove davinci_mdio module
        net/xfrm/xfrm_state.c: fix error return code
        net: ipv6: fix error return code
        net: qmi_wwan: new device: Foxconn/Novatel E396
        usbnet: fix deadlock in resume
        cs89x0 : packet reception not working
        netfilter: nf_conntrack: fix racy timer handling with reliable events
        bnx2x: Correct the ndo_poll_controller call
        bnx2x: Move netif_napi_add to the open call
        ipv4: must use rcu protection while calling fib_lookup
        bnx2x: fix 57840_MF pci id
        net: ipv4: ipmr_expire_timer causes crash when removing net namespace
        e1000e: DoS while TSO enabled caused by link partner with small MSS
        l2tp: avoid to use synchronize_rcu in tunnel free function
        gianfar: fix default tx vlan offload feature flag
        netfilter: nf_nat_sip: fix incorrect handling of EBUSY for RTCP expectation
        xen-netfront: use __pskb_pull_tail to ensure linear area is big enough on RX
        netfilter: nfnetlink_log: fix error return code in init path
        ...
      0b1a34c9
  4. 02 9月, 2012 4 次提交
  5. 01 9月, 2012 10 次提交
  6. 31 8月, 2012 12 次提交
    • P
      netfilter: nf_conntrack: fix racy timer handling with reliable events · 5b423f6a
      Pablo Neira Ayuso 提交于
      Existing code assumes that del_timer returns true for alive conntrack
      entries. However, this is not true if reliable events are enabled.
      In that case, del_timer may return true for entries that were
      just inserted in the dying list. Note that packets / ctnetlink may
      hold references to conntrack entries that were just inserted to such
      list.
      
      This patch fixes the issue by adding an independent timer for
      event delivery. This increases the size of the ecache extension.
      Still we can revisit this later and use variable size extensions
      to allocate this area on demand.
      Tested-by: NOliver Smith <olipro@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      5b423f6a
    • M
      bnx2x: Correct the ndo_poll_controller call · 14a15d61
      Merav Sicron 提交于
      This patch correct poll_bnx2x (ndo_poll_controller call) which was not
      functioning well with MSI-X.
      Signed-off-by: NMerav Sicron <meravs@broadcom.com>
      Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com>
      Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      14a15d61
    • M
      bnx2x: Move netif_napi_add to the open call · 26614ba5
      Merav Sicron 提交于
      Move netif_napi_add for all queues from the probe call to the open call, to
      avoid the case that napi objects are added for queues that may eventually not
      be initialized and activated. With the former behavior, the driver could crash
      when netpoll was calling ndo_poll_controller.
      Signed-off-by: NMerav Sicron <meravs@broadcom.com>
      Signed-off-by: NDmitry Kravkov <dmitry@broadcom.com>
      Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      26614ba5
    • E
      ipv4: must use rcu protection while calling fib_lookup · c5ae7d41
      Eric Dumazet 提交于
      Following lockdep splat was reported by Pavel Roskin :
      
      [ 1570.586223] ===============================
      [ 1570.586225] [ INFO: suspicious RCU usage. ]
      [ 1570.586228] 3.6.0-rc3-wl-main #98 Not tainted
      [ 1570.586229] -------------------------------
      [ 1570.586231] /home/proski/src/linux/net/ipv4/route.c:645 suspicious rcu_dereference_check() usage!
      [ 1570.586233]
      [ 1570.586233] other info that might help us debug this:
      [ 1570.586233]
      [ 1570.586236]
      [ 1570.586236] rcu_scheduler_active = 1, debug_locks = 0
      [ 1570.586238] 2 locks held by Chrome_IOThread/4467:
      [ 1570.586240]  #0:  (slock-AF_INET){+.-...}, at: [<ffffffff814f2c0c>] release_sock+0x2c/0xa0
      [ 1570.586253]  #1:  (fnhe_lock){+.-...}, at: [<ffffffff815302fc>] update_or_create_fnhe+0x2c/0x270
      [ 1570.586260]
      [ 1570.586260] stack backtrace:
      [ 1570.586263] Pid: 4467, comm: Chrome_IOThread Not tainted 3.6.0-rc3-wl-main #98
      [ 1570.586265] Call Trace:
      [ 1570.586271]  [<ffffffff810976ed>] lockdep_rcu_suspicious+0xfd/0x130
      [ 1570.586275]  [<ffffffff8153042c>] update_or_create_fnhe+0x15c/0x270
      [ 1570.586278]  [<ffffffff815305b3>] __ip_rt_update_pmtu+0x73/0xb0
      [ 1570.586282]  [<ffffffff81530619>] ip_rt_update_pmtu+0x29/0x90
      [ 1570.586285]  [<ffffffff815411dc>] inet_csk_update_pmtu+0x2c/0x80
      [ 1570.586290]  [<ffffffff81558d1e>] tcp_v4_mtu_reduced+0x2e/0xc0
      [ 1570.586293]  [<ffffffff81553bc4>] tcp_release_cb+0xa4/0xb0
      [ 1570.586296]  [<ffffffff814f2c35>] release_sock+0x55/0xa0
      [ 1570.586300]  [<ffffffff815442ef>] tcp_sendmsg+0x4af/0xf50
      [ 1570.586305]  [<ffffffff8156fc60>] inet_sendmsg+0x120/0x230
      [ 1570.586308]  [<ffffffff8156fb40>] ? inet_sk_rebuild_header+0x40/0x40
      [ 1570.586312]  [<ffffffff814f4bdd>] ? sock_update_classid+0xbd/0x3b0
      [ 1570.586315]  [<ffffffff814f4c50>] ? sock_update_classid+0x130/0x3b0
      [ 1570.586320]  [<ffffffff814ec435>] do_sock_write+0xc5/0xe0
      [ 1570.586323]  [<ffffffff814ec4a3>] sock_aio_write+0x53/0x80
      [ 1570.586328]  [<ffffffff8114bc83>] do_sync_write+0xa3/0xe0
      [ 1570.586332]  [<ffffffff8114c5a5>] vfs_write+0x165/0x180
      [ 1570.586335]  [<ffffffff8114c805>] sys_write+0x45/0x90
      [ 1570.586340]  [<ffffffff815d2722>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Reported-by: NPavel Roskin <proski@gnu.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c5ae7d41
    • Y
      bnx2x: fix 57840_MF pci id · 5c879d20
      Yuval Mintz 提交于
      Commit c3def943 have added support for
      new pci ids of the 57840 board, while failing to change the obsolete value
      in 'pci_ids.h'.
      This patch does so, allowing the probe of such devices.
      Signed-off-by: NYuval Mintz <yuvalmin@broadcom.com>
      Signed-off-by: NEilon Greenstein <eilong@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5c879d20
    • F
      net: ipv4: ipmr_expire_timer causes crash when removing net namespace · acbb219d
      Francesco Ruggeri 提交于
      When tearing down a net namespace, ipv4 mr_table structures are freed
      without first deactivating their timers. This can result in a crash in
      run_timer_softirq.
      This patch mimics the corresponding behaviour in ipv6.
      Locking and synchronization seem to be adequate.
      We are about to kfree mrt, so existing code should already make sure that
      no other references to mrt are pending or can be created by incoming traffic.
      The functions invoked here do not cause new references to mrt or other
      race conditions to be created.
      Invoking del_timer_sync guarantees that ipmr_expire_timer is inactive.
      Both ipmr_expire_process (whose completion we may have to wait in
      del_timer_sync) and mroute_clean_tables internally use mfc_unres_lock
      or other synchronizations when needed, and they both only modify mrt.
      
      Tested in Linux 3.4.8.
      Signed-off-by: NFrancesco Ruggeri <fruggeri@aristanetworks.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      acbb219d
    • B
      e1000e: DoS while TSO enabled caused by link partner with small MSS · d821a4c4
      Bruce Allan 提交于
      With a low enough MSS on the link partner and TSO enabled locally, the
      networking stack can periodically send a very large (e.g.  64KB) TCP
      message for which the driver will attempt to use more Tx descriptors than
      are available by default in the Tx ring.  This is due to a workaround in
      the code that imposes a limit of only 4 MSS-sized segments per descriptor
      which appears to be a carry-over from the older e1000 driver and may be
      applicable only to some older PCI or PCIx parts which are not supported in
      e1000e.  When the driver gets a message that is too large to fit across the
      configured number of Tx descriptors, it stops the upper stack from queueing
      any more and gets stuck in this state.  After a timeout, the upper stack
      assumes the adapter is hung and calls the driver to reset it.
      
      Remove the unnecessary limitation of using up to only 4 MSS-sized segments
      per Tx descriptor, and put in a hard failure test to catch when attempting
      to check for message sizes larger than would fit in the whole Tx ring.
      Refactor the remaining logic that limits the size of data per Tx descriptor
      from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
      Tx packet buffer as described in the hardware specification.
      
      Also, fix the logic in the check for space in the Tx ring for the next
      largest possible packet after the current one has been successfully queued
      for transmit, and use the appropriate defines for default ring sizes in
      e1000_probe instead of magic values.
      
      This issue goes back to the introduction of e1000e in 2.6.24 when it was
      split off from e1000.
      Reported-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NBruce Allan <bruce.w.allan@intel.com>
      Cc: Stable <stable@vger.kernel.org> [2.6.24+]
      Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d821a4c4
    • X
      l2tp: avoid to use synchronize_rcu in tunnel free function · 99469c32
      xeb@mail.ru 提交于
      Avoid to use synchronize_rcu in l2tp_tunnel_free because context may be
      atomic.
      Signed-off-by: NDmitry Kozlov <xeb@mail.ru>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      99469c32
    • C
      gianfar: fix default tx vlan offload feature flag · e2c53be2
      Claudiu Manoil 提交于
      Commit -
      "b852b720 gianfar: fix bug caused by
      87c288c6"
      disables by default (on mac init) the hw vlan tag insertion.
      The "features" flags were not updated to reflect this, and
      "ethtool -K" shows tx-vlan-offload to be "on" by default.
      
      Cc: Sebastian Poehn <sebastian.poehn@belden.com>
      Signed-off-by: NClaudiu Manoil <claudiu.manoil@freescale.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e2c53be2
    • P
      netfilter: nf_nat_sip: fix incorrect handling of EBUSY for RTCP expectation · 3f509c68
      Pablo Neira Ayuso 提交于
      We're hitting bug while trying to reinsert an already existing
      expectation:
      
      kernel BUG at kernel/timer.c:895!
      invalid opcode: 0000 [#1] SMP
      [...]
      Call Trace:
       <IRQ>
       [<ffffffffa0069563>] nf_ct_expect_related_report+0x4a0/0x57a [nf_conntrack]
       [<ffffffff812d423a>] ? in4_pton+0x72/0x131
       [<ffffffffa00ca69e>] ip_nat_sdp_media+0xeb/0x185 [nf_nat_sip]
       [<ffffffffa00b5b9b>] set_expected_rtp_rtcp+0x32d/0x39b [nf_conntrack_sip]
       [<ffffffffa00b5f15>] process_sdp+0x30c/0x3ec [nf_conntrack_sip]
       [<ffffffff8103f1eb>] ? irq_exit+0x9a/0x9c
       [<ffffffffa00ca738>] ? ip_nat_sdp_media+0x185/0x185 [nf_nat_sip]
      
      We have to remove the RTP expectation if the RTCP expectation hits EBUSY
      since we keep trying with other ports until we succeed.
      Reported-by: NRafal Fitt <rafalf@aplusc.com.pl>
      Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org>
      3f509c68
    • I
      xen-netfront: use __pskb_pull_tail to ensure linear area is big enough on RX · 3683243b
      Ian Campbell 提交于
      I'm slightly concerned by the "only in exceptional circumstances"
      comment on __pskb_pull_tail but the structure of an skb just created
      by netfront shouldn't hit any of the especially slow cases.
      
      This approach still does slightly more work than the old way, since if
      we pull up the entire first frag we now have to shuffle everything
      down where before we just received into the right place in the first
      place.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: xen-devel@lists.xensource.com
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Tested-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3683243b
    • L
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 155e36d4
      Linus Torvalds 提交于
      Pull drm fixes from Dave Airlie:
       "A bunch of scattered fixes ati/intel/nouveau, couple of core ones,
        nothing too shocking or different."
      
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S
        gma500: Consider CRTC initially active.
        drm/radeon: fix dig encoder selection on DCE61
        drm/radeon: fix double free in radeon_gpu_reset
        drm/radeon: force dma32 to fix regression rs4xx,rs6xx,rs740
        drm/radeon: rework panel mode setup
        drm/radeon/atom: powergating fixes for DCE6
        drm/radeon/atom: rework DIG modesetting on DCE3+
        drm/radeon: don't disable plls that are in use by other crtcs
        drm/radeon: add proper checking of RESOLVE_BOX command for r600-r700
        drm/radeon: initialize tracked CS state
        drm/radeon: fix reading CB_COLORn_MASK from the CS
        drm/nvc0/copy: check PUNITS to determine which copy engines are disabled
        i915: Quirk no_lvds on Gigabyte GA-D525TUD ITX motherboard
        drm/i915: Use the correct size of the GTT for placing the per-process entries
        drm: Check for invalid cursor flags
        drm: Initialize object type when using DRM_MODE() macro
        drm/i915: fix color order for BGR formats on IVB
        drm/i915: fix wrong order of parameters in port checking functions
      155e36d4
  7. 30 8月, 2012 4 次提交