1. 25 May, 2017 7 commits
    • Matthias Kaehlcke's avatar
      net: jme: Remove unused functions · 26d732ba
      Matthias Kaehlcke authored
      The functions jme_restart_tx_engine(), jme_pause_rx() and
      jme_resume_rx() are not used. Removing them fixes the following warnings
      when building with clang:
      
      drivers/net/ethernet/jme.c:694:1: error: unused function
          'jme_restart_tx_engine' [-Werror,-Wunused-function]
      
      drivers/net/ethernet/jme.c:2393:20: error: unused function
          'jme_pause_rx' [-Werror,-Wunused-function]
      
      drivers/net/ethernet/jme.c:2406:20: error: unused function
          'jme_resume_rx' [-Werror,-Wunused-function]
      Signed-off-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26d732ba
    • David S. Miller's avatar
      Merge branch 'for-upstream' of... · 52c05fc7
      David S. Miller authored
      Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
      
      Johan Hedberg says:
      
      ====================
      pull request: bluetooth-next 2017-05-23
      
      Here's the first Bluetooth & 802.15.4 pull request targeting the 4.13
      kernel release.
      
       - Bluetooth 5.0 improvements (Data Length Extensions and alternate PHY)
       - Support for new Intel Bluetooth adapter [[8087:0aaa]
       - Various fixes to ieee802154 code
       - Various fixes to HCI UART code
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      52c05fc7
    • Uwe Kleine-König's avatar
      net: phy: put genphy_config_init's EXPORT_SYMBOL directly after the function · a0a32d3a
      Uwe Kleine-König authored
      Commit af6b6967 ("net: phy: export genphy_config_init()") introduced
      this EXPORT_SYMBOL and put it after gen10g_soft_reset() instead of
      directly after genphy_config_init. Probably this happend when the patch
      was applied because http://patchwork.ozlabs.org/patch/339622/ looks ok.
      Signed-off-by: default avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0a32d3a
    • Eric Dumazet's avatar
      tcp: better validation of received ack sequences · d0e1a1b5
      Eric Dumazet authored
      Paul Fiterau Brostean reported :
      
      <quote>
      Linux TCP stack we analyze exhibits behavior that seems odd to me.
      The scenario is as follows (all packets have empty payloads, no window
      scaling, rcv/snd window size should not be a factor):
      
             TEST HARNESS (CLIENT)                        LINUX SERVER
      
         1.  -                                          LISTEN (server listen,
      then accepts)
      
         2.  - --> <SEQ=100><CTL=SYN>               --> SYN-RECEIVED
      
         3.  - <-- <SEQ=300><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED
      
         4.  - --> <SEQ=101><ACK=301><CTL=ACK>      --> ESTABLISHED
      
         5.  - <-- <SEQ=301><ACK=101><CTL=FIN,ACK>  <-- FIN WAIT-1 (server
      opts to close the data connection calling "close" on the connection
      socket)
      
         6.  - --> <SEQ=101><ACK=99999><CTL=FIN,ACK> --> CLOSING (client sends
      FIN,ACK with not yet sent acknowledgement number)
      
         7.  - <-- <SEQ=302><ACK=102><CTL=ACK>      <-- CLOSING (ACK is 102
      instead of 101, why?)
      
      ... (silence from CLIENT)
      
         8.  - <-- <SEQ=301><ACK=102><CTL=FIN,ACK>  <-- CLOSING
      (retransmission, again ACK is 102)
      
      Now, note that packet 6 while having the expected sequence number,
      acknowledges something that wasn't sent by the server. So I would
      expect
      the packet to maybe prompt an ACK response from the server, and then be
      ignored. Yet it is not ignored and actually leads to an increase of the
      acknowledgement number in the server's retransmission of the FIN,ACK
      packet. The explanation I found is that the FIN  in packet 6 was
      processed, despite the acknowledgement number being unacceptable.
      Further experiments indeed show that the server processes this FIN,
      transitioning to CLOSING, then on receiving an ACK for the FIN it had
      send in packet 5, the server (or better said connection) transitions
      from CLOSING to TIME_WAIT (as signaled by netstat).
      
      </quote>
      
      Indeed, tcp_rcv_state_process() calls tcp_ack() but
      does not exploit the @acceptable status but for TCP_SYN_RECV
      state.
      
      What we want here is to send a challenge ACK, if not in TCP_SYN_RECV
      state. TCP_FIN_WAIT1 state is not the only state we should fix.
      
      Add a FLAG_NO_CHALLENGE_ACK so that tcp_rcv_state_process()
      can choose to send a challenge ACK and discard the packet instead
      of wrongly change socket state.
      
      With help from Neal Cardwell.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarPaul Fiterau Brostean <p.fiterau-brostean@science.ru.nl>
      Cc: Neal Cardwell <ncardwell@google.com>
      Cc: Yuchung Cheng <ycheng@google.com>
      Cc: Soheil Hassas Yeganeh <soheil@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d0e1a1b5
    • WANG Cong's avatar
      net_sched: only create filter chains for new filters/actions · 367a8ce8
      WANG Cong authored
      tcf_chain_get() always creates a new filter chain if not found
      in existing ones. This is totally unnecessary when we get or
      delete filters, new chain should be only created for new filters
      (or new actions).
      
      Fixes: 5bc17018 ("net: sched: introduce multichain support for filters")
      Cc: Jamal Hadi Salim <jhs@mojatatu.com>
      Cc: Jiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      367a8ce8
    • Jiri Pirko's avatar
      net: sched: cls_api: make reclassify return all the way back to the original tp · ee538dce
      Jiri Pirko authored
      With the introduction of chain goto action, the reclassification would
      cause the re-iteration of the actual chain. It makes more sense to restart
      the whole thing and re-iterate starting from the original tp - start
      of chain 0.
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Reviewed-by: default avatarSimon Horman <simon.horman@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ee538dce
    • David S. Miller's avatar
      Merge tag 'mlx5-update-2017-05-23' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux · abc7a4ef
      David S. Miller authored
      Saeed Mahameed says:
      
      ====================
      mlx5-update-2017-05-23
      
      First patch from Leon, came to remove the redundant usage of mlx5_vzalloc,
      and directly use kvzalloc across all mlx5 drivers.
      
      2nd patch from Noa, adds new device IDs into the supported devices list.
      
      3rd and 4th patches from Ilan are adding the basic infrastructure and
      support for Mellanox's mlx5 FPGA.
      
      Last two patches from Tariq came to modify the outdated driver version
      reported in ethtool and in mlx5_ib to more reflect the current driver state
      and remove the redundant date string reported in the version.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      abc7a4ef
  2. 24 May, 2017 20 commits
  3. 23 May, 2017 13 commits
    • Gustavo A. R. Silva's avatar
      net: ieee802154: fix potential null pointer dereference · 7dab5467
      Gustavo A. R. Silva authored
      Null check at line 918: if (!spi) {, implies spi might be NULL.
      Function spi_get_drvdata() dereference pointer spi.
      Move pointer priv assignment after the null check.
      
      Addresses-Coverity-ID: 1408888
      Signed-off-by: default avatarGustavo A. R. Silva <garsilva@embeddedor.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      7dab5467
    • Lin Zhang's avatar
      net: ieee802154: fix net_device reference release too early · a611c58b
      Lin Zhang authored
      This patch fixes the kernel oops when release net_device reference in
      advance. In function raw_sendmsg(i think the dgram_sendmsg has the same
      problem), there is a race condition between dev_put and dev_queue_xmit
      when the device is gong that maybe lead to dev_queue_ximt to see
      an illegal net_device pointer.
      
      My test kernel is 3.13.0-32 and because i am not have a real 802154
      device, so i change lowpan_newlink function to this:
      
              /* find and hold real wpan device */
              real_dev = dev_get_by_index(src_net, nla_get_u32(tb[IFLA_LINK]));
              if (!real_dev)
                      return -ENODEV;
      //      if (real_dev->type != ARPHRD_IEEE802154) {
      //              dev_put(real_dev);
      //              return -EINVAL;
      //      }
              lowpan_dev_info(dev)->real_dev = real_dev;
              lowpan_dev_info(dev)->fragment_tag = 0;
              mutex_init(&lowpan_dev_info(dev)->dev_list_mtx);
      
      Also, in order to simulate preempt, i change the raw_sendmsg function
      to this:
      
              skb->dev = dev;
              skb->sk  = sk;
              skb->protocol = htons(ETH_P_IEEE802154);
              dev_put(dev);
              //simulate preempt
              schedule_timeout_uninterruptible(30 * HZ);
              err = dev_queue_xmit(skb);
              if (err > 0)
                      err = net_xmit_errno(err);
      
      and this is my userspace test code named test_send_data:
      
      int main(int argc, char **argv)
      {
              char buf[127];
              int sockfd;
              sockfd = socket(AF_IEEE802154, SOCK_RAW, 0);
              if (sockfd < 0) {
                      printf("create sockfd error: %s\n", strerror(errno));
                      return -1;
              }
              send(sockfd, buf, sizeof(buf), 0);
              return 0;
      }
      
      This is my test case:
      
      root@zhanglin-x-computer:~/develop/802154# uname -a
      Linux zhanglin-x-computer 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15
      03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
      root@zhanglin-x-computer:~/develop/802154# ip link add link eth0 name
      lowpan0 type lowpan
      root@zhanglin-x-computer:~/develop/802154#
      //keep the lowpan0 device down
      root@zhanglin-x-computer:~/develop/802154# ./test_send_data &
      //wait a while
      root@zhanglin-x-computer:~/develop/802154# ip link del link dev lowpan0
      //the device is gone
      //oops
      [381.303307] general protection fault: 0000 [#1]SMP
      [381.303407] Modules linked in: af_802154 6lowpan bnep rfcomm
      bluetooth nls_iso8859_1 snd_hda_codec_hdmi snd_hda_codec_realtek
      rts5139(C) snd_hda_intel
      snd_had_codec snd_hwdep snd_pcm snd_page_alloc snd_seq_midi
      snd_seq_midi_event snd_rawmidi snd_req intel_rapl snd_seq_device
      coretemp i915 kvm_intel
      kvm snd_timer snd crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
      cypted drm_kms_helper drm i2c_algo_bit soundcore video mac_hid
      parport_pc ppdev ip parport hid_generic
      usbhid hid ahci r8169 mii libahdi
      [381.304286] CPU:1 PID: 2524 Commm: 1 Tainted: G C 0 3.13.0-32-generic
      [381.304409] Hardware name: Haier Haier DT Computer/Haier DT Codputer,
      BIOS FIBT19H02_X64 06/09/2014
      [381.304546] tasks: ffff000096965fc0 ti: ffffB0013779c000 task.ti:
      ffffB8013779c000
      [381.304659] RIP: 0010:[<ffffffff01621fe1>] [<ffffffff81621fe1>]
      __dev_queue_ximt+0x61/0x500
      [381.304798] RSP: 0018:ffffB8013779dca0 EFLAGS: 00010202
      [381.304880] RAX: 272b031d57565351 RBX: 0000000000000000 RCX: ffff8800968f1a00
      [381.304987] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800968f1a00
      [381.305095] RBP: ffff8e013773dce0 R08: 0000000000000266 R09: 0000000000000004
      [381.305202] R10: 0000000000000004 R11: 0000000000000005 R12: ffff88013902e000
      [381.305310] R13: 000000000000007f R14: 000000000000007f R15: ffff8800968f1a00
      [381.305418] FS:  00007fc57f50f740(0000) GS: ffff88013fc80000(0000)
      knlGS: 0000000000000000
      [381.305540] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [381.305627] CR2: 00007fad0841c000 CR3: 00000001368dd000 CR4: 00000000001007e0
      [361.905734] Stack:
      [381.305768]  00000000002052d0 000000003facb30a ffff88013779dcc0
      ffff880137764000
      [381.305898]  ffff88013779de70 000000000000007f 000000000000007f
      ffff88013902e000
      [381.306026]  ffff88013779dcf0 ffffffff81622490 ffff88013779dd39
      ffffffffa03af9f1
      [381.306155] Call Trace:
      [381.306202]  [<ffffffff81622490>] dev_queue_xmit+0x10/0x20
      [381.306294]  [<ffffffffa03af9f1>] raw_sendmsg+0x1b1/0x270 [af_802154]
      [381.306396]  [<ffffffffa03af054>] ieee802154_sock_sendmsg+0x14/0x20 [af_802154]
      [381.306512]  [<ffffffff816079eb>] sock_sendmsg+0x8b/0xc0
      [381.306600]  [<ffffffff811d52a5>] ? __d_alloc+0x25/0x180
      [381.306687]  [<ffffffff811a1f56>] ? kmem_cache_alloc_trace+0x1c6/0x1f0
      [381.306791]  [<ffffffff81607b91>] SYSC_sendto+0x121/0x1c0
      [381.306878]  [<ffffffff8109ddf4>] ? vtime_account_user+x54/0x60
      [381.306975]  [<ffffffff81020d45>] ? syscall_trace_enter+0x145/0x250
      [381.307073]  [<ffffffff816086ae>] SyS_sendto+0xe/0x10
      [381.307156]  [<ffffffff8172c87f>] tracesys+0xe1/0xe6
      [381.307233] Code: c6 a1 a4 ff 41 8b 57 78 49 8b 47 20 85 d2 48 8b 80
      78 07 00 00 75 21 49 8b 57 18 48 85 d2 74 18 48 85 c0 74 13 8b 92 ac
      01 00 00 <3b> 50 10 73 08 8b 44 90 14 41 89 47 78 41 f6 84 24 d5 00 00
      00
      [381.307801] RIP [<ffffffff81621fe1>] _dev_queue_xmit+0x61/0x500
      [381.307901]  RSP <ffff88013779dca0>
      [381.347512] Kernel panic - not syncing: Fatal exception in interrupt
      [381.347747] drm_kms_helper: panic occurred, switching back to text console
      
      In my opinion, there is always exist a chance that the device is gong
      before call dev_queue_xmit.
      
      I think the latest kernel is have the same problem and that
      dev_put should be behind of the dev_queue_xmit.
      Signed-off-by: default avatarLin Zhang <xiaolou4617@gmail.com>
      Acked-by: default avatarStefan Schmidt <stefan@osg.samsung.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a611c58b
    • Lin Zhang's avatar
      net: ieee802154: remove explicit set skb->sk · 8fafda77
      Lin Zhang authored
      Explicit set skb->sk is needless, sock_alloc_send_skb is already set it.
      Signed-off-by: default avatarLin Zhang <xiaolou4617@gmail.com>
      Acked-by: default avatarStefan Schmidt <stefan@osg.samsung.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      8fafda77
    • Jürg Billeter's avatar
      Bluetooth: btintel: Add MODULE_FIRMWARE entries for iBT 3.5 controllers · d1b7abae
      Jürg Billeter authored
      The iBT 3.5 controllers (Intel 8265, Windstorm Peak) need
      intel/ibt-12-16.sfi and intel/ibt-12-16.ddc firmware files from
      linux-firmware repository.
      Signed-off-by: default avatarJürg Billeter <j@bitron.ch>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      d1b7abae
    • Alexey Dobriyan's avatar
      net: make struct request_sock_ops::obj_size unsigned · 417ccf6b
      Alexey Dobriyan authored
      This field is sizeof of corresponding kmem_cache so it can't be negative.
      
      Space will be saved after 32-bit kmem_cache_create() patch.
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      417ccf6b
    • Alexey Dobriyan's avatar
      net: make struct inet_frags::qsize unsigned · 4c0ebd6f
      Alexey Dobriyan authored
      This field is sizeof of corresponding kmem_cache so it can't be negative.
      
      Prepare for 32-bit kmem_cache_create().
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4c0ebd6f
    • Govindarajulu Varadarajan's avatar
      enic: unmask intr only when napi is complete · 9acfd1c0
      Govindarajulu Varadarajan authored
      In case of busy poll, napi_complete_done returns false and does not
      dequeue napi. In this case do not unmask the intr. We are guaranteed
      napi is called again. This reduces unnecessary iowrites.
      Signed-off-by: default avatarGovindarajulu Varadarajan <gvaradar@cisco.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9acfd1c0
    • Jiri Pirko's avatar
      net/sched: fix filter flushing · f93e1cdc
      Jiri Pirko authored
      When user instructs to remove all filters from chain, we cannot destroy
      the chain as other actions may hold a reference. Also the put in errout
      would try to destroy it again. So instead, just walk the chain and remove
      all existing filters.
      
      Fixes: 5bc17018 ("net: sched: introduce multichain support for filters")
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Acked-by: default avatarCong Wang <xiyou.wangcong@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f93e1cdc
    • Jiri Pirko's avatar
      net/sched: properly assign RCU pointer in tcf_chain_tp_insert/remove · 31efcc25
      Jiri Pirko authored
      *p_filter_chain is rcu-dereferenced on reader path. So here in writer,
      property assign the pointer.
      
      Fixes: 2190d1d0 ("net: sched: introduce helpers to work with filter chains")
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31efcc25
    • Loic Poulain's avatar
      Bluetooth: btwilink: Fix unexpected skb free · a6187ffd
      Loic Poulain authored
      The caller (hci_core) still owns the skb in case of error, releasing
      it inside the send function can lead to use-after-free errors.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarLoic Poulain <loic.poulain@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      a6187ffd
    • Guodong Xu's avatar
      Bluetooth: hci_ll: Fix download_firmware() return when __hci_cmd_sync fails · 823b8420
      Guodong Xu authored
      When __hci_cmd_sync() fails, download_firmware() should also fail, and
      the same error value should be returned as PTR_ERR(skb).
      
      Without this fix, download_firmware() will return a success when it actually
      failed in __hci_cmd_sync().
      
      Fixes: 37180552 ("bluetooth: hci_uart: add LL protocol serdev driver support")
      Signed-off-by: default avatarGuodong Xu <guodong.xu@linaro.org>
      Acked-by: default avatarRob Herring <robh@kernel.org>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      823b8420
    • David S. Miller's avatar
    • Linus Torvalds's avatar
      Merge tag 'pstore-v4.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux · fadd2ce5
      Linus Torvalds authored
      Pull pstore fix from Kees Cook:
       "Marta noticed another misbehavior in EFI pstore, which this fixes.
      
        Hopefully this is the last of the v4.12 fixes for pstore!"
      
      * tag 'pstore-v4.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
        efi-pstore: Fix write/erase id tracking
      fadd2ce5