1. 08 May, 2018 5 commits
  2. 07 May, 2018 1 commit
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next · 90278871
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter/IPVS updates for net-next
      
      The following patchset contains Netfilter/IPVS updates for your net-next
      tree, more relevant updates in this batch are:
      
      1) Add Maglev support to IPVS. Moreover, store lastest server weight in
         IPVS since this is needed by maglev, patches from from Inju Song.
      
      2) Preparation works to add iptables flowtable support, patches
         from Felix Fietkau.
      
      3) Hand over flows back to conntrack slow path in case of TCP RST/FIN
         packet is seen via new teardown state, also from Felix.
      
      4) Add support for extended netlink error reporting for nf_tables.
      
      5) Support for larger timeouts that 23 days in nf_tables, patch from
         Florian Westphal.
      
      6) Always set an upper limit to dynamic sets, also from Florian.
      
      7) Allow number generator to make map lookups, from Laura Garcia.
      
      8) Use hash_32() instead of opencode hashing in IPVS, from Vicent Bernat.
      
      9) Extend ip6tables SRH match to support previous, next and last SID,
         from Ahmed Abdelsalam.
      
      10) Move Passive OS fingerprint nf_osf.c, from Fernando Fernandez.
      
      11) Expose nf_conntrack_max through ctnetlink, from Florent Fourcot.
      
      12) Several housekeeping patches for xt_NFLOG, x_tables and ebtables,
         from Taehee Yoo.
      
      13) Unify meta bridge with core nft_meta, then make nft_meta built-in.
         Make rt and exthdr built-in too, again from Florian.
      
      14) Missing initialization of tbl->entries in IPVS, from Cong Wang.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      90278871
  3. 06 May, 2018 8 commits
  4. 04 May, 2018 14 commits
  5. 03 May, 2018 12 commits
    • Eric Dumazet's avatar
      dccp: fix tasklet usage · a8d7aa17
      Eric Dumazet authored
      syzbot reported a crash in tasklet_action_common() caused by dccp.
      
      dccp needs to make sure socket wont disappear before tasklet handler
      has completed.
      
      This patch takes a reference on the socket when arming the tasklet,
      and moves the sock_put() from dccp_write_xmit_timer() to dccp_write_xmitlet()
      
      kernel BUG at kernel/softirq.c:514!
      invalid opcode: 0000 [#1] SMP KASAN
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Modules linked in:
      CPU: 1 PID: 17 Comm: ksoftirqd/1 Not tainted 4.17.0-rc3+ #30
      Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
      RIP: 0010:tasklet_action_common.isra.19+0x6db/0x700 kernel/softirq.c:515
      RSP: 0018:ffff8801d9b3faf8 EFLAGS: 00010246
      dccp_close: ABORT with 65423 bytes unread
      RAX: 1ffff1003b367f6b RBX: ffff8801daf1f3f0 RCX: 0000000000000000
      RDX: ffff8801cf895498 RSI: 0000000000000004 RDI: 0000000000000000
      RBP: ffff8801d9b3fc40 R08: ffffed0039f12a95 R09: ffffed0039f12a94
      dccp_close: ABORT with 65423 bytes unread
      R10: ffffed0039f12a94 R11: ffff8801cf8954a3 R12: 0000000000000000
      R13: ffff8801d9b3fc18 R14: dffffc0000000000 R15: ffff8801cf895490
      FS:  0000000000000000(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 0000001b2bc28000 CR3: 00000001a08a9000 CR4: 00000000001406e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      Call Trace:
       tasklet_action+0x1d/0x20 kernel/softirq.c:533
       __do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
      dccp_close: ABORT with 65423 bytes unread
       run_ksoftirqd+0x86/0x100 kernel/softirq.c:646
       smpboot_thread_fn+0x417/0x870 kernel/smpboot.c:164
       kthread+0x345/0x410 kernel/kthread.c:238
       ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
      Code: 48 8b 85 e8 fe ff ff 48 8b 95 f0 fe ff ff e9 94 fb ff ff 48 89 95 f0 fe ff ff e8 81 53 6e 00 48 8b 95 f0 fe ff ff e9 62 fb ff ff <0f> 0b 48 89 cf 48 89 8d e8 fe ff ff e8 64 53 6e 00 48 8b 8d e8
      RIP: tasklet_action_common.isra.19+0x6db/0x700 kernel/softirq.c:515 RSP: ffff8801d9b3faf8
      
      Fixes: dc841e30 ("dccp: Extend CCID packet dequeueing interface")
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
      Cc: dccp@vger.kernel.org
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8d7aa17
    • David S. Miller's avatar
      Merge branch 'smc-fixes' · 31140b47
      David S. Miller authored
      Ursula Braun says:
      
      ====================
      net/smc: fixes 2018/05/03
      
      here are smc fixes for 2 problems:
       * receive buffers in SMC must be registered. If registration fails
         these buffers must not be kept within the link group for reuse.
         Patch 1 is a preparational patch; patch 2 contains the fix.
       * sendpage: do not hold the sock lock when calling kernel_sendpage()
                   or sock_no_sendpage()
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      31140b47
    • Stefan Raspl's avatar
      smc: fix sendpage() call · bda27ff5
      Stefan Raspl authored
      The sendpage() call grabs the sock lock before calling the default
      implementation - which tries to grab it once again.
      Signed-off-by: default avatarStefan Raspl <raspl@linux.ibm.com>
      Signed-off-by: Ursula Braun <ubraun@linux.ibm.com><
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bda27ff5
    • Karsten Graul's avatar
      net/smc: handle unregistered buffers · a6920d1d
      Karsten Graul authored
      When smc_wr_reg_send() fails then tag (regerr) the affected buffer and
      free it in smc_buf_unuse().
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a6920d1d
    • Karsten Graul's avatar
      net/smc: call consolidation · e63a5f8c
      Karsten Graul authored
      Consolidate the call to smc_wr_reg_send() in a new function.
      No functional changes.
      Signed-off-by: default avatarKarsten Graul <kgraul@linux.ibm.com>
      Signed-off-by: default avatarUrsula Braun <ubraun@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e63a5f8c
    • Colin Ian King's avatar
      qed: fix spelling mistake: "offloded" -> "offloaded" · df80b8fb
      Colin Ian King authored
      Trivial fix to spelling mistake in DP_NOTICE message
      Signed-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      df80b8fb
    • David S. Miller's avatar
      Merge branch 'bridge-FDB-Notify-about-removal-of-non-user-added-entries' · 62264f99
      David S. Miller authored
      Petr Machata says:
      
      ====================
      bridge: FDB: Notify about removal of non-user-added entries
      
      Device drivers may generally need to keep in sync with bridge's FDB. In
      particular, for its offload of tc mirror action where the mirrored-to
      device is a gretap device, mlxsw needs to listen to a number of events,
      FDB events among the others. SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE would be
      a natural notification in that case.
      
      However, for removal of FDB entries added due to device activity (as
      opposed to explicit addition through "bridge fdb add" or similar), there
      are no notifications.
      
      Thus in patch #1, add the "added_by_user" field to switchdev
      notifications sent for FDB activity. Adapt drivers to ignore activity on
      non-user-added entries, to maintain the current behavior. Specifically
      in case of mlxsw, allow mlxsw_sp_span_respin() call for any and all FDB
      updates.
      
      In patch #2, change the bridge driver to actually emit notifications for
      these FDB entries. Take care not to send notification for bridge
      updates that itself originate in SWITCHDEV_FDB_*_TO_BRIDGE events.
      
      Changes from v1 to v2:
      - Instead of introducing a new variant of fdb_delete(), add a new
        parameter to the existing function.
      - Name the parameter swdev_notify, not notify.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      62264f99
    • Petr Machata's avatar
      net: bridge: Notify about !added_by_user FDB entries · 161d82de
      Petr Machata authored
      Do not automatically bail out on sending notifications about activity on
      non-user-added FDB entries. Instead, notify about this activity except
      for cases where the activity itself originates in a notification, to
      avoid sending duplicate notifications.
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Acked-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Acked-by: default avatarIvan Vecera <ivecera@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      161d82de
    • Petr Machata's avatar
      switchdev: Add fdb.added_by_user to switchdev notifications · 816a3bed
      Petr Machata authored
      The following patch enables sending notifications also for events on FDB
      entries that weren't added by the user. Give the drivers the information
      necessary to distinguish between the two origins of FDB entries.
      
      To maintain the current behavior, have switchdev-implementing drivers
      bail out on notifications about non-user-added FDB entries. In case of
      mlxsw driver, allow a call to mlxsw_sp_span_respin() so that SPAN over
      bridge catches up with the changed FDB.
      Signed-off-by: default avatarPetr Machata <petrm@mellanox.com>
      Reviewed-by: default avatarNikolay Aleksandrov <nikolay@cumulusnetworks.com>
      Acked-by: default avatarIvan Vecera <ivecera@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      816a3bed
    • David S. Miller's avatar
      Merge branch 'mlxsw-Introduce-support-for-CQEv1-2' · 0e913f28
      David S. Miller authored
      Ido Schimmel says:
      
      ====================
      mlxsw: Introduce support for CQEv1/2
      
      Jiri says:
      
      Current SwitchX2 and Spectrum FWs support CQEv0 and that is what we
      implement in mlxsw. Spectrum FW also supports CQE v1 and v2.
      However, Spectrum-2 won't support CQEv0. Prepare for it and setup the
      CQE versions to use according to what is queried from FW.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0e913f28
    • Jiri Pirko's avatar
      mlxsw: pci: Check number of CQEs for CQE version 2 · 41107685
      Jiri Pirko authored
      Check number of CQEs for CQE version 2 reported by QUERY_AQ_CAP command.
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      41107685
    • Jiri Pirko's avatar
      mlxsw: pci: Allow to use CQEs of version 1 and version 2 · 8404f6f2
      Jiri Pirko authored
      Use previously added resources to query FW support for multiple versions
      of CQEs. Use the biggest version supported. For SDQs, it has no sense to
      use version 2 as it does not introduce any new features, but it is
      twice the size of CQE version 1.
      Signed-off-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarIdo Schimmel <idosch@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8404f6f2