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
On Thu, Mar 12, 2020 at 7:59 PM Stephen Rothwell <[email protected]> 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
On Fri, 13 Mar 2020 12:51:54 -0700, Alexei Starovoitov
<[email protected]> wrote:
> On Thu, Mar 12, 2020 at 7:59 PM Stephen Rothwell <[email protected]>
> 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