1. 22 Feb, 2016 6 commits
    • David S. Miller's avatar
      Merge branch 'netcp-fixes' · d3e17183
      David S. Miller authored
      Murali Karicheri says:
      
      ====================
      net: ti: netcp: restore get/set_pad_info() functionality
      
      This series fixes a regression and add some improvements for the ease
      of maintainance. Incorporated comments against v1.
      
      Changelogs:
      
       v2 : combined 2-3 into one patch as this involves a header change
            fixed a parse warning in 3/4 per comment from Arnd.
            Removed Sign-off from Arnd against 1/4
            added comments in 3/3 to alert on the usage of sw data per review
            comments
       v1 : added 2-4 to accomodate feedback received from review
       v0 : initial version to fix the regression (From Grygorii)
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d3e17183
    • Karicheri, Muralidharan's avatar
      net: netcp: rework the code for get/set sw_data in dma desc · 06324481
      Karicheri, Muralidharan authored
      SW data field in descriptor can be used by software to hold private
      data for the driver. As there are 4 words available for this purpose,
      use separate macros to place it or retrieve the same to/from
      descriptors. Also do type cast of data types accordingly.
      
      Cc: Wingman Kwok <w-kwok2@ti.com>
      Cc: Mugunthan V N <mugunthanvnm@ti.com>
      CC: Arnd Bergmann <arnd@arndb.de>
      CC: Grygorii Strashko <grygorii.strashko@ti.com>
      CC: David Laight <David.Laight@ACULAB.COM>
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      06324481
    • Karicheri, Muralidharan's avatar
      soc: ti: knav_dma: rename pad in struct knav_dma_desc to sw_data · b1cb86ae
      Karicheri, Muralidharan authored
      Rename the pad to sw_data as per description of this field in the hardware
      spec(refer sprugr9 from www.ti.com). Latest version of the document is
      at http://www.ti.com/lit/ug/sprugr9h/sprugr9h.pdf and section 3.1
      Host Packet Descriptor describes this field.
      
      Define and use a constant for the size of sw_data field similar to
      other fields in the struct for desc and document the sw_data field
      in the header. As the sw_data is not touched by hw, it's type can be
      changed to u32.
      
      Rename the helpers to match with the updated dma desc field sw_data.
      
      Cc: Wingman Kwok <w-kwok2@ti.com>
      Cc: Mugunthan V N <mugunthanvnm@ti.com>
      CC: Arnd Bergmann <arnd@arndb.de>
      CC: Grygorii Strashko <grygorii.strashko@ti.com>
      CC: David Laight <David.Laight@ACULAB.COM>
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b1cb86ae
    • Karicheri, Muralidharan's avatar
      net: ti: netcp: restore get/set_pad_info() functionality · 9ecfe875
      Karicheri, Muralidharan authored
      The commit 89907779 ("netcp: try to reduce type confusion in
      descriptors") introduces a regression in Kernel 4.5-rc1 and it breaks
      get/set_pad_info() functionality.
      
      The TI NETCP driver uses pad0 and pad1 fields of knav_dma_desc to
      store DMA/MEM buffer pointer and buffer size respectively. And in both
      cases for Keystone 2 the pointer type size is 32 bit regardless of
      LAPE enabled or not, because CONFIG_ARCH_DMA_ADDR_T_64BIT originally
      is not expected to be defined.
      
      Unfortunately, above commit changed buffer's pointers save/restore
      code (get/set_pad_info()) and added intermediate conversation to u64
      which works incorrectly on 32bit Keystone 2 and causes TI NETCP driver
      crash in RX/TX path due to "Unable to handle kernel NULL pointer"
      exception. This issue was reported and discussed in [1].
      
      Hence, fix it by partially reverting above commit and restoring
      get/set_pad_info() functionality as it was before.
      
      [1] https://www.mail-archive.com/netdev@vger.kernel.org/msg95361.html
      Cc: Wingman Kwok <w-kwok2@ti.com>
      Cc: Mugunthan V N <mugunthanvnm@ti.com>
      CC: David Laight <David.Laight@ACULAB.COM>
      CC: Arnd Bergmann <arnd@arndb.de>
      Reported-by: default avatarFranklin S Cooper Jr <fcooper@ti.com>
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarMurali Karicheri <m-karicheri2@ti.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9ecfe875
    • Ian Campbell's avatar
      MAINTAINERS: Drop myself as xen netback maintainer · 3301be32
      Ian Campbell authored
      Wei has been picking this up for quite a while now.
      Signed-off-by: default avatarIan Campbell <ian.campbell@citrix.com>
      Cc: Wei Liu <wei.liu2@citrix.com>
      Acked-by: default avatarWei Liu <wei.liu2@citrix.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3301be32
    • Neil Horman's avatar
      sctp: Fix port hash table size computation · d9749fb5
      Neil Horman authored
      Dmitry Vyukov noted recently that the sctp_port_hashtable had an error in
      its size computation, observing that the current method never guaranteed
      that the hashsize (measured in number of entries) would be a power of two,
      which the input hash function for that table requires.  The root cause of
      the problem is that two values need to be computed (one, the allocation
      order of the storage requries, as passed to __get_free_pages, and two the
      number of entries for the hash table).  Both need to be ^2, but for
      different reasons, and the existing code is simply computing one order
      value, and using it as the basis for both, which is wrong (i.e. it assumes
      that ((1<<order)*PAGE_SIZE)/sizeof(bucket) is still ^2 when its not).
      
      To fix this, we change the logic slightly.  We start by computing a goal
      allocation order (which is limited by the maximum size hash table we want
      to support.  Then we attempt to allocate that size table, decreasing the
      order until a successful allocation is made.  Then, with the resultant
      successful order we compute the number of buckets that hash table supports,
      which we then round down to the nearest power of two, giving us the number
      of entries the table actually supports.
      
      I've tested this locally here, using non-debug and spinlock-debug kernels,
      and the number of entries in the hashtable consistently work out to be
      powers of two in all cases.
      Signed-off-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      CC: Dmitry Vyukov <dvyukov@google.com>
      CC: Vladislav Yasevich <vyasevich@gmail.com>
      CC: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9749fb5
  2. 20 Feb, 2016 7 commits
  3. 19 Feb, 2016 8 commits
    • Paul Bolle's avatar
      ser_gigaset: use container_of() instead of detour · 8d2c3ab4
      Paul Bolle authored
      The purpose of gigaset_device_release() is to kfree() the struct
      ser_cardstate that contains our struct device. This is done via a bit of
      a detour. First we make our struct device's driver_data point to the
      container of our struct ser_cardstate (which is a struct cardstate). In
      gigaset_device_release() we then retrieve that driver_data again. And
      after that we finally kfree() the struct ser_cardstate that was saved in
      the struct cardstate.
      
      All of this can be achieved much easier by using container_of() to get
      from our struct device to its container, struct ser_cardstate. Do so.
      
      Note that at the time the detour was implemented commit b8b2c7d8
      ("base/platform: assert that dev_pm_domain callbacks are called
      unconditionally") had just entered the tree. That commit disconnected
      our platform_device and our platform_driver. These were reconnected
      again in v4.5-rc2 through commit 25cad69f ("base/platform: Fix
      platform drivers with no probe callback"). And one of the consequences
      of that fix was that it broke the detour via driver_data. That's because
      it made __device_release_driver() stop being a NOP for our struct device
      and actually do stuff again. One of the things it now does, is setting
      our driver_data to NULL. That, in turn, makes it impossible for
      gigaset_device_release() to get to our struct cardstate. Which has the
      net effect of leaking a struct ser_cardstate at every call of this
      driver's tty close() operation. So using container_of() has the
      additional benefit of actually working.
      Reported-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Tested-by: default avatarDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Acked-by: default avatarTilman Schmidt <tilman@imap.cc>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8d2c3ab4
    • David S. Miller's avatar
      Merge tag 'wireless-drivers-for-davem-2016-02-18' of... · 0b7662cf
      David S. Miller authored
      Merge tag 'wireless-drivers-for-davem-2016-02-18' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers
      
      Kalle Valo says:
      
      ====================
      rtlwifi
      
      * fix broken VHT (802.11ac) support, reported by Linus
      
      wlcore
      
      * fix firmware initialisation regression on wl1271
      
      iwlwifi
      
      * fix a race that users reported when we try to load the firmware
        and the hardware rfkill interrupt triggers at the same time
      * fix a very visible bug in scheduled scan: the firmware
        doesn't support scheduled scan with no profile configured and
        the supplicant sometimes requests such scheduled scans
      * build system fix to be able to link iwlwifi statically into kernel
      * firmware name update for 8265
      * typo fix in return value
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0b7662cf
    • Steve Wise's avatar
      cxgb3: fix up vpd strings for kstrto*() · 1003e19c
      Steve Wise authored
      The vpd strings are left justified, in a fixed length array, with possible
      trailing white space and no NUL.  So fix them up before calling kstrto*().
      
      This is a recent regression which causes cxgb3 to fail to load.
      
      Fixes: e72c932d ("cxgb3: Convert simple_strtoul to kstrtox")
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1003e19c
    • Paolo Abeni's avatar
      lwt: fix rx checksum setting for lwt devices tunneling over ipv6 · c868ee70
      Paolo Abeni authored
      the commit 35e2d115 ("tunnels: Allow IPv6 UDP checksums to be
      correctly controlled.") changed the default xmit checksum setting
      for lwt vxlan/geneve ipv6 tunnels, so that now the checksum is not
      set into external UDP header.
      This commit changes the rx checksum setting for both lwt vxlan/geneve
      devices created by openvswitch accordingly, so that lwt over ipv6
      tunnel pairs are again able to communicate with default values.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Acked-by: default avatarJiri Benc <jbenc@redhat.com>
      Acked-by: default avatarJesse Gross <jesse@kernel.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c868ee70
    • Insu Yun's avatar
      tipc: unlock in error path · b53ce3e7
      Insu Yun authored
      tipc_bcast_unlock need to be unlocked in error path.
      Signed-off-by: default avatarInsu Yun <wuninsu@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b53ce3e7
    • David S. Miller's avatar
      Merge tag 'batman-adv-fix-for-davem' of git://git.open-mesh.org/linux-merge · 29d1441d
      David S. Miller authored
      Antonio Quartulli says:
      
      ====================
      Two of the fixes included in this patchset prevent wrong memory
      access - it was triggered when removing an object from a list
      after it was already free'd due to bad reference counting.
      This misbehaviour existed for both the gw_node and the
      orig_node_vlan object and has been fixed by Sven Eckelmann.
      
      The last patch fixes our interface feasibility check and prevents
      it from looping indefinitely when two net_device objects
      reference each other via iflink index (i.e. veth pair), by
      Andrew Lunn
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29d1441d
    • Anton Protopopov's avatar
      rtnl: RTM_GETNETCONF: fix wrong return value · a97eb33f
      Anton Protopopov authored
      An error response from a RTM_GETNETCONF request can return the positive
      error value EINVAL in the struct nlmsgerr that can mislead userspace.
      Signed-off-by: default avatarAnton Protopopov <a.s.protopopov@gmail.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a97eb33f
    • Nikolay Aleksandrov's avatar
      net: make netdev_for_each_lower_dev safe for device removal · cfdd28be
      Nikolay Aleksandrov authored
      When I used netdev_for_each_lower_dev in commit bad53162 ("vrf:
      remove slave queue and private slave struct") I thought that it acts
      like netdev_for_each_lower_private and can be used to remove the current
      device from the list while walking, but unfortunately it acts more like
      netdev_for_each_lower_private_rcu and doesn't allow it. The difference
      is where the "iter" points to, right now it points to the current element
      and that makes it impossible to remove it. Change the logic to be
      similar to netdev_for_each_lower_private and make it point to the "next"
      element so we can safely delete the current one. VRF is the only such
      user right now, there's no change for the read-only users.
      
      Here's what can happen now:
      [98423.249858] general protection fault: 0000 [#1] SMP
      [98423.250175] Modules linked in: vrf bridge(O) stp llc nfsd auth_rpcgss
      oid_registry nfs_acl nfs lockd grace sunrpc crct10dif_pclmul
      crc32_pclmul crc32c_intel ghash_clmulni_intel jitterentropy_rng
      sha256_generic hmac drbg ppdev aesni_intel aes_x86_64 glue_helper lrw
      gf128mul ablk_helper cryptd evdev serio_raw pcspkr virtio_balloon
      parport_pc parport i2c_piix4 i2c_core virtio_console acpi_cpufreq button
      9pnet_virtio 9p 9pnet fscache ipv6 autofs4 ext4 crc16 mbcache jbd2 sg
      virtio_blk virtio_net sr_mod cdrom e1000 ata_generic ehci_pci uhci_hcd
      ehci_hcd usbcore usb_common virtio_pci ata_piix libata floppy
      virtio_ring virtio scsi_mod [last unloaded: bridge]
      [98423.255040] CPU: 1 PID: 14173 Comm: ip Tainted: G           O
      4.5.0-rc2+ #81
      [98423.255386] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
      BIOS 1.8.1-20150318_183358- 04/01/2014
      [98423.255777] task: ffff8800547f5540 ti: ffff88003428c000 task.ti:
      ffff88003428c000
      [98423.256123] RIP: 0010:[<ffffffff81514f3e>]  [<ffffffff81514f3e>]
      netdev_lower_get_next+0x1e/0x30
      [98423.256534] RSP: 0018:ffff88003428f940  EFLAGS: 00010207
      [98423.256766] RAX: 0002000100000004 RBX: ffff880054ff9000 RCX:
      0000000000000000
      [98423.257039] RDX: ffff88003428f8b8 RSI: ffff88003428f950 RDI:
      ffff880054ff90c0
      [98423.257287] RBP: ffff88003428f940 R08: 0000000000000000 R09:
      0000000000000000
      [98423.257537] R10: 0000000000000001 R11: 0000000000000000 R12:
      ffff88003428f9e0
      [98423.257802] R13: ffff880054a5fd00 R14: ffff88003428f970 R15:
      0000000000000001
      [98423.258055] FS:  00007f3d76881700(0000) GS:ffff88005d000000(0000)
      knlGS:0000000000000000
      [98423.258418] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [98423.258650] CR2: 00007ffe5951ffa8 CR3: 0000000052077000 CR4:
      00000000000406e0
      [98423.258902] Stack:
      [98423.259075]  ffff88003428f960 ffffffffa0442636 0002000100000004
      ffff880054ff9000
      [98423.259647]  ffff88003428f9b0 ffffffff81518205 ffff880054ff9000
      ffff88003428f978
      [98423.260208]  ffff88003428f978 ffff88003428f9e0 ffff88003428f9e0
      ffff880035b35f00
      [98423.260739] Call Trace:
      [98423.260920]  [<ffffffffa0442636>] vrf_dev_uninit+0x76/0xa0 [vrf]
      [98423.261156]  [<ffffffff81518205>]
      rollback_registered_many+0x205/0x390
      [98423.261401]  [<ffffffff815183ec>] unregister_netdevice_many+0x1c/0x70
      [98423.261641]  [<ffffffff8153223c>] rtnl_delete_link+0x3c/0x50
      [98423.271557]  [<ffffffff815335bb>] rtnl_dellink+0xcb/0x1d0
      [98423.271800]  [<ffffffff811cd7da>] ? __inc_zone_state+0x4a/0x90
      [98423.272049]  [<ffffffff815337b4>] rtnetlink_rcv_msg+0x84/0x200
      [98423.272279]  [<ffffffff810cfe7d>] ? trace_hardirqs_on+0xd/0x10
      [98423.272513]  [<ffffffff8153370b>] ? rtnetlink_rcv+0x1b/0x40
      [98423.272755]  [<ffffffff81533730>] ? rtnetlink_rcv+0x40/0x40
      [98423.272983]  [<ffffffff8155d6e7>] netlink_rcv_skb+0x97/0xb0
      [98423.273209]  [<ffffffff8153371a>] rtnetlink_rcv+0x2a/0x40
      [98423.273476]  [<ffffffff8155ce8b>] netlink_unicast+0x11b/0x1a0
      [98423.273710]  [<ffffffff8155d2f1>] netlink_sendmsg+0x3e1/0x610
      [98423.273947]  [<ffffffff814fbc98>] sock_sendmsg+0x38/0x70
      [98423.274175]  [<ffffffff814fc253>] ___sys_sendmsg+0x2e3/0x2f0
      [98423.274416]  [<ffffffff810d841e>] ? do_raw_spin_unlock+0xbe/0x140
      [98423.274658]  [<ffffffff811e1bec>] ? handle_mm_fault+0x26c/0x2210
      [98423.274894]  [<ffffffff811e19cd>] ? handle_mm_fault+0x4d/0x2210
      [98423.275130]  [<ffffffff81269611>] ? __fget_light+0x91/0xb0
      [98423.275365]  [<ffffffff814fcd42>] __sys_sendmsg+0x42/0x80
      [98423.275595]  [<ffffffff814fcd92>] SyS_sendmsg+0x12/0x20
      [98423.275827]  [<ffffffff81611bb6>] entry_SYSCALL_64_fastpath+0x16/0x7a
      [98423.276073] Code: c3 31 c0 5d c3 0f 1f 84 00 00 00 00 00 66 66 66 66
      90 48 8b 06 55 48 81 c7 c0 00 00 00 48 89 e5 48 8b 00 48 39 f8 74 09 48
      89 06 <48> 8b 40 e8 5d c3 31 c0 5d c3 0f 1f 84 00 00 00 00 00 66 66 66
      [98423.279639] RIP  [<ffffffff81514f3e>] netdev_lower_get_next+0x1e/0x30
      [98423.279920]  RSP <ffff88003428f940>
      
      CC: David Ahern <dsa@cumulusnetworks.com>
      CC: David S. Miller <davem@davemloft.net>
      CC: Roopa Prabhu <roopa@cumulusnetworks.com>
      CC: Vlad Yasevich <vyasevic@redhat.com>
      Fixes: bad53162 ("vrf: remove slave queue and private slave struct")
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Reviewed-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Tested-by: default avatarDavid Ahern <dsa@cumulusnetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cfdd28be
  4. 18 Feb, 2016 19 commits