[PATCH] docs: process: Remove outdated info about -git patches
As can be seen by clicking around the timeline on web.archive.org[1], there were no -git patches/tarballs on kernel.org since release 3.1. [1]: https://web.archive.org/web/2003073843/http://www.kernel.org/ Signed-off-by: Jonathan Neuschäfer --- Documentation/process/howto.rst | 9 - 1 file changed, 9 deletions(-) diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst index 58b2f46c4f98..00c8ddd2ed2c 100644 --- a/Documentation/process/howto.rst +++ b/Documentation/process/howto.rst @@ -302,15 +302,6 @@ The file :ref:`Documentation/process/stable-kernel-rules.rst
Re: [PATCH v2 1/4] perf-security: document perf_events/Perf resource control
On Thu, 7 Feb 2019, Alexey Budankov wrote: General note: Please stay in the 80 char limit for all of the text. > +The perf_events system call API [2]_ allocates file descriptors for every > configured > +PMU event. Open file descriptors are a per-process accountable resource > governed > +by the RLIMIT_NOFILE [11]_ limit (ulimit -n), which is usually derived from > the login > +shell process. When configuring Perf collection for a long list of events on > a > +large server system, this limit can be easily hit preventing required > monitoring > +configuration. I'd move this sentence into a different paragraph and keep those related to RLIMIT_NOFILE together. > ... RLIMIT_NOFILE limit can be increased on per-user basis modifying > +content of the limits.conf file [12]_ on some systems. On some systems? > Ordinarily, a Perf sampling session > +(perf record) requires an amount of open perf_event file descriptors that is > not > +less than a number of monitored events multiplied by a number of monitored > CPUs. s/a number of/the number of/ The ordinary use case is: perf CMD pile-of-events PROCESS which does not specify the monitored CPUs at all. Then the number of file descriptors is NR_EVENTS * NR_ONLINE_CPUS. > +An amount of memory available to user processes for capturing performance > monitoring The amount ... > +data is governed by the perf_event_mlock_kb [2]_ setting. This perf_event > specific > +resource setting defines overall per-cpu limits of memory allowed for mapping > +by the user processes to execute performance monitoring. The setting > essentially > +extends the RLIMIT_MEMLOCK [11]_ limit, but only for memory regions mapped > specially s/specially/specifically/ > +for capturing monitored performance events and related data. > + > +For example, if a machine has eight cores and perf_event_mlock_kb limit is > set > +to 516 KiB, then a user process is provided with 516 KiB * 8 = 4128 KiB of > memory > +above the RLIMIT_MEMLOCK limit (ulimit -l) for perf_event mmap buffers. In > particular, > +this means that, if the user wants to start two or more performance > monitoring > +processes, the user is required to manually distribute available 4128 KiB > between the distribute the available > +monitoring processes, for example, using the --mmap-pages Perf record mode > option. > +Otherwise, the first started performance monitoring process allocates all > available > +4128 KiB and the other processes will fail to proceed due to the lack of > memory. > + > +RLIMIT_MEMLOCK and perf_event_mlock_kb resource costraints are ignored for constraints. > +processes with the CAP_IPC_LOCK capability. Thus, perf_events/Perf > privileged users what means perf_events/Perf ? > +can be provided with memory above the constraints for perf_events/Perf > performance > +monitoring purpose by providing the Perf executable with CAP_IPC_LOCK > capability. Thanks, tglx
Re: [PATCH 1/2] Provide in-kernel headers for making it easy to extend the kernel
On Fri, Feb 8, 2019 at 6:13 AM Joel Fernandes (Google) wrote: > > Introduce in-kernel headers and other artifacts which are made available > as an archive through proc (/proc/kheaders.txz file). This archive makes > it possible to build kernel modules, run eBPF programs, and other > tracing programs that need to extend the kernel for tracing purposes > without any dependency on the file system having headers and build > artifacts. > > On Android and embedded systems, it is common to switch kernels but not > have kernel headers available on the file system. Raw kernel headers > also cannot be copied into the filesystem like they can be on other > distros, due to licensing and other issues. There's no linux-headers > package on Android. Further once a different kernel is booted, any > headers stored on the file system will no longer be useful. By storing > the headers as a compressed archive within the kernel, we can avoid these > issues that have been a hindrance for a long time. > > The feature is also buildable as a module just in case the user desires > it not being part of the kernel image. This makes it possible to load > and unload the headers on demand. A tracing program, or a kernel module > builder can load the module, do its operations, and then unload the > module to save kernel memory. The total memory needed is 3.8MB. > > The code to read the headers is based on /proc/config.gz code and uses > the same technique to embed the headers. > > To build a module, the below steps have been tested on an x86 machine: > modprobe kheaders > rm -rf $HOME/headers > mkdir -p $HOME/headers > tar -xvf /proc/kheaders.txz -C $HOME/headers >/dev/null > cd my-kernel-module > make -C $HOME/headers M=$(pwd) modules > rmmod kheaders > > Signed-off-by: Joel Fernandes (Google) > --- > Changes since RFC: > Both changes bring size down to 3.8MB: > - use xz for compression > - strip comments except SPDX lines > - Call out the module name in Kconfig > - Also added selftests in second patch to ensure headers are always > working. > > Documentation/dontdiff| 1 + > arch/x86/Makefile | 2 ++ > init/Kconfig | 11 ++ > kernel/.gitignore | 2 ++ > kernel/Makefile | 29 +++ > kernel/kheaders.c | 74 +++ > scripts/gen_ikh_data.sh | 19 ++ > scripts/strip-comments.pl | 8 + > 8 files changed, 146 insertions(+) > create mode 100644 kernel/kheaders.c > create mode 100755 scripts/gen_ikh_data.sh > create mode 100755 scripts/strip-comments.pl > > diff --git a/Documentation/dontdiff b/Documentation/dontdiff > index 2228fcc8e29f..05a2319ee2a2 100644 > --- a/Documentation/dontdiff > +++ b/Documentation/dontdiff > @@ -151,6 +151,7 @@ int8.c > kallsyms > kconfig > keywords.c > +kheaders_data.h* > ksym.c* > ksym.h* > kxgettext > diff --git a/arch/x86/Makefile b/arch/x86/Makefile > index 88398fdf8129..ad176d669da4 100644 > --- a/arch/x86/Makefile > +++ b/arch/x86/Makefile > @@ -240,6 +240,8 @@ archmacros: > ASM_MACRO_FLAGS = -Wa,arch/x86/kernel/macros.s > export ASM_MACRO_FLAGS > KBUILD_CFLAGS += $(ASM_MACRO_FLAGS) > +IKH_EXTRA += arch/x86/kernel/macros.s > +export IKH_EXTRA This does not exist in any of released kernels. See commit 6ac389346e6 > > ### > # Kernel objects > diff --git a/init/Kconfig b/init/Kconfig > index a4112e95724a..b95d769b6098 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -549,6 +549,17 @@ config IKCONFIG_PROC > This option enables access to the kernel configuration file > through /proc/config.gz. > > +config IKHEADERS_PROC > + tristate "Enable kernel header artifacts through /proc/kheaders.txz" > + select BUILD_BIN2C > + depends on PROC_FS > + help > + This option enables access to the kernel header and other artifacts > that > + are generated during the build process. These can be used to build > kernel > + modules, and other in-kernel programs such as those generated by > eBPF > + and systemtap tools. If you build the headers as a module, a module > + called kheaders.ko is built which can be loaded to get access to > them. > + > config LOG_BUF_SHIFT > int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" > range 12 25 > diff --git a/kernel/.gitignore b/kernel/.gitignore > index b3097bde4e9c..6acf71acbdcb 100644 > --- a/kernel/.gitignore > +++ b/kernel/.gitignore > @@ -3,5 +3,7 @@ > # > config_data.h > config_data.gz > +kheaders_data.h > +kheaders_data.txz > timeconst.h > hz.bc > diff --git a/kernel/Makefile b/kernel/Makefile > index 7343b3a9bff0..aa2d3f9b9f49 100644 > --- a/kernel/Makefile > +++ b/kernel/Makefile > @@ -73,6 +73,7 @@ obj-$(CONFIG_UTS_NS) += utsname.o > obj-$(CONFIG_USER_NS) += user_namespace.o > obj-$(CONFIG_PID_NS) += pid_namespace.o > obj-$(CONFIG_IKCONFIG) += configs.o > +obj-$(CONFIG_IKHEADERS_PROC) += kheaders.o > obj-$(CONFIG_SMP) +
[PATCH] Documentation: driver-api: fix dmatest.rst warning
From: Randy Dunlap Fix markup warning: insert a blank line before the hint. Documentation/driver-api/dmaengine/dmatest.rst:63: WARNING: Unexpected indentation. Signed-off-by: Randy Dunlap Cc: Andy Shevchenko Cc: Vinod Koul Cc: dmaeng...@vger.kernel.org --- Documentation/driver-api/dmaengine/dmatest.rst |1 + 1 file changed, 1 insertion(+) --- lnx-50-rc6.orig/Documentation/driver-api/dmaengine/dmatest.rst +++ lnx-50-rc6/Documentation/driver-api/dmaengine/dmatest.rst @@ -59,6 +59,7 @@ parameter, that specific channel is requ is created with the existing parameters. This thread is set as pending and will be executed once run is set to 1. Any parameters set after the thread is created are not applied. + .. hint:: available channel list could be extracted by running the following command::
[PATCH] Documenation: driver-api: fix gpio/board.rst warning
From: Randy Dunlap Fix markup warning: insert a blank line before the list. Documentation/driver-api/gpio/board.rst:209: WARNING: Unexpected indentation. Signed-off-by: Randy Dunlap Cc: Linus Walleij Cc: Bartosz Golaszewski Cc: linux-g...@vger.kernel.org --- Documentation/driver-api/gpio/board.rst |1 + 1 file changed, 1 insertion(+) --- lnx-50-rc6.orig/Documentation/driver-api/gpio/board.rst +++ lnx-50-rc6/Documentation/driver-api/gpio/board.rst @@ -204,6 +204,7 @@ between a caller and a respective .get/s In order to qualify for fast bitmap processing, the array must meet the following requirements: + - pin hardware number of array member 0 must also be 0, - pin hardware numbers of consecutive array members which belong to the same chip as member 0 does must also match their array indexes.
[PATCH] Documentation: fix lg-laptop.rst warnings
From: Randy Dunlap Fix markup warnings by inserting blank lines. Also correct one typo. Documentation/laptops/lg-laptop.rst:2: WARNING: Explicit markup ends without a blank line; unexpected unindent. Documentation/laptops/lg-laptop.rst:16: WARNING: Unexpected indentation. Documentation/laptops/lg-laptop.rst:17: WARNING: Block quote ends without a blank line; unexpected unindent. Signed-off-by: Randy Dunlap Cc: Matan Ziv-Av Cc: platform-driver-...@vger.kernel.org --- Documentation/laptops/lg-laptop.rst |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- lnx-50-rc6.orig/Documentation/laptops/lg-laptop.rst +++ lnx-50-rc6/Documentation/laptops/lg-laptop.rst @@ -1,4 +1,5 @@ .. SPDX-License-Identifier: GPL-2.0+ + LG Gram laptop extra features = @@ -9,6 +10,7 @@ Hotkeys --- The following FN keys are ignored by the kernel without this driver: + - FN-F1 (LG control panel) - Generates F15 - FN-F5 (Touchpad toggle)- Generates F13 - FN-F6 (Airplane mode) - Generates RFKILL @@ -16,7 +18,7 @@ The following FN keys are ignored by the This key also changes keyboard backlight mode. - FN-F9 (Reader mode)- Generates F14 -The rest of the FN key work without a need for a special driver. +The rest of the FN keys work without a need for a special driver. Reader mode
[PATCH] Documentation: fix some freescale dpio-driver.rst warnings
From: Randy Dunlap Fix markup warnings for one list by using correct list syntax. Fix markup warnings for another list by using blank lines before the list. Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst:30: WARNING: Unexpected indentation. Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst:143: WARNING: Unexpected indentation. Signed-off-by: Randy Dunlap Cc: Stuart Yoder Cc: Laurentiu Tudor Cc: Ioana Radulescu Cc: net...@vger.kernel.org Cc: Madalin Bucur --- This still leaves 2 other warnings that I don't yet see how to fix. Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst | 14 +- 1 file changed, 7 insertions(+), 7 deletions(-) --- lnx-50-rc6.orig/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst +++ lnx-50-rc6/Documentation/networking/device_drivers/freescale/dpaa2/dpio-driver.rst @@ -27,11 +27,12 @@ Driver Overview The DPIO driver is bound to DPIO objects discovered on the fsl-mc bus and provides services that: - A) allow other drivers, such as the Ethernet driver, to enqueue and dequeue + + A. allow other drivers, such as the Ethernet driver, to enqueue and dequeue frames for their respective objects - B) allow drivers to register callbacks for data availability notifications + B. allow drivers to register callbacks for data availability notifications when data becomes available on a queue or channel - C) allow drivers to manage hardware buffer pools + C. allow drivers to manage hardware buffer pools The Linux DPIO driver consists of 3 primary components-- DPIO object driver-- fsl-mc driver that manages the DPIO object @@ -140,11 +141,10 @@ QBman portal interface (qbman-portal.c) The qbman-portal component provides APIs to do the low level hardware bit twiddling for operations such as: - -initializing Qman software portals - - -building and sending portal commands - -portal interrupt configuration and processing + - initializing Qman software portals + - building and sending portal commands + - portal interrupt configuration and processing The qbman-portal APIs are not public to other drivers, and are only used by dpio-service.
[PATCH] Documentation: fix vm/slub.rst warning
From: Randy Dunlap Fix markup warning by quoting the '*' character with a backslash. Documentation/vm/slub.rst:71: WARNING: Inline emphasis start-string without end-string. Signed-off-by: Randy Dunlap Cc: Christoph Lameter Cc: Sergey Senozhatsky --- Documentation/vm/slub.rst |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- lnx-50-rc6.orig/Documentation/vm/slub.rst +++ lnx-50-rc6/Documentation/vm/slub.rst @@ -68,7 +68,7 @@ end of the slab name, in order to cover example, here's how you can poison the dentry cache as well as all kmalloc slabs: - slub_debug=P,kmalloc-*,dentry + slub_debug=P,kmalloc-\*,dentry Red zoning and tracking may realign the slab. We can just apply sanity checks to the dentry cache with::
RE: [External] Re: [PATCH v3 0/5] Optimize writecache when using pmem as cache
> From: Mikulas Patocka
> Sent: Monday, February 04, 2019 7:28 PM
> On Thu, 31 Jan 2019, Huaisheng Ye wrote:
>
> > From: Huaisheng Ye
> >
> > This patch set could be used for dm-writecache when use persistent
> > memory as cache data device.
> >
> > Patch 1 and 2 go towards removing unused parameter and codes which
> > actually doesn't really work.
>
> I agree that there is some unused variables and code, but I would let it
> be as it is. The processors can write data to persistent memory either by
> using non-temporal stores (the movnti instruction) or by normal stores
> followed by the clwb instruction.
>
> Currently, the movnti instruction is faster - however, it may be possible
> that with some newer processors, the clwb instruction could be faster -
> and in that case, we need the code that you have removed.
>
> I would like to keep both flush strategies around (movnti and clwb), so
> that we can test how do they perform on various processors.
> Unfortunatelly, some upstream developers hate code with #ifdefs :-(
>
> Note that compiler optimizations already remove the unused parameter and
> the impossible code behind "if (WC_MODE_PMEM(wc)) if (!WC_MODE_PMEM(wc))".
Hi Mikulas,
Thanks for your reply, now I could understand the code flow of dm-writecache
better
than before.
In the process of playing around the code, I found that writecache_flush would
try
to free earlier committed entry with lower seq-count. More seriously is that,
writecache_flush
must check it for all entries which hasn't been committed. That's a lot of work
to do when
there are many entries need to be flushed.
I have a plan for writecache_map to avoid using free entry when the committed
writecache
has been hit. Does it make sense to simple the code flow, especially for saving
additional rb-tree
node insertion and free steps?
Cheers,
Huaisheng Ye
> > Patch 3 and 4 are targeted at solving problem fn ctr failed to work
> > due to invalid magic or version, which is caused by the super block
> > of pmem has messy data stored.
>
> LVM zeros the beginning of new logical volumes, so there should be no
> problem with it. If the user wants to use the writecache target without
> LVM, he should zero the superblock with dd if=/dev/zero of=/dev/pmem0
> bs=4k count=1
>
> Note that other device mapper targets also follow this policy - for
> example see drivers/md/dm-snap-persistent.c:
> if (le32_to_cpu(dh->magic) == 0) {
> *new_snapshot = 1;
> return 0;
> }
>
> if (le32_to_cpu(dh->magic) != SNAP_MAGIC) {
> DMWARN("Invalid or corrupt snapshot");
> r = -ENXIO;
> goto bad;
> }
>
> So, I think there is no need for these patches - dm-writecache just does
> what others targets do.
>
> > Patch 5 is used for getting the status of seq_count.
>
> It may be accepted if other LVM team members find some use for this value.
>
> Mikulas
>
> > Changes Since v2:
> > - seq_count is important for flush operations, output it within
> > status
> > for debugging and analyzing code behavior.
> > [1]: https://lkml.org/lkml/2019/1/3/43
> > [2]: https://lkml.org/lkml/2019/1/9/6
> >
> > Huaisheng Ye (5):
> > dm-writecache: remove unused size to writecache_flush_region
> > dm-writecache: get rid of memory_data flush to writecache_flush_entry
> > dm-writecache: expand pmem_reinit for struct dm_writecache
> > Documentation/device-mapper: add optional parameter reinit
> > dm-writecache: output seq_count within status
> >
> > Documentation/device-mapper/writecache.txt | 4
> > drivers/md/dm-writecache.c | 23 +--
> > 2 files changed, 17 insertions(+), 10 deletions(-)
> >
> > --
> > 1.8.3.1
> >
> >
Re: [PATCH] Documentation: fix vm/slub.rst warning
On Sun, Feb 10, 2019 at 10:34:11PM -0800, Randy Dunlap wrote: > From: Randy Dunlap > > Fix markup warning by quoting the '*' character with a backslash. > > Documentation/vm/slub.rst:71: WARNING: Inline emphasis start-string without > end-string. > > Signed-off-by: Randy Dunlap > Cc: Christoph Lameter > Cc: Sergey Senozhatsky Acked-by: Mike Rapoport > --- > Documentation/vm/slub.rst |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- lnx-50-rc6.orig/Documentation/vm/slub.rst > +++ lnx-50-rc6/Documentation/vm/slub.rst > @@ -68,7 +68,7 @@ end of the slab name, in order to cover > example, here's how you can poison the dentry cache as well as all kmalloc > slabs: > > - slub_debug=P,kmalloc-*,dentry > + slub_debug=P,kmalloc-\*,dentry > > Red zoning and tracking may realign the slab. We can just apply sanity > checks > to the dentry cache with:: > > -- Sincerely yours, Mike.
Re: [PATCH] Documentation: fix vm/slub.rst warning
On (02/11/19 09:35), Mike Rapoport wrote: > On Sun, Feb 10, 2019 at 10:34:11PM -0800, Randy Dunlap wrote: > > From: Randy Dunlap > > > > Fix markup warning by quoting the '*' character with a backslash. > > > > Documentation/vm/slub.rst:71: WARNING: Inline emphasis start-string without > > end-string. > > > > Signed-off-by: Randy Dunlap > > Cc: Christoph Lameter > > Cc: Sergey Senozhatsky > > Acked-by: Mike Rapoport FWIW, Reviewed-by: Sergey Senozhatsky -ss
