- 08 Mar, 2019 40 commits
-
-
Matt Sealey authored
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/20181127161913.23863-5-dave.rodgman@arm.com Link: http://lkml.kernel.org/r/20190205141950.9058-3-dave.rodgman@arm.comSigned-off-by:
Matt Sealey <matt.sealey@arm.com> Signed-off-by:
Dave Rodgman <dave.rodgman@arm.com> Cc: David S. Miller <davem@davemloft.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Markus F.X.J. Oberhumer <markus@oberhumer.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Nitin Gupta <nitingupta910@gmail.com> Cc: Richard Purdie <rpurdie@openedhand.com> Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> Cc: Sonny Rao <sonnyrao@google.com> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Dave Rodgman authored
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/20190205141950.9058-2-dave.rodgman@arm.comSigned-off-by:
-
Gustavo A. R. Silva authored
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@embeddedorSigned-off-by:
Gustavo A. R. Silva <gustavo@embeddedor.com> Reviewed-by:
-
Mathieu Malaterre authored
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/20190114203608.18218-1-malat@debian.orgSigned-off-by:
Mathieu Malaterre <malat@debian.org> Reviewed-by:
-
David Engraf authored
Use distinct error messages when archive decompression failed. Link: http://lkml.kernel.org/r/20190212075635.7373-1-david.engraf@sysgo.comSigned-off-by:
David Engraf <david.engraf@sysgo.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by:
-
Anders Roxell authored
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. [aryabinin@virtuozzo.com: changelog addition] Link: http://lkml.kernel.org/r/20181217150326.30933-1-anders.roxell@linaro.orgSigned-off-by:
Anders Roxell <anders.roxell@linaro.org> Suggested-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by:
-
Jackie Liu authored
Since commit 1751e8a6 ("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 e262e32d "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, e262e32d 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. [kieran.bingham@ideasonboard.com: add fixes tag, reword commit message] Link: http://lkml.kernel.org/r/20190305103014.25847-1-kieran.bingham@ideasonboard.com Fixes: e262e32d "vfs: Suppress MS_* flag defs within the kernel unless explicitly enabled" Signed-off-by:
Jackie Liu <liuyun01@kylinos.cn> Signed-off-by:
Kieran Bingham <kieran.bingham@ideasonboard.com> Tested-by:
Nick Desaulniers <ndesaulniers@google.com> Tested-by:
-
Elena Reshetova authored
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/1547634429-772-1-git-send-email-elena.reshetova@intel.comSigned-off-by:
Elena Reshetova <elena.reshetova@intel.com> Suggested-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
David Windsor <dwindsor@gmail.com> Reviewed-by:
Hans Liljestrand <ishkamiel@gmail.com> Reviewed-by:
Dmitry Vyukov <dvyukov@google.com> Reviewed-by:
Andrea Parri <andrea.parri@amarulasolutions.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Greg Kroah-Hartman authored
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/20190122152151.16139-46-gregkh@linuxfoundation.orgSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Andrey Ryabinin <aryabinin@virtuozzo.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Anders Roxell <anders.roxell@linaro.org> Signed-off-by:
-
Masahiro Yamada authored
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. [yamada.masahiro@socionext.com: v2] Link: http://lkml.kernel.org/r/1550108893-21226-1-git-send-email-yamada.masahiro@socionext.com Link: http://lkml.kernel.org/r/1549941160-8084-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Alexander Popov <alex.popov@linux.com> Cc: Kees Cook <keescook@chromium.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Richard Guy Briggs <rgb@redhat.com> Signed-off-by:
-
Alexey Brodkin authored
This Kconfig option was removed during v4.19 development in commit 771c0353 ("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/20190128152434.41969-1-abrodkin@synopsys.comSigned-off-by:
Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by:
-
Gustavo A. R. Silva authored
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@embeddedorSigned-off-by:Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by:
-
Christian Brauner authored
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/20190107222700.15954-3-christian@brauner.ioSigned-off-by:
Christian Brauner <christian@brauner.io> Acked-by:
-
Christian Brauner authored
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/20190107222700.15954-2-christian@brauner.ioSigned-off-by:
-
Gustavo A. R. Silva authored
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@embeddedorSigned-off-by:Alexandre Bounine <alex.bou9@gmail.com> Signed-off-by:
-
Dan Carpenter authored
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: b6e8d4aa ("rapidio: add RapidIO channelized messaging driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Johannes Weiner authored
This function can only be called safely from very specific scheduler contexts. Document those. Link: http://lkml.kernel.org/r/20190206150528.31198-1-hannes@cmpxchg.orgSigned-off-by:
Johannes Weiner <hannes@cmpxchg.org> Suggested-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Oleg Nesterov authored
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. [oleg@redhat.com: update comment, per Kees] Link: http://lkml.kernel.org/r/20181112160956.GA28472@redhat.comSigned-off-by:
Oleg Nesterov <oleg@redhat.com> Reported-by:
Ben Woodard <woodard@redhat.com> Reviewed-by:
Michal Hocko <mhocko@suse.com> Acked-by:
-
Vineet Gupta authored
Link: http://lkml.kernel.org/r/1548275584-18096-2-git-send-email-vgupta@synopsys.com Link: http://lkml.kernel.org/g/20150807115710.GA16897@redhat.comSigned-off-by:
Vineet Gupta <vgupta@synopsys.com> Reviewed-by:
Anthony Yznaga <anthony.yznaga@oracle.com> Acked-by:
-
Hou Tao authored
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/20190210094754.56355-1-houtao1@huawei.comSigned-off-by:
Hou Tao <houtao1@huawei.com> Acked-by:
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by:
-
NeilBrown authored
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-netSigned-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
Ian Kent <raven@themaw.net> Signed-off-by:
-
Ian Kent authored
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-netSigned-off-by:
-
Ian Kent authored
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-netSigned-off-by: -
Valdis Kletnieks authored
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/18827.1548750938@turing-police.cc.vt.eduSigned-off-by:Valdis Kletnieks <valdis.kletnieks@vt.edu> Reviewed-by:
-
Alexey Dobriyan authored
Link: http://lkml.kernel.org/r/20190204202830.GC27482@avx2Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Reviewed-by:
-
Alexey Dobriyan authored
[adobriyan@gmail.com: fixup compilation] Link: http://lkml.kernel.org/r/20190205064334.GA2152@avx2 Link: http://lkml.kernel.org/r/20190204202800.GB27482@avx2Signed-off-by:
-
Alexey Dobriyan authored
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@avx2Signed-off-by:
-
Roman Penyaev authored
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/20190103150104.17128-5-rpenyaev@suse.deSigned-off-by:Roman Penyaev <rpenyaev@suse.de> Cc: Davidlohr Bueso <dbueso@suse.de> Cc: Jason Baron <jbaron@akamai.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Signed-off-by:
-
Roman Penyaev authored
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/20190103150104.17128-4-rpenyaev@suse.deSigned-off-by:
-
Roman Penyaev authored
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/20190103150104.17128-2-rpenyaev@suse.deSigned-off-by:Davidlohr Bueso <dbueso@suse.de> Cc: Jason Baron <jbaron@akamai.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Signed-off-by:
-
Joe Perches authored
Warn when any SPDX-License-Identifier: tag is not created on the proper line number. Link: http://lkml.kernel.org/r/9b74ee87f8c1b8fd310e213fcb4994d58610fcb6.camel@perches.comSigned-off-by:
Joe Perches <joe@perches.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: "Enrico Weigelt, metux IT consult" <lkml@metux.net> Signed-off-by:
-
Vadim Bendebury authored
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/20190110224957.25008-1-vbendeb@chromium.orgSigned-off-by:
Vadim Bendebury <vbendeb@chromium.org> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
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/a5e60a2b93e10baf84af063f6c8e56402273105d.camel@perches.comSigned-off-by:
-
Joe Perches authored
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/8b02899853247a2c67669561761f354dd3bd110e.camel@perches.comSigned-off-by:
-
Dan Carpenter authored
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@kadamSigned-off-by:
-
Gustavo A. R. Silva authored
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@embeddedorSigned-off-by: -
Olof Johansson authored
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/20190113183210.56154-1-olof@lixom.netSigned-off-by:
Olof Johansson <olof@lixom.net> Acked-by:
-
Stanislaw Gruszka authored
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/1548686944-11891-1-git-send-email-sgruszka@redhat.com Fixes: 658716d1 ("div64_u64(): improve precision on 32bit platforms") Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Reported-by:
Siarhei Volkau <lis8215@gmail.com> Tested-by:
-
Vineet Gupta authored
| > 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/20150807110955.GH16853@twins.programming.kicks-ass.net Link: http://lkml.kernel.org/r/1548275584-18096-4-git-send-email-vgupta@synopsys.comSigned-off-by:
Peter Zijlstra <peterz@infradead.org> Reviewed-by:
Will Deacon <will.deacon@arm.com> Cc: Miklos Szeredi <mszeredi@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Rasmus Villemoes authored
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/20190212214150.4807-15-linux@rasmusvillemoes.dkSigned-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
Jason Baron <jbaron@akamai.com> Cc: David Sterba <dsterba@suse.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Petr Mladek <pmladek@suse.com> Cc: Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
