Documentation: core-api: Drop :export: for int_log.h

The :export: keyword makes sense only for C-files, where EXPORT_SYMBOL()
might appear. Otherwise kernel-doc may not produce anything out of this

Documentation: core-api: Drop :export: for int_log.h

The :export: keyword makes sense only for C-files, where EXPORT_SYMBOL()
might appear. Otherwise kernel-doc may not produce anything out of this
file.

Reported-by: Stephen Rothwell <[email protected]>
Fixes: f97fa3dcb2db ("lib/math: Move dvb_math.c into lib/math/int_log.c")
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Acked-by: Jonathan Corbet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

lib/math: Move dvb_math.c into lib/math/int_log.c

Some existing and new users may benefit from the intlog2() and
intlog10() APIs, make them wide available.

Reviewed-by: Mauro Carvalho Chehab <mcheh

lib/math: Move dvb_math.c into lib/math/int_log.c

Some existing and new users may benefit from the intlog2() and
intlog10() APIs, make them wide available.

Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Acked-by: Mauro Carvalho Chehab <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

Documentation: core-api: Add error pointer functions to kernel-api

Bring the error pointer functions (e.g. ERR_PTR(), PTR_ERR()) into
the docs build so that they can be cross-referenced elsewhere.

Documentation: core-api: Add error pointer functions to kernel-api

Bring the error pointer functions (e.g. ERR_PTR(), PTR_ERR()) into
the docs build so that they can be cross-referenced elsewhere.

List them as kernel library functions in the kernel-api document.
Nowhere else seems to fit, and they need to go *somewhere*.

Signed-off-by: James Seo <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

rcu: Add more RCU files to kernel-api.rst

Recent changes and additions to RCU have not been reflected in
Documentation/core-api/kernel-api.rst, which makes it harder to find
the kernel-doc headers i

rcu: Add more RCU files to kernel-api.rst

Recent changes and additions to RCU have not been reflected in
Documentation/core-api/kernel-api.rst, which makes it harder to find
the kernel-doc headers in recently added RCU files.

Therefore, add those files.

Signed-off-by: Paul E. McKenney <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Luis Chamberlain <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Liam Beguin <[email protected]>
Cc: <[email protected]>

show more ...

module: add debug stats to help identify memory pressure

Loading modules with finit_module() can end up using vmalloc(), vmap()
and vmalloc() again, for a total of up to 3 separate allocations in th

module: add debug stats to help identify memory pressure

Loading modules with finit_module() can end up using vmalloc(), vmap()
and vmalloc() again, for a total of up to 3 separate allocations in the
worst case for a single module. We always kernel_read*() the module,
that's a vmalloc(). Then vmap() is used for the module decompression,
and if so the last read buffer is freed as we use the now decompressed
module buffer to stuff data into our copy module. The last allocation is
specific to each architectures but pretty much that's generally a series
of vmalloc() calls or a variation of vmalloc to handle ELF sections with
special permissions.

Evaluation with new stress-ng module support [1] with just 100 ops
is proving that you can end up using GiBs of data easily even with all
care we have in the kernel and userspace today in trying to not load modules
which are already loaded. 100 ops seems to resemble the sort of pressure a
system with about 400 CPUs can create on module loading. Although issues
relating to duplicate module requests due to each CPU inucurring a new
module reuest is silly and some of these are being fixed, we currently lack
proper tooling to help diagnose easily what happened, when it happened
and who likely is to blame -- userspace or kernel module autoloading.

Provide an initial set of stats which use debugfs to let us easily scrape
post-boot information about failed loads. This sort of information can
be used on production worklaods to try to optimize *avoiding* redundant
memory pressure using finit_module().

There's a few examples that can be provided:

A 255 vCPU system without the next patch in this series applied:

Startup finished in 19.143s (kernel) + 7.078s (userspace) = 26.221s
graphical.target reached after 6.988s in userspace

And 13.58 GiB of virtual memory space lost due to failed module loading:

