linux-next: manual merge of the bpf-next tree with the jc_docs tree

linux-next: manual merge of the bpf-next tree with the jc_docs tree

[Stephen Rothwell]

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

Hi all,

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

  Documentation/bpf/index.rst

between commit:

  1c1c3c7d08d8 ("libbpf: update index.rst reference")

from the jc_docs tree and commit:

  5931d9a3d052 ("bpf, docs: Fix ordering of bpf documentation")

from the bpf-next tree.

I fixed it up (the latter removed the line updated by the former, so I
just the latter) 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

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

Re: linux-next: manual merge of the bpf-next tree with the jc_docs tree

[Daniel Borkmann]

On 11/18/21 12:13 AM, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>    Documentation/bpf/index.rst
> 
> between commit:
> 
>    1c1c3c7d08d8 ("libbpf: update index.rst reference")
> 
> from the jc_docs tree and commit:
> 
>    5931d9a3d052 ("bpf, docs: Fix ordering of bpf documentation")
> 
> from the bpf-next tree.
> 
> I fixed it up (the latter removed the line updated by the former, so I
> just the latter) and can carry the fix as necessary.
Ack, sounds good. Dave's rework fixed it implicitly.

Re: linux-next: manual merge of the bpf-next tree with the jc_docs tree

[Stephen Kitt]

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

On Fri, 13 Mar 2020 12:51:54 -0700, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Thu, Mar 12, 2020 at 7:59 PM Stephen Rothwell <sfr@canb.auug.org.au>
> wrote:
> > Today's linux-next merge of the bpf-next tree got a conflict in:
> >
> >   Documentation/admin-guide/sysctl/kernel.rst
> >
> > between commit:
> >
> >   a3cb66a50852 ("docs: pretty up sysctl/kernel.rst")
> >
> > from the jc_docs tree and commit:
> >
> >   c480a3b79cbc ("docs: sysctl/kernel: Document BPF entries")
> >
> > from the bpf-next tree.  
> 
> I dropped this commit from bpf-next, since it causes unnecessary conflicts.
> Please steer it via Jon's tree.

OK, I’ll do that.

Regards,

Stephen

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

Re: linux-next: manual merge of the bpf-next tree with the jc_docs tree

[Alexei Starovoitov]

On Thu, Mar 12, 2020 at 7:59 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
>   Documentation/admin-guide/sysctl/kernel.rst
>
> between commit:
>
>   a3cb66a50852 ("docs: pretty up sysctl/kernel.rst")
>
> from the jc_docs tree and commit:
>
>   c480a3b79cbc ("docs: sysctl/kernel: Document BPF entries")
>
> from the bpf-next tree.

I dropped this commit from bpf-next, since it causes unnecessary conflicts.
Please steer it via Jon's tree.
Thanks

linux-next: manual merge of the bpf-next tree with the jc_docs tree

[Stephen Rothwell]

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

Hi all,

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

  Documentation/admin-guide/sysctl/kernel.rst

between commit:

  a3cb66a50852 ("docs: pretty up sysctl/kernel.rst")

from the jc_docs tree and commit:

  c480a3b79cbc ("docs: sysctl/kernel: Document BPF entries")

from the bpf-next tree.

