- 22 Aug, 2018 40 commits
-
-
Paul Menzel authored
Add a log message to `run_init_process()`. This log message serves two purposes. 1. If the init process is not specified on the Linux Kernel command line, the user sees, what file was chosen. 2. The time stamps shows exactly, when the Linux kernel handed over control to the init process. Link: http://lkml.kernel.org/r/b1fc97fa-4aa9-1904-ddb5-859e78995c41@molgen.mpg.deSigned-off-by:Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Randy Dunlap authored
Correct typos of "it's" to "its. Link: http://lkml.kernel.org/r/0ac627b6-5527-55f4-0489-1631aa34fc11@infradead.orgSigned-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
-
Luc Van Oostenryck authored
Sparse checking used to be disabled on init/do_mounts.c and a few related files because "Many of the syscalls used in this file expect some of the arguments to be __user pointers not __kernel pointers". However since 28128c61 ("kconfig.h: Include compiler types to avoid missed struct attributes") the checks are, in fact, not disabled anymore because of the more early include of "linux/compiler_types.h" So remove the now ineffective #undefery that was done to disable these warnings, as well as the associated comment. Link: http://lkml.kernel.org/r/20180617115355.53799-1-luc.vanoostenryck@gmail.comSigned-off-by:
Luc Van Oostenryck <luc.vanoostenryck@gmail.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
-
Davidlohr Bueso authored
Instead of having each caller pass the rdllink explicitly, just have ep_is_linked() pass it while the callers just need the epi pointer. This helper is all about the rdllink, and this change, furthermore, improves the function's self documentation. Link: http://lkml.kernel.org/r/20180727053432.16679-3-dave@stgolabs.netSigned-off-by:
Davidlohr Bueso <dbueso@suse.de> Reviewed-by:
-
Davidlohr Bueso authored
Similar to other calls, ep_poll() is not called with interrupts disabled, and we can therefore avoid the irq save/restore dance and just disable local irqs. In fact, the call should never be called in irq context at all, considering that the only path is epoll_wait(2) -> do_epoll_wait() -> ep_poll(). When running on a 2 socket 40-core (ht) IvyBridge a common pipe based epoll_wait(2) microbenchmark, the following performance improvements are seen: # threads vanilla dirty 1 1805587 2106412 2 1854064 2090762 4 1805484 2017436 8 1751222 1974475 16 1725299 1962104 32 1378463 1571233 64 787368 900784 Which is a pretty constantly near 15%. Also add a lockdep check such that we detect any mischief before deadlocking. Link: http://lkml.kernel.org/r/20180727053432.16679-2-dave@stgolabs.netSigned-off-by: -
Davidlohr Bueso authored
... 'tis easier on the eye. [akpm@linux-foundation.org: use inlines rather than macros] Link: http://lkml.kernel.org/r/20180725185620.11020-1-dave@stgolabs.netSigned-off-by:
-
Rob Herring authored
Devicetree bindings should be their own patch as documented in Documentation/devicetree/bindings/submitting-patches.txt section I.1. This is because bindings are logically independent from a driver implementation, they have a different maintainer (even though they often are applied via the same tree), and it makes for a cleaner history in the DT only tree created with git-filter-branch. [robh@kernel.org: add doc pointer to warning, simplify logic] Link: http://lkml.kernel.org/r/20180810170513.26284-1-robh@kernel.org [robh@kernel.org: v3] Link: http://lkml.kernel.org/r/20180810225049.20452-1-robh@kernel.org Link: http://lkml.kernel.org/r/20180809205032.22205-1-robh@kernel.orgSigned-off-by:
Rob Herring <robh@kernel.org> Acked-by:
Joe Perches <joe@perches.com> Cc: Andy Whitcroft <apw@canonical.com> Signed-off-by:
-
Joe Perches authored
On Sun, 2018-08-05 at 08:52 -0700, Linus Torvalds wrote: > "long unsigned int" isn't _technically_ wrong. But we normally > call that type "unsigned long". So add a checkpatch test for it. Link: http://lkml.kernel.org/r/7bbd97dc0a1e5896a0251fada7bb68bb33643f77.camel@perches.comSigned-off-by:
-
Michal Zylowski authored
Current checkpatch implementation permits notation like } else{ in kernel code. It looks like oversight and inconsistency in checkpatch rules (e.g. instruction like 'do' is tested). Add regex for checking space after 'else' keyword and trigger error if space is not present. Link: http://lkml.kernel.org/r/1533545753-8870-1-git-send-email-michal.zylowski@intel.comSigned-off-by:Michal Zylowski <michal.zylowski@intel.com> Acked-by:
-
Joe Perches authored
checkpatch uses the in-kernel script spdxcheck.py to validate the specific license in a file or script. This check can currently fail for a couple reasons: o spdxcheck.py assumes the existence of git tree that may not exist for a bare source tree from something like a tarball o the spdxcheck.py must be run from the top level root directory So add a git existence test and set the subprocess subdirectory. Link: http://lkml.kernel.org/r/2b32864324ae9c92948b002ec4c0c22409ed98f1.camel@perches.comSigned-off-by:
Charlemagne Lasse <charlemagnelasse@gmail.com> Tested-by:
-
Joe Perches authored
Potential patches should have a commit description. Emit a warning when there isn't one. [akpm@linux-foundation.org: s/else if/elsif/] Link: http://lkml.kernel.org/r/1b099f4d8373aa583a17011992676bf0f3f09eee.camel@perches.comSigned-off-by:
Prakruthi Deepak Heragu <pheragu@codeaurora.org> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Prakruthi Deepak Heragu authored
The #if 0 or #if 1 is used to toggle features. Warn if #if 0 or #if 1 is present and suggest that they can be removed. [akpm@linux-foundation.org: fix spacing around periods, per Joe\ Link: http://lkml.kernel.org/r/1532625218-24321-1-git-send-email-pheragu@codeaurora.orgSigned-off-by:
Abhijeet Dharmapurikar <adharmap@codeaurora.org> Signed-off-by:
-
Joe Perches authored
The current krealloc test does not function correctly when the temporary pointer return name contains the original pointer name. Fix that by maximally matching the return pointer name and the original pointer name and doing a separate comparison of the both names. Link: http://lkml.kernel.org/r/e617ecb8c019a9c4c56540a1bec16c8aed43a4e4.camel@perches.comSigned-off-by:
Lars-Peter Clausen <lars@metafoo.de> Cc: Manish Narani <manish.narani@xilinx.com> Signed-off-by:
-
Joe Perches authored
Use the existing scripts/spdxcheck.py to validate any SPDX-License-Identifier found in line 1 or 2 of patches or files. Miscellanea: o Properly indent the existing SPDX-License-Identifier block. Link: http://lkml.kernel.org/r/05b832407b24e0a27e419906187cd863bc1617c7.camel@perches.comSigned-off-by:
-
Joe Perches authored
Multiple line macro definitions where the arguments are separated by line continuations can cause checkpatch to emit invalid syntax regex tests. This can occur when a single argument is modified in a part of a patch. For example: (to not add a diff in the commit message) $ ./scripts/checkpatch.pl --git db023296 Unterminated \g... pattern in regex; <very long regex omitted> And, the test does not work correctly when these arguments are all new as the initial patch line addition "+" is used in the argument name. Fix this by stripping the line continuations and any "+" from the list of arguments. Link: http://lkml.kernel.org/r/86cdb43a4db70670c102020093f7fb4eb3003e01.camel@perches.comSigned-off-by:
-
Geert Uytterhoeven authored
Print a warning if none of the Signed-off-by lines cover the patch author. Non-ASCII quoted printable encoding in From: headers and (lack of) double quotes are handled. Split From: headers are not fully handled: only the first part is compared. [geert+renesas@glider.be: only encode UTF-8 quoted printable mail headers] Link: http://lkml.kernel.org/r/20180718145254.4770-1-geert+renesas@glider.be Link: http://lkml.kernel.org/r/20180712100323.26684-1-geert+renesas@glider.beSigned-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Geert Uytterhoeven authored
As of commit bd721ea7 ("treewide: replace obsolete _refok by __ref"), __init_refok no longer exists, so it can be removed. While at it, add the modern variants that were still missing. Link: http://lkml.kernel.org/r/20180706084205.26367-1-geert+renesas@glider.beSigned-off-by:
-
Joe Perches authored
checkpatch repeatedly uses a runtime minimum version check that validates the minimum perl version required for a regex match by using a "$^V ge 5.10.0" runtime string match. Only perform that minimum version test once and store the result to reduce string matching time. This reduces runtime execution time for patches or files with high line counts. An example runtime improvement: new: $ time ./scripts/checkpatch.pl -f drivers/net/ethernet/intel/i40e/i40e_main.c > /dev/null real 0m11.856s user 0m11.831s sys 0m0.025s old: $ time ./scripts/checkpatch.pl -f drivers/net/ethernet/intel/i40e/i40e_main.c > /dev/null real 0m13.330s user 0m13.282s sys 0m0.049s Link: http://lkml.kernel.org/r/db21aa9703833bad65ab70cc4e8a78da5b399138.camel@perches.comSigned-off-by:
-
Joe Perches authored
Add the ability to --fix these string issues. e.g.: printk(KERN_INFO"bar" "baz"QUX); converts to printk(KERN_INFO "barbaz" QUX); Link: http://lkml.kernel.org/r/a9fb505ccfedffc5869d08832a7ff05a21d85621.camel@perches.comSigned-off-by:
-
Joe Perches authored
A struct with a bool member can have different sizes on various architectures because neither bool size nor alignment is standardized. So emit a message on the use of bool in structs only in .h files and not .c files. There is the real possibility that this test could have a false positive when a bool is declared as an automatic, so limit the test to .h files where the only false positive is for declarations in static inline functions. Link: http://lkml.kernel.org/r/95477c93db187bab6da8a8ba7c57836868446179.camel@perches.comSigned-off-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
-
Christophe Leroy authored
On a big endian cpu, test_hexdump fails as follows. The logs show that bytes are expected in reversed order. [...] test_hexdump: Len: 24 buflen: 130 strlen: 97 test_hexdump: Result: 97 'be32db7b 0a1893b2 70bac424 7d83349b a69c31ad 9c0face9 .2.{....p..$}.4...1.....' test_hexdump: Expect: 97 '7bdb32be b293180a 24c4ba70 9b34837d ad319ca6 e9ac0f9c .2.{....p..$}.4...1.....' test_hexdump: Len: 8 buflen: 130 strlen: 77 test_hexdump: Result: 77 'be32db7b0a1893b2 .2.{....' test_hexdump: Expect: 77 'b293180a7bdb32be .2.{....' test_hexdump: Len: 6 buflen: 131 strlen: 87 test_hexdump: Result: 87 'be32 db7b 0a18 .2.{..' test_hexdump: Expect: 87 '32be 7bdb 180a .2.{..' test_hexdump: Len: 24 buflen: 131 strlen: 97 test_hexdump: Result: 97 'be32db7b 0a1893b2 70bac424 7d83349b a69c31ad 9c0face9 .2.{....p..$}.4...1.....' test_hexdump: Expect: 97 '7bdb32be b293180a 24c4ba70 9b34837d ad319ca6 e9ac0f9c .2.{....p..$}.4...1.....' test_hexdump: Len: 32 buflen: 131 strlen: 101 test_hexdump: Result: 101 'be32db7b0a1893b2 70bac4247d83349b a69c31ad9c0face9 4cd1199943b1af0c .2.{....p..$}.4...1.....L...C...' test_hexdump: Expect: 101 'b293180a7bdb32be 9b34837d24c4ba70 e9ac0f9cad319ca6 0cafb1439919d14c .2.{....p..$}.4...1.....L...C...' test_hexdump: failed 801 out of 1184 tests This patch fixes it. Link: http://lkml.kernel.org/r/f3112437f62c2f48300535510918e8be1dceacfb.1533610877.git.christophe.leroy@c-s.fr Fixes: 64d1d77a ("hexdump: introduce test suite") Signed-off-by:Christophe Leroy <christophe.leroy@c-s.fr> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: rashmica <rashmicy@gmail.com> Signed-off-by:
-
Andy Shevchenko authored
It seems contributors follow the style of Kconfig entries where explicit 'default n' is present. The default 'default' is 'n' already, thus, drop these lines from Kconfig to make it more clear. Link: http://lkml.kernel.org/r/20180719085131.79541-1-andriy.shevchenko@linux.intel.comSigned-off-by:
Coly Li <colyli@suse.de> Signed-off-by:
-
Coly Li authored
Now we have crc64 calculation in lib/crc64.c, it is unnecessary for bcache to use its own version. This patch changes bcache code to use crc64 routines in lib/crc64.c. Link: http://lkml.kernel.org/r/20180718165545.1622-3-colyli@suse.deSigned-off-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
-
Coly Li authored
Patch series "add crc64 calculation as kernel library", v5. This patchset adds basic implementation of crc64 calculation as a Linux kernel library. Since bcache already does crc64 by itself, this patchset also modifies bcache code to use the new crc64 library routine. Currently bcache is the only user of crc64 calculation, another potential user is bcachefs which is on the way to be in mainline kernel. Therefore it makes sense to make crc64 calculation to be a public library. bcache uses crc64 as storage checksum, if a change of crc lib routines results an inconsistent result, the unmatched checksum may make bcache 'think' the on-disk is corrupted, such a change should be avoided or detected as early as possible. Therefore a patch is being prepared which adds a crc test framework, to check consistency of different calculations. This patch (of 2): Add the re-write crc64 calculation routines for Linux kernel. The CRC64 polynomical arithmetic follows ECMA-182 specification, inspired by CRC paper of Dr. Ross N. Williams (see http://www.ross.net/crc/download/crc_v3.txt) and other public domain implementations. All the changes work in this way, - When Linux kernel is built, host program lib/gen_crc64table.c will be compiled to lib/gen_crc64table and executed. - The output of gen_crc64table execution is an array called as lookup table (a.k.a POLY 0x42f0e1eba9ea369) which contain 256 64-bit long numbers, this table is dumped into header file lib/crc64table.h. - Then the header file is included by lib/crc64.c for normal 64bit crc calculation. - Function declaration of the crc64 calculation routines is placed in include/linux/crc64.h Currently bcache is the only user of crc64_be(), another potential user is bcachefs which is on the way to be in mainline kernel. Therefore it makes sense to move crc64 calculation into lib/crc64.c as public code. [colyli@suse.de: fix review comments from v4] Link: http://lkml.kernel.org/r/20180726053352.2781-2-colyli@suse.de Link: http://lkml.kernel.org/r/20180718165545.1622-2-colyli@suse.deSigned-off-by:
-
Colin Ian King authored
The pointer foo is local to the source and does not need to be in global scope, so make it static. Cleans up sparse warning: symbol 'foo' was not declared. Should it be static? Link: http://lkml.kernel.org/r/20180624112206.5722-1-colin.king@canonical.comSigned-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Chris Wilson authored
net_dim.h has a rather useful extension to BITS_PER_BYTE to compute the number of bits in a type (BITS_PER_BYTE * sizeof(T)), so promote the macro to bitops.h, alongside BITS_PER_BYTE, for wider usage. Link: http://lkml.kernel.org/r/20180706094458.14116-1-chris@chris-wilson.co.ukSigned-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Andy Gospodarek <gospo@broadcom.com> Cc: David S. Miller <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Andy Shevchenko authored
nbits == 0 is safe to be supplied to the function body, so remove unnecessary checks in bitmap_to_arr32() and bitmap_from_arr32(). Link: http://lkml.kernel.org/r/20180531131914.44352-1-andriy.shevchenko@linux.intel.comSigned-off-by:
Yury Norov <ynorov@caviumnetworks.com> Signed-off-by:
-
Joe Perches authored
There is an external use case for multiple private MAINTAINER style files in a separate directory. Allow it. --mpath has a default of "./MAINTAINERS". The value entered can be either a file or a directory. The behaviors are now: --mpath <file> Read only the specific file as <MAINTAINER_TYPE> file --mpath <directory> Read all files in <directory> as <MAINTAINER_TYPE> files --mpath <directory> --find-maintainer-files Recurse through <directory> and read all files named MAINTAINERS Link: http://lkml.kernel.org/r/991b2f20112d53863cd79e61d908f1d26d3e1971.camel@perches.comSigned-off-by:Don Zickus <dzickus@redhat.com> Signed-off-by:
-
Joe Perches authored
Add the ability to have an override for the location of the MAINTAINERS file. Miscellanea: o Properly indent a few lines with leading spaces Link: http://lkml.kernel.org/r/a86e69195076ed3c4c526fddc76b86c28e0a1e37.camel@perches.comSigned-off-by:
-
Antonio Nino Diaz authored
Add option '--no-tree' to get_maintainer.pl script to allow using this script in projects that aren't the Linux kernel if they use the same format for their MAINTAINERS file. This command is also available in checkpatch.pl, for example. Link: http://lkml.kernel.org/r/04452ac6-1575-f612-72c6-6ea88e70a9d5@arm.comSigned-off-by:
Antonio Nino Diaz <antonio.ninodiaz@arm.com> Cc: Joe Perches <joe@perches.com> Signed-off-by:
-
Davidlohr Bueso authored
Sprinkle lockdep_assert_irqs_enabled() checks in the functions that do not save and restore interrupts when dealing with the ep->wq.lock. These are ep_scan_ready_list() and those called by epoll_ctl(): ep_insert, ep_modify and ep_remove. [akpm@linux-foundation.org: remove too-obvious comments] Link: http://lkml.kernel.org/r/20180721183127.3busfa335zlcjeox@linux-r8p5Signed-off-by:
-
Davidlohr Bueso authored
Both functions are similar to the context of ep_modify(), called via epoll_ctl(2). Just like ep_modify(), saving and restoring interrupts is an overkill in these calls as it will never be called with irqs disabled. While ep_remove() can be called directly from EPOLL_CTL_DEL, it can also be called when releasing the file, but this also complies with the above. Link: http://lkml.kernel.org/r/20180720172956.2883-3-dave@stgolabs.netSigned-off-by:
-
Davidlohr Bueso authored
Patch series "fs/epoll: loosen irq safety when possible". Both patches replace saving+restoring interrupts when taking the ep->lock (now the waitqueue lock), with just disabling local irqs. This shows immediate performance benefits in patch 1 for an epoll workload running on Xen. The main concern we need to have with this sort of changes in epoll is the ep_poll_callback() which is passed to the wait queue wakeup and is done very often under irq context, this patch does not touch this call. Patches have been tested pretty heavily with the customer workload, microbenchmarks, ltp testcases and two high level workloads that use epoll under the hood: nginx and libevent benchmarks. This patch (of 2): Saving and restoring interrupts in ep_scan_ready_list() is an overkill as it is never called with interrupts disabled. Loosen this to simply disabling local irqs such that archs where managing irqs is expensive or virtual environments. This patch yields some throughput improvements on a workload that is epoll intensive running on a single Xen DomU. 1 Job 7500 --> 8800 enq/s (+17%) 2 Jobs 14000 --> 15200 enq/s (+8%) 3 Jobs 20500 --> 22300 enq/s (+8%) 4 Jobs 25000 --> 28000 enq/s (+8-12)% On bare metal: For a 2-socket 40-core (ht) IvyBridge on a few workloads, unfortunately I don't have a xen environment and the results for Xen I do have (which numbers are in patch 1) I don't have the actual workload, so cannot compare them directly. 1) Different configurations were used for a epoll_wait (pipes io) microbench (http://linux-scalability.org/epoll/epoll-test.c) and shows around a 7-10% improvement in overall total number of times the epoll_wait() loops when using both regular and nested epolls, so very raw numbers, but measurable nonetheless. # threads vanilla dirty 1 1677717 1805587 2 1660510 1854064 4 1610184 1805484 8 1577696 1751222 16 1568837 1725299 32 1291532 1378463 64 752584 787368 Note that stddev is pretty small. 2) Another pipe test, which shows no real measurable improvement. (http://www.xmailserver.org/linux-patches/pipetest.c) Link: http://lkml.kernel.org/r/20180720172956.2883-2-dave@stgolabs.netSigned-off-by:
-
Christoph Hellwig authored
Better ensure we actually hold the lock using lockdep than just commenting on it. Due to the various exported _locked interfaces it is far too easy to get the locking wrong. Link: http://lkml.kernel.org/r/20171214152344.6880-4-hch@lst.deSigned-off-by:
Christoph Hellwig <hch@lst.de> Acked-by:
Ingo Molnar <mingo@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jason Baron <jbaron@akamai.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Davidlohr Bueso <dave@stgolabs.net> Signed-off-by:
-
Matthew Wilcox authored
The userfaultfd code currently uses the unlocked waitqueue helpers for managing fault_wqh, but instead of holding the waitqueue lock for this waitqueue around these calls, it the waitqueue lock of fault_pending_wq, which is a different waitqueue instance. Given that the waitqueue is not exposed to the rest of the kernel this actually works ok at the moment, but prevents the userfaultfd locking rules from being enforced using lockdep. Switch to the internally locked waitqueue helpers instead. This means that the lock inside fault_wqh now nests inside the fault_pending_wqh lock, but that's not a problem since it was entirely unused before. [hch@lst.de: slight changelog updates] [rppt@linux.vnet.ibm.com: spotted changelog spellos] Link: http://lkml.kernel.org/r/20171214152344.6880-3-hch@lst.deSigned-off-by:
Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by:
Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Jason Baron <jbaron@akamai.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Davidlohr Bueso <dave@stgolabs.net> Cc: Matthew Wilcox <willy@infradead.org> Signed-off-by:
-
Christoph Hellwig authored
Patch series "waitqueue lockdep annotation", v3. This series adds a strategic lockdep_assert_held to __wake_up_common to ensure callers really do hold the wait_queue_head lock when calling the unlocked wake_up variants. It turns out epoll did not do this for a fairly common path (hit all the time by systemd during bootup), so the second patch fixed this instance as well. This patch (of 3): The epoll code currently uses the unlocked waitqueue helpers for managing ep->wq, but instead of holding the waitqueue lock around these calls, it uses its own ep->lock spinlock. Given that the waitqueue is not exposed to the rest of the kernel this actually works ok at the moment, but prevents the epoll locking rules from being enforced using lockdep. Remove ep->lock and use the waitqueue lock to not only reduce the size of struct eventpoll but also to make sure we can assert locking invariants in the waitqueue code. Link: http://lkml.kernel.org/r/20171214152344.6880-2-hch@lst.deSigned-off-by:
Jason Baron <jbaron@akamai.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: Jason Baron <jbaron@akamai.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Davidlohr Bueso <dave@stgolabs.net> Signed-off-by:
-
Ard Biesheuvel authored
To avoid the need for relocating absolute references to tracepoint structures at boot time when running relocatable kernels (which may take a disproportionate amount of space), add the option to emit these tables as relative references instead. Link: http://lkml.kernel.org/r/20180704083651.24360-7-ard.biesheuvel@linaro.orgAcked-by:
Michael Ellerman <mpe@ellerman.id.au> Acked-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: James Morris <james.morris@microsoft.com> Cc: James Morris <jmorris@namei.org> Cc: Jessica Yu <jeyu@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Nicolas Pitre <nico@linaro.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Petr Mladek <pmladek@suse.com> Cc: Russell King <linux@armlinux.org.uk> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Thomas Garnier <thgarnie@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Ard Biesheuvel authored
Allow the PCI quirk tables to be emitted in a way that avoids absolute references to the hook functions. This reduces the size of the entries, and, more importantly, makes them invariant under runtime relocation (e.g., for KASLR) Link: http://lkml.kernel.org/r/20180704083651.24360-6-ard.biesheuvel@linaro.orgAcked-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
-
Ard Biesheuvel authored
Allow the initcall tables to be emitted using relative references that are only half the size on 64-bit architectures and don't require fixups at runtime on relocatable kernels. Link: http://lkml.kernel.org/r/20180704083651.24360-5-ard.biesheuvel@linaro.orgAcked-by:
James Morris <james.morris@microsoft.com> Acked-by:
Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Acked-by:
Petr Mladek <pmladek@suse.com> Acked-by:
-
Ard Biesheuvel authored
An ordinary arm64 defconfig build has ~64 KB worth of __ksymtab entries, each consisting of two 64-bit fields containing absolute references, to the symbol itself and to a char array containing its name, respectively. When we build the same configuration with KASLR enabled, we end up with an additional ~192 KB of relocations in the .init section, i.e., one 24 byte entry for each absolute reference, which all need to be processed at boot time. Given how the struct kernel_symbol that describes each entry is completely local to module.c (except for the references emitted by EXPORT_SYMBOL() itself), we can easily modify it to contain two 32-bit relative references instead. This reduces the size of the __ksymtab section by 50% for all 64-bit architectures, and gets rid of the runtime relocations entirely for architectures implementing KASLR, either via standard PIE linking (arm64) or using custom host tools (x86). Note that the binary search involving __ksymtab contents relies on each section being sorted by symbol name. This is implemented based on the input section names, not the names in the ksymtab entries, so this patch does not interfere with that. Given that the use of place-relative relocations requires support both in the toolchain and in the module loader, we cannot enable this feature for all architectures. So make it dependent on whether CONFIG_HAVE_ARCH_PREL32_RELOCATIONS is defined. Link: http://lkml.kernel.org/r/20180704083651.24360-4-ard.biesheuvel@linaro.orgSigned-off-by:
Jessica Yu <jeyu@kernel.org> Acked-by:
Will Deacon <will.deacon@arm.com> Acked-by:
-
