1. 09 Mar, 2023 33 commits
  2. 08 Mar, 2023 7 commits
    • Jakub Kicinski's avatar
      Merge https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next · ed69e066
      Jakub Kicinski authored
      Andrii Nakryiko says:
      
      ====================
      pull-request: bpf-next 2023-03-08
      
      We've added 23 non-merge commits during the last 2 day(s) which contain
      a total of 28 files changed, 414 insertions(+), 104 deletions(-).
      
      The main changes are:
      
      1) Add more precise memory usage reporting for all BPF map types,
         from Yafang Shao.
      
      2) Add ARM32 USDT support to libbpf, from Puranjay Mohan.
      
      3) Fix BTF_ID_LIST size causing problems in !CONFIG_DEBUG_INFO_BTF,
         from Nathan Chancellor.
      
      4) IMA selftests fix, from Roberto Sassu.
      
      5) libbpf fix in APK support code, from Daniel Müller.
      
      * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (23 commits)
        selftests/bpf: Fix IMA test
        libbpf: USDT arm arg parsing support
        libbpf: Refactor parse_usdt_arg() to re-use code
        libbpf: Fix theoretical u32 underflow in find_cd() function
        bpf: enforce all maps having memory usage callback
        bpf: offload map memory usage
        bpf, net: xskmap memory usage
        bpf, net: sock_map memory usage
        bpf, net: bpf_local_storage memory usage
        bpf: local_storage memory usage
        bpf: bpf_struct_ops memory usage
        bpf: queue_stack_maps memory usage
        bpf: devmap memory usage
        bpf: cpumap memory usage
        bpf: bloom_filter memory usage
        bpf: ringbuf memory usage
        bpf: reuseport_array memory usage
        bpf: stackmap memory usage
        bpf: arraymap memory usage
        bpf: hashtab memory usage
        ...
      ====================
      
      Link: https://lore.kernel.org/r/20230308193533.1671597-1-andrii@kernel.orgSigned-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      ed69e066
    • Roberto Sassu's avatar
      selftests/bpf: Fix IMA test · 12fabae0
      Roberto Sassu authored
      Commit 62622dab ("ima: return IMA digest value only when IMA_COLLECTED
      flag is set") caused bpf_ima_inode_hash() to refuse to give non-fresh
      digests. IMA test #3 assumed the old behavior, that bpf_ima_inode_hash()
      still returned also non-fresh digests.
      
      Correct the test by accepting both cases. If the samples returned are 1,
      assume that the commit above is applied and that the returned digest is
      fresh. If the samples returned are 2, assume that the commit above is not
      applied, and check both the non-fresh and fresh digest.
      
      Fixes: 62622dab ("ima: return IMA digest value only when IMA_COLLECTED flag is set")
      Reported-by: default avatarDavid Vernet <void@manifault.com>
      Signed-off-by: default avatarRoberto Sassu <roberto.sassu@huawei.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Reviewed-by: default avatarMatt Bobrowski <mattbobrowski@google.com>
      Link: https://lore.kernel.org/bpf/20230308103713.1681200-1-roberto.sassu@huaweicloud.com
      12fabae0
    • Eric Dumazet's avatar
      net: reclaim skb->scm_io_uring bit · 10369080
      Eric Dumazet authored
      Commit 0091bfc8 ("io_uring/af_unix: defer registered
      files gc to io_uring release") added one bit to struct sk_buff.
      
      This structure is critical for networking, and we try very hard
      to not add bloat on it, unless absolutely required.
      
      For instance, we can use a specific destructor as a wrapper
      around unix_destruct_scm(), to identify skbs that unix_gc()
      has to special case.
      Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
      Cc: Pavel Begunkov <asml.silence@gmail.com>
      Cc: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Reviewed-by: default avatarJens Axboe <axboe@kernel.dk>
      Reviewed-by: default avatarPavel Begunkov <asml.silence@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      10369080
    • David S. Miller's avatar
      Merge branch 'sparx5-tc-flower-templates' · b3f4cd07
      David S. Miller authored
      Steen Hegelund says:
      
      ====================
      Add support for TC flower templates in Sparx5
      
      This adds support for the TC template mechanism in the Sparx5 flower filter
      implementation.
      
      Templates are as such handled by the TC framework, but when a template is
      created (using a chain id) there are by definition no filters on this
      chain (an error will be returned if there are any).
      
      If the templates chain id is one that is represented by a VCAP lookup, then
      when the template is created, we know that it is safe to use the keys
      provided in the template to change the keyset configuration for the (port,
      lookup) combination, if this is needed to improve the match on the
      template.
      
      The original port keyset configuration is captured in the template state
      information which is kept per port, so that when the template is deleted
      the port keyset configuration can be restored to its previous setting.
      
      The template also provides the protocol parameter which is the basic
      information that is used to find out which port keyset configuration needs
      to be changed.
      
      The VCAPs and lookups are slightly different when it comes to which keys,
      keysets and protocol are supported and used for selection, so in some
      cases a bit of tweaking is needed to find a useful match.  This is done by
      e.g. removing a key that prevents the best matching keyset from being
      selected.
      
      The debugfs output that is provided for a port allows inspection of the
      currently used keyset in each of the VCAPs lookups.  So when a template has
      been created the debugfs output allows you to verify if the keyset
      configuration has been changed successfully.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3f4cd07
    • Steen Hegelund's avatar
      net: microchip: sparx5: Add TC template support · e1d597ec
      Steen Hegelund authored
      This adds support for using the "template add" and "template destroy"
      functionality to change the port keyset configuration.
      
      If the VCAP lookup already contains rules, the port keyset is left
      unchanged, as a change would make these rules unusable.
      
      When the template is destroyed the port keyset configuration is restored.
      The filters using the template chain will automatically be deleted by the
      TC framework.
      Signed-off-by: default avatarSteen Hegelund <steen.hegelund@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e1d597ec
    • Steen Hegelund's avatar
      net: microchip: sparx5: Add port keyset changing functionality · d9f175b0
      Steen Hegelund authored
      With this its is now possible for clients (like TC) to change the port
      keyset configuration in the Sparx5 VCAPs.
      
      This is typically done per traffic class which is guided with the L3
      protocol information.
      Before the change the current keyset configuration is collected in a list
      that is handed back to the client.
      Signed-off-by: default avatarSteen Hegelund <steen.hegelund@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d9f175b0
    • Steen Hegelund's avatar
      net: microchip: sparx5: Add TC template list to a port · 1c14432d
      Steen Hegelund authored
      This adds a list that is used to collect the templates that are active on a
      port.
      
      This allows the template creation to change the port configuration
      and the template destruction to change it back.
      Signed-off-by: default avatarSteen Hegelund <steen.hegelund@microchip.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1c14432d