public inbox for linux-next@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Rothwell <sfr@canb.auug.org.au>
To: Paul Moore <paul@paul-moore.com>,
	David Miller <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>
Cc: Networking <netdev@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Ondrej Mosnacek <omosnace@redhat.com>
Subject: linux-next: manual merge of the security tree with the net-next tree
Date: Fri, 23 Feb 2024 12:50:27 +1100	[thread overview]
Message-ID: <20240223125027.1c9f4f07@canb.auug.org.au> (raw)

[-- Attachment #1: Type: text/plain, Size: 4002 bytes --]

Hi all,

Today's linux-next merge of the security tree got a conflict in:

  security/security.c

between commits:

  1b67772e4e3f ("bpf,lsm: Refactor bpf_prog_alloc/bpf_prog_free LSM hooks")
  a2431c7eabcf ("bpf,lsm: Refactor bpf_map_alloc/bpf_map_free LSM hooks")
  f568a3d49af9 ("bpf,lsm: Add BPF token LSM hooks")

from the net-next tree and commit:

  260017f31a8c ("lsm: use default hook return value in call_int_hook()")

from the security tree.

I fixed it up (I think, see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc security/security.c
index aef69632d0a9,b95772333d05..000000000000
--- a/security/security.c
+++ b/security/security.c
@@@ -5458,10 -5436,9 +5439,10 @@@ int security_bpf_prog(struct bpf_prog *
   *
   * Return: Returns 0 on success, error on failure.
   */
 -int security_bpf_map_alloc(struct bpf_map *map)
 +int security_bpf_map_create(struct bpf_map *map, union bpf_attr *attr,
 +			    struct bpf_token *token)
  {
- 	return call_int_hook(bpf_map_create, 0, map, attr, token);
 -	return call_int_hook(bpf_map_alloc_security, map);
++	return call_int_hook(bpf_map_create, map, attr, token);
  }
  
  /**
@@@ -5476,59 -5449,9 +5457,59 @@@
   *
   * Return: Returns 0 on success, error on failure.
   */
 -int security_bpf_prog_alloc(struct bpf_prog_aux *aux)
 +int security_bpf_prog_load(struct bpf_prog *prog, union bpf_attr *attr,
 +			   struct bpf_token *token)
  {
- 	return call_int_hook(bpf_prog_load, 0, prog, attr, token);
 -	return call_int_hook(bpf_prog_alloc_security, aux);
++	return call_int_hook(bpf_prog_load, prog, attr, token);
 +}
 +
 +/**
 + * security_bpf_token_create() - Check if creating of BPF token is allowed
 + * @token: BPF token object
 + * @attr: BPF syscall attributes used to create BPF token
 + * @path: path pointing to BPF FS mount point from which BPF token is created
 + *
 + * Do a check when the kernel instantiates a new BPF token object from BPF FS
 + * instance. This is also the point where LSM blob can be allocated for LSMs.
 + *
 + * Return: Returns 0 on success, error on failure.
 + */
 +int security_bpf_token_create(struct bpf_token *token, union bpf_attr *attr,
 +			      struct path *path)
 +{
- 	return call_int_hook(bpf_token_create, 0, token, attr, path);
++	return call_int_hook(bpf_token_create, token, attr, path);
 +}
 +
 +/**
 + * security_bpf_token_cmd() - Check if BPF token is allowed to delegate
 + * requested BPF syscall command
 + * @token: BPF token object
 + * @cmd: BPF syscall command requested to be delegated by BPF token
 + *
 + * Do a check when the kernel decides whether provided BPF token should allow
 + * delegation of requested BPF syscall command.
 + *
 + * Return: Returns 0 on success, error on failure.
 + */
 +int security_bpf_token_cmd(const struct bpf_token *token, enum bpf_cmd cmd)
 +{
- 	return call_int_hook(bpf_token_cmd, 0, token, cmd);
++	return call_int_hook(bpf_token_cmd, token, cmd);
 +}
 +
 +/**
 + * security_bpf_token_capable() - Check if BPF token is allowed to delegate
 + * requested BPF-related capability
 + * @token: BPF token object
 + * @cap: capabilities requested to be delegated by BPF token
 + *
 + * Do a check when the kernel decides whether provided BPF token should allow
 + * delegation of requested BPF-related capabilities.
 + *
 + * Return: Returns 0 on success, error on failure.
 + */
 +int security_bpf_token_capable(const struct bpf_token *token, int cap)
 +{
- 	return call_int_hook(bpf_token_capable, 0, token, cap);
++	return call_int_hook(bpf_token_capable, token, cap);
  }
  
  /**

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

             reply	other threads:[~2024-02-23  1:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-23  1:50 Stephen Rothwell [this message]
2024-02-23 16:21 ` linux-next: manual merge of the security tree with the net-next tree Paul Moore
  -- strict thread matches above, loose matches on Subject: below --
2023-08-01  1:42 Stephen Rothwell
2023-08-01 18:41 ` Paul Moore
2014-08-04  6:26 Stephen Rothwell
2014-08-04  6:30 ` Alexei Starovoitov
2012-04-16  3:29 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240223125027.1c9f4f07@canb.auug.org.au \
    --to=sfr@canb.auug.org.au \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=davem@davemloft.net \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=omosnace@redhat.com \
    --cc=pabeni@redhat.com \
    --cc=paul@paul-moore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox