<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/Documentation/admin-guide/sysctl/kernel.rst, branch v6.7.9</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.7.9</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v6.7.9'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2023-11-02T01:28:33Z</updated>
<entry>
<title>Merge tag 'asm-generic-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic</title>
<updated>2023-11-02T01:28:33Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-11-02T01:28:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1e0c505e13162a2abe7c984309cfe2ae976b428d'/>
<id>urn:sha1:1e0c505e13162a2abe7c984309cfe2ae976b428d</id>
<content type='text'>
Pull ia64 removal and asm-generic updates from Arnd Bergmann:

 - The ia64 architecture gets its well-earned retirement as planned,
   now that there is one last (mostly) working release that will be
   maintained as an LTS kernel.

 - The architecture specific system call tables are updated for the
   added map_shadow_stack() syscall and to remove references to the
   long-gone sys_lookup_dcookie() syscall.

* tag 'asm-generic-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
  hexagon: Remove unusable symbols from the ptrace.h uapi
  asm-generic: Fix spelling of architecture
  arch: Reserve map_shadow_stack() syscall number for all architectures
  syscalls: Cleanup references to sys_lookup_dcookie()
  Documentation: Drop or replace remaining mentions of IA64
  lib/raid6: Drop IA64 support
  Documentation: Drop IA64 from feature descriptions
  kernel: Drop IA64 support from sig_fault handlers
  arch: Remove Itanium (IA-64) architecture
</content>
</entry>
<entry>
<title>sched/topology: Change behaviour of the 'sched_energy_aware' sysctl, based on the platform</title>
<updated>2023-10-09T15:24:44Z</updated>
<author>
<name>Shrikanth Hegde</name>
<email>sshegde@linux.vnet.ibm.com</email>
</author>
<published>2023-10-09T06:00:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8f833c82cdab7b4049bcfe88311d35fa5f24e422'/>
<id>urn:sha1:8f833c82cdab7b4049bcfe88311d35fa5f24e422</id>
<content type='text'>
The 'sched_energy_aware' sysctl is available for the admin to disable/enable
energy aware scheduling(EAS). EAS is enabled only if few conditions are
met by the platform. They are, asymmetric CPU capacity, no SMT,
schedutil CPUfreq governor, frequency invariant load tracking etc.
A platform may boot without EAS capability, but could gain such
capability at runtime. For example, changing/registering the cpufreq
governor to schedutil.

At present, though platform doesn't support EAS, this sysctl returns 1
and it ends up calling build_perf_domains on write to 1 and
NOP when writing to 0. That is confusing and un-necessary.

Desired behavior would be to have this sysctl to enable/disable the EAS
on supported platform. On non-supported platform write to the sysctl
would return not supported error and read of the sysctl would return
empty. So sched_energy_aware returns empty - EAS is not possible at this moment
This will include EAS capable platforms which have at least one EAS
condition false during startup, e.g. not using the schedutil cpufreq governor
sched_energy_aware returns 0 - EAS is supported but disabled by admin.
sched_energy_aware returns 1 - EAS is supported and enabled.

User can find out the reason why EAS is not possible by checking
info messages. sched_is_eas_possible returns true if the platform
can do EAS at this moment.

Signed-off-by: Shrikanth Hegde &lt;sshegde@linux.vnet.ibm.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Tested-by: Pierre Gondois &lt;pierre.gondois@arm.com&gt;
Reviewed-by: Valentin Schneider &lt;vschneid@redhat.com&gt;
Link: https://lore.kernel.org/r/20231009060037.170765-3-sshegde@linux.vnet.ibm.com
</content>
</entry>
<entry>
<title>Documentation: Drop or replace remaining mentions of IA64</title>
<updated>2023-09-11T08:13:18Z</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ardb@kernel.org</email>
</author>
<published>2023-01-13T17:32:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=944834901adc94b3a44d1dd153eb739a937e52d2'/>
<id>urn:sha1:944834901adc94b3a44d1dd153eb739a937e52d2</id>
<content type='text'>
Drop or update mentions of IA64, as appropriate.

Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'io_uring-6.6-2023-09-08' of git://git.kernel.dk/linux</title>
<updated>2023-09-09T04:32:28Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2023-09-09T04:32:28Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7ccc3ebf0c575728bff2d3cb4719ccd84aa186ab'/>
<id>urn:sha1:7ccc3ebf0c575728bff2d3cb4719ccd84aa186ab</id>
<content type='text'>
Pull io_uring fixes from Jens Axboe:
 "A few fixes that should go into the 6.6-rc merge window:

   - Fix for a regression this merge window caused by the SQPOLL
     affinity patch, where we can race with SQPOLL thread shutdown and
     cause an oops when trying to set affinity (Gabriel)

   - Fix for a regression this merge window where fdinfo reading with
     for a ring setup with IORING_SETUP_NO_SQARRAY will attempt to
     deference the non-existing SQ ring array (me)

   - Add the patch that allows more finegrained control over who can use
     io_uring (Matteo)

   - Locking fix for a regression added this merge window for IOPOLL
     overflow (Pavel)

   - IOPOLL fix for stable, breaking our loop if helper threads are
     exiting (Pavel)

  Also had a fix for unreaped iopoll requests from io-wq from Ming, but
  we found an issue with that and hence it got reverted. Will get this
  sorted for a future rc"

* tag 'io_uring-6.6-2023-09-08' of git://git.kernel.dk/linux:
  Revert "io_uring: fix IO hang in io_wq_put_and_exit from do_exit()"
  io_uring: fix unprotected iopoll overflow
  io_uring: break out of iowq iopoll on teardown
  io_uring: add a sysctl to disable io_uring system-wide
  io_uring/fdinfo: only print -&gt;sq_array[] if it's there
  io_uring: fix IO hang in io_wq_put_and_exit from do_exit()
  io_uring: Don't set affinity on a dying sqpoll thread
</content>
</entry>
<entry>
<title>io_uring: add a sysctl to disable io_uring system-wide</title>
<updated>2023-09-05T14:34:07Z</updated>
<author>
<name>Matteo Rizzo</name>
<email>matteorizzo@google.com</email>
</author>
<published>2023-08-21T21:15:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=76d3ccecfa186af3120e206d62f03db1a94a535f'/>
<id>urn:sha1:76d3ccecfa186af3120e206d62f03db1a94a535f</id>
<content type='text'>
Introduce a new sysctl (io_uring_disabled) which can be either 0, 1, or
2. When 0 (the default), all processes are allowed to create io_uring
instances, which is the current behavior.  When 1, io_uring creation is
disabled (io_uring_setup() will fail with -EPERM) for unprivileged
processes not in the kernel.io_uring_group group.  When 2, calls to
io_uring_setup() fail with -EPERM regardless of privilege.

Signed-off-by: Matteo Rizzo &lt;matteorizzo@google.com&gt;
[JEM: modified to add io_uring_group]
Signed-off-by: Jeff Moyer &lt;jmoyer@redhat.com&gt;
Link: https://lore.kernel.org/r/x49y1i42j1z.fsf@segfault.boston.devel.redhat.com
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
</content>
</entry>
<entry>
<title>Documentation: admin-guide: Add riscv sysctl_perf_user_access</title>
<updated>2023-08-16T14:28:21Z</updated>
<author>
<name>Alexandre Ghiti</name>
<email>alexghiti@rivosinc.com</email>
</author>
<published>2023-08-02T08:03:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=57972127b20ef9cb84fc214f7cfacaa7ab884a38'/>
<id>urn:sha1:57972127b20ef9cb84fc214f7cfacaa7ab884a38</id>
<content type='text'>
riscv now uses this sysctl so document its usage for this architecture.

Signed-off-by: Alexandre Ghiti &lt;alexghiti@rivosinc.com&gt;
</content>
</entry>
<entry>
<title>docs: arm64: Move arm64 documentation under Documentation/arch/</title>
<updated>2023-06-21T14:51:51Z</updated>
<author>
<name>Jonathan Corbet</name>
<email>corbet@lwn.net</email>
</author>
<published>2023-06-12T12:06:39Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e4624435f38b34e7ce827070aa0f8b533a37c07e'/>
<id>urn:sha1:e4624435f38b34e7ce827070aa0f8b533a37c07e</id>
<content type='text'>
Architecture-specific documentation is being moved into Documentation/arch/
as a way of cleaning up the top-level documentation directory and making
the docs hierarchy more closely match the source hierarchy.  Move
Documentation/arm64 into arch/ (along with the Chinese equvalent
translations) and fix up documentation references.

Cc: Will Deacon &lt;will@kernel.org&gt;
Cc: Alex Shi &lt;alexs@kernel.org&gt;
Cc: Hu Haowen &lt;src.res@email.cn&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Acked-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Reviewed-by: Yantengsi &lt;siyanteng@loongson.cn&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
</entry>
<entry>
<title>docs: move x86 documentation into Documentation/arch/</title>
<updated>2023-03-30T18:58:51Z</updated>
<author>
<name>Jonathan Corbet</name>
<email>corbet@lwn.net</email>
</author>
<published>2023-03-14T23:06:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ff61f0791ce969d2db6c9f3b71d74ceec0a2e958'/>
<id>urn:sha1:ff61f0791ce969d2db6c9f3b71d74ceec0a2e958</id>
<content type='text'>
Move the x86 documentation under Documentation/arch/ as a way of cleaning
up the top-level directory and making the structure of our docs more
closely match the structure of the source directories it describes.

