[PATCH] doc:lock: remove reference to clever use of read-write lock
Remove the clever example about read-write lock because these type of lock is not reccomended anymore (according to the very same document). So there is no reason to teach cleaver things that people should not do. (and by the way there was a little typo) Signed-off-by: Federico Vaga --- Documentation/locking/spinlocks.rst | 14 +- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/Documentation/locking/spinlocks.rst b/Documentation/locking/spinlocks.rst index e93ec6645238..8053fd4c3544 100644 --- a/Documentation/locking/spinlocks.rst +++ b/Documentation/locking/spinlocks.rst @@ -106,7 +106,7 @@ and on other architectures it can be worse). If you have a case where you have to protect a data structure across several CPU's and you want to use spinlocks you can potentially use -cheaper versions of the spinlocks. IFF you know that the spinlocks are +cheaper versions of the spinlocks. If you know that the spinlocks are never used in interrupt handlers, you can use the non-irq versions:: spin_lock(&lock); @@ -139,18 +139,6 @@ on other CPU's, because an interrupt on another CPU doesn't interrupt the CPU that holds the lock, so the lock-holder can continue and eventually releases the lock). -Note that you can be clever with read-write locks and interrupts. For -example, if you know that the interrupt only ever gets a read-lock, then -you can use a non-irq version of read locks everywhere - because they -don't block on each other (and thus there is no dead-lock wrt interrupts. -But when you do the write-lock, you have to use the irq-safe version. - -For an example of being clever with rw-locks, see the "waitqueue_lock" -handling in kernel/sched/core.c - nothing ever _changes_ a wait-queue from -within an interrupt, they only read the queue in order to know whom to -wake up. So read-locks are safe (which is good: they are very common -indeed), while write-locks need to protect themselves against interrupts. - Linus -- 2.21.0
Re: [PATCH] doc:lock: remove reference to clever use of read-write lock
On Sat, 31 Aug 2019 15:41:16 +0200 Federico Vaga wrote: > several CPU's and you want to use spinlocks you can potentially use > -cheaper versions of the spinlocks. IFF you know that the spinlocks are > +cheaper versions of the spinlocks. If you know that the spinlocks are > never used in interrupt handlers, you can use the non-irq versions:: I suspect that was not actually a typo; "iff" is a way for the mathematically inclined to say "if and only if". jon
[PATCH v2] docs: ftrace: clarify when tracing is disabled by the trace file
The current text could mislead the user into believing that only read() disables tracing. Clarify that any open() call that requests read access disables tracing. Link: https://lkml.kernel.org/r/CAADnVQ+hU6QOC_dPmpjnuv=9g4SQEeaMEMqXOS2WpMj=q=l...@mail.gmail.com Signed-off-by: Peter Wu --- v2: fix typo s/trace_file/trace_pipe/ (spotted by Steven) --- Documentation/trace/ftrace.rst | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst index f60079259669..e3060eedb22d 100644 --- a/Documentation/trace/ftrace.rst +++ b/Documentation/trace/ftrace.rst @@ -125,7 +125,8 @@ of ftrace. Here is a list of some of the key files: This file holds the output of the trace in a human readable format (described below). Note, tracing is temporarily - disabled while this file is being read (opened). + disabled when the file is open for reading. Once all readers + are closed, tracing is re-enabled. trace_pipe: @@ -139,8 +140,9 @@ of ftrace. Here is a list of some of the key files: will not be read again with a sequential read. The "trace" file is static, and if the tracer is not adding more data, it will display the same - information every time it is read. This file will not - disable tracing while being read. + information every time it is read. Unlike the + "trace" file, opening this file for reading will not + temporarily disable tracing. trace_options: @@ -3153,7 +3155,10 @@ different. The trace is live. Note, reading the trace_pipe file will block until more input is -added. +added. This is contrary to the trace file. If any process opened +the trace file for reading, it will actually disable tracing and +prevent new entries from being added. The trace_pipe file does +not have this limitation. trace entries - -- 2.22.0
[PATCH] Ext4 Docs: Add missing bigalloc documentation.
There was a broken link for bigalloc. The page https://ext4.wiki.kernel.org/index.php/Bigalloc was not migrated into the current documentation sources. This patch adds the contents of that missing page into the section for Bigalloc itself. Signed-off-by: Ayush Ranjan --- Please note that I have not included changes from the "Kernel Support" and "E2fsprogs Support" sections of the original page because the comments there seemed outdated. Documentation/filesystems/ext4/bigalloc.rst | 32 ++--- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/Documentation/filesystems/ext4/bigalloc.rst b/Documentation/filesystems/ext4/bigalloc.rst index c6d885575..72075aa60 100644 --- a/Documentation/filesystems/ext4/bigalloc.rst +++ b/Documentation/filesystems/ext4/bigalloc.rst @@ -9,14 +9,26 @@ ext4 code is not prepared to handle the case where the block size exceeds the page size. However, for a filesystem of mostly huge files, it is desirable to be able to allocate disk blocks in units of multiple blocks to reduce both fragmentation and metadata overhead. The -`bigalloc `__ feature provides exactly this ability. The -administrator can set a block cluster size at mkfs time (which is stored -in the s\_log\_cluster\_size field in the superblock); from then on, the -block bitmaps track clusters, not individual blocks. This means that -block groups can be several gigabytes in size (instead of just 128MiB); -however, the minimum allocation unit becomes a cluster, not a block, -even for directories. TaoBao had a patchset to extend the “use units of -clusters instead of blocks” to the extent tree, though it is not clear -where those patches went-- they eventually morphed into “extent tree v2” -but that code has not landed as of May 2015. +bigalloc feature provides exactly this ability. + +The bigalloc feature (EXT4_FEATURE_RO_COMPAT_BIGALLOC) changes ext4 to +use clustered allocation, so that each bit in the ext4 block allocation +bitmap addresses a power of two number of blocks. For example, if the +file system is mainly going to be storing large files in the 4-32 +megabyte range, it might make sense to set a cluster size of 1 megabyte. +This means that each bit in the block allocation bitmap now addresses +256 4k blocks. This shrinks the total size of the block allocation +bitmaps for a 2T file system from 64 megabytes to 256 kilobytes. It also +means that a block group addresses 32 gigabytes instead of 128 megabytes, +also shrinking the amount of file system overhead for metadata. + +The administrator can set a block cluster size at mkfs time (which is +stored in the s\_log\_cluster\_size field in the superblock); from then +on, the block bitmaps track clusters, not individual blocks. This means +that block groups can be several gigabytes in size (instead of just +128MiB); however, the minimum allocation unit becomes a cluster, not a +block, even for directories. TaoBao had a patchset to extend the “use +units of clusters instead of blocks” to the extent tree, though it is +not clear where those patches went-- they eventually morphed into +“extent tree v2” but that code has not landed as of May 2015. -- 2.23.0
Re: [PATCH v2] docs: ftrace: clarify when tracing is disabled by the trace file
On Sat, 31 Aug 2019 16:35:00 +0100 Peter Wu wrote: > The current text could mislead the user into believing that only read() > disables tracing. Clarify that any open() call that requests read access > disables tracing. > > Link: > https://lkml.kernel.org/r/CAADnVQ+hU6QOC_dPmpjnuv=9g4SQEeaMEMqXOS2WpMj=q=l...@mail.gmail.com > Signed-off-by: Peter Wu Acked-by: Steven Rostedt (VMware) Jon care to take this in your tree? Thanks! -- Steve > --- > v2: fix typo s/trace_file/trace_pipe/ (spotted by Steven) > --- > Documentation/trace/ftrace.rst | 13 + > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst > index f60079259669..e3060eedb22d 100644 > --- a/Documentation/trace/ftrace.rst > +++ b/Documentation/trace/ftrace.rst > @@ -125,7 +125,8 @@ of ftrace. Here is a list of some of the key files: > > This file holds the output of the trace in a human > readable format (described below). Note, tracing is temporarily > - disabled while this file is being read (opened). > + disabled when the file is open for reading. Once all readers > + are closed, tracing is re-enabled. > >trace_pipe: > > @@ -139,8 +140,9 @@ of ftrace. Here is a list of some of the key files: > will not be read again with a sequential read. The > "trace" file is static, and if the tracer is not > adding more data, it will display the same > - information every time it is read. This file will not > - disable tracing while being read. > + information every time it is read. Unlike the > + "trace" file, opening this file for reading will not > + temporarily disable tracing. > >trace_options: > > @@ -3153,7 +3155,10 @@ different. The trace is live. > > > Note, reading the trace_pipe file will block until more input is > -added. > +added. This is contrary to the trace file. If any process opened > +the trace file for reading, it will actually disable tracing and > +prevent new entries from being added. The trace_pipe file does > +not have this limitation. > > trace entries > -
[PATCH v3 2/2] kbuild: rename KBUILD_ENABLE_EXTRA_GCC_CHECKS to KBUILD_EXTRA_WARN
KBUILD_ENABLE_EXTRA_GCC_CHECKS started as a switch to add extra warning options for GCC, but now it is a historical misnomer since we use it also for Clang, DTC, and even kernel-doc. Rename it to more sensible, and shorter KBUILD_EXTRA_WARN. For the backward compatibility, KBUILD_ENABLE_EXTRA_GCC_CHECKS is still supported (but not advertised in the documentation). I also fixed up 'make help', and updated the documentation. Signed-off-by: Masahiro Yamada --- Changes in v3: - new patch Changes in v2: None Documentation/kbuild/kbuild.rst | 14 +- Makefile| 2 +- scripts/Makefile.build | 2 +- scripts/Makefile.extrawarn | 13 + scripts/Makefile.lib| 4 ++-- scripts/genksyms/Makefile | 2 +- 6 files changed, 23 insertions(+), 14 deletions(-) diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst index 62f9d86c082c..f1e5dce86af7 100644 --- a/Documentation/kbuild/kbuild.rst +++ b/Documentation/kbuild/kbuild.rst @@ -105,6 +105,15 @@ The output directory can also be specified using "O=...". Setting "O=..." takes precedence over KBUILD_OUTPUT. +KBUILD_EXTRA_WARN +- +Specify the extra build checks. The same value can be assigned by passing +W=... from the command line. + +See `make help` for the list of the supported values. + +Setting "W=..." takes precedence over KBUILD_EXTRA_WARN. + KBUILD_DEBARCH -- For the deb-pkg target, allows overriding the normal heuristics deployed by @@ -241,11 +250,6 @@ To get all available archs you can also specify all. E.g.:: $ make ALLSOURCE_ARCHS=all tags -KBUILD_ENABLE_EXTRA_GCC_CHECKS --- -If enabled over the make command line with "W=1", it turns on additional -gcc -W... options for more extensive build-time checking. - KBUILD_BUILD_TIMESTAMP -- Setting this to a date string overrides the timestamp used in the diff --git a/Makefile b/Makefile index 06e1e21c0f45..016d72eb3ddf 100644 --- a/Makefile +++ b/Makefile @@ -1538,7 +1538,7 @@ help: @echo ' make C=1 [targets] Check re-compiled c source with $$CHECK (sparse by default)' @echo ' make C=2 [targets] Force check of all c source with $$CHECK' @echo ' make RECORDMCOUNT_WARN=1 [targets] Warn about ignored mcount sections' - @echo ' make W=n [targets] Enable extra gcc checks, n=1,2,3 where' + @echo ' make W=n [targets] Enable extra checks, n=1,2,3 where' @echo '1: warnings which may be relevant and do not occur too often' @echo '2: warnings which occur quite often but may still be relevant' @echo '3: more obscure warnings, can most likely be ignored' diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 2a21ca86b720..f72aba64d611 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -85,7 +85,7 @@ else ifeq ($(KBUILD_CHECKSRC),2) cmd_force_checksrc = $(CHECK) $(CHECKFLAGS) $(c_flags) $< endif -ifneq ($(KBUILD_ENABLE_EXTRA_GCC_CHECKS),) +ifneq ($(KBUILD_EXTRA_WARN),) cmd_checkdoc = $(srctree)/scripts/kernel-doc -none $< endif diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn index d226c5fb13e2..53eb7e0c6a5a 100644 --- a/scripts/Makefile.extrawarn +++ b/scripts/Makefile.extrawarn @@ -8,14 +8,19 @@ KBUILD_CFLAGS += $(call cc-disable-warning, packed-not-aligned) +# backward compatibility +KBUILD_EXTRA_WARN ?= $(KBUILD_ENABLE_EXTRA_GCC_CHECKS) + ifeq ("$(origin W)", "command line") - export KBUILD_ENABLE_EXTRA_GCC_CHECKS := $(W) + KBUILD_EXTRA_WARN := $(W) endif +export KBUILD_EXTRA_WARN + # # W=1 - warnings which may be relevant and do not occur too often # -ifneq ($(findstring 1, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)),) +ifneq ($(findstring 1, $(KBUILD_EXTRA_WARN)),) KBUILD_CFLAGS += -Wextra -Wunused -Wno-unused-parameter KBUILD_CFLAGS += -Wmissing-declarations @@ -48,7 +53,7 @@ endif # # W=2 - warnings which occur quite often but may still be relevant # -ifneq ($(findstring 2, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)),) +ifneq ($(findstring 2, $(KBUILD_EXTRA_WARN)),) KBUILD_CFLAGS += -Wcast-align KBUILD_CFLAGS += -Wdisabled-optimization @@ -65,7 +70,7 @@ endif # # W=3 - more obscure warnings, can most likely be ignored # -ifneq ($(findstring 3, $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)),) +ifneq ($(findstring 3, $(KBUILD_EXTRA_WARN)),) KBUILD_CFLAGS += -Wbad-function-cast KBUILD_CFLAGS += -Wcast-qual diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 7ab17712ab24..df83967268ba 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -248,7 +248,7 @@ quiet_cmd_gzip = GZIP$@ DTC ?= $(objtree)/scripts/dtc/dtc # Disable noisy checks by default -ifeq ($(findstring 1,$(KBUILD_ENABLE_EXTRA_GCC_CHECKS)),) +ifeq ($(findstring 1,$(KBUILD_EXTRA_WARN)),) DTC_FLAGS += -Wno-unit_address_vs_reg \