1. 02 Aug, 2013 6 commits
    • Roman Gushchin's avatar
      net: check net.core.somaxconn sysctl values · 5f671d6b
      Roman Gushchin authored
      It's possible to assign an invalid value to the net.core.somaxconn
      sysctl variable, because there is no checks at all.
      
      The sk_max_ack_backlog field of the sock structure is defined as
      unsigned short. Therefore, the backlog argument in inet_listen()
      shouldn't exceed USHRT_MAX. The backlog argument in the listen() syscall
      is truncated to the somaxconn value. So, the somaxconn value shouldn't
      exceed 65535 (USHRT_MAX).
      Also, negative values of somaxconn are meaningless.
      
      before:
      $ sysctl -w net.core.somaxconn=256
      net.core.somaxconn = 256
      $ sysctl -w net.core.somaxconn=65536
      net.core.somaxconn = 65536
      $ sysctl -w net.core.somaxconn=-100
      net.core.somaxconn = -100
      
      after:
      $ sysctl -w net.core.somaxconn=256
      net.core.somaxconn = 256
      $ sysctl -w net.core.somaxconn=65536
      error: "Invalid argument" setting key "net.core.somaxconn"
      $ sysctl -w net.core.somaxconn=-100
      error: "Invalid argument" setting key "net.core.somaxconn"
      
      Based on a prior patch from Changli Gao.
      Signed-off-by: default avatarRoman Gushchin <klamm@yandex-team.ru>
      Reported-by: default avatarChangli Gao <xiaosuo@gmail.com>
      Suggested-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5f671d6b
    • Denis Kirjanov's avatar
      sis900: Fix the tx queue timeout issue · 3508ea33
      Denis Kirjanov authored
      [  198.720048] ------------[ cut here ]------------
      [  198.720108] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:255 dev_watchdog+0x229/0x240()
      [  198.720118] NETDEV WATCHDOG: eth0 (sis900): transmit queue 0 timed out
      [  198.720125] Modules linked in: bridge stp llc dmfe sundance 3c59x sis900 mii
      [  198.720159] CPU: 0 PID: 0 Comm: swapper Not tainted 3.11.0-rc3+ #12
      [  198.720167] Hardware name: System Manufacturer System Name/TUSI-M, BIOS ASUS TUSI-M ACPI BIOS
      Revision 1013 Beta 001 12/14/2001
      [  198.720175]  000000ff c13fa6b9 c169ddcc c12208d6 c169ddf8 c1031e4d c1664a84 c169de24
      [  198.720197]  00000000 c165f5ea 000000ff c13fa6b9 00000001 000000ff c1664a84 c169de10
      [  198.720217]  c1031f13 00000009 c169de08 c1664a84 c169de24 c169de50 c13fa6b9 c165f5ea
      [  198.720240] Call Trace:
      [  198.720257]  [<c13fa6b9>] ? dev_watchdog+0x229/0x240
      [  198.720274]  [<c12208d6>] dump_stack+0x16/0x20
      [  198.720306]  [<c1031e4d>] warn_slowpath_common+0x7d/0xa0
      [  198.720318]  [<c13fa6b9>] ? dev_watchdog+0x229/0x240
      [  198.720330]  [<c1031f13>] warn_slowpath_fmt+0x33/0x40
      [  198.720342]  [<c13fa6b9>] dev_watchdog+0x229/0x240
      [  198.720357]  [<c103f158>] call_timer_fn+0x78/0x150
      [  198.720369]  [<c103f0e0>] ? internal_add_timer+0x40/0x40
      [  198.720381]  [<c13fa490>] ? dev_init_scheduler+0xa0/0xa0
      [  198.720392]  [<c103f33f>] run_timer_softirq+0x10f/0x200
      [  198.720412]  [<c103954f>] ? __do_softirq+0x6f/0x210
      [  198.720424]  [<c13fa490>] ? dev_init_scheduler+0xa0/0xa0
      [  198.720435]  [<c1039598>] __do_softirq+0xb8/0x210
      [  198.720467]  [<c14b54d2>] ? _raw_spin_unlock+0x22/0x30
      [  198.720484]  [<c1003245>] ? handle_irq+0x25/0xd0
      [  198.720496]  [<c1039c0c>] irq_exit+0x9c/0xb0
      [  198.720508]  [<c14bc9d7>] do_IRQ+0x47/0x94
      [  198.720534]  [<c1056078>] ? hrtimer_start+0x28/0x30
      [  198.720564]  [<c14bc8b1>] common_interrupt+0x31/0x38
      [  198.720589]  [<c1008692>] ? default_idle+0x22/0xa0
      [  198.720600]  [<c10083c7>] arch_cpu_idle+0x17/0x30
      [  198.720631]  [<c106d23d>] cpu_startup_entry+0xcd/0x180
      [  198.720643]  [<c14ae30a>] rest_init+0xaa/0xb0
      [  198.720654]  [<c14ae260>] ? reciprocal_value+0x50/0x50
      [  198.720668]  [<c17044e0>] ? repair_env_string+0x60/0x60
      [  198.720679]  [<c1704bda>] start_kernel+0x29a/0x350
      [  198.720690]  [<c17044e0>] ? repair_env_string+0x60/0x60
      [  198.720721]  [<c1704269>] i386_start_kernel+0x39/0xa0
      [  198.720729] ---[ end trace 81e0a6266f5c73a8 ]---
      [  198.720740] eth0: Transmit timeout, status 00000204 00000000
      
      timer routine checks the link status and if it's up calls
      netif_carrier_on() allowing upper layer to start the tx queue
      even if the auto-negotiation process is not finished.
      
      Also remove ugly auto-negotiation check from the sis900_start_xmit()
      
      CC: Duan Fugang <B38611@freescale.com>
      CC: Ben Hutchings <bhutchings@solarflare.com>
      Signed-off-by: default avatarDenis Kirjanov <kda@linux-powerpc.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3508ea33
    • Daniel Borkmann's avatar
      net: rtm_to_ifaddr: free ifa if ifa_cacheinfo processing fails · 446266b0
      Daniel Borkmann authored
      Commit 5c766d64 ("ipv4: introduce address lifetime") leaves the ifa
      resource that was allocated via inet_alloc_ifa() unfreed when returning
      the function with -EINVAL. Thus, free it first via inet_free_ifa().
      Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
      Reviewed-by: default avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      446266b0
    • Lekensteyn's avatar
      r8169: remove "PHY reset until link up" log spam · 9bb8eeb5
      Lekensteyn authored
      This message was added in commit a7154cb8 (June 2004, [PATCH] r8169:
      link handling and phy reset rework) and is printed every ten seconds
      when no cable is connected and runtime power management is disabled.
      (Before that commit, "Reset RTL8169s PHY" would be printed instead.)
      Signed-off-by: default avatarPeter Wu <lekensteyn@gmail.com>
      Acked-by: default avatarFrancois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9bb8eeb5
    • Felipe Balbi's avatar
      net: ethernet: cpsw: drop IRQF_DISABLED · 7069f982
      Felipe Balbi authored
      IRQF_DISABLED is a no-op by now and should be
      removed.
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      Acked-by: default avatarMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7069f982
    • stephen hemminger's avatar
      htb: fix sign extension bug · cbd37556
      stephen hemminger authored
      When userspace passes a large priority value
      the assignment of the unsigned value hopt->prio
      to  signed int cl->prio causes cl->prio to become negative and the
      comparison is with TC_HTB_NUMPRIO is always false.
      
      The result is that HTB crashes by referencing outside
      the array when processing packets. With this patch the large value
      wraps around like other values outside the normal range.
      
      See: https://bugzilla.kernel.org/show_bug.cgi?id=60669Signed-off-by: default avatarStephen Hemminger <stephen@networkplumber.org>
      Acked-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cbd37556
  2. 01 Aug, 2013 15 commits
    • Michael S. Tsirkin's avatar
      macvlan: handle set_promiscuity failures · 78738141
      Michael S. Tsirkin authored
      It's quite unlikely that dev_set_promiscuity will fail,
      but worth checking just in case.
      
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      78738141
    • Michael S. Tsirkin's avatar
      macvlan: better mode validation · 266e8347
      Michael S. Tsirkin authored
      macvlan passthrough mode is special: it's not possible to switch to or
      from it through a netlink command.
      
      But if you try, the command will succeed, which is
      confusing.
      
      Validate input and return error to user.
      
      Cc:  Sridhar Samudrala <sri@us.ibm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      266e8347
    • Ying Xue's avatar
      tipc: fix oops when creating server socket fails · c756891a
      Ying Xue authored
      When creation of TIPC internal server socket fails,
      we get an oops with the following dump:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
      IP: [<ffffffffa0011f49>] tipc_close_conn+0x59/0xb0 [tipc]
      PGD 13719067 PUD 12008067 PMD 0
      Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      Modules linked in: tipc(+)
      CPU: 4 PID: 4340 Comm: insmod Not tainted 3.10.0+ #1
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      task: ffff880014360000 ti: ffff88001374c000 task.ti: ffff88001374c000
      RIP: 0010:[<ffffffffa0011f49>]  [<ffffffffa0011f49>] tipc_close_conn+0x59/0xb0 [tipc]
      RSP: 0018:ffff88001374dc98  EFLAGS: 00010292
      RAX: 0000000000000000 RBX: ffff880012ac09d8 RCX: 0000000000000000
      RDX: 0000000000000046 RSI: 0000000000000001 RDI: ffff880014360000
      RBP: ffff88001374dcb8 R08: 0000000000000001 R09: 0000000000000001
      R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa0016fa0
      R13: ffffffffa0017010 R14: ffffffffa0017010 R15: ffff880012ac09d8
      FS:  0000000000000000(0000) GS:ffff880016600000(0063) knlGS:00000000f76668d0
      CS:  0010 DS: 002b ES: 002b CR0: 000000008005003b
      CR2: 0000000000000020 CR3: 0000000012227000 CR4: 00000000000006e0
      Stack:
      ffff88001374dcb8 ffffffffa0016fa0 0000000000000000 0000000000000001
      ffff88001374dcf8 ffffffffa0012922 ffff88001374dce8 00000000ffffffea
      ffffffffa0017100 0000000000000000 ffff8800134241a8 ffffffffa0017150
      Call Trace:
      [<ffffffffa0012922>] tipc_server_stop+0xa2/0x1b0 [tipc]
      [<ffffffffa0009995>] tipc_subscr_stop+0x15/0x20 [tipc]
      [<ffffffffa00130f5>] tipc_core_stop+0x1d/0x33 [tipc]
      [<ffffffffa001f0d4>] tipc_init+0xd4/0xf8 [tipc]
      [<ffffffffa001f000>] ? 0xffffffffa001efff
      [<ffffffff8100023f>] do_one_initcall+0x3f/0x150
      [<ffffffff81082f4d>] ? __blocking_notifier_call_chain+0x7d/0xd0
      [<ffffffff810cc58a>] load_module+0x11aa/0x19c0
      [<ffffffff810c8d60>] ? show_initstate+0x50/0x50
      [<ffffffff8190311c>] ? retint_restore_args+0xe/0xe
      [<ffffffff810cce79>] SyS_init_module+0xd9/0x110
      [<ffffffff8190dc65>] sysenter_dispatch+0x7/0x1f
      Code: 6c 24 70 4c 89 ef e8 b7 04 8f e1 8b 73 04 4c 89 e7 e8 7c 9e 32 e1 41 83 ac 24
      b8 00 00 00 01 4c 89 ef e8 eb 0a 8f e1 48 8b 43 08 <4c> 8b 68 20 4d 8d a5 48 03 00
      00 4c 89 e7 e8 04 05 8f e1 4c 89
      RIP  [<ffffffffa0011f49>] tipc_close_conn+0x59/0xb0 [tipc]
      RSP <ffff88001374dc98>
      CR2: 0000000000000020
      ---[ end trace b02321f40e4269a3 ]---
      
      We have the following call chain:
      
      tipc_core_start()
          ret = tipc_subscr_start()
              ret = tipc_server_start(){
                        server->enabled = 1;
                        ret = tipc_open_listening_sock()
                    }
      
      I.e., the server->enabled flag is unconditionally set to 1, whatever
      the return value of tipc_open_listening_sock().
      
      This causes a crash when tipc_core_start() tries to clean up
      resources after a failed initialization:
      
          if (ret == failed)
              tipc_subscr_stop()
                  tipc_server_stop(){
                      if (server->enabled)
                          tipc_close_conn(){
                              NULL reference of con->sock-sk
                              OOPS!
                      }
                  }
      
      To avoid this, tipc_server_start() should only set server->enabled
      to 1 in case of a succesful socket creation. In case of failure, it
      should release all allocated resources before returning.
      
      Problem introduced in commit c5fa7b3c
      ("tipc: introduce new TIPC server infrastructure") in v3.11-rc1.
      Note that it won't be seen often; it takes a module load under memory
      constrained conditions in order to trigger the failure condition.
      Signed-off-by: default avatarYing Xue <ying.xue@windriver.com>
      Signed-off-by: default avatarJon Maloy <jon.maloy@ericsson.com>
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c756891a
    • Cong Wang's avatar
      net: rename CONFIG_NET_LL_RX_POLL to CONFIG_NET_RX_BUSY_POLL · e0d1095a
      Cong Wang authored
      Eliezer renames several *ll_poll to *busy_poll, but forgets
      CONFIG_NET_LL_RX_POLL, so in case of confusion, rename it too.
      
      Cc: Eliezer Tamir <eliezer.tamir@linux.intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0d1095a
    • Cong Wang's avatar
      net: fix a compile error when CONFIG_NET_LL_RX_POLL is not set · dfcefb0b
      Cong Wang authored
      When CONFIG_NET_LL_RX_POLL is not set, I got:
      
      net/socket.c: In function ‘sock_poll’:
      net/socket.c:1165:4: error: implicit declaration of function ‘sk_busy_loop’ [-Werror=implicit-function-declaration]
      
      Fix this by adding a nop when !CONFIG_NET_LL_RX_POLL.
      
      Cc: Eliezer Tamir <eliezer.tamir@linux.intel.com>
      Cc: David S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarCong Wang <amwang@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dfcefb0b
    • Jack Morgenstein's avatar
      net/mlx4_core: VFs must ignore the enable_64b_cqe_eqe module param · b3051320
      Jack Morgenstein authored
      Slaves get the 64B CQE/EQE state from QUERY_HCA, not from the module parameter.
      
      If the parameter is set to zero, the slave outputs an incorrect/irrelevant
      warning message that 64B CQEs/EQEs are supported but not enabled (even if the
      hypervisor has enabled 64B CQEs/EQEs).
      Signed-off-by: default avatarJack Morgenstein <jackm@dev.mellanox.co.il>
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3051320
    • Or Gerlitz's avatar
      net/mlx4_core: Don't give VFs MAC addresses which are derived from the PF MAC · 0508ad64
      Or Gerlitz authored
      If the user has not assigned a MAC address to a VM, then don't give it MAC which
      is based on the PF one. The current derivation scheme is wrong and leads to VM
      MAC collisions when the number of cards/hypervisors becomes big enough.
      
      Instead, just give it zeros and let them figure out what to do with that.
      Signed-off-by: default avatarOr Gerlitz <ogerlitz@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0508ad64
    • Jiri Benc's avatar
      ipv6: prevent race between address creation and removal · 8a226b2c
      Jiri Benc authored
      There's a race in IPv6 automatic addess assignment. The address is created
      with zero lifetime when it's added to various address lists. Before it gets
      assigned the correct lifetime, there's a window where a new address may be
      configured. This causes the semi-initiated address to be deleted in
      addrconf_verify.
      
      This was discovered as a reference leak caused by concurrent run of
      __ipv6_ifa_notify for both RTM_NEWADDR and RTM_DELADDR with the same
      address.
      
      Fix this by setting the lifetime before the address is added to
      inet6_addr_lst.
      
      A few notes:
      
      1. In addrconf_prefix_rcv, by setting update_lft to zero, the
         if (update_lft) { ... } condition is no longer executed for newly
         created addresses. This is okay, as the ifp fields are set in
         ipv6_add_addr now and ipv6_ifa_notify is called (and has been called)
         through addrconf_dad_start.
      
      2. The removal of the whole block under ifp->lock in inet6_addr_add is okay,
         too, as tstamp is initialized to jiffies in ipv6_add_addr.
      Signed-off-by: default avatarJiri Benc <jbenc@redhat.com>
      Signed-off-by: default avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8a226b2c
    • Jiri Pirko's avatar
      3f8f5298
    • Michal Kubeček's avatar
      ipv6: update ip6_rt_last_gc every time GC is run · 49a18d86
      Michal Kubeček authored
      As pointed out by Eric Dumazet, net->ipv6.ip6_rt_last_gc should
      hold the last time garbage collector was run so that we should
      update it whenever fib6_run_gc() calls fib6_clean_all(), not only
      if we got there from ip6_dst_gc().
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      49a18d86
    • Michal Kubeček's avatar
      ipv6: prevent fib6_run_gc() contention · 2ac3ac8f
      Michal Kubeček authored
      On a high-traffic router with many processors and many IPv6 dst
      entries, soft lockup in fib6_run_gc() can occur when number of
      entries reaches gc_thresh.
      
      This happens because fib6_run_gc() uses fib6_gc_lock to allow
      only one thread to run the garbage collector but ip6_dst_gc()
      doesn't update net->ipv6.ip6_rt_last_gc until fib6_run_gc()
      returns. On a system with many entries, this can take some time
      so that in the meantime, other threads pass the tests in
      ip6_dst_gc() (ip6_rt_last_gc is still not updated) and wait for
      the lock. They then have to run the garbage collector one after
      another which blocks them for quite long.
      
      Resolve this by replacing special value ~0UL of expire parameter
      to fib6_run_gc() by explicit "force" parameter to choose between
      spin_lock_bh() and spin_trylock_bh() and call fib6_run_gc() with
      force=false if gc_thresh is reached but not max_size.
      Signed-off-by: default avatarMichal Kubecek <mkubecek@suse.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2ac3ac8f
    • David S. Miller's avatar
      Merge branch 'for-davem' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless · 1f1059fc
      David S. Miller authored
      John W. Linville says:
      
      ====================
      This pull request is intended for the 3.11 stream.  It is a bit
      larger than usual, as it includes pulls from most of my feeder trees
      as well...
      
      For the Bluetooth bits, Gustavo says:
      
      "A few fixes and devices ID additions for 3.11:
      
       * There are 4 new ath3k device ids
       * Fixed stack memory usage in ath3k.
       * Fixed the init process of BlueFRITZ! devices, they were failing to init
         due to an unsupported command we sent.
       * Fixed wrong use of PTR_ERR in btusb code that was preventing intel devices
         to work properly.
       * Fixed race condition between hci_register_dev() and hci_dev_open() that
         could cause a NULL pointer dereference.
       * Fixed race condition that could call hci_req_cmd_complete() and make some
         devices to fail as showed in the log added to the commit message."
      
      Regarding the NFC bits, Samuel says:
      
      "We have:
      
      1) A build failure fix for the NCI SPI transport layer due to a
         missing CRC_CCITT Kconfig dependency.
      
      2) A netlink command rename: CMD_FW_UPLOAD was merged during the 3.11
         merge window but the typical terminology for loading a firmware to a
         target is firmware download rather than upload. In order to avoid any
         confusion in a file exported to userspace, we rename this command to
         CMD_FW_DOWNLOAD."
      
      Samuel's item #2 isn't strictly a fix, but it seems safe and should
      avoid confusion in the future.
      
      As for the mac80211 bits, Johannes says:
      
      "I only have three fixes this time, a fix for a suspend regression, a
      patch correcting the initiator in regulatory code and one fix for mesh
      station powersave."
      
      With respect to the iwlwifi bits, Johannes says:
      
      "We have a scan fix for passive channels, a new PCI device ID for an old
      device, a NIC reset fix, an RF-Kill fix, a fix for powersave when GO
      interfaces are present as well as an aggregation session fix (for a
      corner case) and a workaround for a firmware design issue - it only
      supports a single GTK in D3."
      
      Bringing-up the rear with the Atheros trees, Kalle says:
      
      "Geert Uytterhoeven fixed an ath10k build problem when NO_DMA=y. I added
      a missing MAINTAINERS entry for ath10k and updated ath6kl git tree
      location."
      
      Along with the above...
      
      Arend van Spriel fixes a brcmfmac WARNING when unplugging the device.
      
      Avinash Patil proves a couple of minor mwifiex fixes relating to P2P mode.
      
      Luciano Coelho updates the MAINTAINERS entry for the wilink drivers.
      
      Stanislaw Gruszka brings an rt2x00 fix for a queue start/stop problem.
      
      Stone Piao fixes another mwifiex problem, a command timeout related to P2P mode.
      
      Tomasz Moń corrects an endian problem in mwifiex.
      
      I'll remind my feeder maintainers to slowdown the patchflow.
      Beyond that, please let me know if there are problems!
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1f1059fc
    • John W. Linville's avatar
      Merge branch 'master' of... · 22e02a02
      John W. Linville authored
      Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
      22e02a02
    • Linus Lüssing's avatar
      bridge: disable snooping if there is no querier · b00589af
      Linus Lüssing authored
      If there is no querier on a link then we won't get periodic reports and
      therefore won't be able to learn about multicast listeners behind ports,
      potentially leading to lost multicast packets, especially for multicast
      listeners that joined before the creation of the bridge.
      
      These lost multicast packets can appear since c5c23260
      ("bridge: Add multicast_querier toggle and disable queries by default")
      in particular.
      
      With this patch we are flooding multicast packets if our querier is
      disabled and if we didn't detect any other querier.
      
      A grace period of the Maximum Response Delay of the querier is added to
      give multicast responses enough time to arrive and to be learned from
      before disabling the flooding behaviour again.
      Signed-off-by: default avatarLinus Lüssing <linus.luessing@web.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b00589af
    • Neil Horman's avatar
      8139cp: Add dma_mapping_error checking · cf3c4c03
      Neil Horman authored
      Self explanitory dma_mapping_error addition to the 8139 driver, based on this:
      https://bugzilla.redhat.com/show_bug.cgi?id=947250
      
      It showed several backtraces arising for dma_map_* usage without checking the
      return code on the mapping.  Add the check and abort the rx/tx operation if its
      failed.  Untested as I have no hardware and the reporter has wandered off, but
      seems pretty straightforward.
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      CC: "David S. Miller" <davem@davemloft.net>
      CC: Francois Romieu <romieu@fr.zoreil.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cf3c4c03
  3. 31 Jul, 2013 19 commits