root@big ~ # cat /sys/kernel/debug/modules/stats
Mods ever loaded 67
Mods failed on kread 0
Mods failed on decompress 0
Mods failed on becoming 0
Mods failed on load 1411
Total module size 11464704
Total mod text size 4194304
Failed kread bytes 0
Failed decompress bytes 0
Failed becoming bytes 0
Failed kmod bytes 14588526272
Virtual mem wasted bytes 14588526272
Average mod size 171115
Average mod text size 62602
Average fail load bytes 10339140
Duplicate failed modules:
module-name How-many-times Reason
kvm_intel 249 Load
kvm 249 Load
irqbypass 8 Load
crct10dif_pclmul 128 Load
ghash_clmulni_intel 27 Load
sha512_ssse3 50 Load
sha512_generic 200 Load
aesni_intel 249 Load
crypto_simd 41 Load
cryptd 131 Load
evdev 2 Load
serio_raw 1 Load
virtio_pci 3 Load
nvme 3 Load
nvme_core 3 Load
virtio_pci_legacy_dev 3 Load
virtio_pci_modern_dev 3 Load
t10_pi 3 Load
virtio 3 Load
crc32_pclmul 6 Load
crc64_rocksoft 3 Load
crc32c_intel 40 Load
virtio_ring 3 Load
crc64 3 Load

The following screen shot, of a simple 8vcpu 8 GiB KVM guest with the
next patch in this series applied, shows 226.53 MiB are wasted in virtual
memory allocations which due to duplicate module requests during boot.
It also shows an average module memory size of 167.10 KiB and an an
average module .text + .init.text size of 61.13 KiB. The end shows all
modules which were detected as duplicate requests and whether or not
they failed early after just the first kernel_read*() call or late after
we've already allocated the private space for the module in
layout_and_allocate(). A system with module decompression would reveal
more wasted virtual memory space.

We should put effort now into identifying the source of these duplicate
module requests and trimming these down as much possible. Larger systems
will obviously show much more wasted virtual memory allocations.

root@kmod ~ # cat /sys/kernel/debug/modules/stats
Mods ever loaded 67
Mods failed on kread 0
Mods failed on decompress 0
Mods failed on becoming 83
Mods failed on load 16
Total module size 11464704
Total mod text size 4194304
Failed kread bytes 0
Failed decompress bytes 0
Failed becoming bytes 228959096
Failed kmod bytes 8578080
Virtual mem wasted bytes 237537176
Average mod size 171115
Average mod text size 62602
Avg fail becoming bytes 2758544
Average fail load bytes 536130
Duplicate failed modules:
module-name How-many-times Reason
kvm_intel 7 Becoming
kvm 7 Becoming
irqbypass 6 Becoming & Load
crct10dif_pclmul 7 Becoming & Load
ghash_clmulni_intel 7 Becoming & Load
sha512_ssse3 6 Becoming & Load
sha512_generic 7 Becoming & Load
aesni_intel 7 Becoming
crypto_simd 7 Becoming & Load
cryptd 3 Becoming & Load
evdev 1 Becoming
serio_raw 1 Becoming
nvme 3 Becoming
nvme_core 3 Becoming
t10_pi 3 Becoming
virtio_pci 3 Becoming
crc32_pclmul 6 Becoming & Load
crc64_rocksoft 3 Becoming
crc32c_intel 3 Becoming
virtio_pci_modern_dev 2 Becoming
virtio_pci_legacy_dev 1 Becoming
crc64 2 Becoming
virtio 2 Becoming
virtio_ring 2 Becoming

[0] https://github.com/ColinIanKing/stress-ng.git
[1] echo 0 > /proc/sys/vm/oom_dump_tasks
./stress-ng --module 100 --module-name xfs

Signed-off-by: Luis Chamberlain <[email protected]>

show more ...

Documentation: core-api: update kernel-doc reference to kmod.c

