| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
LZO leaves some performance on the table by not realising that arm64 can
optimize count-trailing-zeros bit operations.
Add CONFIG_ARM64 to the checked definitions alongside CONFIG_X86_64 to
enable the use of rbit/clz instructions on full 64-bit quantities.
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Matt Sealey <[email protected]>
Signed-off-by: Dave Rodgman <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: Markus F.X.J. Oberhumer <[email protected]>
Cc: Minchan Kim <[email protected]>
Cc: Nitin Gupta <[email protected]>
Cc: Richard Purdie <[email protected]>
Cc: Sergey Senozhatsky <[email protected]>
Cc: Sonny Rao <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Patch series "lib/lzo: performance improvements", v5.
This patch (of 3):
Modify the ifdefs in lzodefs.h to be more consistent with normal kernel
macros (e.g., change __aarch64__ to CONFIG_ARM64).
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Dave Rodgman <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: David S. Miller <[email protected]>
Cc: Nitin Gupta <[email protected]>
Cc: Richard Purdie <[email protected]>
Cc: Markus F.X.J. Oberhumer <[email protected]>
Cc: Minchan Kim <[email protected]>
Cc: Sergey Senozhatsky <[email protected]>
Cc: Sonny Rao <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Matt Sealey <[email protected]>
Cc: Stephen Rothwell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Use kvzalloc() instead of kvmalloc() and memset().
Also, make use of the struct_size() helper instead of the open-coded
version in order to avoid any potential type mistakes.
This code was detected with the help of Coccinelle.
Link: http://lkml.kernel.org/r/20190131214221.GA28930@embeddedor
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: Manfred Spraul <[email protected]>
Cc: Kees Cook <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
There is a plan to build the kernel with -Wimplicit-fallthrough and this
place in the code produced a warning (W=1).
This commit remove the following warning:
ipc/sem.c:1683:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Mathieu Malaterre <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Use distinct error messages when archive decompression failed.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: David Engraf <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Tested-by: Andy Shevchenko <[email protected]>
Cc: Dominik Brodowski <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Philippe Ombredanne <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Luc Van Oostenryck <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
When booting an allmodconfig kernel, there are a lot of false-positives.
With a message like this 'UBSAN: Undefined behaviour in...' with a call
trace that follows.
UBSAN warnings are a result of enabling noisy CONFIG_UBSAN_ALIGNMENT
which is disabled by default if HAVE_EFFICIENT_UNALIGNED_ACCESS=y.
It's noisy even if don't have efficient unaligned access, e.g. people
often add __cacheline_aligned_in_smp in structs, but forget to align
allocations of such struct (kmalloc() give 8-byte alignment in worst
case).
Rework so that when building a allmodconfig kernel that turns everything
into '=m' or '=y' will turn off UBSAN_ALIGNMENT.
[[email protected]: changelog addition]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Anders Roxell <[email protected]>
Suggested-by: Arnd Bergmann <[email protected]>
Acked-by: Andrey Ryabinin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Since commit 1751e8a6cb93 ("Rename superblock flags (MS_xyz ->
SB_xyz)"), scripts/gdb should be updated to replace MS_xyz with SB_xyz.
This change didn't directly affect the running operation of scripts/gdb
until commit e262e32d6bde "vfs: Suppress MS_* flag defs within the
kernel unless explicitly enabled" removed the definitions used by
constants.py.
Update constants.py.in to utilise the new internal flags, matching the
implementation at fs/proc_namespace.c::show_sb_opts.
Note to stable, e262e32d6bde landed in v5.0-rc1 (which was just
released), so we'll want this picked back to 5.0 stable once this patch
hits mainline (akpm just picked it up). Without this, debugging a
kernel a kernel via GDB+QEMU is broken in the 5.0 release.
[[email protected]: add fixes tag, reword commit message]
Link: http://lkml.kernel.org/r/[email protected]
Fixes: e262e32d6bde "vfs: Suppress MS_* flag defs within the kernel unless explicitly enabled"
Signed-off-by: Jackie Liu <[email protected]>
Signed-off-by: Kieran Bingham <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
Tested-by: Kieran Bingham <[email protected]>
Cc: Felipe Balbi <[email protected]>
Cc: Dan Robertson <[email protected]>
Cc: Jan Kiszka <[email protected]>
Cc: David Howells <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basic atomic operations
(set, inc, inc_not_zero, dec_and_test, etc.)
Such atomic variables should be converted to a newly provided refcount_t
type and API that prevents accidental counter overflows and underflows.
This is important since overflows and underflows can lead to
use-after-free situation and be exploitable.
The variable kcov.refcount is used as pure reference counter. Convert
it to refcount_t and fix up the operations.
**Important note for maintainers:
Some functions from refcount_t API defined in lib/refcount.c have
different memory ordering guarantees than their atomic counterparts.
The full comparison can be seen in https://lkml.org/lkml/2017/11/15/57
and it is hopefully soon in state to be merged to the documentation
tree. Normally the differences should not matter since refcount_t
provides enough guarantees to satisfy the refcounting use cases, but in
some rare cases it might matter. Please double check that you don't
have some undocumented memory guarantees for this variable usage.
For the kcov.refcount it might make a difference
in following places:
- kcov_put(): decrement in refcount_dec_and_test() only
provides RELEASE ordering and control dependency on success
vs. fully ordered atomic counterpart
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Elena Reshetova <[email protected]>
Suggested-by: Kees Cook <[email protected]>
Reviewed-by: David Windsor <[email protected]>
Reviewed-by: Hans Liljestrand <[email protected]>
Reviewed-by: Dmitry Vyukov <[email protected]>
Reviewed-by: Andrea Parri <[email protected]>
Cc: Mark Rutland <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: "Steven Rostedt (VMware)" <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: Anders Roxell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
This slightly optimizes the kernel/configs.c build.
bin2c is not very efficient because it converts a data file into a huge
array to embed it into a *.c file.
Instead, we can use the .incbin directive.
Also, this simplifies the code; Makefile is cleaner, and the way to get
the offset/size of the config_data.gz is more straightforward.
I used the "asm" statement in *.c instead of splitting it into *.S
because MODULE_* tags are not supported in *.S files.
I also cleaned up kernel/.gitignore; "config_data.gz" is unneeded
because the top-level .gitignore takes care of the "*.gz" pattern.
[[email protected]: v2]
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Masahiro Yamada <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Alexander Popov <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Dan Williams <[email protected]>
Cc: Mathieu Desnoyers <[email protected]>
Cc: Richard Guy Briggs <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
This Kconfig option was removed during v4.19 development in commit
771c035372a0 ("deprecate the '__deprecated' attribute warnings entirely
and for good") so there's no point to keep it in defconfigs any longer.
FWIW defconfigs were patched with:
--------------------------->8----------------------
find . -name *_defconfig -exec sed -i '/CONFIG_ENABLE_WARN_DEPRECATED/d' {} \;
--------------------------->8----------------------
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Alexey Brodkin <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
One of the more common cases of allocation size calculations is finding
the size of a structure that has a zero-sized array at the end, along
with memory for some number of elements for that array. For example:
struct foo {
int stuff;
void *entry[];
};
instance = kzalloc(sizeof(struct foo) + sizeof(void *) * count, GFP_KERNEL);
Instead of leaving these open-coded and prone to type mistakes, we can
now use the new struct_size() helper:
instance = kzalloc(struct_size(instance, entry, count), GFP_KERNEL);
This code was detected with the help of Coccinelle.
Link: http://lkml.kernel.org/r/20190109172445.GA15908@embeddedor
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Reviewed-by: Peter Oberparleiter <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Currently, when writing
echo 18446744073709551616 > /proc/sys/fs/file-max
/proc/sys/fs/file-max will overflow and be set to 0. That quickly
crashes the system.
This commit sets the max and min value for file-max. The max value is
set to long int. Any higher value cannot currently be used as the
percpu counters are long ints and not unsigned integers.
Note that the file-max value is ultimately parsed via
__do_proc_doulongvec_minmax(). This function does not report error when
min or max are exceeded. Which means if a value largen that long int is
written userspace will not receive an error instead the old value will be
kept. There is an argument to be made that this should be changed and
__do_proc_doulongvec_minmax() should return an error when a dedicated min
or max value are exceeded. However this has the potential to break
userspace so let's defer this to an RFC patch.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Christian Brauner <[email protected]>
Acked-by: Kees Cook <[email protected]>
Cc: Alexey Dobriyan <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Dominik Brodowski <[email protected]>
Cc: "Eric W. Biederman" <[email protected]>
Cc: Joe Lawrence <[email protected]>
Cc: Luis Chamberlain <[email protected]>
Cc: Waiman Long <[email protected]>
[[email protected]: v4]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
proc_get_long() is a funny function. It uses simple_strtoul() and for a
good reason. proc_get_long() wants to always succeed the parse and
return the maybe incorrect value and the trailing characters to check
against a pre-defined list of acceptable trailing values. However,
simple_strtoul() explicitly ignores overflows which can cause funny
things like the following to happen:
echo 18446744073709551616 > /proc/sys/fs/file-max
cat /proc/sys/fs/file-max
0
(Which will cause your system to silently die behind your back.)
On the other hand kstrtoul() does do overflow detection but does not
return the trailing characters, and also fails the parse when anything
other than '\n' is a trailing character whereas proc_get_long() wants to
be more lenient.
Now, before adding another kstrtoul() function let's simply add a static
parse strtoul_lenient() which:
- fails on overflow with -ERANGE
- returns the trailing characters to the caller
The reason why we should fail on ERANGE is that we already do a partial
fail on overflow right now. Namely, when the TMPBUFLEN is exceeded. So
we already reject values such as 184467440737095516160 (21 chars) but
accept values such as 18446744073709551616 (20 chars) but both are
overflows. So we should just always reject 64bit overflows and not
special-case this based on the number of chars.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Christian Brauner <[email protected]>
Acked-by: Kees Cook <[email protected]>
Cc: "Eric W. Biederman" <[email protected]>
Cc: Luis Chamberlain <[email protected]>
Cc: Joe Lawrence <[email protected]>
Cc: Waiman Long <[email protected]>
Cc: Dominik Brodowski <[email protected]>
Cc: Al Viro <[email protected]>
Cc: Alexey Dobriyan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
In preparation for enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warning:
drivers/rapidio/devices/rio_mport_cdev.c: In function `mport_release_mapping':
drivers/rapidio/devices/rio_mport_cdev.c:2151:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
rio_unmap_inb_region(mport, map->phys_addr);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC drivers/regulator/fixed-helper.o
CC drivers/pinctrl/stm32/pinctrl-stm32f429.o
drivers/rapidio/devices/rio_mport_cdev.c:2152:2: note: here
case MAP_DMA:
^~~~
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enable
-Wimplicit-fallthrough.
Link: http://lkml.kernel.org/r/20190212175014.GA14326@embeddedor
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Acked-by: Alexandre Bounine <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
If riocm_get_channel() fails, then we should just return -EINVAL.
Calling riocm_put_channel() will trigger a NULL dereference and
generally we should call put() if the get() didn't succeed.
Link: http://lkml.kernel.org/r/20190110130230.GB27017@kadam
Fixes: b6e8d4aa1110 ("rapidio: add RapidIO channelized messaging driver")
Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: Matt Porter <[email protected]>
Cc: Alexandre Bounine <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
This function can only be called safely from very specific scheduler
contexts. Document those.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Johannes Weiner <[email protected]>
Suggested-by: Andrew Morton <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Large enterprise clients often run applications out of networked file
systems where the IT mandated layout of project volumes can end up
leading to paths that are longer than 128 characters. Bumping this up
to the next order of two solves this problem in all but the most
egregious case while still fitting into a 512b slab.
[[email protected]: update comment, per Kees]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Oleg Nesterov <[email protected]>
Reported-by: Ben Woodard <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Acked-by: Kees Cook <[email protected]>
Cc: "Eric W. Biederman" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/g/[email protected]
Signed-off-by: Vineet Gupta <[email protected]>
Reviewed-by: Anthony Yznaga <[email protected]>
Acked-by: Oleg Nesterov <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Peter Zijlstra (Intel) <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Miklos Szeredi <[email protected]>
Cc: Theodore Ts'o <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Now splice() on O_DIRECT-opened fat file will return -EFAULT, that is
because the default .splice_write, namely default_file_splice_write(),
will construct an ITER_KVEC iov_iter and dio_refill_pages() in dio path
can not handle it.
Fix it by implementing .splice_write through iter_file_splice_write().
Spotted by xfs-tests generic/091.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Hou Tao <[email protected]>
Acked-by: OGAWA Hirofumi <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
autofs does not expect the pipe it is given to have O_NONBLOCK set -
specifically if __kernel_write() in autofs_write() returns -EAGAIN, this
is treated as a fatal error and the pipe is closed.
For safety autofs should, therefore, clear the O_NONBLOCK flag.
Releases of systemd prior to 8th February 2019 used
pipe2(p, O_NONBLOCK|O_CLOEXEC)
and thus (inadvertently) set this flag.
Link: http://lkml.kernel.org/r/154993550902.3321.1183632970046073478.stgit@pluto-themaw-net
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Ian Kent <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Fix checkpatch.sh WARNING about the use of seq_printf() to print simple
strings in autofs_show_options(), use seq_puts() in this case.
Link: http://lkml.kernel.org/r/154889012613.4863.12231175554744203482.stgit@pluto-themaw-net
Signed-off-by: Ian Kent <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Add an autofs file system mount option that can be used to provide a
generic indicator to applications that the mount entry should be ignored
when displaying mount information.
In other OSes that provide autofs and that provide a mount list to user
space based on the kernel mount list a no-op mount option ("ignore" is
the one use on the most common OS) is allowed so that autofs file system
users can optionally use it.
The idea is that it be used by user space programs to exclude autofs
mounts from consideration when reading the mounts list.
Prior to the change to link /etc/mtab to /proc/self/mounts all I needed
to do to achieve this was to use mount(2) and not update the mtab but
now that no longer works.
I know the symlinking happened a long time ago and I considered doing
this then but, at the time I couldn't remember the commonly used option
name and thought persuading the various utility maintainers would be too
hard.
But now I have a RHEL request to do this for compatibility for a widely
used product so I want to go ahead with it and try and enlist the help
of some utility package maintainers.
Clearly, without the option nothing can be done so it's at least a
start.
Link: http://lkml.kernel.org/r/154725123970.11260.6113771566924907275.stgit@pluto-themaw-net
Signed-off-by: Ian Kent <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Sparse issues a warning:
CHECK init/calibrate.c
init/calibrate.c:271:28: warning: symbol 'calibration_delay_done' was not declared. Should it be static?
The actual issue is that it's a __weak symbol that archs can override
(in fact, ARM does so), but no prototype is provided. Let's provide one
to prevent surprises.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Valdis Kletnieks <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Link: http://lkml.kernel.org/r/20190204202830.GC27482@avx2
Signed-off-by: Alexey Dobriyan <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
[[email protected]: fixup compilation]
Link: http://lkml.kernel.org/r/20190205064334.GA2152@avx2
Link: http://lkml.kernel.org/r/20190204202800.GB27482@avx2
Signed-off-by: Alexey Dobriyan <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Number of ELF program headers is 16-bit by spec, so total size
comfortably fits into "unsigned int".
Space savings: 7 bytes!
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-7 (-7)
Function old new delta
load_elf_phdrs 137 130 -7
Link: http://lkml.kernel.org/r/20190204202715.GA27482@avx2
Signed-off-by: Alexey Dobriyan <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The goal of this patch is to reduce contention of ep_poll_callback()
which can be called concurrently from different CPUs in case of high
events rates and many fds per epoll. Problem can be very well
reproduced by generating events (write to pipe or eventfd) from many
threads, while consumer thread does polling. In other words this patch
increases the bandwidth of events which can be delivered from sources to
the poller by adding poll items in a lockless way to the list.
The main change is in replacement of the spinlock with a rwlock, which
is taken on read in ep_poll_callback(), and then by adding poll items to
the tail of the list using xchg atomic instruction. Write lock is taken
everywhere else in order to stop list modifications and guarantee that
list updates are fully completed (I assume that write side of a rwlock
does not starve, it seems qrwlock implementation has these guarantees).
The following are some microbenchmark results based on the test [1]
which starts threads which generate N events each. The test ends when
all events are successfully fetched by the poller thread:
spinlock
========
threads events/ms run-time ms
8 6402 12495
16 7045 22709
32 7395 43268
rwlock + xchg
=============
threads events/ms run-time ms
8 10038 7969
16 12178 13138
32 13223 24199
According to the results bandwidth of delivered events is significantly
increased, thus execution time is reduced.
This patch was tested with different sort of microbenchmarks and
artificial delays (e.g. "udelay(get_random_int() & 0xff)") introduced
in kernel on paths where items are added to lists.
[1] https://github.com/rouming/test-tools/blob/master/stress-epoll.c
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Roman Penyaev <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: Jason Baron <[email protected]>
Cc: Al Viro <[email protected]>
Cc: "Paul E. McKenney" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Original comment "Activate ep->ws since epi->ws may get deactivated at
any time" indeed sounds loud, but it is incorrect, because the path
where we check epi->ws is a path where insert to ovflist happens, i.e.
ep_scan_ready_list() has taken ep->mtx and waits for this callback to
finish, thus ep_modify() (which unregisters wakeup source) waits for
ep_scan_ready_list().
Here in this patch I simply call ep_pm_stay_awake_rcu(), which is a bit
extra for this path (indirectly protected by main ep->mtx, so even rcu
is not needed), but I do not want to create another naked
__ep_pm_stay_awake() variant only for this particular case, so rcu variant
is just better for all the cases.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Roman Penyaev <[email protected]>
Cc: Davidlohr Bueso <[email protected]>
Cc: Jason Baron <[email protected]>
Cc: Al Viro <[email protected]>
Cc: "Paul E. McKenney" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Patch series "use rwlock in order to reduce ep_poll_callback()
contention", v3.
The last patch targets the contention problem in ep_poll_callback(),
which can be very well reproduced by generating events (write to pipe or
eventfd) from many threads, while consumer thread does polling.
The following are some microbenchmark results based on the test [1]
which starts threads which generate N events each. The test ends when
all events are successfully fetched by the poller thread:
spinlock
========
threads events/ms run-time ms
8 6402 12495
16 7045 22709
32 7395 43268
rwlock + xchg
=============
threads events/ms run-time ms
8 10038 7969
16 12178 13138
32 13223 24199
According to the results bandwidth of delivered events is significantly
increased, thus execution time is reduced.
This patch (of 4):
All coming events are stored in FIFO order and this is also should be
applicable to ->ovflist, which originally is stack, i.e. LIFO.
Thus to keep correct FIFO order ->ovflist should reversed by adding
elements to the head of the read list but not to the tail.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Roman Penyaev <[email protected]>
Reviewed-by: Davidlohr Bueso <[email protected]>
Cc: Jason Baron <[email protected]>
Cc: Al Viro <[email protected]>
Cc: "Paul E. McKenney" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Warn when any SPDX-License-Identifier: tag is not created on the proper
line number.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Joe Perches <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: "Enrico Weigelt, metux IT consult" <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Presently C99 style comments are removed unconditionally before actual
patch validity check happens. This is a problem for some third party
projects which use checkpatch.pl but do not allow C99 style comments.
This patch adds yet another variable, named C99_COMMENT_TOLERANCE. If
it is included in the --ignore command line or config file options list,
C99 comments in the patch are reported as errors.
Tested by processing a patch with a C99 style comment, it passes the
check just fine unless '--ignore C99_COMMENT_TOLERANCE' is present in
.checkpatch.conf.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Vadim Bendebury <[email protected]>
Cc: Joe Perches <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Many new generic allocation functions like the kvmalloc family have been
added recently to the kernel.
The allocation functions test now includes:
o kvmalloc and variants
o kstrdup_const
o kmemdup_nul
o dma_alloc_coherent
o alloc_skb and variants
Add a separate $allocFunctions variable to help make the allocation
functions test a bit more readable.
Miscellanea:
o Use $allocFunctions in the unnecessary OOM message test and
add exclude uses with __GFP_NOWARN
o Use $allocFunctions in the unnecessary cast test
o Add the kvmalloc family to the preferred sizeof alloc style
foo = kvmalloc(sizeof(*foo), ...)
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Joe Perches <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Using SPDX commenting style // or /* is specified for various file types
in Documentation/process/license-rules.rst so add an appropriate test for
.[chsS] files because many proposed file additions and patches do not use
the correct style.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Joe Perches <[email protected]>
Cc: Rob Herring <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The test_fw_config->reqs allocation succeeded so these addresses can't
be NULL.
Also on the second error path, we forgot to set "rc = -ENOMEM;".
Link: http://lkml.kernel.org/r/20190221183700.GA1737@kadam
Signed-off-by: Dan Carpenter <[email protected]>
Reviewed-by: Andrew Morton <[email protected]>
Cc: "Luis R. Rodriguez" <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warning:
lib/assoc_array.c: In function `assoc_array_delete':
lib/assoc_array.c:1110:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
for (slot = 0; slot < ASSOC_ARRAY_FAN_OUT; slot++) {
^~~
lib/assoc_array.c:1118:2: note: here
case assoc_array_walk_tree_empty:
^~~~
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enable
-Wimplicit-fallthrough.
Link: http://lkml.kernel.org/r/20190212212206.GA16378@embeddedor
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Cc: Kees Cook <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Since we now build with -Wvla, any use of VLA throws a warning.
Including this test, so... maybe we should just remove the test?
lib/test_ubsan.c: In function 'test_ubsan_vla_bound_not_positive':
lib/test_ubsan.c:48:2: warning: ISO C90 forbids variable length array 'buf' [-Wvla]
For the out-of-bounds test, switch to non-VLA setup.
lib/test_ubsan.c: In function 'test_ubsan_out_of_bounds':
lib/test_ubsan.c:64:2: warning: ISO C90 forbids variable length array 'arr' [-Wvla]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Olof Johansson <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Cc: Colin Ian King <[email protected]>
Cc: Jinbum Park <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Kees Cook <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
fls counts bits starting from 1 to 32 (returns 0 for zero argument). If
we add 1 we shift right one bit more and loose precision from divisor,
what cause function incorect results with some numbers.
Corrected code was tested in user-space, see bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=202391
Link: http://lkml.kernel.org/r/[email protected]
Fixes: 658716d19f8f ("div64_u64(): improve precision on 32bit platforms")
Signed-off-by: Stanislaw Gruszka <[email protected]>
Reported-by: Siarhei Volkau <[email protected]>
Tested-by: Siarhei Volkau <[email protected]>
Acked-by: Oleg Nesterov <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
| > Also, set_mask_bits is used in fs quite a bit and we can possibly come up
| > with a generic llsc based implementation (w/o the cmpxchg loop)
|
| May I also suggest changing the return value of set_mask_bits() to old.
|
| You can compute the new value given old, but you cannot compute the old
| value given new, therefore old is the better return value. Also, no
| current user seems to use the return value, so changing it is without
| risk.
Link: http://lkml.kernel.org/g/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Vineet Gupta <[email protected]>
Suggested-by: Peter Zijlstra <[email protected]>
Reviewed-by: Anthony Yznaga <[email protected]>
Acked-by: Will Deacon <[email protected]>
Cc: Miklos Szeredi <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Alexander Viro <[email protected]>
Cc: Oleg Nesterov <[email protected]>
Cc: Theodore Ts'o <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
With coming changes on x86-64, all dynamic debug descriptors in a
translation unit must have distinct names. The macro _dynamic_func_call
takes care of that. No functional change.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Acked-by: Jason Baron <[email protected]>
Cc: David Sterba <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: Steven Rostedt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
If CONFIG_DYNAMIC_DEBUG is not set, acpi_handle_debug directly invokes
acpi_handle_printk (if DEBUG) or does a no-printk (if !DEBUG). So this
macro is never used.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Jason Baron <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Cc: David Sterba <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: Steven Rostedt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
dynamic debug may be implemented via static keys, but ACPI is missing
out on that runtime benefit since it open-codes one possible definition
of DYNAMIC_DEBUG_BRANCH.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Jason Baron <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Cc: David Sterba <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: Steven Rostedt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
First, the btrfs_debug macros open-code (one possible definition of)
DYNAMIC_DEBUG_BRANCH, so they don't benefit from the CONFIG_JUMP_LABEL
optimization.
Second, a planned change of struct _ddebug (to reduce its size on 64 bit
machines) requires that all descriptors in a translation unit use
distinct identifiers.
Using the new _dynamic_func_call_no_desc helper macro from
dynamic_debug.h takes care of both of these. No functional change.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: David Sterba <[email protected]>
Acked-by: Jason Baron <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: "Rafael J . Wysocki" <[email protected]>
Cc: Steven Rostedt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
For the upcoming 'define the _ddebug descriptor in assembly', we need
all the descriptors in a translation unit to have distinct names
(because asm does not understand C scope). The easiest way to achieve
that is as usual with an extra level of macros, passing the identifier
to use to the innermost macro, generating it via __UNIQUE_ID or
something.
However, instead of repeating that exercise for dynamic_pr_debug,
dynamic_dev_dbg, dynamic_netdev_dbg and dynamic_hex_dump separately, we
can use the similarity between their bodies to implement them via a
common macro, _dynamic_func_call - though the hex_dump case requires a
slight variant, since print_hex_dump does not take the _ddebug
descriptor. We'll also get to use that variant elsewhere (btrfs).
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Jason Baron <[email protected]>
Cc: David Sterba <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: "Rafael J . Wysocki" <[email protected]>
Cc: Steven Rostedt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
For symmetry with ddebug_remove_module, and to avoid a bit of ifdeffery
in module.c, move the declaration of ddebug_add_module inside #if
defined(CONFIG_DYNAMIC_DEBUG) and add a corresponding no-op stub in the
#else branch.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Jason Baron <[email protected]>
Cc: David Sterba <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: "Rafael J . Wysocki" <[email protected]>
Cc: Steven Rostedt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
This serves two purposes: First, we get a diagnostic if (though
extremely unlikely), any of the calls of ddebug_add_module for built-in
code fails, effectively disabling dynamic_debug. Second, I want to make
struct _ddebug opaque, and avoid accessing any of its members outside
dynamic_debug.[ch].
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Jason Baron <[email protected]>
Cc: David Sterba <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: "Rafael J . Wysocki" <[email protected]>
Cc: Steven Rostedt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The only caller of ddebug_{add,remove}_module outside dynamic_debug.c is
kernel/module.c, which is obviously not itself modular (though it would
be an interesting exercise to make that happen...). I also fail to see
how these interfaces can be used by modules, in-tree or not.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Jason Baron <[email protected]>
Cc: David Sterba <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: "Rafael J . Wysocki" <[email protected]>
Cc: Steven Rostedt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Now that we store the passed-in string directly in ddebug_add_module, we
can use pointer equality instead of strcmp. This is a little more
efficient, but more importantly, this also makes the code somewhat more
correct:
Currently, if one loads and then unloads a module whose name happens to
match the KBUILD_MODNAME of some built-in functionality (which need not
even be modular at all), all of their dynamic debug entries vanish along
with those of the actual module. For example, loading and unloading a
core.ko hides all pr_debugs from drivers/base/core.c and other built-in
files called core.c (incidentally, there is an in-tree module whose name
is core, but I just tested this with an out-of-tree trivial one).
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Jason Baron <[email protected]>
Cc: David Sterba <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: "Rafael J . Wysocki" <[email protected]>
Cc: Steven Rostedt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
For built-in modules, we're already reusing the passed-in string via
kstrdup_const(). But for actual modules (i.e. when we're called from
dynamic_debug_setup in module.c), the passed-in string (which points at
the name[] array inside struct module) is also guaranteed to live at
least as long as the struct ddebug_table, since free_module() calls
ddebug_remove_module().
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Jason Baron <[email protected]>
Cc: David Sterba <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: "Rafael J . Wysocki" <[email protected]>
Cc: Steven Rostedt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Instead of defining DEFINE_DYNAMIC_DEBUG_METADATA in terms of a helper
DEFINE_DYNAMIC_DEBUG_METADATA_KEY, that needs another helper dd_key_init
to be properly defined, just make the various #ifdef branches define a
_DPRINTK_KEY_INIT that can be used directly, similar to
_DPRINTK_FLAGS_DEFAULT.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Rasmus Villemoes <[email protected]>
Acked-by: Jason Baron <[email protected]>
Cc: David Sterba <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Petr Mladek <[email protected]>
Cc: "Rafael J . Wysocki" <[email protected]>
Cc: Steven Rostedt <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|