1. 20 Jul, 2021 40 commits
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: absorb dsa_8021q_setup into dsa_tag_8021q_{,un}register · 328621f6
      Vladimir Oltean authored
      Right now, setting up tag_8021q is a 2-step operation for a driver,
      first the context structure needs to be created, then the VLANs need to
      be installed on the ports. A similar thing is true for teardown.
      
      Merge the 2 steps into the register/unregister methods, to be as
      transparent as possible for the driver as to what tag_8021q does behind
      the scenes. This also gets rid of the funny "bool setup == true means
      setup, == false means teardown" API that tag_8021q used to expose.
      
      Note that dsa_tag_8021q_register() must be called at least in the
      .setup() driver method and never earlier (like in the driver probe
      function). This is because the DSA switch tree is not initialized at
      probe time, and the cross-chip notifiers will not work.
      
      For symmetry with .setup(), the unregister method should be put in
      .teardown().
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      328621f6
    • Vladimir Oltean's avatar
      net: dsa: make tag_8021q operations part of the core · 5da11eb4
      Vladimir Oltean authored
      Make tag_8021q a more central element of DSA and move the 2 driver
      specific operations outside of struct dsa_8021q_context (which is
      supposed to hold dynamic data and not really constant function
      pointers).
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5da11eb4
    • Vladimir Oltean's avatar
      net: dsa: let the core manage the tag_8021q context · d7b1fd52
      Vladimir Oltean authored
      The basic problem description is as follows:
      
      Be there 3 switches in a daisy chain topology:
      
                                                   |
          sw0p0     sw0p1     sw0p2     sw0p3     sw0p4
       [  user ] [  user ] [  user ] [  dsa  ] [  cpu  ]
                                         |
                                         +---------+
                                                   |
          sw1p0     sw1p1     sw1p2     sw1p3     sw1p4
       [  user ] [  user ] [  user ] [  dsa  ] [  dsa  ]
                                         |
                                         +---------+
                                                   |
          sw2p0     sw2p1     sw2p2     sw2p3     sw2p4
       [  user ] [  user ] [  user ] [  user ] [  dsa  ]
      
      The CPU will not be able to ping through the user ports of the
      bottom-most switch (like for example sw2p0), simply because tag_8021q
      was not coded up for this scenario - it has always assumed DSA switch
      trees with a single switch.
      
      To add support for the topology above, we must admit that the RX VLAN of
      sw2p0 must be added on some ports of switches 0 and 1 as well. This is
      in fact a textbook example of thing that can use the cross-chip notifier
      framework that DSA has set up in switch.c.
      
      There is only one problem: core DSA (switch.c) is not able right now to
      make the connection between a struct dsa_switch *ds and a struct
      dsa_8021q_context *ctx. Right now, it is drivers who call into
      tag_8021q.c and always provide a struct dsa_8021q_context *ctx pointer,
      and tag_8021q.c calls them back with the .tag_8021q_vlan_{add,del}
      methods.
      
      But with cross-chip notifiers, it is possible for tag_8021q to call
      drivers without drivers having ever asked for anything. A good example
      is right above: when sw2p0 wants to set itself up for tag_8021q,
      the .tag_8021q_vlan_add method needs to be called for switches 1 and 0,
      so that they transport sw2p0's VLANs towards the CPU without dropping
      them.
      
      So instead of letting drivers manage the tag_8021q context, add a
      tag_8021q_ctx pointer inside of struct dsa_switch, which will be
      populated when dsa_tag_8021q_register() returns success.
      
      The patch is fairly long-winded because we are partly reverting commit
      5899ee36 ("net: dsa: tag_8021q: add a context structure") which made
      the driver-facing tag_8021q API use "ctx" instead of "ds". Now that we
      can access "ctx" directly from "ds", this is no longer needed.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7b1fd52
    • Vladimir Oltean's avatar
      net: dsa: build tag_8021q.c as part of DSA core · 8b6e638b
      Vladimir Oltean authored
      Upcoming patches will add tag_8021q related logic to switch.c and
      port.c, in order to allow it to make use of cross-chip notifiers.
      In addition, a struct dsa_8021q_context *ctx pointer will be added to
      struct dsa_switch.
      
      It seems fairly low-reward to #ifdef the *ctx from struct dsa_switch and
      to provide shim implementations of the entire tag_8021q.c calling
      surface (not even clear what to do about the tag_8021q cross-chip
      notifiers to avoid compiling them). The runtime overhead for switches
      which don't use tag_8021q is fairly small because all helpers will check
      for ds->tag_8021q_ctx being a NULL pointer and stop there.
      
      So let's make it part of dsa_core.o.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8b6e638b
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: create dsa_tag_8021q_{register,unregister} helpers · cedf4670
      Vladimir Oltean authored
      In preparation of moving tag_8021q to core DSA, move all initialization
      and teardown related to tag_8021q which is currently done by drivers in
      2 functions called "register" and "unregister". These will gather more
      functionality in future patches, which will better justify the chosen
      naming scheme.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cedf4670
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: remove struct packet_type declaration · 8afbea18
      Vladimir Oltean authored
      This is no longer necessary since tag_8021q doesn't register itself as a
      full-blown tagger anymore.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8afbea18
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: use symbolic error names · 69ebb370
      Vladimir Oltean authored
      Use %pe to give the user a string holding the error code instead of just
      a number.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      69ebb370
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: use "err" consistently instead of "rc" · a81a4574
      Vladimir Oltean authored
      Some of the tag_8021q code has been taken out of sja1105, which uses
      "rc" for its return code variables, whereas the DSA core uses "err".
      Change tag_8021q for consistency.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a81a4574
    • Vladimir Oltean's avatar
      net: dsa: sja1105: delete the best_effort_vlan_filtering mode · 0fac6aa0
      Vladimir Oltean authored
      Simply put, the best-effort VLAN filtering mode relied on VLAN retagging
      from a bridge VLAN towards a tag_8021q sub-VLAN in order to be able to
      decode the source port in the tagger, but the VLAN retagging
      implementation inside the sja1105 chips is not the best and we were
      relying on marginal operating conditions.
      
      The most notable limitation of the best-effort VLAN filtering mode is
      its incapacity to treat this case properly:
      
      ip link add br0 type bridge vlan_filtering 1
      ip link set swp2 master br0
      ip link set swp4 master br0
      bridge vlan del dev swp4 vid 1
      bridge vlan add dev swp4 vid 1 pvid
      
      When sending an untagged packet through swp2, the expectation is for it
      to be forwarded to swp4 as egress-tagged (so it will contain VLAN ID 1
      on egress). But the switch will send it as egress-untagged.
      
      There was an attempt to fix this here:
      https://patchwork.kernel.org/project/netdevbpf/patch/20210407201452.1703261-2-olteanv@gmail.com/
      
      but it failed miserably because it broke PTP RX timestamping, in a way
      that cannot be corrected due to hardware issues related to VLAN
      retagging.
      
      So with either PTP broken or pushing VLAN headers on egress for untagged
      packets being broken, the sad reality is that the best-effort VLAN
      filtering code is broken. Delete it.
      
      Note that this means there will be a temporary loss of functionality in
      this driver until it is replaced with something better (network stack
      RX/TX capability for "mode 2" as described in
      Documentation/networking/dsa/sja1105.rst, the "port under VLAN-aware
      bridge" case). We simply cannot keep this code until that driver rework
      is done, it is super bloated and tangled with tag_8021q.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0fac6aa0
    • David S. Miller's avatar
      Merge branch 's390-next' · c18e9405
      David S. Miller authored
      Julian Wiedmann says:
      
      ====================
      s390/qeth: updates 2021-07-20
      
      please apply the following patch series for qeth to netdev's net-next tree.
      
      This removes the deprecated support for OSN-mode devices, and does some
      follow-on cleanups.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c18e9405
    • David S. Miller's avatar
      Merge branch 'veth-flexible-channel-numbers' · 542bb396
      David S. Miller authored
      Paolo Abeni says:
      
      ====================
      veth: more flexible channels number configuration
      
      XDP setups can benefit from multiple veth RX/TX queues. Currently
      veth allow setting such number only at creation time via the
      'numrxqueues' and 'numtxqueues' parameters.
      
      This series introduces support for the ethtool set_channel operation
      and allows configuring the queue number via a new module parameter.
      
      The veth default configuration is not changed.
      
      Finally self-tests are updated to check the new features, with both
      valid and invalid arguments.
      
      This iteration is a rebase of the most recent RFC, it does not provide
      a module parameter to configure the default number of queues, but I
      think could be worthy
      
      RFC v1 -> RFC v2:
       - report more consistent 'combined' count
       - make set_channel as resilient as possible to errors
       - drop module parameter - but I would still consider it.
       - more self-tests
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      542bb396
    • David S. Miller's avatar
      Merge branch 'bridge-vlan-multicast' · 2c080404
      David S. Miller authored
      Nikolay Aleksandrov says:
      
      ====================
      net: bridge: multicast: add vlan support
      
      This patchset adds initial per-vlan multicast support, most of the code
      deals with moving to multicast context pointers from bridge/port pointers.
      That allows us to switch them with the per-vlan contexts when a multicast
      packet is being processed and vlan multicast snooping has been enabled.
      That is controlled by a global bridge option added in patch 06 which is
      off by default (BR_BOOLOPT_MCAST_VLAN_SNOOPING). It is important to note
      that this option can change only under RTNL and doesn't require
      multicast_lock, so we need to be careful when retrieving mcast contexts
      in parallel. For packet processing they are switched only once in
      br_multicast_rcv() and then used until the packet has been processed.
      For the most part we need these contexts only to read config values and
      check if they are disabled. The global mcast state which is maintained
      consists of querier and router timers, the rest are config options.
      The port mcast state which is maintained consists of query timer and
      link to router port list if it's ever marked as a router port. Port
      multicast contexts _must_ be used only with their respective global
      contexts, that is a bridge port's mcast context must be used only with
      bridge's global mcast context and a vlan/port's mcast context must be
      used only with that vlan's global mcast context due to the router port
      lists. This way a bridge port can be marked as a router in multiple
      vlans, but might not be a router in some other vlan. Also this allows us
      to have per-vlan querier elections, per-vlan queries and basically the
      whole multicast state becomes per-vlan when the option is enabled.
      One of the hardest parts is synchronization with vlan's memory
      management, that is done through a new vlan flag: BR_VLFLAG_MCAST_ENABLED
      which is changed only under multicast_lock. When a vlan is being
      destroyed first that flag is removed under the lock, then the multicast
      context is torn down which includes waiting for any outstanding context
      timers. Since all of the vlan processing depends on BR_VLFLAG_MCAST_ENABLED
      it must be checked first if the contexts are vlan and the multicast_lock
      has been acquired. That is done by all IGMP/MLD packet processing
      functions and timers. When processing a packet we have RCU so the vlan
      memory won't be freed, but if the flag is missing we must not process it.
      The timers are synchronized in the same way with the addition of waiting
      for them to finish in case they are running after removing the flag
      under multicast_lock (i.e. they were waiting for the lock). Multicast vlan
      snooping requires vlan filtering to be enabled, if it's disabled then
      snooping gets automatically disabled, too. BR_VLFLAG_GLOBAL_MCAST_ENABLED
      controls if a vlan has BR_VLFLAG_MCAST_ENABLED set which is used in all
      vlan disabled checks. We need both flags because one is controlled by
      user-space globally (BR_VLFLAG_GLOBAL_MCAST_ENABLED) and the other is
      for a particular bridge/vlan or port/vlan entry (BR_VLFLAG_MCAST_ENABLED).
      Since the latter is also used for synchronization between the multicast
      and vlan code, and also controlled by BR_VLFLAG_GLOBAL_MCAST_ENABLED we
      rely on it when checking if a vlan context is disabled. The multicast
      fast-path has 3 new bit tests on the cache-hot bridge flags field, I
      didn't observe any measurable difference. I haven't forced either
      context options to be always disabled when the other type is enabled
      because the state consists of timers which either expire (router) or
      don't affect the normal operation. Some options, like the mcast querier
      one, won't be allowed to change for the disabled context type, that will
      come with a future patch-set which adds per-vlan querier control.
      
      Another important addition is the global vlan options, so far we had
      only per bridge/port vlan options but in order to control vlan multicast
      snooping globally we need to add a new type of global vlan options.
      They can be changed only on the bridge device and are dumped only when a
      special flag is set in the dump request. The first global option is vlan
      mcast snooping control, it controls the vlan BR_VLFLAG_GLOBAL_MCAST_ENABLED
      private flag. It can be set only on master vlan entries. There will be
      many more global vlan options in the future both for multicast config
      and other per-vlan options (e.g. STP).
      
      There's a lot of room for improvements, I'll do some of the initial
      ones but splitting the state to different contexts opens the door
      for a lot more. Also any new multicast options become vlan-supported with
      very little to no effort by using the same contexts.
      
      Short patch description:
        patches 01-04: initial mcast context add, no functional changes
        patch      05: adds vlan mcast init and control helpers and uses them on
                       vlan create/destroy
        patch      06: adds a global bridge mcast vlan snooping knob (default
                       off)
        patches 07-08: add a helper for users which must derive the contexts
                       based on current bridge and vlan options (e.g. timers)
        patch      09: adds checks for disabled vlan contexts in packet
                       processing and timers
        patch      10: adds support for per-vlan querier and tagged queries
        patch      11: adds router port vlan id in the notifications
        patches 12-14: add global vlan options support (change, dump, notify)
        patch      15: adds per-vlan global mcast snooping control
      
      Future patch-sets which build on this one (in order):
       - vlan state mcast handling
       - user-space mdb contexts (currently only the bridge contexts are used
         there)
       - all bridge multicast config options added per-vlan global and per
         vlan/port
       - iproute2 support for all the new uAPIs
       - selftests
      
      This set has been stress-tested (deleting/adding ports/vlans while changing
      vlan mcast snooping while processing IGMP/MLD packets), and also has
      passed all bridge self-tests. I'm sending this set as early as possible
      since there're a few more related sets that should go in the same
      release to get proper and full mcast vlan snooping support.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2c080404
    • Julian Wiedmann's avatar
      s390/qeth: clean up device_type management · ae57ea7a
      Julian Wiedmann authored
      qeth uses three device_type structs - a generic one, and one for each
      sub-driver (which is used for fixed-layer devices only). Instead of
      exporting these device_types back&forth between the driver's modules,
      make all the logic self-contained within the sub-drivers.
      
      On disc->setup() they either install their own device_type, or add the
      sysfs attributes that are missing in the generic device_type. Later on
      disc->remove() these attributes are removed again from any device that
      has the generic device_type.
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ae57ea7a
    • Julian Wiedmann's avatar
      s390/qeth: clean up QETH_PROT_* naming · a37cfa28
      Julian Wiedmann authored
      The QETH_PROT_* naming is shared among two unrelated areas - one is
      the MPC-level protocol identifiers, the other is the qeth_prot_version
      enum.
      
      Rename the MPC definitions to use QETH_MPC_PROT_*.
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: default avatarAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a37cfa28
    • Julian Wiedmann's avatar
      s390/qeth: remove OSN support · a8c7629c
      Julian Wiedmann authored
      Commit fb64de1b ("s390/qeth: phase out OSN support") spelled out
      why the OSN support in qeth is in a bad shape, and put any remaining
      interested parties on notice to speak up before it gets ripped out.
      
      It's 2021 now, so make true on that promise and remove all the
      OSN-specific parts from qeth. This also means that we no longer need to
      export various parts of the cmd & data path internals to the L2 driver.
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Reviewed-by: default avatarAlexandra Winter <wintera@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a8c7629c
    • David S. Miller's avatar
      Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue · bc672d49
      David S. Miller authored
      Tony Nguyen says:
      
      ====================
      40GbE Intel Wired LAN Driver Updates 2021-07-19
      
      This series contains updates to iavf and i40e drivers.
      
      Stefan Assmann adds locking to a path that does not acquire a spinlock
      where needed for i40e. He also adjusts locking of critical sections to
      help avoid races and removes overriding of the adapter state during
      pending reset for iavf driver.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bc672d49
    • David S. Miller's avatar
      Merge branch 'veth-flexible-channel-numbers' · e4b1dc43
      David S. Miller authored
      Paolo Abeni says:
      
      ====================
      veth: more flexible channels number configuration
      
      XDP setups can benefit from multiple veth RX/TX queues. Currently
      veth allow setting such number only at creation time via the
      'numrxqueues' and 'numtxqueues' parameters.
      
      This series introduces support for the ethtool set_channel operation
      and allows configuring the queue number via a new module parameter.
      
      The veth default configuration is not changed.
      
      Finally self-tests are updated to check the new features, with both
      valid and invalid arguments.
      
      This iteration is a rebase of the most recent RFC, it does not provide
      a module parameter to configure the default number of queues, but I
      think could be worthy
      
      RFC v1 -> RFC v2:
       - report more consistent 'combined' count
       - make set_channel as resilient as possible to errors
       - drop module parameter - but I would still consider it.
       - more self-tests
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e4b1dc43
    • Paolo Abeni's avatar
      selftests: net: veth: add tests for set_channel · 1ec2230f
      Paolo Abeni authored
      Simple functional test for the newly exposed features.
      
      Also add an optional stress test for the channel number
      update under flood.
      
      RFC v1 -> RFC v2:
       - add the stress test
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1ec2230f
    • Paolo Abeni's avatar
      veth: create by default nr_possible_cpus queues · 9d3684c2
      Paolo Abeni authored
      This allows easier XDP usage. The number of default active
      queues is not changed: 1 RX and 1 TX so that this does
      not introduce overhead on the datapath for queue selection.
      
      v1 -> v2:
       - drop the module parameter, force default to nr_possible_cpus - Toke
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9d3684c2
    • Paolo Abeni's avatar
      veth: implement support for set_channel ethtool op · 4752eeb3
      Paolo Abeni authored
      This change implements the set_channel() ethtool operation,
      preserving the current defaults values and allowing up set
      the number of queues in the range set ad device creation
      time.
      
      The update operation tries hard to leave the device in a
      consistent status in case of errors.
      
      RFC v1 -> RFC v2:
       - don't flip device status on set_channel()
       - roll-back the changes if possible on error - Jackub
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4752eeb3
    • Paolo Abeni's avatar
      veth: factor out initialization helper · dedd53c5
      Paolo Abeni authored
      Extract in simpler helpers the code to enable and disable a
      range of xdp/napi instance, with the common property that
      "disable" helpers can't fail.
      
      Will be used by the next patch. No functional change intended.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dedd53c5
    • Paolo Abeni's avatar
      veth: always report zero combined channels · f7918b79
      Paolo Abeni authored
      veth get_channel currently reports for channels being both RX/TX and
      combined. As Jakub noted:
      
      """
      ethtool man page is relatively clear, unfortunately the kernel code
      is not and few read the man page. A channel is approximately an IRQ,
      not a queue, and IRQ can't be dedicated and combined simultaneously
      """
      
      This patch changes the information exposed by veth_get_channels,
      setting max_combined to zero, being more consistent with the above
      statement. The ethtool_channels is always cleared by the caller, we just
      need to avoid setting the 'combined' fields.
      Signed-off-by: default avatarPaolo Abeni <pabeni@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7918b79
    • Vasily Averin's avatar
      memcg: enable accounting for scm_fp_list objects · 2c6ad20b
      Vasily Averin authored
      unix sockets allows to send file descriptors via SCM_RIGHTS type messages.
      Each such send call forces kernel to allocate up to 2Kb memory for
      struct scm_fp_list.
      
      It makes sense to account for them to restrict the host's memory
      consumption from inside the memcg-limited container.
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2c6ad20b
    • Vasily Averin's avatar
      memcg: ipv6/sit: account and don't WARN on ip_tunnel_prl structs allocation · 1b51d827
      Vasily Averin authored
      Author: Andrey Ryabinin <aryabinin@virtuozzo.com>
      
      The size of the ip_tunnel_prl structs allocation is controllable from
      user-space, thus it's better to avoid spam in dmesg if allocation failed.
      Also add __GFP_ACCOUNT as this is a good candidate for per-memcg
      accounting. Allocation is temporary and limited by 4GB.
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1b51d827
    • Vasily Averin's avatar
      memcg: enable accounting for VLAN group array · a89893dd
      Vasily Averin authored
      vlan array consume up to 8 pages of memory per net device.
      
      It makes sense to account for them to restrict the host's memory
      consumption from inside the memcg-limited container.
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a89893dd
    • Vasily Averin's avatar
      memcg: enable accounting for inet_bin_bucket cache · 990c74e3
      Vasily Averin authored
      net namespace can create up to 64K tcp and dccp ports and force kernel
      to allocate up to several megabytes of memory per netns
      for inet_bind_bucket objects.
      
      It makes sense to account for them to restrict the host's memory
      consumption from inside the memcg-limited container.
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      990c74e3
    • Vasily Averin's avatar
      memcg: enable accounting for IP address and routing-related objects · 6126891c
      Vasily Averin authored
      An netadmin inside container can use 'ip a a' and 'ip r a'
      to assign a large number of ipv4/ipv6 addresses and routing entries
      and force kernel to allocate megabytes of unaccounted memory
      for long-lived per-netdevice related kernel objects:
      'struct in_ifaddr', 'struct inet6_ifaddr', 'struct fib6_node',
      'struct rt6_info', 'struct fib_rules' and ip_fib caches.
      
      These objects can be manually removed, though usually they lives
      in memory till destroy of its net namespace.
      
      It makes sense to account for them to restrict the host's memory
      consumption from inside the memcg-limited container.
      
      One of such objects is the 'struct fib6_node' mostly allocated in
      net/ipv6/route.c::__ip6_ins_rt() inside the lock_bh()/unlock_bh() section:
      
       write_lock_bh(&table->tb6_lock);
       err = fib6_add(&table->tb6_root, rt, info, mxc);
       write_unlock_bh(&table->tb6_lock);
      
      In this case it is not enough to simply add SLAB_ACCOUNT to corresponding
      kmem cache. The proper memory cgroup still cannot be found due to the
      incorrect 'in_interrupt()' check used in memcg_kmem_bypass().
      
      Obsoleted in_interrupt() does not describe real execution context properly.
      >From include/linux/preempt.h:
      
       The following macros are deprecated and should not be used in new code:
       in_interrupt()	- We're in NMI,IRQ,SoftIRQ context or have BH disabled
      
      To verify the current execution context new macro should be used instead:
       in_task()	- We're in task context
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6126891c
    • Vasily Averin's avatar
      memcg: enable accounting for net_device and Tx/Rx queues · c948f51c
      Vasily Averin authored
      Container netadmin can create a lot of fake net devices,
      then create a new net namespace and repeat it again and again.
      Net device can request the creation of up to 4096 tx and rx queues,
      and force kernel to allocate up to several tens of megabytes memory
      per net device.
      
      It makes sense to account for them to restrict the host's memory
      consumption from inside the memcg-limited container.
      Signed-off-by: default avatarVasily Averin <vvs@virtuozzo.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c948f51c
    • David S. Miller's avatar
      Merge branch 'bridge-vlan-multicast' · 2967eed9
      David S. Miller authored
      Nikolay Aleksandrov says:
      
      ====================
      net: bridge: multicast: add vlan support
      
      This patchset adds initial per-vlan multicast support, most of the code
      deals with moving to multicast context pointers from bridge/port pointers.
      That allows us to switch them with the per-vlan contexts when a multicast
      packet is being processed and vlan multicast snooping has been enabled.
      That is controlled by a global bridge option added in patch 06 which is
      off by default (BR_BOOLOPT_MCAST_VLAN_SNOOPING). It is important to note
      that this option can change only under RTNL and doesn't require
      multicast_lock, so we need to be careful when retrieving mcast contexts
      in parallel. For packet processing they are switched only once in
      br_multicast_rcv() and then used until the packet has been processed.
      For the most part we need these contexts only to read config values and
      check if they are disabled. The global mcast state which is maintained
      consists of querier and router timers, the rest are config options.
      The port mcast state which is maintained consists of query timer and
      link to router port list if it's ever marked as a router port. Port
      multicast contexts _must_ be used only with their respective global
      contexts, that is a bridge port's mcast context must be used only with
      bridge's global mcast context and a vlan/port's mcast context must be
      used only with that vlan's global mcast context due to the router port
      lists. This way a bridge port can be marked as a router in multiple
      vlans, but might not be a router in some other vlan. Also this allows us
      to have per-vlan querier elections, per-vlan queries and basically the
      whole multicast state becomes per-vlan when the option is enabled.
      One of the hardest parts is synchronization with vlan's memory
      management, that is done through a new vlan flag: BR_VLFLAG_MCAST_ENABLED
      which is changed only under multicast_lock. When a vlan is being
      destroyed first that flag is removed under the lock, then the multicast
      context is torn down which includes waiting for any outstanding context
      timers. Since all of the vlan processing depends on BR_VLFLAG_MCAST_ENABLED
      it must be checked first if the contexts are vlan and the multicast_lock
      has been acquired. That is done by all IGMP/MLD packet processing
      functions and timers. When processing a packet we have RCU so the vlan
      memory won't be freed, but if the flag is missing we must not process it.
      The timers are synchronized in the same way with the addition of waiting
      for them to finish in case they are running after removing the flag
      under multicast_lock (i.e. they were waiting for the lock). Multicast vlan
      snooping requires vlan filtering to be enabled, if it's disabled then
      snooping gets automatically disabled, too. BR_VLFLAG_GLOBAL_MCAST_ENABLED
      controls if a vlan has BR_VLFLAG_MCAST_ENABLED set which is used in all
      vlan disabled checks. We need both flags because one is controlled by
      user-space globally (BR_VLFLAG_GLOBAL_MCAST_ENABLED) and the other is
      for a particular bridge/vlan or port/vlan entry (BR_VLFLAG_MCAST_ENABLED).
      Since the latter is also used for synchronization between the multicast
      and vlan code, and also controlled by BR_VLFLAG_GLOBAL_MCAST_ENABLED we
      rely on it when checking if a vlan context is disabled. The multicast
      fast-path has 3 new bit tests on the cache-hot bridge flags field, I
      didn't observe any measurable difference. I haven't forced either
      context options to be always disabled when the other type is enabled
      because the state consists of timers which either expire (router) or
      don't affect the normal operation. Some options, like the mcast querier
      one, won't be allowed to change for the disabled context type, that will
      come with a future patch-set which adds per-vlan querier control.
      
      Another important addition is the global vlan options, so far we had
      only per bridge/port vlan options but in order to control vlan multicast
      snooping globally we need to add a new type of global vlan options.
      They can be changed only on the bridge device and are dumped only when a
      special flag is set in the dump request. The first global option is vlan
      mcast snooping control, it controls the vlan BR_VLFLAG_GLOBAL_MCAST_ENABLED
      private flag. It can be set only on master vlan entries. There will be
      many more global vlan options in the future both for multicast config
      and other per-vlan options (e.g. STP).
      
      There's a lot of room for improvements, I'll do some of the initial
      ones but splitting the state to different contexts opens the door
      for a lot more. Also any new multicast options become vlan-supported with
      very little to no effort by using the same contexts.
      
      Short patch description:
        patches 01-04: initial mcast context add, no functional changes
        patch      05: adds vlan mcast init and control helpers and uses them on
                       vlan create/destroy
        patch      06: adds a global bridge mcast vlan snooping knob (default
                       off)
        patches 07-08: add a helper for users which must derive the contexts
                       based on current bridge and vlan options (e.g. timers)
        patch      09: adds checks for disabled vlan contexts in packet
                       processing and timers
        patch      10: adds support for per-vlan querier and tagged queries
        patch      11: adds router port vlan id in the notifications
        patches 12-14: add global vlan options support (change, dump, notify)
        patch      15: adds per-vlan global mcast snooping control
      
      Future patch-sets which build on this one (in order):
       - vlan state mcast handling
       - user-space mdb contexts (currently only the bridge contexts are used
         there)
       - all bridge multicast config options added per-vlan global and per
         vlan/port
       - iproute2 support for all the new uAPIs
       - selftests
      
      This set has been stress-tested (deleting/adding ports/vlans while changing
      vlan mcast snooping while processing IGMP/MLD packets), and also has
      passed all bridge self-tests. I'm sending this set as early as possible
      since there're a few more related sets that should go in the same
      release to get proper and full mcast vlan snooping support.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2967eed9
    • Nikolay Aleksandrov's avatar
      net: bridge: vlan: add mcast snooping control · 9dee572c
      Nikolay Aleksandrov authored
      Add a new global vlan option which controls whether multicast snooping
      is enabled or disabled for a single vlan. It controls the vlan private
      flag: BR_VLFLAG_GLOBAL_MCAST_ENABLED.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9dee572c
    • Nikolay Aleksandrov's avatar
      net: bridge: vlan: notify when global options change · 9aba624d
      Nikolay Aleksandrov authored
      Add support for global options notifications. They use only RTM_NEWVLAN
      since global options can only be set and are contained in a separate
      vlan global options attribute. Notifications are compressed in ranges
      where possible, i.e. the sequential vlan options are equal.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9aba624d
    • Nikolay Aleksandrov's avatar
      net: bridge: vlan: add support for dumping global vlan options · 743a53d9
      Nikolay Aleksandrov authored
      Add a new vlan options dump flag which causes only global vlan options
      to be dumped. The dumps are done only with bridge devices, ports are
      ignored. They support vlan compression if the options in sequential
      vlans are equal (currently always true).
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      743a53d9
    • Nikolay Aleksandrov's avatar
      net: bridge: vlan: add support for global options · 47ecd2db
      Nikolay Aleksandrov authored
      We can have two types of vlan options depending on context:
       - per-device vlan options (split in per-bridge and per-port)
       - global vlan options
      
      The second type wasn't supported in the bridge until now, but we need
      them for per-vlan multicast support, per-vlan STP support and other
      options which require global vlan context. They are contained in the global
      bridge vlan context even if the vlan is not configured on the bridge device
      itself. This patch adds initial netlink attributes and support for setting
      these global vlan options, they can only be set (RTM_NEWVLAN) and the
      operation must use the bridge device. Since there are no such options yet
      it shouldn't have any functional effect.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      47ecd2db
    • Nikolay Aleksandrov's avatar
      net: bridge: multicast: include router port vlan id in notifications · 1e9ca456
      Nikolay Aleksandrov authored
      Use the port multicast context to check if the router port is a vlan and
      in case it is include its vlan id in the notification.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1e9ca456
    • Nikolay Aleksandrov's avatar
      net: bridge: multicast: add vlan querier and query support · 615cc23e
      Nikolay Aleksandrov authored
      Add basic vlan context querier support, if the contexts passed to
      multicast_alloc_query are vlan then the query will be tagged. Also
      handle querier start/stop of vlan contexts.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      615cc23e
    • Nikolay Aleksandrov's avatar
      net: bridge: multicast: check if should use vlan mcast ctx · 4cdd0d10
      Nikolay Aleksandrov authored
      Add helpers which check if the current bridge/port multicast context
      should be used (i.e. they're not disabled) and use them for Rx IGMP/MLD
      processing, timers and new group addition. It is important for vlans to
      disable processing of timer/packet after the multicast_lock is obtained
      if the vlan context doesn't have BR_VLFLAG_MCAST_ENABLED. There are two
      cases when that flag is missing:
       - if the vlan is getting destroyed it will be removed and timers will
         be stopped
       - if the vlan mcast snooping is being disabled
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4cdd0d10
    • Nikolay Aleksandrov's avatar
      net: bridge: multicast: use the port group to port context helper · eb1593a0
      Nikolay Aleksandrov authored
      We need to use the new port group to port context helper in places where
      we cannot pass down the proper context (i.e. functions that can be
      called by timers or outside the packet snooping paths).
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      eb1593a0
    • Nikolay Aleksandrov's avatar
      net: bridge: multicast: add helper to get port mcast context from port group · 74edfd48
      Nikolay Aleksandrov authored
      Add br_multicast_pg_to_port_ctx() which returns the proper port multicast
      context from either port or vlan based on bridge option and vlan flags.
      As the comment inside explains the locking is a bit tricky, we rely on
      the fact that BR_VLFLAG_MCAST_ENABLED requires multicast_lock to change
      and we also require it to be held to call that helper. If we find the
      vlan under rcu and it still has the flag then we can be sure it will be
      alive until we unlock multicast_lock which should be enough.
      Note that the context might change from vlan to bridge between different
      calls to this helper as the mcast vlan knob requires only rtnl so it should
      be used carefully and for read-only/check purposes.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      74edfd48
    • Nikolay Aleksandrov's avatar
      net: bridge: add vlan mcast snooping knob · f4b7002a
      Nikolay Aleksandrov authored
      Add a global knob that controls if vlan multicast snooping is enabled.
      The proper contexts (vlan or bridge-wide) will be chosen based on the knob
      when processing packets and changing bridge device state. Note that
      vlans have their individual mcast snooping enabled by default, but this
      knob is needed to turn on bridge vlan snooping. It is disabled by
      default. To enable the knob vlan filtering must also be enabled, it
      doesn't make sense to have vlan mcast snooping without vlan filtering
      since that would lead to inconsistencies. Disabling vlan filtering will
      also automatically disable vlan mcast snooping.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f4b7002a
    • Nikolay Aleksandrov's avatar
      net: bridge: multicast: add vlan state initialization and control · 7b54aaaf
      Nikolay Aleksandrov authored
      Add helpers to enable/disable vlan multicast based on its flags, we need
      two flags because we need to know if the vlan has multicast enabled
      globally (user-controlled) and if it has it enabled on the specific device
      (bridge or port). The new private vlan flags are:
       - BR_VLFLAG_MCAST_ENABLED: locally enabled multicast on the device, used
         when removing a vlan, toggling vlan mcast snooping and controlling
         single vlan (kernel-controlled, valid under RTNL and multicast_lock)
       - BR_VLFLAG_GLOBAL_MCAST_ENABLED: globally enabled multicast for the
         vlan, used to control the bridge-wide vlan mcast snooping for a
         single vlan (user-controlled, can be checked under any context)
      
      Bridge vlan contexts are created with multicast snooping enabled by
      default to be in line with the current bridge snooping defaults. In
      order to actually activate per vlan snooping and context usage a
      bridge-wide knob will be added later which will default to disabled.
      If that knob is enabled then automatically all vlan snooping will be
      enabled. All vlan contexts are initialized with the current bridge
      multicast context defaults.
      Signed-off-by: default avatarNikolay Aleksandrov <nikolay@nvidia.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7b54aaaf