1. 06 4月, 2012 5 次提交
    • B
      ethtool: Remove exception to the requirement of holding RTNL lock · b4f79e5c
      Ben Hutchings 提交于
      Commit e52ac339 ('net: Use device
      model to get driver name in skb_gso_segment()') removed the only
      in-tree caller of ethtool ops that doesn't hold the RTNL lock.
      Signed-off-by: NBen Hutchings <bhutchings@solarflare.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b4f79e5c
    • S
      MAINTAINERS: update for Marvell Ethernet drivers · 44c14c1d
      stephen hemminger 提交于
      Marvell has agreed to do maintenance on the sky2 driver.
         * Add the developer to the maintainers file
         * Remove the old reference to the long gone (sk98lin) driver
         * Rearrange to fit current topic organization
      Signed-off-by: NStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      44c14c1d
    • V
      bonding: properly unset current_arp_slave on slave link up · 5a430974
      Veaceslav Falico 提交于
      When a slave comes up, we're unsetting the current_arp_slave without
      removing active flags from it, which can lead to situations where we have
      more than one slave with active flags in active-backup mode.
      
      To avoid this situation we must remove the active flags from a slave before
      removing it as a current_arp_slave.
      Signed-off-by: NVeaceslav Falico <vfalico@redhat.com>
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NAndy Gospodarek <andy@greyhouse.net>
      Signed-off-by: NMarcelo Ricardo Leitner <mleitner@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a430974
    • S
      phonet: Check input from user before allocating · bcf1b70a
      Sasha Levin 提交于
      A phonet packet is limited to USHRT_MAX bytes, this is never checked during
      tx which means that the user can specify any size he wishes, and the kernel
      will attempt to allocate that size.
      
      In the good case, it'll lead to the following warning, but it may also cause
      the kernel to kick in the OOM and kill a random task on the server.
      
      [ 8921.744094] WARNING: at mm/page_alloc.c:2255 __alloc_pages_slowpath+0x65/0x730()
      [ 8921.749770] Pid: 5081, comm: trinity Tainted: G        W    3.4.0-rc1-next-20120402-sasha #46
      [ 8921.756672] Call Trace:
      [ 8921.758185]  [<ffffffff810b2ba7>] warn_slowpath_common+0x87/0xb0
      [ 8921.762868]  [<ffffffff810b2be5>] warn_slowpath_null+0x15/0x20
      [ 8921.765399]  [<ffffffff8117eae5>] __alloc_pages_slowpath+0x65/0x730
      [ 8921.769226]  [<ffffffff81179c8a>] ? zone_watermark_ok+0x1a/0x20
      [ 8921.771686]  [<ffffffff8117d045>] ? get_page_from_freelist+0x625/0x660
      [ 8921.773919]  [<ffffffff8117f3a8>] __alloc_pages_nodemask+0x1f8/0x240
      [ 8921.776248]  [<ffffffff811c03e0>] kmalloc_large_node+0x70/0xc0
      [ 8921.778294]  [<ffffffff811c4bd4>] __kmalloc_node_track_caller+0x34/0x1c0
      [ 8921.780847]  [<ffffffff821b0e3c>] ? sock_alloc_send_pskb+0xbc/0x260
      [ 8921.783179]  [<ffffffff821b3c65>] __alloc_skb+0x75/0x170
      [ 8921.784971]  [<ffffffff821b0e3c>] sock_alloc_send_pskb+0xbc/0x260
      [ 8921.787111]  [<ffffffff821b002e>] ? release_sock+0x7e/0x90
      [ 8921.788973]  [<ffffffff821b0ff0>] sock_alloc_send_skb+0x10/0x20
      [ 8921.791052]  [<ffffffff824cfc20>] pep_sendmsg+0x60/0x380
      [ 8921.792931]  [<ffffffff824cb4a6>] ? pn_socket_bind+0x156/0x180
      [ 8921.794917]  [<ffffffff824cb50f>] ? pn_socket_autobind+0x3f/0x90
      [ 8921.797053]  [<ffffffff824cb63f>] pn_socket_sendmsg+0x4f/0x70
      [ 8921.798992]  [<ffffffff821ab8e7>] sock_aio_write+0x187/0x1b0
      [ 8921.801395]  [<ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0
      [ 8921.803501]  [<ffffffff8111842c>] ? __lock_acquire+0x42c/0x4b0
      [ 8921.805505]  [<ffffffff821ab760>] ? __sock_recv_ts_and_drops+0x140/0x140
      [ 8921.807860]  [<ffffffff811e07cc>] do_sync_readv_writev+0xbc/0x110
      [ 8921.809986]  [<ffffffff811958e7>] ? might_fault+0x97/0xa0
      [ 8921.811998]  [<ffffffff817bd99e>] ? security_file_permission+0x1e/0x90
      [ 8921.814595]  [<ffffffff811e17e2>] do_readv_writev+0xe2/0x1e0
      [ 8921.816702]  [<ffffffff810b8dac>] ? do_setitimer+0x1ac/0x200
      [ 8921.818819]  [<ffffffff810e2ec1>] ? get_parent_ip+0x11/0x50
      [ 8921.820863]  [<ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0
      [ 8921.823318]  [<ffffffff811e1926>] vfs_writev+0x46/0x60
      [ 8921.825219]  [<ffffffff811e1a3f>] sys_writev+0x4f/0xb0
      [ 8921.827127]  [<ffffffff82658039>] system_call_fastpath+0x16/0x1b
      [ 8921.829384] ---[ end trace dffe390f30db9eb7 ]---
      Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
      Acked-by: NRémi Denis-Courmont <remi.denis-courmont@nokia.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bcf1b70a
    • E
      tcp: tcp_sendpages() should call tcp_push() once · 35f9c09f
      Eric Dumazet 提交于
      commit 2f533844 (tcp: allow splice() to build full TSO packets) added
      a regression for splice() calls using SPLICE_F_MORE.
      
      We need to call tcp_flush() at the end of the last page processed in
      tcp_sendpages(), or else transmits can be deferred and future sends
      stall.
      
      Add a new internal flag, MSG_SENDPAGE_NOTLAST, acting like MSG_MORE, but
      with different semantic.
      
      For all sendpage() providers, its a transparent change. Only
      sock_sendpage() and tcp_sendpages() can differentiate the two different
      flags provided by pipe_to_sendpage()
      Reported-by: NTom Herbert <therbert@google.com>
      Cc: Nandita Dukkipati <nanditad@google.com>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Tom Herbert <therbert@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: H.K. Jerry Chu <hkchu@google.com>
      Cc: Maciej Żenczykowski <maze@google.com>
      Cc: Mahesh Bandewar <maheshb@google.com>
      Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: NEric Dumazet <eric.dumazet@gmail&gt;com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      35f9c09f
  2. 05 4月, 2012 17 次提交
  3. 04 4月, 2012 18 次提交