I fixed it up (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 Documentation/admin-guide/sysctl/kernel.rst
index 335696d3360d,9e1417628572..000000000000
--- a/Documentation/admin-guide/sysctl/kernel.rst
+++ b/Documentation/admin-guide/sysctl/kernel.rst
@@@ -98,53 -170,64 +98,67 @@@ bootloader_version (x86 only
  The complete bootloader version number.  In the example above, this
  file will contain the value 564 = 0x234.
  
 -See the type_of_loader and ext_loader_ver fields in
 -Documentation/x86/boot.rst for additional information.
 +See the ``type_of_loader`` and ``ext_loader_ver`` fields in
 +:doc:`/x86/boot` for additional information.
  
  
+ bpf_stats_enabled
+ =================
+ 
+ Controls whether the kernel should collect statistics on BPF programs
+ (total time spent running, number of times run...). Enabling
+ statistics causes a slight reduction in performance on each program
+ run. The statistics can be seen using ``bpftool``.
+ 
+ = ===================================
+ 0 Don't collect statistics (default).
+ 1 Collect statistics.
+ = ===================================
+ 
+ 
 -cap_last_cap:
 -=============
 +cap_last_cap
 +============
  
  Highest valid capability of the running kernel.  Exports
 -CAP_LAST_CAP from the kernel.
 +``CAP_LAST_CAP`` from the kernel.
  
  
 -core_pattern:
 -=============
 +core_pattern
 +============
  
 -core_pattern is used to specify a core dumpfile pattern name.
 +``core_pattern`` is used to specify a core dumpfile pattern name.
  
  * max length 127 characters; default value is "core"
 -* core_pattern is used as a pattern template for the output filename;
 -  certain string patterns (beginning with '%') are substituted with
 -  their actual values.
 -* backward compatibility with core_uses_pid:
 +* ``core_pattern`` is used as a pattern template for the output
 +  filename; certain string patterns (beginning with '%') are
 +  substituted with their actual values.
 +* backward compatibility with ``core_uses_pid``:
  
 -	If core_pattern does not include "%p" (default does not)
 -	and core_uses_pid is set, then .PID will be appended to
 +	If ``core_pattern`` does not include "%p" (default does not)
 +	and ``core_uses_pid`` is set, then .PID will be appended to
  	the filename.
  
 -* corename format specifiers::
 -
 -	%<NUL>	'%' is dropped
 -	%%	output one '%'
 -	%p	pid
 -	%P	global pid (init PID namespace)
 -	%i	tid
 -	%I	global tid (init PID namespace)
 -	%u	uid (in initial user namespace)
 -	%g	gid (in initial user namespace)
 -	%d	dump mode, matches PR_SET_DUMPABLE and
 -		/proc/sys/fs/suid_dumpable
 -	%s	signal number
 -	%t	UNIX time of dump
 -	%h	hostname
 -	%e	executable filename (may be shortened)
 -	%E	executable path
 -	%<OTHER> both are dropped
 +* corename format specifiers
 +
 +	========	==========================================
 +	%<NUL>		'%' is dropped
 +	%%		output one '%'
 +	%p		pid
 +	%P		global pid (init PID namespace)
 +	%i		tid
 +	%I		global tid (init PID namespace)
 +	%u		uid (in initial user namespace)
 +	%g		gid (in initial user namespace)
 +	%d		dump mode, matches ``PR_SET_DUMPABLE`` and
 +			``/proc/sys/fs/suid_dumpable``
 +	%s		signal number
 +	%t		UNIX time of dump
 +	%h		hostname
 +	%e		executable filename (may be shortened)
 +	%E		executable path
 +	%c		maximum size of core file by resource limit RLIMIT_CORE
 +	%<OTHER>	both are dropped
 +	========	==========================================
  
  * If the first character of the pattern is a '|', the kernel will treat
    the rest of the pattern as a command to run.  The core dump will be
@@@ -1166,21 -1137,29 +1180,31 @@@ NMI switch that most IA32 servers have 
  example.  If a system hangs up, try pressing the NMI switch.
  
  
+ unprivileged_bpf_disabled
+ =========================
+ 
+ Writing 1 to this entry will disable unprivileged calls to ``bpf()``;
+ once disabled, calling ``bpf()`` without ``CAP_SYS_ADMIN`` will return
+ ``-EPERM``.
+ 
+ Once set, this can't be cleared.
+ 
+ 
 -watchdog:
 -=========
 +watchdog
 +========
  
  This parameter can be used to disable or enable the soft lockup detector
 -_and_ the NMI watchdog (i.e. the hard lockup detector) at the same time.
 -
 -   0 - disable both lockup detectors
 +*and* the NMI watchdog (i.e. the hard lockup detector) at the same time.
  
 -   1 - enable both lockup detectors
 += ==============================
 +0 Disable both lockup detectors.
 +1 Enable both lockup detectors.
 += ==============================
  
  The soft lockup detector and the NMI watchdog can also be disabled or
 -enabled individually, using the soft_watchdog and nmi_watchdog parameters.
 -If the watchdog parameter is read, for example by executing::
 +enabled individually, using the ``soft_watchdog`` and ``nmi_watchdog``
 +parameters.
 +If the ``watchdog`` parameter is read, for example by executing::
  
     cat /proc/sys/kernel/watchdog
  

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

Re: linux-next: manual merge of the bpf-next tree with the jc_docs tree

[Jonathan Corbet]

On Mon, 15 Apr 2019 09:55:31 +0800
Alex Shi <alex.shi@linux.alibaba.com> wrote:

> > This is now a conflict between the net-next tree and the jc_docs tree.  
> Sorry, Stephen, What I can do for this?

What you can do is to not worry.  A trivial conflict like this is easily
handled when everything goes upsteam.

jon

Re: linux-next: manual merge of the bpf-next tree with the jc_docs tree

[Stephen Rothwell]

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

Hi all,

On Fri, 12 Apr 2019 11:05:18 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   .mailmap
> 
> between commit:
> 
>   9b628c6ab437 ("mailmap: update my obsolete email address")
> 
> from the jc_docs tree and commit:
> 
>   fa0dcb3fe2ca ("mailmap: add entry for email addresses")
> 
> from the bpf-next tree.
> 
> I fixed it up (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.
> 
> diff --cc .mailmap
> index 151501c73503,e7984bb6b4b0..000000000000
> --- a/.mailmap
> +++ b/.mailmap
> @@@ -16,8 -16,9 +16,11 @@@ Alan Cox <alan@lxorguk.ukuu.org.uk
>   Alan Cox <root@hraefn.swansea.linux.org.uk>
>   Aleksey Gorelov <aleksey_gorelov@phoenix.com>
>   Aleksandar Markovic <aleksandar.markovic@mips.com> <aleksandar.markovic@imgtec.com>
>  +Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@intel.com>
>  +Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@linaro.org>
> + Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
> + Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>
> + Alexei Starovoitov <ast@kernel.org> <ast@fb.com>
>   Al Viro <viro@ftp.linux.org.uk>
>   Al Viro <viro@zenIV.linux.org.uk>
>   Andi Shyti <andi@etezian.org> <andi.shyti@samsung.com>

This is now a conflict between the net-next tree and the jc_docs tree.

-- 
Cheers,
Stephen Rothwell

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

linux-next: manual merge of the bpf-next tree with the jc_docs tree

[Stephen Rothwell]

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

Hi all,

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

  .mailmap

between commit:

  9b628c6ab437 ("mailmap: update my obsolete email address")

from the jc_docs tree and commit:

  fa0dcb3fe2ca ("mailmap: add entry for email addresses")

from the bpf-next tree.

I fixed it up (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 .mailmap
index 151501c73503,e7984bb6b4b0..000000000000
--- a/.mailmap
+++ b/.mailmap
@@@ -16,8 -16,9 +16,11 @@@ Alan Cox <alan@lxorguk.ukuu.org.uk
  Alan Cox <root@hraefn.swansea.linux.org.uk>
  Aleksey Gorelov <aleksey_gorelov@phoenix.com>
  Aleksandar Markovic <aleksandar.markovic@mips.com> <aleksandar.markovic@imgtec.com>
 +Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@intel.com>
 +Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@linaro.org>
+ Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
+ Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>
+ Alexei Starovoitov <ast@kernel.org> <ast@fb.com>
  Al Viro <viro@ftp.linux.org.uk>
  Al Viro <viro@zenIV.linux.org.uk>
  Andi Shyti <andi@etezian.org> <andi.shyti@samsung.com>

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