Commit d6f819908f8aac ("module: fold usermode helper kmod into modules
directory") moves kmod helper implementation (kmod.c) to kernel/

Documentation: core-api: update kernel-doc reference to kmod.c

Commit d6f819908f8aac ("module: fold usermode helper kmod into modules
directory") moves kmod helper implementation (kmod.c) to kernel/module/
directory but forgets to update its reference on kernel api doc, hence:

WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -sphinx-version 2.4.4 -export ./kernel/kmod.c' failed with return code 2

Update the reference.

Fixes: d6f819908f8aac ("module: fold usermode helper kmod into modules directory")
Reported-by: Stephen Rothwell <[email protected]>
Link: https://lore.kernel.org/linux-next/[email protected]/
Signed-off-by: Bagas Sanjaya <[email protected]>
Reviewed-by: Liam Beguin <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>

show more ...

math64: favor kernel-doc from header files

Fix the kernel-doc markings for div64 functions to point to the header
file instead of the lib/ directory. This avoids having implementation
specific comm

math64: favor kernel-doc from header files

Fix the kernel-doc markings for div64 functions to point to the header
file instead of the lib/ directory. This avoids having implementation
specific comments in generic documentation. Furthermore, given that
some kernel-doc comments are identical, drop them from lib/math64 and
only keep there comments that add implementation details.

Signed-off-by: Liam Beguin <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

string: Rewrite and add more kern-doc for the str*() functions

While there were varying degrees of kern-doc for various str*()-family
functions, many needed updating and clarification, or to just be

string: Rewrite and add more kern-doc for the str*() functions

While there were varying degrees of kern-doc for various str*()-family
functions, many needed updating and clarification, or to just be
entirely written. Update (and relocate) existing kern-doc and add missing
functions, sadly shaking my head at how many times I have written "Do
not use this function". Include the results in the core kernel API doc.

Cc: Bagas Sanjaya <[email protected]>
Cc: Andy Shevchenko <[email protected]>
Cc: Rasmus Villemoes <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: [email protected]
Tested-by: Akira Yokosawa <[email protected]>
Link: https://lore.kernel.org/lkml/[email protected]
Signed-off-by: Kees Cook <[email protected]>

show more ...

overflow: Fix kern-doc markup for functions

Fix the kern-doc markings for several of the overflow helpers and move
their location into the core kernel API documentation, where it belongs
(it's not d

overflow: Fix kern-doc markup for functions

Fix the kern-doc markings for several of the overflow helpers and move
their location into the core kernel API documentation, where it belongs
(it's not driver-specific).

Cc: Jonathan Corbet <[email protected]>
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Akira Yokosawa <[email protected]>
Signed-off-by: Kees Cook <[email protected]>

show more ...

doc: module: update file references

Adjust documents to the file moves made by commit cfc1d277891e ("module:
Move all into module/").

Thanks to Yanteng Si for helping me to update
Documentation/tra

doc: module: update file references

Adjust documents to the file moves made by commit cfc1d277891e ("module:
Move all into module/").

Thanks to Yanteng Si for helping me to update
Documentation/translations/zh_CN/core-api/kernel-api.rst

Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Yanteng Si <[email protected]>
Signed-off-by: Luis Chamberlain <[email protected]>

show more ...

block: Add bio_for_each_folio_all()

Allow callers to iterate over each folio instead of each page. The
bio need not have been constructed using folios originally.

Signed-off-by: Matthew Wilcox (Or

block: Add bio_for_each_folio_all()

Allow callers to iterate over each folio instead of each page. The
bio need not have been constructed using folios originally.

Signed-off-by: Matthew Wilcox (Oracle) <[email protected]>
Reviewed-by: Jens Axboe <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Reviewed-by: Darrick J. Wong <[email protected]>

show more ...

block: remove blk-exec.c

All this code is tightly coupled to the blk-mq core, so move it
there.

Signed-off-by: Christoph Hellwig <[email protected]>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc

block: remove blk-exec.c

All this code is tightly coupled to the blk-mq core, so move it
there.

Signed-off-by: Christoph Hellwig <[email protected]>
Reviewed-by: Johannes Thumshirn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[axboe: remove doc generation for blk-exec.c]
Signed-off-by: Jens Axboe <[email protected]>

show more ...

block: move fs/block_dev.c to block/bdev.c

Move it together with the rest of the block layer.

Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lore.kernel.org/r/20210907141303.1371844-3-

block: move fs/block_dev.c to block/bdev.c

Move it together with the rest of the block layer.

Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe <[email protected]>

show more ...

kernel.h: split out kstrtox() and simple_strtox() to a separate header

kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitti

kernel.h: split out kstrtox() and simple_strtox() to a separate header

kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out kstrtox() and
simple_strtox() helpers.

At the same time convert users in header and lib folders to use new
header. Though for time being include new header back to kernel.h to
avoid twisted indirected includes for existing users.

[[email protected]: fix documentation references]
Link: https://lkml.kernel.org/r/[email protected]

Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Jonathan Cameron <[email protected]>
Cc: Francis Laniel <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Kars Mulder <[email protected]>
Cc: Trond Myklebust <[email protected]>
Cc: Anna Schumaker <[email protected]>
Cc: "J. Bruce Fields" <[email protected]>
Cc: Chuck Lever <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

docs: kernel-api.rst: drop kernel/irq/manage.c kernel-doc tag

This is already included at genericirq.rst. Adding it twice
causes C namespace duplication:

.../Documentation/core-api/kernel-api:237:

docs: kernel-api.rst: drop kernel/irq/manage.c kernel-doc tag

This is already included at genericirq.rst. Adding it twice
causes C namespace duplication:

.../Documentation/core-api/kernel-api:237: ../kernel/irq/manage.c:100: WARNING: Duplicate C declaration, also defined in 'genericirq'.
Declaration is 'synchronize_hardirq'.
.../Documentation/core-api/kernel-api:237: ../kernel/irq/manage.c:128: WARNING: Duplicate C declaration, also defined in 'genericirq'.
Declaration is 'synchronize_irq'.
.../Documentation/core-api/kernel-api:237: ../kernel/irq/manage.c:443: WARNING: Duplicate C declaration, also defined in 'genericirq'.
Declaration is 'irq_set_affinity_notifier'.
...

Signed-off-by: Mauro Carvalho Chehab <[email protected]>

show more ...

docs/core-api: Remove possibly confusing sub-headings from Bit Operations

The recent commit 81d2c6f81996 ("kasan: support instrumented bitops
combined with generic bitops"), split the KASAN instrume

docs/core-api: Remove possibly confusing sub-headings from Bit Operations

The recent commit 81d2c6f81996 ("kasan: support instrumented bitops
combined with generic bitops"), split the KASAN instrumented bitops
into separate headers for atomic, non-atomic and locking operations.

This was done to allow arches to include just the instrumented bitops
they need, while also using some of the generic bitops in
asm-generic/bitops (which are automatically instrumented). The generic
bitops are already split into atomic, non-atomic and locking headers.

This split required an update to kernel-api.rst because it included
include/asm-generic/bitops-instrumented.h, which no longer exists. So
now kernel-api.rst includes all three instrumented headers to get the
definitions for all the bitops.

When adding the three headers it seemed sensible to add sub-headings
for each, ie. "Atomic", "Non-atomic" and "Locking".

The confusion is that test_bit() is (and always has been) in
non-atomic.h, but is documented elsewhere (atomic_bitops.txt) as being
atomic. So having it appear under the "Non-atomic" heading is possibly
confusing.

Probably test_bit() should move from bitops/non-atomic.h to atomic.h,
but that has flow on effects. For now just remove the newly added
sub-headings in the documentation, so we at least aren't adding to the
confusion about whether test_bit() is atomic or not.

Signed-off-by: Michael Ellerman <[email protected]>

show more ...

kasan: support instrumented bitops combined with generic bitops

Currently bitops-instrumented.h assumes that the architecture provides
atomic, non-atomic and locking bitops (e.g. both set_bit and __

kasan: support instrumented bitops combined with generic bitops

Currently bitops-instrumented.h assumes that the architecture provides
atomic, non-atomic and locking bitops (e.g. both set_bit and __set_bit).
This is true on x86 and s390, but is not always true: there is a
generic bitops/non-atomic.h header that provides generic non-atomic
operations, and also a generic bitops/lock.h for locking operations.

powerpc uses the generic non-atomic version, so it does not have it's
own e.g. __set_bit that could be renamed arch___set_bit.

Split up bitops-instrumented.h to mirror the atomic/non-atomic/lock
split. This allows arches to only include the headers where they
have arch-specific versions to rename. Update x86 and s390.

(The generic operations are automatically instrumented because they're
written in C, not asm.)

Suggested-by: Christophe Leroy <[email protected]>
Reviewed-by: Christophe Leroy <[email protected]>
Signed-off-by: Daniel Axtens <[email protected]>
Acked-by: Marco Elver <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

kernel-doc: core-api: include string.h into core-api

core-api should show all the various string functions including the newly
added stracpy and stracpy_pad.

Miscellanea:

o Update the Returns: val

kernel-doc: core-api: include string.h into core-api

core-api should show all the various string functions including the newly
added stracpy and stracpy_pad.

Miscellanea:

o Update the Returns: value for strscpy
o fix a defect with %NUL)

[[email protected]: correct return of -E2BIG descriptions]
Link: http://lkml.kernel.org/r/29f998b4c1a9d69fbeae70500ba0daa4b340c546.1563889130.git.joe@perches.com
Link: http://lkml.kernel.org/r/224a6ebf39955f4107c0c376d66155d970e46733.1563841972.git.joe@perches.com
Signed-off-by: Joe Perches <[email protected]>
Reviewed-by: Kees Cook <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Stephen Kitt <[email protected]>
Cc: Nitin Gote <[email protected]>
Cc: Rasmus Villemoes <[email protected]>
Cc: Jann Horn <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

asm-generic, x86: add bitops instrumentation for KASAN

This adds a new header to asm-generic to allow optionally instrumenting
architecture-specific asm implementations of bitops.

This change inclu

asm-generic, x86: add bitops instrumentation for KASAN

This adds a new header to asm-generic to allow optionally instrumenting
architecture-specific asm implementations of bitops.

This change includes the required change for x86 as reference and
changes the kernel API doc to point to bitops-instrumented.h instead.
Rationale: the functions in x86's bitops.h are no longer the kernel API
functions, but instead the arch_ prefixed functions, which are then
instrumented via bitops-instrumented.h.

Other architectures can similarly add support for asm implementations of
bitops.

The documentation text was derived from x86 and existing bitops
asm-generic versions: 1) references to x86 have been removed; 2) as a
result, some of the text had to be reworded for clarity and consistency.

Tested using lib/test_kasan with bitops tests (pre-requisite patch).
Bugzilla ref: https://bugzilla.kernel.org/show_bug.cgi?id=198439

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Marco Elver <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Reviewed-by: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Cc: Andrey Konovalov <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Peter Zijlstra (Intel) <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

docs/core-api: Add integer power functions to the list

Some times integer power functions, such as int_sqrt(), are needed, but
there is nothing about them in the generated documentation.

Fill the g

docs/core-api: Add integer power functions to the list

Some times integer power functions, such as int_sqrt(), are needed, but
there is nothing about them in the generated documentation.

Fill the gap by adding a reference to the corresponding exported functions.

Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mike Rapoport <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

docs/core-api: Add string helpers API to the list

Some times string helpers are needed, but there is nothing about them
in the generated documentation.

Fill the gap by adding a reference to string_

docs/core-api: Add string helpers API to the list

Some times string helpers are needed, but there is nothing about them
in the generated documentation.

Fill the gap by adding a reference to string_helpers.c exported functions.

Signed-off-by: Andy Shevchenko <[email protected]>
Acked-by: Mike Rapoport <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

docs: Do not seek comments in kernel/rcu/tree_plugin.h

There are no kerneldoc comments in this file, so do not attempt to
include them in the docs build.

Signed-off-by: Jonathan Corbet <corbet@lwn.

docs: Do not seek comments in kernel/rcu/tree_plugin.h

There are no kerneldoc comments in this file, so do not attempt to
include them in the docs build.

Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

lib: Move mathematic helpers to separate folder

For better maintenance and expansion move the mathematic helpers to the
separate folder.

No functional change intended.

Note, the int_sqrt() is not

lib: Move mathematic helpers to separate folder

For better maintenance and expansion move the mathematic helpers to the
separate folder.

No functional change intended.

Note, the int_sqrt() is not used as a part of lib, so, moved to regular
obj.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Daniel Thompson <[email protected]>
Cc: Ray Jui <[email protected]>
[[email protected]: fix broken doc references for div64.c and gcd.c]
Link: http://lkml.kernel.org/r/734f49bae5d4052b3c25691dfefad59bea2e5843.1555580999.git.mchehab+samsung@kernel.org
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

docs: don't try to get comments from rcupdate_wait.h or rcutree.h

Neither file contains any kerneldoc comments, so including them generates
these warnings in the docs build:

./include/linux/rcupd

docs: don't try to get comments from rcupdate_wait.h or rcutree.h

Neither file contains any kerneldoc comments, so including them generates
these warnings in the docs build:

./include/linux/rcupdate_wait.h:1: warning: no structured comments found
./include/linux/rcutree.h:1: warning: no structured comments found

Remove them and make life a little quieter.

Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

Docs/kernel-api.rst: Remove blk-tag.c reference

After 7ca01926463a, legacy rq tagging was removed, so block/blk-tag.c
does not exists anymore. When generating pdfdocs, sphinx complains about
this mi

Docs/kernel-api.rst: Remove blk-tag.c reference

After 7ca01926463a, legacy rq tagging was removed, so block/blk-tag.c
does not exists anymore. When generating pdfdocs, sphinx complains about
this missing file:

Error: Cannot open file ./block/blk-tag.c
Error: Cannot open file ./block/blk-tag.c
Error: Cannot open file ./block/blk-tag.c
Error: Cannot open file ./block/blk-tag.c

So remove blk-tag.c traces from kernel-api.rst file to silence these
warnings.

Signed-off-by: Marcos Paulo de Souza <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...