All in-kernel references to the old paths have been updated.

Acked-by: Dave Hansen &lt;dave.hansen@linux.intel.com&gt;
Cc: linux-arch@vger.kernel.org
Cc: x86@kernel.org
Cc: Borislav Petkov &lt;bp@alien8.de&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: https://lore.kernel.org/lkml/20230315211523.108836-1-corbet@lwn.net/
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
</entry>
<entry>
<title>kexec: introduce sysctl parameters kexec_load_limit_*</title>
<updated>2023-02-03T06:50:05Z</updated>
<author>
<name>Ricardo Ribalda</name>
<email>ribalda@chromium.org</email>
</author>
<published>2023-01-04T14:38:48Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a42aaad2e47b23d63037bfc0130e33fc0f74cd71'/>
<id>urn:sha1:a42aaad2e47b23d63037bfc0130e33fc0f74cd71</id>
<content type='text'>
kexec allows replacing the current kernel with a different one.  This is
usually a source of concerns for sysadmins that want to harden a system.

Linux already provides a way to disable loading new kexec kernel via
kexec_load_disabled, but that control is very coard, it is all or nothing
and does not make distinction between a panic kexec and a normal kexec.

This patch introduces new sysctl parameters, with finer tuning to specify
how many times a kexec kernel can be loaded.  The sysadmin can set
different limits for kexec panic and kexec reboot kernels.  The value can
be modified at runtime via sysctl, but only with a stricter value.

With these new parameters on place, a system with loadpin and verity
enabled, using the following kernel parameters:
sysctl.kexec_load_limit_reboot=0 sysct.kexec_load_limit_panic=1 can have a
good warranty that if initrd tries to load a panic kernel, a malitious
user will have small chances to replace that kernel with a different one,
even if they can trigger timeouts on the disk where the panic kernel
lives.

Link: https://lkml.kernel.org/r/20221114-disable-kexec-reset-v6-3-6a8531a09b9a@chromium.org
Signed-off-by: Ricardo Ribalda &lt;ribalda@chromium.org&gt;
Reviewed-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
Acked-by: Baoquan He &lt;bhe@redhat.com&gt;
Cc: Bagas Sanjaya &lt;bagasdotme@gmail.com&gt;
Cc: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Cc: Guilherme G. Piccoli &lt;gpiccoli@igalia.com&gt; # Steam Deck
Cc: Joel Fernandes (Google) &lt;joel@joelfernandes.org&gt;
Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Cc: Philipp Rudo &lt;prudo@redhat.com&gt;
Cc: Ross Zwisler &lt;zwisler@kernel.org&gt;
Cc: Sergey Senozhatsky &lt;senozhatsky@chromium.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>Documentation: sysctl: correct kexec_load_disabled</title>
<updated>2023-02-03T06:50:04Z</updated>
<author>
<name>Ricardo Ribalda</name>
<email>ribalda@chromium.org</email>
</author>
<published>2023-01-04T14:38:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=06dcb0138f5f815f50142234b2e06f5540471715'/>
<id>urn:sha1:06dcb0138f5f815f50142234b2e06f5540471715</id>
<content type='text'>
Patch series "kexec: Add new parameter to limit the access to kexec", v6.

Add two parameter to specify how many times a kexec kernel can be loaded.

These parameter allow hardening the system.

While we are at it, fix a documentation issue and refactor some code.


This patch (of 3):

kexec_load_disabled affects both ``kexec_load`` and ``kexec_file_load``
syscalls. Make it explicit.

Link: https://lkml.kernel.org/r/20221114-disable-kexec-reset-v6-0-6a8531a09b9a@chromium.org
Link: https://lkml.kernel.org/r/20221114-disable-kexec-reset-v6-1-6a8531a09b9a@chromium.org
Signed-off-by: Ricardo Ribalda &lt;ribalda@chromium.org&gt;
Reviewed-by: Steven Rostedt (Google) &lt;rostedt@goodmis.org&gt;
Acked-by: Baoquan He &lt;bhe@redhat.com&gt;
Cc: Bagas Sanjaya &lt;bagasdotme@gmail.com&gt;
Cc: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Cc: Guilherme G. Piccoli &lt;gpiccoli@igalia.com&gt;
Cc: Joel Fernandes (Google) &lt;joel@joelfernandes.org&gt;
Cc: Jonathan Corbet &lt;corbet@lwn.net&gt;
Cc: Philipp Rudo &lt;prudo@redhat.com&gt;
Cc: Ross Zwisler &lt;zwisler@kernel.org&gt;
Cc: Sergey Senozhatsky &lt;senozhatsky@chromium.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
</content>
</entry>
</feed>
