1. 21 Jul, 2015 14 commits
    • Joachim Eastwood's avatar
      stmmac: fix setting of driver data in stmmac_dvr_probe · a7a62685
      Joachim Eastwood authored
      Commit 803f8fc4 ("stmmac: move driver data setting into
      stmmac_dvr_probe") mistakenly set priv and not priv->dev as
      driver data. This meant that the remove, resume and suspend
      callbacks that fetched and tried to use this data would most
      likely explode. Fix the issue by using the correct variable.
      
      Fixes: 803f8fc4 ("stmmac: move driver data setting into stmmac_dvr_probe")
      Signed-off-by: default avatarJoachim Eastwood <manabian@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7a62685
    • David S. Miller's avatar
      Merge branch 'sch_panic' · 053c26f3
      David S. Miller authored
      Daniel Borkmann says:
      
      ====================
      Couple of classifier fixes
      
      This fixes a couple of panics in the form of (analogous for
      cls_flow{,er}):
      
      [  912.759276] BUG: unable to handle kernel NULL pointer dereference at (null)
      [  912.759373] IP: [<ffffffffa09d4d6d>] cls_bpf_change+0x23d/0x268 [cls_bpf]
      [  912.759441] PGD 8783c067 PUD 5f684067 PMD 0
      [  912.759491] Oops: 0002 [#1] SMP DEBUG_PAGEALLOC
      [  912.759543] Modules linked in: cls_bpf(E) act_gact [...]
      [  912.772734] CPU: 3 PID: 10489 Comm: tc Tainted: G        W   E   4.2.0-rc2+ #73
      [  912.775004] Hardware name: Apple Inc. MacBookAir5,1/Mac-66F35F19FE2A0D05, BIOS MBA51.88Z.00EF.B02.1211271028 11/27/2012
      [  912.777327] task: ffff88025eaa8000 ti: ffff88005f734000 task.ti: ffff88005f734000
      [  912.779662] RIP: 0010:[<ffffffffa09d4d6d>]  [<ffffffffa09d4d6d>] cls_bpf_change+0x23d/0x268 [cls_bpf]
      [  912.781991] RSP: 0018:ffff88005f7379c8  EFLAGS: 00010286
      [  912.784183] RAX: ffff880201d64e48 RBX: 0000000000000000 RCX: ffff880201d64e40
      [  912.786402] RDX: 0000000000000000 RSI: ffffffffa09d51c0 RDI: ffffffffa09d51a6
      [  912.788625] RBP: ffff88005f737a68 R08: 0000000000000000 R09: 0000000000000000
      [  912.790854] R10: 0000000000000001 R11: 0000000000000001 R12: ffff880078ab5a80
      [  912.793082] R13: ffff880232b31570 R14: ffff88005f737ae0 R15: ffff8801e215d1d0
      [  912.795181] FS:  00007f3c0c80d740(0000) GS:ffff880265400000(0000) knlGS:0000000000000000
      [  912.797281] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  912.799402] CR2: 0000000000000000 CR3: 000000005460f000 CR4: 00000000001407e0
      [  912.799403] Stack:
      [  912.799407]  ffffffff00000000 ffff88023ea18000 000000005f737a08 0000000000000000
      [  912.799415]  ffffffff81f06140 ffff880201d64e40 0000000000000000 ffff88023ea1804c
      [  912.799418]  0000000000000000 ffff88023ea18044 ffff88023ea18030 ffff88023ea18038
      [  912.799418] Call Trace:
      [  912.799437]  [<ffffffff816d5685>] tc_ctl_tfilter+0x335/0x910
      [  912.799443]  [<ffffffff813622a8>] ? security_capable+0x48/0x60
      [  912.799448]  [<ffffffff816b90e5>] rtnetlink_rcv_msg+0x95/0x240
      [  912.799454]  [<ffffffff810f612d>] ? trace_hardirqs_on+0xd/0x10
      [  912.799456]  [<ffffffff816b902f>] ? rtnetlink_rcv+0x1f/0x40
      [  912.799459]  [<ffffffff816b902f>] ? rtnetlink_rcv+0x1f/0x40
      [  912.799461]  [<ffffffff816b9050>] ? rtnetlink_rcv+0x40/0x40
      [  912.799464]  [<ffffffff816df38f>] netlink_rcv_skb+0xaf/0xc0
      [  912.799467]  [<ffffffff816b903e>] rtnetlink_rcv+0x2e/0x40
      [  912.799469]  [<ffffffff816deaef>] netlink_unicast+0xef/0x1b0
      [  912.799471]  [<ffffffff816defa0>] netlink_sendmsg+0x3f0/0x620
      [  912.799476]  [<ffffffff81687028>] sock_sendmsg+0x38/0x50
      [  912.799479]  [<ffffffff81687938>] ___sys_sendmsg+0x288/0x290
      [  912.799482]  [<ffffffff810f7852>] ? __lock_acquire+0x572/0x2050
      [  912.799488]  [<ffffffff810265db>] ? native_sched_clock+0x2b/0x90
      [  912.799493]  [<ffffffff8116135f>] ? __audit_syscall_entry+0xaf/0x100
      [  912.799497]  [<ffffffff8116135f>] ? __audit_syscall_entry+0xaf/0x100
      [  912.799501]  [<ffffffff8112aa19>] ? current_kernel_time+0x69/0xd0
      [  912.799505]  [<ffffffff81266f16>] ? __fget_light+0x66/0x90
      [  912.799508]  [<ffffffff81688812>] __sys_sendmsg+0x42/0x80
      [  912.799510]  [<ffffffff81688862>] SyS_sendmsg+0x12/0x20
      [  912.799515]  [<ffffffff817f9a6e>] entry_SYSCALL_64_fastpath+0x12/0x76
      [  912.799540] Code: 4d 88 49 8b 57 08 48 89 51 08 49 8b 57 10 48 89 c8 48 83 c0 08 48
                           89 51 10 48 8b 51 10 48 c7 c6 c0 51 9d a0 48 c7 c7 a6 51 9d a0 <48>
                           89 02 48 8b 51 08 48 89 42 08 48 b8 00 02 20 00 00 00 ad de
      [  912.799544] RIP  [<ffffffffa09d4d6d>] cls_bpf_change+0x23d/0x268 [cls_bpf]
      [  912.799544]  RSP <ffff88005f7379c8>
      [  912.799545] CR2: 0000000000000000
      [  912.807380] ---[ end trace a6440067cfdc7c29 ]---
      
      I've split them into 3 patches, so they can be backported easier
      when needed.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      053c26f3
    • Daniel Borkmann's avatar
      sched: cls_flow: fix panic on filter replace · 32b2f4b1
      Daniel Borkmann authored
      The following test case causes a NULL pointer dereference in cls_flow:
      
        tc filter add dev foo parent 1: handle 0x1 flow hash keys dst action ok
        tc filter replace dev foo parent 1: pref 49152 handle 0x1 \
                  flow hash keys mark action drop
      
      To be more precise, actually two different panics are fixed, the first
      occurs because tcf_exts_init() is not called on the newly allocated
      filter when we do a replace. And the second panic uncovered after that
      happens since the arguments of list_replace_rcu() are swapped, the old
      element needs to be the first argument and the new element the second.
      
      Fixes: 70da9f0b ("net: sched: cls_flow use RCU")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      32b2f4b1
    • Daniel Borkmann's avatar
      sched: cls_flower: fix panic on filter replace · ff3532f2
      Daniel Borkmann authored
      The following test case causes a NULL pointer dereference in cls_flower:
      
        tc filter add dev foo parent 1: flower eth_type ipv4 action ok flowid 1:1
        tc filter replace dev foo parent 1: pref 49152 handle 0x1 \
                  flower eth_type ipv6 action ok flowid 1:1
      
      The problem is that commit 77b9900e ("tc: introduce Flower classifier")
      accidentally swapped the arguments of list_replace_rcu(), the old
      element needs to be the first argument and the new element the second.
      
      Fixes: 77b9900e ("tc: introduce Flower classifier")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ff3532f2
    • Daniel Borkmann's avatar
      sched: cls_bpf: fix panic on filter replace · f6bfc46d
      Daniel Borkmann authored
      The following test case causes a NULL pointer dereference in cls_bpf:
      
        FOO="1,6 0 0 4294967295,"
        tc filter add dev foo parent 1: bpf bytecode "$FOO" flowid 1:1 action ok
        tc filter replace dev foo parent 1: pref 49152 handle 0x1 \
                  bpf bytecode "$FOO" flowid 1:1 action drop
      
      The problem is that commit 1f947bf1 ("net: sched: rcu'ify cls_bpf")
      accidentally swapped the arguments of list_replace_rcu(), the old
      element needs to be the first argument and the new element the second.
      
      Fixes: 1f947bf1 ("net: sched: rcu'ify cls_bpf")
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarJohn Fastabend <john.r.fastabend@intel.com>
      Acked-by: default avatarAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6bfc46d
    • David S. Miller's avatar
      Merge tag 'mac80211-for-davem-2015-07-17' of... · 27dfead1
      David S. Miller authored
      Merge tag 'mac80211-for-davem-2015-07-17' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
      
      Johannes Berg says:
      
      ====================
      Some fixes for the current cycle:
      
       1. Arik introduced an rtnl-locked regulatory API to be able
          to differentiate between place do/don't have the RTNL;
          this fixes missing locking in some of the code paths
      
       2. Two small mesh bugfixes from Bob, one to avoid treating
          a certain malformed over-the-air frame and one to avoid
          sending a garbage field over the air.
      
       3. A fix for powersave during WoWLAN suspend from Krishna Chaitanya.
      
       4. A fix for a powersave vs. aggregation teardown race, from Michal.
      
       5. Thomas reduced the loglevel of CRDA messages to avoid spamming
          the kernel log with mostly irrelevant information.
      
       6. Tom fixed a dangling debugfs directory pointer that could cause
          crashes if subsequent addition of the same interface to debugfs
          failed for some reason.
      
       7. A fix from myself for a list corruption issue in mac80211 during
          combined interface shutdown/removal - shut down interfaces first
          and only then remove them to avoid that.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      27dfead1
    • Shaohui Xie's avatar
      net/mdio: fix mdio_bus_match for c45 PHY · e0536cd9
      Shaohui Xie authored
      We store c45 PHY's id information in c45_ids, so it should be used to
      check the matching between PHY driver and PHY device for c45 PHY.
      Signed-off-by: default avatarShaohui Xie <Shaohui.Xie@freescale.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e0536cd9
    • Konstantin Khlebnikov's avatar
      net: ratelimit warnings about dst entry refcount underflow or overflow · 8bf4ada2
      Konstantin Khlebnikov authored
      Kernel generates a lot of warnings when dst entry reference counter
      overflows and becomes negative. That bug was seen several times at
      machines with outdated 3.10.y kernels. Most like it's already fixed
      in upstream. Anyway that flood completely kills machine and makes
      further debugging impossible.
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8bf4ada2
    • Eric Dumazet's avatar
      caif: fix leaks and race in caif_queue_rcv_skb() · b8a23e8d
      Eric Dumazet authored
      1) If sk_filter() is applied, skb was leaked (not freed)
      2) Testing SOCK_DEAD twice is racy :
         packet could be freed while already queued.
      3) Remove obsolete comment about caching skb->len
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b8a23e8d
    • Reinhard Speyerer's avatar
      qmi_wwan: add the second QMI/network interface for Sierra Wireless MC7305/MC7355 · e3426ca7
      Reinhard Speyerer authored
      Sierra Wireless MC7305/MC7355 with USB ID 1199:9041 also provide a
      second QMI/network interface like the MC73xx with USB ID 1199:68c0 on
      USB interface #10 when used in the appropriate USB configuration.
      Add the corresponding QMI_FIXED_INTF entry to the qmi_wwan driver.
      
      Please note that the second QMI/network interface is not working for
      early MC73xx firmware versions like 01.08.x as the device does not
      respond to QMI messages on the second /dev/cdc-wdm port.
      Signed-off-by: default avatarReinhard Speyerer <rspmn@arcor.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3426ca7
    • Sergei Shtylyov's avatar
      ravb: fix race updating TCCR · 06613e38
      Sergei Shtylyov authored
      The TCCR.TSRQn bit may get clearead after TCCR gets read, so that TCCR write
      would get skipped. We don't need to check this bit before setting.
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06613e38
    • Karicheri, Muralidharan's avatar
      net: netcp: fix improper initialization in netcp_ndo_open() · 194ac06e
      Karicheri, Muralidharan authored
      The keystone qmss will raise interrupt when packet arrive at the
      receive queue. Only control available to avoid interrupt from happening
      is to keep the free descriptor queue (FDQ) empty in the receive side.
      So the filling of descriptors into the FDQ has to happen after
      request_irq() call is made as part of knav_queue_enable_notify(). So
      move the function netcp_rxpool_refill() after this call.
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      194ac06e
    • dingtianhong's avatar
      bonding: correct the MAC address for "follow" fail_over_mac policy · a951bc1e
      dingtianhong authored
      The "follow" fail_over_mac policy is useful for multiport devices that
      either become confused or incur a performance penalty when multiple
      ports are programmed with the same MAC address, but the same MAC
      address still may happened by this steps for this policy:
      
      1) echo +eth0 > /sys/class/net/bond0/bonding/slaves
         bond0 has the same mac address with eth0, it is MAC1.
      
      2) echo +eth1 > /sys/class/net/bond0/bonding/slaves
         eth1 is backup, eth1 has MAC2.
      
      3) ifconfig eth0 down
         eth1 became active slave, bond will swap MAC for eth0 and eth1,
         so eth1 has MAC1, and eth0 has MAC2.
      
      4) ifconfig eth1 down
         there is no active slave, and eth1 still has MAC1, eth2 has MAC2.
      
      5) ifconfig eth0 up
         the eth0 became active slave again, the bond set eth0 to MAC1.
      
      Something wrong here, then if you set eth1 up, the eth0 and eth1 will have the same
      MAC address, it will break this policy for ACTIVE_BACKUP mode.
      
      This patch will fix this problem by finding the old active slave and
      swap them MAC address before change active slave.
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Tested-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a951bc1e
    • David S. Miller's avatar
      Merge tag 'linux-can-fixes-for-4.2-20150716' of... · 686c953e
      David S. Miller authored
      Merge tag 'linux-can-fixes-for-4.2-20150716' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
      
      Marc Kleine-Budde says:
      
      ====================
      pull-request: can 2015-07-16
      
      this is a pull request of 2 patches by Stefan Agner. He fixes the resume
      operation in the mcp251x driver.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      686c953e
  2. 20 Jul, 2015 6 commits
    • Herbert Xu's avatar
      Revert "sit: Add gro callbacks to sit_offload" · fdbf5b09
      Herbert Xu authored
      This patch reverts 19424e05 ("sit:
      Add gro callbacks to sit_offload") because it generates packets
      that cannot be handled even by our own GSO.
      Reported-by: default avatarWolfgang Walter <linux@stwm.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fdbf5b09
    • Florian Fainelli's avatar
      net: dsa: bcm_sf2: do not use indirect reads and writes for 7445E0 · b8c6cd1d
      Florian Fainelli authored
      7445E0 contains an ECO which disconnected the internal SF2 pseudo-PHY which was
      known to conflict with the external pseudo-PHY of BCM53125 switches. This
      motivated the need to utilize the internal SF2 MDIO controller via indirect
      register reads/writes to control external Broadcom switches due to this address
      conflict (both responded at address 30d).
      
      For 7445E0, the internal pseudo-PHY of the SF2 switch got disconnected, and as
      a consequence this prevents the internal SF2 MDIO bus controller from reading
      data (reads back everything as 0) since the MDI line is tied low.
      
      Fix this by making the indirect register reads and writes conditional to
      7445D0, on 7445E0 we can utilize the SWITCH_MDIO controller (backed by
      mdio-unimac and not the DSA created slave MII bus).
      
      We utilize of_machine_is_compatible() here since this is the only way for use
      to differentiate between these two chips in a way that does not violate layers
      or becomes (too) vendor-specific.
      Signed-off-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b8c6cd1d
    • Nikolay Aleksandrov's avatar
      bonding: correctly handle bonding type change on enslave failure · 7d5cd2ce
      Nikolay Aleksandrov authored
      If the bond is enslaving a device with different type it will be setup
      by it, but if after being setup the enslave fails the bond doesn't
      switch back its type and also keeps pointers to foreign structures that can
      be long gone. Thus revert back any type changes if the enslave failed and
      the bond had to change its type.
      Example:
       Before patch:
      $ echo lo > bond0/bonding/slaves
      -bash: echo: write error: Cannot assign requested address
      $ ip l sh bond0
      20: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
      mode DEFAULT group default
          link/loopback 16:54:78:34:bd:41 brd 00:00:00:00:00:00
      $ echo +eth1 > bond0/bonding/slaves
      $ ip l sh bond0
      20: bond0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode
      DEFAULT group default qlen 1000
          link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
      (notice the MASTER flag is gone)
      
       After patch:
      $ echo lo > bond0/bonding/slaves
      -bash: echo: write error: Cannot assign requested address
      $ ip l sh bond0
      21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
      mode DEFAULT group default qlen 1000
          link/ether 6e:66:94:f6:07:fc brd ff:ff:ff:ff:ff:ff
      $ echo +eth1 > bond0/bonding/slaves
      $ ip l sh bond0
      21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
      mode DEFAULT group default qlen 1000
          link/ether 52:54:00:3f:47:69 brd ff:ff:ff:ff:ff:ff
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Fixes: e36b9d16 ("bonding: clean muticast addresses when device changes type")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7d5cd2ce
    • Nikolay Aleksandrov's avatar
      bonding: fix destruction of bond with devices different from arphrd_ether · 06f6d109
      Nikolay Aleksandrov authored
      When the bonding is being unloaded and the netdevice notifier is
      unregistered it executes NETDEV_UNREGISTER for each device which should
      remove the bond's proc entry but if the device enslaved is not of
      ARPHRD_ETHER type and is in front of the bonding, it may execute
      bond_release_and_destroy() first which would release the last slave and
      destroy the bond device leaving the proc entry and thus we will get the
      following error (with dynamic debug on for bond_netdev_event to see the
      events order):
      [  908.963051] eql: event: 9
      [  908.963052] eql: IFF_SLAVE
      [  908.963054] eql: event: 2
      [  908.963056] eql: IFF_SLAVE
      [  908.963058] eql: event: 6
      [  908.963059] eql: IFF_SLAVE
      [  908.963110] bond0: Releasing active interface eql
      [  908.976168] bond0: Destroying bond bond0
      [  908.976266] bond0 (unregistering): Released all slaves
      [  908.984097] ------------[ cut here ]------------
      [  908.984107] WARNING: CPU: 0 PID: 1787 at fs/proc/generic.c:575
      remove_proc_entry+0x112/0x160()
      [  908.984110] remove_proc_entry: removing non-empty directory
      'net/bonding', leaking at least 'bond0'
      [  908.984111] Modules linked in: bonding(-) eql(O) 9p nfsd auth_rpcgss
      oid_registry nfs_acl nfs lockd grace fscache sunrpc crct10dif_pclmul
      crc32_pclmul crc32c_intel ghash_clmulni_intel ppdev qxl drm_kms_helper
      snd_hda_codec_generic aesni_intel ttm aes_x86_64 glue_helper pcspkr lrw
      gf128mul ablk_helper cryptd snd_hda_intel virtio_console snd_hda_codec
      psmouse serio_raw snd_hwdep snd_hda_core 9pnet_virtio 9pnet evdev joydev
      drm virtio_balloon snd_pcm snd_timer snd soundcore i2c_piix4 i2c_core
      pvpanic acpi_cpufreq parport_pc parport processor thermal_sys button
      autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid hid sg sr_mod cdrom
      ata_generic virtio_blk virtio_net floppy ata_piix e1000 libata ehci_pci
      virtio_pci scsi_mod uhci_hcd ehci_hcd virtio_ring virtio usbcore
      usb_common [last unloaded: bonding]
      
      [  908.984168] CPU: 0 PID: 1787 Comm: rmmod Tainted: G        W  O
      4.2.0-rc2+ #8
      [  908.984170] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [  908.984172]  0000000000000000 ffffffff81732d41 ffffffff81525b34
      ffff8800358dfda8
      [  908.984175]  ffffffff8106c521 ffff88003595af78 ffff88003595af40
      ffff88003e3a4280
      [  908.984178]  ffffffffa058d040 0000000000000000 ffffffff8106c59a
      ffffffff8172ebd0
      [  908.984181] Call Trace:
      [  908.984188]  [<ffffffff81525b34>] ? dump_stack+0x40/0x50
      [  908.984193]  [<ffffffff8106c521>] ? warn_slowpath_common+0x81/0xb0
      [  908.984196]  [<ffffffff8106c59a>] ? warn_slowpath_fmt+0x4a/0x50
      [  908.984199]  [<ffffffff81218352>] ? remove_proc_entry+0x112/0x160
      [  908.984205]  [<ffffffffa05850e6>] ? bond_destroy_proc_dir+0x26/0x30
      [bonding]
      [  908.984208]  [<ffffffffa057540e>] ? bond_net_exit+0x8e/0xa0 [bonding]
      [  908.984217]  [<ffffffff8142f407>] ? ops_exit_list.isra.4+0x37/0x70
      [  908.984225]  [<ffffffff8142f52d>] ?
      unregister_pernet_operations+0x8d/0xd0
      [  908.984228]  [<ffffffff8142f58d>] ?
      unregister_pernet_subsys+0x1d/0x30
      [  908.984232]  [<ffffffffa0585269>] ? bonding_exit+0x23/0xdba [bonding]
      [  908.984236]  [<ffffffff810e28ba>] ? SyS_delete_module+0x18a/0x250
      [  908.984241]  [<ffffffff81086f99>] ? task_work_run+0x89/0xc0
      [  908.984244]  [<ffffffff8152b732>] ?
      entry_SYSCALL_64_fastpath+0x16/0x75
      [  908.984247] ---[ end trace 7c006ed4abbef24b ]---
      
      Thus remove the proc entry manually if bond_release_and_destroy() is
      used. Because of the checks in bond_remove_proc_entry() it's not a
      problem for a bond device to change namespaces (the bug fixed by the
      Fixes commit) but since commit
      f9399814 ("bonding: Don't allow bond devices to change network
      namespaces.") that can't happen anyway.
      Reported-by: default avatarCarol Soto <clsoto@linux.vnet.ibm.com>
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Fixes: a64d49c3 ("bonding: Manage /proc/net/bonding/ entries from
                            the netdev events")
      Tested-by: default avatarCarol L Soto <clsoto@linux.vnet.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06f6d109
    • Vivien Didelot's avatar
      net: dsa: mv88e6xxx: fix fid_mask when leaving bridge · 40a71660
      Vivien Didelot authored
      The mv88e6xxx_priv_state structure contains an fid_mask, where 1 means
      the FID is free to use, 0 means the FID is in use.
      
      This patch fixes the bit clear in mv88e6xxx_leave_bridge() when
      assigning a new FID to a port.
      
      Example scenario: I have 7 ports, port 5 is CPU, port 6 is unused (no
      PHY). After setting the ports 0, 1 and 2 in bridge br0, and ports 3 and
      4 in bridge br1, I have the following fid_mask: 0b111110010110 (0xf96).
      
      Indeed, br0 uses FID 0, and br1 uses FID 3.
      
      After setting nomaster for port 0, I get the wrong fid_mask: 0b10 (0x2).
      
      With this patch we correctly get 0b111110010100 (0xf94), meaning port 0
      uses FID 1, br0 uses FID 0, and br1 uses FID 3.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@savoirfairelinux.com>
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      40a71660
    • Michael S. Tsirkin's avatar
      virtio_net: don't require ANY_LAYOUT with VERSION_1 · 75993300
      Michael S. Tsirkin authored
      ANY_LAYOUT is a compatibility feature. It's implied
      for VERSION_1 devices, and non-transitional devices
      might not offer it. Change code to behave accordingly.
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      75993300
  3. 17 Jul, 2015 9 commits
    • Arik Nemtsov's avatar
      cfg80211: use RTNL locked reg_can_beacon for IR-relaxation · 923b352f
      Arik Nemtsov authored
      The RTNL is required to check for IR-relaxation conditions that allow
      more channels to beacon. Export an RTNL locked version of reg_can_beacon
      and use it where possible in AP/STA interface type flows, where
      IR-relaxation may be applicable.
      
      Fixes: 06f207fc ("cfg80211: change GO_CONCURRENT to IR_CONCURRENT for STA")
      Signed-off-by: default avatarArik Nemtsov <arikx.nemtsov@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      923b352f
    • Bob Copeland's avatar
      mac80211: add missing length check for confirm frames · b3e7de87
      Bob Copeland authored
      Although mesh_rx_plink_frame() already checks that frames have enough
      bytes for the action code plus another two bytes for capability/reason
      code, it doesn't take into account that confirm frames also have an
      additional two-byte aid.  As a result, a corrupt frame could cause a
      subsequent subtraction to wrap around to ill effect.  Add another
      check for this case.
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b3e7de87
    • Bob Copeland's avatar
      mac80211: correct aid location in peering frames · 2ea752cd
      Bob Copeland authored
      According to 802.11-2012 8.5.16.3.2 AID comes directly after the
      capability bytes in mesh peering confirm frames.  The existing
      code, however, was adding a 2 byte offset to this location,
      resulting in garbage data going out over the air.  Remove the
      offset to fix it.
      Signed-off-by: default avatarBob Copeland <me@bobcopeland.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      2ea752cd
    • Thomas Petazzoni's avatar
      wireless: regulatory: reduce log level of CRDA related messages · 042ab5fc
      Thomas Petazzoni authored
      With a basic Linux userspace, the messages "Calling CRDA to update
      world regulatory domain" appears 10 times after boot every second or
      so, followed by a final "Exceeded CRDA call max attempts. Not calling
      CRDA". For those of us not having the corresponding userspace parts,
      having those messages repeatedly displayed at boot time is a bit
      annoying, so this commit reduces their log level to pr_debug().
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      042ab5fc
    • Johannes Berg's avatar
      mac80211: shut down interfaces before destroying interface list · d8d9008c
      Johannes Berg authored
      If the hardware is unregistered while interfaces are up, mac80211 will
      unregister all interfaces, which in turns causes mac80211 to be called
      again to remove them all from the driver and eventually shut down the
      hardware.
      
      During this shutdown, however, it's currently already unsafe to iterate
      the list of interfaces atomically, as the list is manipulated in an
      unsafe manner. This puts an undue burden on the driver - it must stop
      all its activities before calling ieee80211_unregister_hw(), while in
      the normal stop path it can do all cleanup in the stop method. If, for
      example, it's using the iteration during RX for some reason, it would
      have to stop RX before unregistering to avoid crashes.
      
      Fix this problem by closing all interfaces before unregistering them.
      This will cause the driver stop to have completed before we manipulate
      the interface list, and after the driver is stopped *and* has called
      ieee80211_unregister_hw() it really musn't be iterating any more as
      the memory will be freed as well.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      d8d9008c
    • Chaitanya T K's avatar
      mac80211: wowlan: enable powersave if suspend while ps-polling · 541b6ed7
      Chaitanya T K authored
      If for any reason we're in the middle of PS-polling or awake after
      TX due to dynamic powersave while going to suspend, go back to save
      power. This might cause a response frame to get lost, but since we
      can't really wait for it while going to suspend that's still better
      than not enabling powersave which would cause higher power usage
      during (and possibly even after) suspend.
      
      Note that this really only affects the very few drivers that use
      the powersave implementation in mac80211.
      Signed-off-by: default avatarChaitanya T K <chaitanya.mgit@gmail.com>
      [rewrite misleading commit log]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      541b6ed7
    • Michal Kazior's avatar
      mac80211: don't clear all tx flags when requeing · e9de0190
      Michal Kazior authored
      When acting as AP and a PS-Poll frame is received
      associated station is marked as one in a Service
      Period. This state is kept until Tx status for
      released frame is reported. While a station is in
      Service Period PS-Poll frames are ignored.
      
      However if PS-Poll was received during A-MPDU
      teardown it was possible to have the to-be
      released frame re-queued back to pending queue.
      In such case the frame was stripped of 2 important
      flags:
      
       (a) IEEE80211_TX_CTL_NO_PS_BUFFER
       (b) IEEE80211_TX_STATUS_EOSP
      
      Stripping of (a) led to the frame that was to be
      released to be queued back to ps_tx_buf queue. If
      station remained to use only PS-Poll frames the
      re-queued frame (and new ones) was never actually
      transmitted because mac80211 would ignore
      subsequent PS-Poll frames due to station being in
      Service Period. There was nothing left to clear
      the Service Period bit (no xmit -> no tx status ->
      no SP end), i.e. the AP would have the station
      stuck in Service Period. Beacon TIM would
      repeatedly prompt station to poll for frames but
      it would get none.
      
      Once (a) is not stripped (b) becomes important
      because it's the main condition to clear the
      Service Period bit of the station when Tx status
      for the released frame is reported back.
      
      This problem was observed with ath9k acting as P2P
      GO in some testing scenarios but isn't limited to
      it. AP operation with mac80211 based Tx A-MPDU
      control combined with clients using PS-Poll frames
      is subject to this race.
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      e9de0190
    • Tom Hughes's avatar
      mac80211: clear subdir_stations when removing debugfs · 4479004e
      Tom Hughes authored
      If we don't do this, and we then fail to recreate the debugfs
      directory during a mode change, then we will fail later trying
      to add stations to this now bogus directory:
      
      BUG: unable to handle kernel NULL pointer dereference at 0000006c
      IP: [<c0a92202>] mutex_lock+0x12/0x30
      Call Trace:
      [<c0678ab4>] start_creating+0x44/0xc0
      [<c0679203>] debugfs_create_dir+0x13/0xf0
      [<f8a938ae>] ieee80211_sta_debugfs_add+0x6e/0x490 [mac80211]
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarTom Hughes <tom@compton.nu>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      4479004e
    • Sergei Shtylyov's avatar
      ravb: do not invalidate cache for RX buffer twice · e2370f07
      Sergei Shtylyov authored
      First, dma_sync_single_for_cpu() shouldn't have been called in the first place
      (it's a streaming DMA API), dma_unmap_single() should have been called instead.
      Second, dma_unmap_single() call after handing the buffer to napi_gro_receive()
      makes little sense.  Moreover desc->dptr might not be valid at this point.
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e2370f07
  4. 16 Jul, 2015 11 commits