1. 20 Apr, 2016 5 commits
    • Takashi Iwai's avatar
      ALSA: timer: Use mod_timer() for rearming the system timer · 415ab756
      Takashi Iwai authored
      commit 4a07083e upstream.
      
      ALSA system timer backend stops the timer via del_timer() without sync
      and leaves del_timer_sync() at the close instead.  This is because of
      the restriction by the design of ALSA timer: namely, the stop callback
      may be called from the timer handler, and calling the sync shall lead
      to a hangup.  However, this also triggers a kernel BUG() when the
      timer is rearmed immediately after stopping without sync:
       kernel BUG at kernel/time/timer.c:966!
       Call Trace:
        <IRQ>
        [<ffffffff8239c94e>] snd_timer_s_start+0x13e/0x1a0
        [<ffffffff8239e1f4>] snd_timer_interrupt+0x504/0xec0
        [<ffffffff8122fca0>] ? debug_check_no_locks_freed+0x290/0x290
        [<ffffffff8239ec64>] snd_timer_s_function+0xb4/0x120
        [<ffffffff81296b72>] call_timer_fn+0x162/0x520
        [<ffffffff81296add>] ? call_timer_fn+0xcd/0x520
        [<ffffffff8239ebb0>] ? snd_timer_interrupt+0xec0/0xec0
        ....
      
      It's the place where add_timer() checks the pending timer.  It's clear
      that this may happen after the immediate restart without sync in our
      cases.
      
      So, the workaround here is just to use mod_timer() instead of
      add_timer().  This looks like a band-aid fix, but it's a right move,
      as snd_timer_interrupt() takes care of the continuous rearm of timer.
      Reported-by: default avatarJiri Slaby <jslaby@suse.cz>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      415ab756
    • Helge Deller's avatar
      parisc: Fix kernel crash with reversed copy_from_user() · 168d26de
      Helge Deller authored
      commit ef72f311 upstream.
      
      The kernel module testcase (lib/test_user_copy.c) exhibited a kernel
      crash on parisc if the parameters for copy_from_user were reversed
      ("illegal reversed copy_to_user" testcase).
      
      Fix this potential crash by checking the fault handler if the faulting
      address is in the exception table.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      168d26de
    • Helge Deller's avatar
      parisc: Avoid function pointers for kernel exception routines · b1366744
      Helge Deller authored
      commit e3893027 upstream.
      
      We want to avoid the kernel module loader to create function pointers
      for the kernel fixup routines of get_user() and put_user(). Changing
      the external reference from function type to int type fixes this.
      
      This unbreaks exception handling for get_user() and put_user() when
      called from a kernel module.
      Signed-off-by: default avatarHelge Deller <deller@gmx.de>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      b1366744
    • Guenter Roeck's avatar
      hwmon: (max1111) Return -ENODEV from max1111_read_channel if not instantiated · f51d4ce2
      Guenter Roeck authored
      commit 3c2e2266 upstream.
      
      arm:pxa_defconfig can result in the following crash if the max1111 driver
      is not instantiated.
      
      Unhandled fault: page domain fault (0x01b) at 0x00000000
      pgd = c0004000
      [00000000] *pgd=00000000
      Internal error: : 1b [#1] PREEMPT ARM
      Modules linked in:
      CPU: 0 PID: 300 Comm: kworker/0:1 Not tainted 4.5.0-01301-g1701f680 #10
      Hardware name: SHARP Akita
      Workqueue: events sharpsl_charge_toggle
      task: c390a000 ti: c391e000 task.ti: c391e000
      PC is at max1111_read_channel+0x20/0x30
      LR is at sharpsl_pm_pxa_read_max1111+0x2c/0x3c
      pc : [<c03aaab0>]    lr : [<c0024b50>]    psr: 20000013
      ...
      [<c03aaab0>] (max1111_read_channel) from [<c0024b50>]
      					(sharpsl_pm_pxa_read_max1111+0x2c/0x3c)
      [<c0024b50>] (sharpsl_pm_pxa_read_max1111) from [<c00262e0>]
      					(spitzpm_read_devdata+0x5c/0xc4)
      [<c00262e0>] (spitzpm_read_devdata) from [<c0024094>]
      					(sharpsl_check_battery_temp+0x78/0x110)
      [<c0024094>] (sharpsl_check_battery_temp) from [<c0024f9c>]
      					(sharpsl_charge_toggle+0x48/0x110)
      [<c0024f9c>] (sharpsl_charge_toggle) from [<c004429c>]
      					(process_one_work+0x14c/0x48c)
      [<c004429c>] (process_one_work) from [<c0044618>] (worker_thread+0x3c/0x5d4)
      [<c0044618>] (worker_thread) from [<c004a238>] (kthread+0xd0/0xec)
      [<c004a238>] (kthread) from [<c000a670>] (ret_from_fork+0x14/0x24)
      
      This can occur because the SPI controller driver (SPI_PXA2XX) is built as
      module and thus not necessarily loaded. While building SPI_PXA2XX into the
      kernel would make the problem disappear, it appears prudent to ensure that
      the driver is instantiated before accessing its data structures.
      
      Cc: Arnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      f51d4ce2
    • Petr Štetiar's avatar
      USB: qmi_wwan: Add quirk for Quectel EC20 Mini PCIe module · 28a9b9b7
      Petr Štetiar authored
      commit b3d8cf01 upstream.
      
      This device has same vendor and product IDs as G2K devices, but it has
      different number of interfaces(4 vs 5) and also different interface
      layout where EC20 has QMI on interface 4 instead of 0.
      
      lsusb output:
      
      	Bus 002 Device 003: ID 05c6:9215 Qualcomm, Inc. Acer Gobi 2000
      	Device Descriptor:
      	  bLength                18
      	  bDescriptorType         1
      	  bcdUSB               2.00
      	  bDeviceClass            0 (Defined at Interface level)
      	  bDeviceSubClass         0
      	  bDeviceProtocol         0
      	  bMaxPacketSize0        64
      	  idVendor           0x05c6 Qualcomm, Inc.
      	  idProduct          0x9215 Acer Gobi 2000 Wireless Modem
      	  bcdDevice            2.32
      	  iManufacturer           1 Quectel
      	  iProduct                2 Quectel LTE Module
      	  iSerial                 0
      	  bNumConfigurations      1
      	  Configuration Descriptor:
      	    bLength                 9
      	    bDescriptorType         2
      	    wTotalLength          209
      	    bNumInterfaces          5
      	    bConfigurationValue     1
      	    iConfiguration          0
      	    bmAttributes         0xa0
      	      (Bus Powered)
      	      Remote Wakeup
      	    MaxPower              500mA
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      Acked-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      28a9b9b7
  2. 19 Apr, 2016 8 commits
    • Jakub Sitnicki's avatar
      ipv6: Count in extension headers in skb->network_header · 9dfcd3a8
      Jakub Sitnicki authored
      [ Upstream commit 3ba3458f ]
      
      When sending a UDPv6 message longer than MTU, account for the length
      of fragmentable IPv6 extension headers in skb->network_header offset.
      Same as we do in alloc_new_skb path in __ip6_append_data().
      
      This ensures that later on __ip6_make_skb() will make space in
      headroom for fragmentable extension headers:
      
      	/* move skb->data to ip header from ext header */
      	if (skb->data < skb_network_header(skb))
      		__skb_pull(skb, skb_network_offset(skb));
      
      Prevents a splat due to skb_under_panic:
      
      skbuff: skb_under_panic: text:ffffffff8143397b len:2126 put:14 \
      head:ffff880005bacf50 data:ffff880005bacf4a tail:0x48 end:0xc0 dev:lo
      ------------[ cut here ]------------
      kernel BUG at net/core/skbuff.c:104!
      invalid opcode: 0000 [#1] KASAN
      CPU: 0 PID: 160 Comm: reproducer Not tainted 4.6.0-rc2 #65
      [...]
      Call Trace:
       [<ffffffff813eb7b9>] skb_push+0x79/0x80
       [<ffffffff8143397b>] eth_header+0x2b/0x100
       [<ffffffff8141e0d0>] neigh_resolve_output+0x210/0x310
       [<ffffffff814eab77>] ip6_finish_output2+0x4a7/0x7c0
       [<ffffffff814efe3a>] ip6_output+0x16a/0x280
       [<ffffffff815440c1>] ip6_local_out+0xb1/0xf0
       [<ffffffff814f1115>] ip6_send_skb+0x45/0xd0
       [<ffffffff81518836>] udp_v6_send_skb+0x246/0x5d0
       [<ffffffff8151985e>] udpv6_sendmsg+0xa6e/0x1090
      [...]
      Reported-by: default avatarJi Jianwen <jiji@redhat.com>
      Signed-off-by: default avatarJakub Sitnicki <jkbs@redhat.com>
      Acked-by: default avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      9dfcd3a8
    • Thadeu Lima de Souza Cascardo's avatar
      ip6_tunnel: set rtnl_link_ops before calling register_netdevice · 4eb6e92e
      Thadeu Lima de Souza Cascardo authored
      [ Upstream commit b6ee376c ]
      
      When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set
      before ip6_tnl_create2 is called. When register_netdevice is called, there
      is no linkinfo attribute in the NEWLINK message because of that.
      
      Setting rtnl_link_ops before calling register_netdevice fixes that.
      
      Fixes: 0b112457 ("ip6tnl: add support of link creation via rtnl")
      Signed-off-by: default avatarThadeu Lima de Souza Cascardo <cascardo@redhat.com>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      4eb6e92e
    • Haishuang Yan's avatar
      ipv6: l2tp: fix a potential issue in l2tp_ip6_recv · 80136dc2
      Haishuang Yan authored
      [ Upstream commit be447f30 ]
      
      pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
      right place.
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      80136dc2
    • Haishuang Yan's avatar
      ipv4: l2tp: fix a potential issue in l2tp_ip_recv · 4a05fe25
      Haishuang Yan authored
      [ Upstream commit 5745b823 ]
      
      pskb_may_pull() can change skb->data, so we have to load ptr/optr at the
      right place.
      Signed-off-by: default avatarHaishuang Yan <yanhaishuang@cmss.chinamobile.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      4a05fe25
    • subashab@codeaurora.org's avatar
      xfrm: Fix crash observed during device unregistration and decryption · e1e03d36
      subashab@codeaurora.org authored
      [ Upstream commit 071d36bf ]
      
      A crash is observed when a decrypted packet is processed in receive
      path. get_rps_cpus() tries to dereference the skb->dev fields but it
      appears that the device is freed from the poison pattern.
      
      [<ffffffc000af58ec>] get_rps_cpu+0x94/0x2f0
      [<ffffffc000af5f94>] netif_rx_internal+0x140/0x1cc
      [<ffffffc000af6094>] netif_rx+0x74/0x94
      [<ffffffc000bc0b6c>] xfrm_input+0x754/0x7d0
      [<ffffffc000bc0bf8>] xfrm_input_resume+0x10/0x1c
      [<ffffffc000ba6eb8>] esp_input_done+0x20/0x30
      [<ffffffc0000b64c8>] process_one_work+0x244/0x3fc
      [<ffffffc0000b7324>] worker_thread+0x2f8/0x418
      [<ffffffc0000bb40c>] kthread+0xe0/0xec
      
      -013|get_rps_cpu(
           |    dev = 0xFFFFFFC08B688000,
           |    skb = 0xFFFFFFC0C76AAC00 -> (
           |      dev = 0xFFFFFFC08B688000 -> (
           |        name =
      "......................................................
           |        name_hlist = (next = 0xAAAAAAAAAAAAAAAA, pprev =
      0xAAAAAAAAAAA
      
      Following are the sequence of events observed -
      
      - Encrypted packet in receive path from netdevice is queued
      - Encrypted packet queued for decryption (asynchronous)
      - Netdevice brought down and freed
      - Packet is decrypted and returned through callback in esp_input_done
      - Packet is queued again for process in network stack using netif_rx
      
      Since the device appears to have been freed, the dereference of
      skb->dev in get_rps_cpus() leads to an unhandled page fault
      exception.
      
      Fix this by holding on to device reference when queueing packets
      asynchronously and releasing the reference on call back return.
      
      v2: Make the change generic to xfrm as mentioned by Steffen and
      update the title to xfrm
      Suggested-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarJerome Stanislaus <jeromes@codeaurora.org>
      Signed-off-by: default avatarSubash Abhinov Kasiviswanathan <subashab@codeaurora.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      e1e03d36
    • Guillaume Nault's avatar
      ppp: take reference on channels netns · 736a17fe
      Guillaume Nault authored
      [ Upstream commit 1f461dcd ]
      
      Let channels hold a reference on their network namespace.
      Some channel types, like ppp_async and ppp_synctty, can have their
      userspace controller running in a different namespace. Therefore they
      can't rely on them to preclude their netns from being removed from
      under them.
      
      ==================================================================
      BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at
      addr ffff880064e217e0
      Read of size 8 by task syz-executor/11581
      =============================================================================
      BUG net_namespace (Not tainted): kasan: bad access detected
      -----------------------------------------------------------------------------
      
      Disabling lock debugging due to kernel taint
      INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906
      [<      none      >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
      [<      none      >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
      [<     inline     >] slab_alloc_node kernel/mm/slub.c:2532
      [<     inline     >] slab_alloc kernel/mm/slub.c:2574
      [<      none      >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579
      [<     inline     >] kmem_cache_zalloc kernel/include/linux/slab.h:597
      [<     inline     >] net_alloc kernel/net/core/net_namespace.c:325
      [<      none      >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360
      [<      none      >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95
      [<      none      >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150
      [<      none      >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451
      [<     inline     >] copy_process kernel/kernel/fork.c:1274
      [<      none      >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723
      [<     inline     >] SYSC_clone kernel/kernel/fork.c:1832
      [<      none      >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826
      [<      none      >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185
      
      INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631
      [<      none      >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
      [<     inline     >] slab_free kernel/mm/slub.c:2805
      [<      none      >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814
      [<     inline     >] net_free kernel/net/core/net_namespace.c:341
      [<      none      >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348
      [<      none      >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448
      [<      none      >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036
      [<      none      >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170
      [<      none      >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303
      [<      none      >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468
      INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000
      flags=0x5fffc0000004080
      INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200
      
      CPU: 1 PID: 11581 Comm: syz-executor Tainted: G    B           4.4.0+
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
       00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300
       ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054
       ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000
      Call Trace:
       [<     inline     >] __dump_stack kernel/lib/dump_stack.c:15
       [<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50
       [<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654
       [<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661
       [<     inline     >] print_address_description kernel/mm/kasan/report.c:138
       [<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236
       [<     inline     >] kasan_report kernel/mm/kasan/report.c:259
       [<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280
       [<     inline     >] ? ppp_pernet kernel/include/linux/compiler.h:218
       [<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<     inline     >] ppp_pernet kernel/include/linux/compiler.h:218
       [<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<     inline     >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293
       [<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
       [<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241
       [<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000
       [<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478
       [<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744
       [<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772
       [<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901
       [<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688
       [<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208
       [<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244
       [<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115
       [<     inline     >] exit_task_work kernel/include/linux/task_work.h:21
       [<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750
       [<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
       [<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357
       [<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550
       [<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145
       [<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880
       [<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307
       [<     inline     >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113
       [<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158
       [<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712
       [<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655
       [<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165
       [<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692
       [<     inline     >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099
       [<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678
       [<     inline     >] ? context_switch kernel/kernel/sched/core.c:2807
       [<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283
       [<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247
       [<     inline     >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282
       [<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344
       [<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281
      Memory state around the buggy address:
       ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      >ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                                             ^
       ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
      ==================================================================
      
      Fixes: 273ec51d ("net: ppp_generic - introduce net-namespace functionality v2")
      Reported-by: default avatarBaozeng Ding <sploving1@gmail.com>
      Signed-off-by: default avatarGuillaume Nault <g.nault@alphalink.fr>
      Reviewed-by: default avatarCyrill Gorcunov <gorcunov@openvz.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      736a17fe
    • Manish Chopra's avatar
      qlge: Fix receive packets drop. · ee9f959b
      Manish Chopra authored
      [ Upstream commit 2c9a266a ]
      
      When running small packets [length < 256 bytes] traffic, packets were
      being dropped due to invalid data in those packets which were
      delivered by the driver upto the stack. Using pci_dma_sync_single_for_cpu
      ensures copying latest and updated data into skb from the receive buffer.
      Signed-off-by: default avatarSony Chacko <sony.chacko@qlogic.com>
      Signed-off-by: default avatarManish Chopra <manish.chopra@qlogic.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      ee9f959b
    • Dmitri Epshtein's avatar
      net: mvneta: enable change MAC address when interface is up · 46e63be2
      Dmitri Epshtein authored
      [ Upstream commit 928b6519 ]
      
      Function eth_prepare_mac_addr_change() is called as part of MAC
      address change. This function check if interface is running.
      To enable change MAC address when interface is running:
      IFF_LIVE_ADDR_CHANGE flag must be set to dev->priv_flags field
      
      Fixes: c5aff182 ("net: mvneta: driver for Marvell Armada 370/XP
      network unit")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitri Epshtein <dima@marvell.com>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      46e63be2
  3. 18 Apr, 2016 27 commits