1. 28 Jul, 2017 2 commits
    • Arnd Bergmann's avatar
      phy: bcm-ns-usb3: fix MDIO_BUS dependency · 245db3c3
      Arnd Bergmann authored
      The driver attempts to 'select MDIO_DEVICE', but the code
      is actually a loadable module when PHYLIB=m:
      
      drivers/phy/broadcom/phy-bcm-ns-usb3.o: In function `bcm_ns_usb3_mdiodev_phy_write':
      phy-bcm-ns-usb3.c:(.text.bcm_ns_usb3_mdiodev_phy_write+0x28): undefined reference to `mdiobus_write'
      drivers/phy/broadcom/phy-bcm-ns-usb3.o: In function `bcm_ns_usb3_module_exit':
      phy-bcm-ns-usb3.c:(.exit.text+0x18): undefined reference to `mdio_driver_unregister'
      drivers/phy/broadcom/phy-bcm-ns-usb3.o: In function `bcm_ns_usb3_module_init':
      phy-bcm-ns-usb3.c:(.init.text+0x18): undefined reference to `mdio_driver_register'
      phy-bcm-ns-usb3.c:(.init.text+0x38): undefined reference to `mdio_driver_unregister'
      
      Using 'depends on MDIO_BUS' instead will avoid the link error.
      
      Fixes: af850e14 ("phy: bcm-ns-usb3: add MDIO driver using proper bus layer")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      245db3c3
    • Arnd Bergmann's avatar
      net: phy: rework Kconfig settings for MDIO_BUS · 4c3464a8
      Arnd Bergmann authored
      I still see build errors in randconfig builds and have had this
      patch for a while to locally work around it:
      
      drivers/built-in.o: In function `xgene_mdio_probe':
      mux-core.c:(.text+0x352154): undefined reference to `of_mdiobus_register'
      mux-core.c:(.text+0x352168): undefined reference to `mdiobus_free'
      mux-core.c:(.text+0x3521c0): undefined reference to `mdiobus_alloc_size'
      
      The idea is that CONFIG_MDIO_BUS now reflects whether the mdio_bus
      code is built-in or a module, and other drivers that use the core
      code can simply depend on that, instead of having a complex
      dependency line.
      
      Fixes: 90eff909 ("net: phy: Allow splitting MDIO bus/device support from PHYs")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4c3464a8
  2. 27 Jul, 2017 6 commits
    • Xin Long's avatar
      sctp: fix the check for _sctp_walk_params and _sctp_walk_errors · 6b84202c
      Xin Long authored
      Commit b1f5bfc2 ("sctp: don't dereference ptr before leaving
      _sctp_walk_{params, errors}()") tried to fix the issue that it
      may overstep the chunk end for _sctp_walk_{params, errors} with
      'chunk_end > offset(length) + sizeof(length)'.
      
      But it introduced a side effect: When processing INIT, it verifies
      the chunks with 'param.v == chunk_end' after iterating all params
      by sctp_walk_params(). With the check 'chunk_end > offset(length)
      + sizeof(length)', it would return when the last param is not yet
      accessed. Because the last param usually is fwdtsn supported param
      whose size is 4 and 'chunk_end == offset(length) + sizeof(length)'
      
      This is a badly issue even causing sctp couldn't process 4-shakes.
      Client would always get abort when connecting to server, due to
      the failure of INIT chunk verification on server.
      
      The patch is to use 'chunk_end <= offset(length) + sizeof(length)'
      instead of 'chunk_end < offset(length) + sizeof(length)' for both
      _sctp_walk_params and _sctp_walk_errors.
      
      Fixes: b1f5bfc2 ("sctp: don't dereference ptr before leaving _sctp_walk_{params, errors}()")
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Acked-by: default avatarNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6b84202c
    • Xin Long's avatar
      dccp: fix a memleak for dccp_feat_init err process · e90ce2fc
      Xin Long authored
      In dccp_feat_init, when ccid_get_builtin_ccids failsto alloc
      memory for rx.val, it should free tx.val before returning an
      error.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e90ce2fc
    • Xin Long's avatar
      dccp: fix a memleak that dccp_ipv4 doesn't put reqsk properly · b7953d3c
      Xin Long authored
      The patch "dccp: fix a memleak that dccp_ipv6 doesn't put reqsk
      properly" fixed reqsk refcnt leak for dccp_ipv6. The same issue
      exists on dccp_ipv4.
      
      This patch is to fix it for dccp_ipv4.
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7953d3c
    • Xin Long's avatar
      dccp: fix a memleak that dccp_ipv6 doesn't put reqsk properly · 0c2232b0
      Xin Long authored
      In dccp_v6_conn_request, after reqsk gets alloced and hashed into
      ehash table, reqsk's refcnt is set 3. one is for req->rsk_timer,
      one is for hlist, and the other one is for current using.
      
      The problem is when dccp_v6_conn_request returns and finishes using
      reqsk, it doesn't put reqsk. This will cause reqsk refcnt leaks and
      reqsk obj never gets freed.
      
      Jianlin found this issue when running dccp_memleak.c in a loop, the
      system memory would run out.
      
      dccp_memleak.c:
        int s1 = socket(PF_INET6, 6, IPPROTO_IP);
        bind(s1, &sa1, 0x20);
        listen(s1, 0x9);
        int s2 = socket(PF_INET6, 6, IPPROTO_IP);
        connect(s2, &sa1, 0x20);
        close(s1);
        close(s2);
      
      This patch is to put the reqsk before dccp_v6_conn_request returns,
      just as what tcp_conn_request does.
      Reported-by: default avatarJianlin Shi <jishi@redhat.com>
      Signed-off-by: default avatarXin Long <lucien.xin@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c2232b0
    • Jakub Kicinski's avatar
      bpf: don't zero out the info struct in bpf_obj_get_info_by_fd() · d777b2dd
      Jakub Kicinski authored
      The buffer passed to bpf_obj_get_info_by_fd() should be initialized
      to zeros.  Kernel will enforce that to guarantee we can safely extend
      info structures in the future.
      
      Making the bpf_obj_get_info_by_fd() call in libbpf perform the zeroing
      is problematic, however, since some members of the info structures
      may need to be initialized by the callers (for instance pointers
      to buffers to which kernel is to dump translated and jited images).
      
      Remove the zeroing and fix up the in-tree callers before any kernel
      has been released with this code.
      
      As Daniel points out this seems to be the intended operation anyway,
      since commit 95b9afd3 ("bpf: Test for bpf ID") is itself setting
      the buffer pointers before calling bpf_obj_get_info_by_fd().
      Signed-off-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d777b2dd
    • Matthias Kaehlcke's avatar
      netpoll: Fix device name check in netpoll_setup() · 0c3a8f8b
      Matthias Kaehlcke authored
      Apparently netpoll_setup() assumes that netpoll.dev_name is a pointer
      when checking if the device name is set:
      
      if (np->dev_name) {
        ...
      
      However the field is a character array, therefore the condition always
      yields true. Check instead whether the first byte of the array has a
      non-zero value.
      Signed-off-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0c3a8f8b
  3. 26 Jul, 2017 6 commits
  4. 25 Jul, 2017 7 commits
  5. 24 Jul, 2017 13 commits
  6. 21 Jul, 2017 6 commits