Changes in Makefile

ee57ab5a - locking/lockdep: Disable KASAN instrumentation of lockdep.c

Fri, 07 Mar 2025 23:26:55 +0000

locking/lockdep: Disable KASAN instrumentation of lockdep.cBoth KASAN and LOCKDEP are commonly enabled in building a debug kernel.Each of them can significantly slow down the speed of a debug kernel.Enabling KASAN instrumentation of the LOCKDEP code will further slowthings down.Since LOCKDEP is a high overhead debugging tool, it will never getenabled in a production kernel. The LOCKDEP code is also pretty matureand is unlikely to get major changes. There is also a possibility ofrecursion similar to KCSAN.To evaluate the performance impact of disabling KASAN instrumentationof lockdep.c, the time to do a parallel build of the Linux defconfigkernel was used as the benchmark. Two x86-64 systems (Skylake & Zen 2)and an arm64 system were used as test beds. Two sets of non-RT and RTkernels with similar configurations except mainly CONFIG_PREEMPT_RTwere used for evaluation.For the Skylake system: Kernel Run time Sys time ------ -------- -------- Non-debug kernel (baseline) 0m47.642s 4m19.811s [CONFIG_KASAN_INLINE=y] Debug kernel 2m11.108s (x2.8) 38m20.467s (x8.9) Debug kernel (patched) 1m49.602s (x2.3) 31m28.501s (x7.3) Debug kernel (patched + mitigations=off) 1m30.988s (x1.9) 26m41.993s (x6.2) RT kernel (baseline) 0m54.871s 7m15.340s [CONFIG_KASAN_INLINE=n] RT debug kernel 6m07.151s (x6.7) 135m47.428s (x18.7) RT debug kernel (patched) 3m42.434s (x4.1) 74m51.636s (x10.3) RT debug kernel (patched + mitigations=off) 2m40.383s (x2.9) 57m54.369s (x8.0) [CONFIG_KASAN_INLINE=y] RT debug kernel 3m22.155s (x3.7) 77m53.018s (x10.7) RT debug kernel (patched) 2m36.700s (x2.9) 54m31.195s (x7.5) RT debug kernel (patched + mitigations=off) 2m06.110s (x2.3) 45m49.493s (x6.3)For the Zen 2 system: Kernel Run time Sys time ------ -------- -------- Non-debug kernel (baseline) 1m42.806s 39m48.714s [CONFIG_KASAN_INLINE=y] Debug kernel 4m04.524s (x2.4) 125m35.904s (x3.2) Debug kernel (patched) 3m56.241s (x2.3) 127m22.378s (x3.2) Debug kernel (patched + mitigations=off) 2m38.157s (x1.5) 92m35.680s (x2.3) RT kernel (baseline) 1m51.500s 14m56.322s [CONFIG_KASAN_INLINE=n] RT debug kernel 16m04.962s (x8.7) 244m36.463s (x16.4) RT debug kernel (patched) 9m09.073s (x4.9) 129m28.439s (x8.7) RT debug kernel (patched + mitigations=off) 3m31.662s (x1.9) 51m01.391s (x3.4)For the arm64 system: Kernel Run time Sys time ------ -------- -------- Non-debug kernel (baseline) 1m56.844s 8m47.150s Debug kernel 3m54.774s (x2.0) 92m30.098s (x10.5) Debug kernel (patched) 3m32.429s (x1.8) 77m40.779s (x8.8) RT kernel (baseline) 4m01.641s 18m16.777s [CONFIG_KASAN_INLINE=n] RT debug kernel 19m32.977s (x4.9) 304m23.965s (x16.7) RT debug kernel (patched) 16m28.354s (x4.1) 234m18.149s (x12.8)Turning the mitigations off doesn't seems to have any noticeable impacton the performance of the arm64 system. So the mitigation=off entriesaren't included.For the x86 CPUs, CPU mitigations has a much biggerimpact on performance, especially the RT debug kernel withCONFIG_KASAN_INLINE=n. The SRSO mitigation in Zen 2 has an especiallybig impact on the debug kernel. It is also the majority of the slowdownwith mitigations on. It is because the patched RET instruction slowsdown function returns. A lot of helper functions that are normallycompiled out or inlined may become real function calls in the debugkernel.With !CONFIG_KASAN_INLINE, the KASAN instrumentation inserts alot of __asan_loadX*() and __kasan_check_read() function calls to memoryaccess portion of the code. The lockdep's __lock_acquire() function,for instance, has 66 __asan_loadX*() and 6 __kasan_check_read() callsadded with KASAN instrumentation. Of course, the actual numbers may varydepending on the compiler used and the exact version of the lockdep code.With the Skylake test system, the parallel kernel build times reductionof the RT debug kernel with this patch are: CONFIG_KASAN_INLINE=n: -37% CONFIG_KASAN_INLINE=y: -22%The time reduction is less with CONFIG_KASAN_INLINE=y, but it is stillsignificant.Setting CONFIG_KASAN_INLINE=y can result in a significant performanceimprovement. The major drawback is a significant increase in the sizeof kernel text. In the case of vmlinux, its text size increases from45997948 to 67606807. That is a 47% size increase (about 21 Mbytes). Thesize increase of other kernel modules should be similar.With the newly added rtmutex and lockdep lock events, the relevantevent counts for the test runs with the Skylake system were: Event type Debug kernel RT debug kernel ---------- ------------ --------------- lockdep_acquire 1,968,663,277 5,425,313,953 rtlock_slowlock - 401,701,156 rtmutex_slowlock - 139,672The __lock_acquire() calls in the RT debug kernel are x2.8 times of thenon-RT debug kernel with the same workload. Since the __lock_acquire()function is a big hitter in term of performance slowdown, this makesthe RT debug kernel much slower than the non-RT one. The average locknesting depth is likely to be higher in the RT debug kernel too leadingto longer execution time in the __lock_acquire() function.As the small advantage of enabling KASAN instrumentation to catchpotential memory access error in the lockdep debugging tool is probablynot worth the drawback of further slowing down a debug kernel, disableKASAN instrumentation in the lockdep code to allow the debug kernelsto regain some performance back, especially for the RT debug kernels.Signed-off-by: Waiman Long Signed-off-by: Boqun Feng Signed-off-by: Ingo Molnar Reviewed-by: Marco Elver Reviewed-by: Andrey Konovalov Cc: Linus Torvalds Link: https://lore.kernel.org/r/20250307232717.1759087-6-boqun.feng@gmail.com List of files: /linux-6.15/kernel/locking/Makefile

1e8e4a7c - lockdep: allow instrumenting lockdep.c with KMSAN

Mon, 28 Nov 2022 09:45:40 +0000

lockdep: allow instrumenting lockdep.c with KMSANLockdep and KMSAN used to play badly together, causing deadlocks whenKMSAN instrumentation of lockdep.c called lockdep functions recursively.Looks like this is no more the case, and a kernel can run (yet slower)with both KMSAN and lockdep enabled. This patch should fix falsepositives on wq_head->lock->dep_map, which KMSAN used to consideruninitialized because of lockdep.c not being instrumented.Link: https://lore.kernel.org/lkml/Y3b9AAEKp2Vr3e6O@sol.localdomain/Link: https://lkml.kernel.org/r/20221128094541.2645890-1-glider@google.comSigned-off-by: Alexander Potapenko Reported-by: Eric Biggers Cc: Dmitry Vyukov Cc: Ingo Molnar Cc: Marco Elver Cc: Peter Zijlstra Cc: Will Deacon Signed-off-by: Andrew Morton List of files: /linux-6.15/kernel/locking/Makefile

79dbd006 - kmsan: disable instrumentation of unsupported common kernel code

Thu, 15 Sep 2022 15:03:46 +0000

kmsan: disable instrumentation of unsupported common kernel codeEFI stub cannot be linked with KMSAN runtime, so we disableinstrumentation for it.Instrumenting kcov, stackdepot or lockdep leads to infinite recursioncaused by instrumentation hooks calling instrumented code again.Link: https://lkml.kernel.org/r/20220915150417.722975-13-glider@google.comSigned-off-by: Alexander Potapenko Reviewed-by: Marco Elver Cc: Alexander Viro Cc: Alexei Starovoitov Cc: Andrey Konovalov Cc: Andrey Konovalov Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Christoph Hellwig Cc: Christoph Lameter Cc: David Rientjes Cc: Dmitry Vyukov Cc: Eric Biggers Cc: Eric Biggers Cc: Eric Dumazet Cc: Greg Kroah-Hartman Cc: Herbert Xu Cc: Ilya Leoshkevich Cc: Ingo Molnar Cc: Jens Axboe Cc: Joonsoo Kim Cc: Kees Cook Cc: Mark Rutland Cc: Matthew Wilcox Cc: Michael S. Tsirkin Cc: Pekka Enberg Cc: Peter Zijlstra Cc: Petr Mladek Cc: Stephen Rothwell Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Vegard Nossum Cc: Vlastimil Babka Signed-off-by: Andrew Morton List of files: /linux-6.15/kernel/locking/Makefile

f8635d50 - locking/ww_mutex: Implement rtmutex based ww_mutex API functions

Sun, 15 Aug 2021 21:29:00 +0000

locking/ww_mutex: Implement rtmutex based ww_mutex API functionsAdd the actual ww_mutex API functions which replace the mutex based varianton RT enabled kernels.Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210815211305.024057938@linutronix.de List of files: /linux-6.15/kernel/locking/Makefile

0f383b6d - locking/spinlock: Provide RT variant

Sun, 15 Aug 2021 21:28:27 +0000

locking/spinlock: Provide RT variantProvide the actual locking functions which make use of the general andspinlock specific rtmutex code.Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210815211303.826621464@linutronix.de List of files: /linux-6.15/kernel/locking/Makefile

531ae4b0 - locking/rtmutex: Split API from implementation

Sun, 15 Aug 2021 21:27:57 +0000

locking/rtmutex: Split API from implementationPrepare for reusing the inner functions of rtmutex for RT locksubstitutions: introduce kernel/locking/rtmutex_api.c and movethem there.Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210815211302.726560996@linutronix.de List of files: /linux-6.15/kernel/locking/Makefile

f41dcc18 - locking/rtmutex: Move debug functions as inlines into common header

Fri, 26 Mar 2021 15:29:39 +0000

locking/rtmutex: Move debug functions as inlines into common headerThere is no value in having two header files providing just empty stubs anda C file which implements trivial debug functions which can just be inlined.Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20210326153944.052454464@linutronix.de List of files: /linux-6.15/kernel/locking/Makefile

997acaf6 - lockdep: report broken irq restoration

Mon, 11 Jan 2021 15:37:07 +0000

lockdep: report broken irq restorationWe generally expect local_irq_save() and local_irq_restore() to bepaired and sanely nested, and so local_irq_restore() expects to becalled with irqs disabled. Thus, within local_irq_restore() we onlytrace irq flag changes when unmasking irqs.This means that a sequence such as:| local_irq_disable();| local_irq_save(flags);| local_irq_enable();| local_irq_restore(flags);... is liable to break things, as the local_irq_restore() would maskirqs without tracing this change. Similar problems may exist forarchitectures whose arch_irq_restore() function depends on being calledwith irqs disabled.We don't consider such sequences to be a good idea, so let's definethose as forbidden, and add tooling to detect such broken cases.This patch adds debug code to WARN() when raw_local_irq_restore() iscalled with irqs enabled. As raw_local_irq_restore() is expected to pairwith raw_local_irq_save(), it should never be called with irqs enabled.To avoid the possibility of circular header dependencies betweenirqflags.h and bug.h, the warning is handled in a separate C file.The new code is all conditional on a new CONFIG_DEBUG_IRQFLAGS symbolwhich is independent of CONFIG_TRACE_IRQFLAGS. As noted above such caseswill confuse lockdep, so CONFIG_DEBUG_LOCKDEP now selectsCONFIG_DEBUG_IRQFLAGS.Signed-off-by: Mark Rutland Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210111153707.10071-1-mark.rutland@arm.com List of files: /linux-6.15/kernel/locking/Makefile

f1bc9621 - kcsan: Make KCSAN compatible with lockdep

Wed, 15 Jan 2020 16:25:12 +0000

kcsan: Make KCSAN compatible with lockdepWe must avoid any recursion into lockdep if KCSAN is enabled on utilitiesused by lockdep. One manifestation of this is corruption of lockdep'sIRQ trace state (if TRACE_IRQFLAGS), resulting in spurious warnings(see below). This commit fixes this by:1. Using raw_local_irq{save,restore} in kcsan_setup_watchpoint().2. Disabling lockdep in kcsan_report().Tested with: CONFIG_LOCKDEP=y CONFIG_DEBUG_LOCKDEP=y CONFIG_TRACE_IRQFLAGS=yThis fix eliminates spurious warnings such as the following one: WARNING: CPU: 0 PID: 2 at kernel/locking/lockdep.c:4406 check_flags.part.0+0x101/0x220 Modules linked in: CPU: 0 PID: 2 Comm: kthreadd Not tainted 5.5.0-rc1+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:check_flags.part.0+0x101/0x220 Call Trace: lock_is_held_type+0x69/0x150 freezer_fork+0x20b/0x370 cgroup_post_fork+0x2c9/0x5c0 copy_process+0x2675/0x3b40 _do_fork+0xbe/0xa30 ? _raw_spin_unlock_irqrestore+0x40/0x50 ? match_held_lock+0x56/0x250 ? kthread_park+0xf0/0xf0 kernel_thread+0xa6/0xd0 ? kthread_park+0xf0/0xf0 kthreadd+0x321/0x3d0 ? kthread_create_on_cpu+0x130/0x130 ret_from_fork+0x3a/0x50 irq event stamp: 64 hardirqs last enabled at (63): [] _raw_spin_unlock_irqrestore+0x40/0x50 hardirqs last disabled at (64): [] kcsan_setup_watchpoint+0x92/0x460 softirqs last enabled at (32): [] fpu__copy+0xe8/0x470 softirqs last disabled at (30): [] fpu__copy+0x69/0x470Reported-by: Qian Cai Signed-off-by: Marco Elver Acked-by: Alexander Potapenko Tested-by: Qian Cai Signed-off-by: Paul E. McKenney Signed-off-by: Ingo Molnar List of files: /linux-6.15/kernel/locking/Makefile

5dec94d4 - locking/rwsem: Merge rwsem.h and rwsem-xadd.c into rwsem.c

Mon, 20 May 2019 20:59:03 +0000

locking/rwsem: Merge rwsem.h and rwsem-xadd.c into rwsem.cNow we only have one implementation of rwsem. Even though we still usexadd to handle reader locking, we use cmpxchg for writer instead. Sothe filename rwsem-xadd.c is not strictly correct. Also no one outsideof the rwsem code need to know the internal implementation other thanfunction prototypes for two internal functions that are called directlyfrom percpu-rwsem.c.So the rwsem-xadd.c and rwsem.h files are now merged into rwsem.c inthe following order:

The rwsem.h file now contains only 2 function declarations for__up_read() and __down_read().This is a code relocation patch with no code change at all exceptmaking __up_read() and __down_read() non-static functions so theycan be used by percpu-rwsem.c.Suggested-by: Peter Zijlstra Signed-off-by: Waiman Long Signed-off-by: Peter Zijlstra (Intel) Cc: Borislav Petkov Cc: Davidlohr Bueso Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Thomas Gleixner Cc: Tim Chen Cc: Will Deacon Cc: huang ying Link: https://lkml.kernel.org/r/20190520205918.22251-5-longman@redhat.comSigned-off-by: Ingo Molnar List of files: /linux-6.15/kernel/locking/Makefile

fb346fd9 - locking/lock_events: Make lock_events available for all archs & other locks

Thu, 04 Apr 2019 17:43:17 +0000

locking/lock_events: Make lock_events available for all archs & other locksThe QUEUED_LOCK_STAT option to report queued spinlocks event countswas previously allowed only on x86 architecture. To make the lockingevent counting code more useful, it is now renamed to a more genericLOCK_EVENT_COUNTS config option. This new option will be available toall the architectures that use qspinlock at the moment.Other locking code can now start to use the generic locking eventcounting code by including lock_events.h and put the new locking eventnames into the lock_events_list.h header file.My experience with lock event counting is that it gives valuable insighton how the locking code works and what can be done to make it better. Iwould like to extend this benefit to other locking code like mutex andrwsem in the near future.The PV qspinlock specific code will stay in qspinlock_stat.h. Thelocking event counters will now reside in the /lock_event_countsdirectory.Signed-off-by: Waiman Long Acked-by: Peter Zijlstra Acked-by: Davidlohr Bueso Cc: Andrew Morton Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Davidlohr Bueso Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Tim Chen Cc: Will Deacon Link: http://lkml.kernel.org/r/20190404174320.22416-9-longman@redhat.comSigned-off-by: Ingo Molnar List of files: /linux-6.15/kernel/locking/Makefile

390a0c62 - locking/rwsem: Remove rwsem-spinlock.c & use rwsem-xadd.c for all archs

Fri, 22 Mar 2019 14:30:07 +0000

locking/rwsem: Remove rwsem-spinlock.c & use rwsem-xadd.c for all archsCurrently, we have two different implementation of rwsem: 1) CONFIG_RWSEM_GENERIC_SPINLOCK (rwsem-spinlock.c) 2) CONFIG_RWSEM_XCHGADD_ALGORITHM (rwsem-xadd.c)As we are going to use a single generic implementation for rwsem-xadd.cand no architecture-specific code will be needed, there is no pointin keeping two different implementations of rwsem. In most cases, theperformance of rwsem-spinlock.c will be worse. It also doesn't get allthe performance tuning and optimizations that had been implemented inrwsem-xadd.c over the years.For simplication, we are going to remove rwsem-spinlock.c and make allarchitectures use a single implementation of rwsem - rwsem-xadd.c.All references to RWSEM_GENERIC_SPINLOCK and RWSEM_XCHGADD_ALGORITHMin the code are removed.Suggested-by: Peter Zijlstra Signed-off-by: Waiman Long Signed-off-by: Peter Zijlstra (Intel) Acked-by: Linus Torvalds Cc: Andrew Morton Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Davidlohr Bueso Cc: H. Peter Anvin Cc: Paul E. McKenney Cc: Thomas Gleixner Cc: Tim Chen Cc: Will Deacon Cc: linux-arm-kernel@lists.infradead.orgCc: linux-c6x-dev@linux-c6x.orgCc: linux-m68k@lists.linux-m68k.orgCc: linux-riscv@lists.infradead.orgCc: linux-um@lists.infradead.orgCc: linux-xtensa@linux-xtensa.orgCc: linuxppc-dev@lists.ozlabs.orgCc: nios2-dev@lists.rocketboards.orgCc: openrisc@lists.librecores.orgCc: uclinux-h8-devel@lists.sourceforge.jpLink: https://lkml.kernel.org/r/20190322143008.21313-3-longman@redhat.comSigned-off-by: Ingo Molnar List of files: /linux-6.15/kernel/locking/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/kernel/locking/Makefile

f2a5fec1 - locking/ww_mutex: Begin kselftests for ww_mutex

Thu, 01 Dec 2016 11:47:06 +0000

locking/ww_mutex: Begin kselftests for ww_mutexSigned-off-by: Chris Wilson Signed-off-by: Peter Zijlstra (Intel) Cc: Andrew Morton Cc: Linus Torvalds Cc: Maarten Lankhorst Cc: Nicolai Hähnle Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20161201114711.28697-4-chris@chris-wilson.co.ukSigned-off-by: Ingo Molnar List of files: /linux-6.15/kernel/locking/Makefile

d32cdbfb - locking/lglock: Remove lglock implementation

Mon, 23 Nov 2015 17:36:16 +0000

locking/lglock: Remove lglock implementationIt is now unused, remove it before someone else thinks its a good ideato use this.Signed-off-by: Peter Zijlstra (Intel) Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.orgSigned-off-by: Ingo Molnar List of files: /linux-6.15/kernel/locking/Makefile

5c9a8750 - kernel: add kcov code coverage

Tue, 22 Mar 2016 21:27:30 +0000

kernel: add kcov code coveragekcov provides code coverage collection for coverage-guided fuzzing(randomized testing). Coverage-guided fuzzing is a testing techniquethat uses coverage feedback to determine new interesting inputs to asystem. A notable user-space example is AFL(http://lcamtuf.coredump.cx/afl/). However, this technique is notwidely used for kernel testing due to missing compiler and kernelsupport.kcov does not aim to collect as much coverage as possible. It aims tocollect more or less stable coverage that is function of syscall inputs.To achieve this goal it does not collect coverage in soft/hardinterrupts and instrumentation of some inherently non-deterministic ornon-interesting parts of kernel is disbled (e.g. scheduler, locking).Currently there is a single coverage collection mode (tracing), but theAPI anticipates additional collection modes. Initially I alsoimplemented a second mode which exposes coverage in a fixed-size hashtable of counters (what Quentin used in his original patch). I'vedropped the second mode for simplicity.This patch adds the necessary support on kernel side. The complimentarycompiler support was added in gcc revision 231296.We've used this support to build syzkaller system call fuzzer, which hasfound 90 kernel bugs in just 2 months: https://github.com/google/syzkaller/wiki/Found-BugsWe've also found 30+ bugs in our internal systems with syzkaller.Another (yet unexplored) direction where kcov coverage would greatlyhelp is more traditional "blob mutation". For example, mounting arandom blob as a filesystem, or receiving a random blob over wire.Why not gcov. Typical fuzzing loop looks as follows: (1) resetcoverage, (2) execute a bit of code, (3) collect coverage, repeat. Atypical coverage can be just a dozen of basic blocks (e.g. an invalidinput). In such context gcov becomes prohibitively expensive asreset/collect coverage steps depend on total number of basicblocks/edges in program (in case of kernel it is about 2M). Cost ofkcov depends only on number of executed basic blocks/edges. On top ofthat, kernel requires per-thread coverage because there are alwaysbackground threads and unrelated processes that also produce coverage.With inlined gcov instrumentation per-thread coverage is not possible.kcov exposes kernel PCs and control flow to user-space which isinsecure. But debugfs should not be mapped as user accessible.Based on a patch by Quentin Casasnovas.[akpm@linux-foundation.org: make task_struct.kcov_mode have type `enum kcov_mode'][akpm@linux-foundation.org: unbreak allmodconfig][akpm@linux-foundation.org: follow x86 Makefile layout standards]Signed-off-by: Dmitry Vyukov Reviewed-by: Kees Cook Cc: syzkaller Cc: Vegard Nossum Cc: Catalin Marinas Cc: Tavis Ormandy Cc: Will Deacon Cc: Quentin Casasnovas Cc: Kostya Serebryany Cc: Eric Dumazet Cc: Alexander Potapenko Cc: Kees Cook Cc: Bjorn Helgaas Cc: Sasha Levin Cc: David Drysdale Cc: Ard Biesheuvel Cc: Andrey Ryabinin Cc: Kirill A. Shutemov Cc: Jiri Slaby Cc: Ingo Molnar Cc: Thomas Gleixner Cc: "H. Peter Anvin" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/kernel/locking/Makefile

bf3eac84 - percpu-rwsem: kill CONFIG_PERCPU_RWSEM

Tue, 11 Aug 2015 15:26:29 +0000

percpu-rwsem: kill CONFIG_PERCPU_RWSEMRemove CONFIG_PERCPU_RWSEM, the next patch adds the unconditionaluser of percpu_rw_semaphore.Signed-off-by: Oleg Nesterov List of files: /linux-6.15/kernel/locking/Makefile

1b0b7c17 - rtmutex: Delete scriptable tester

Wed, 01 Jul 2015 20:29:48 +0000

rtmutex: Delete scriptable testerNo one uses this anymore, and this is not the first time theidea of replacing it with a (now possible) userspace side.Lock stealing logic was removed long ago in when the lockwas granted to the highest prio.Signed-off-by: Davidlohr Bueso Cc: Darren Hart Cc: Steven Rostedt Cc: Mike Galbraith Cc: Paul E. McKenney Cc: Sebastian Andrzej Siewior Cc: Davidlohr Bueso Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1435782588-4177-2-git-send-email-dave@stgolabs.netSigned-off-by: Thomas Gleixner List of files: /linux-6.15/kernel/locking/Makefile

c7114b4e - locking/qrwlock: Rename QUEUE_RWLOCK to QUEUED_RWLOCKS

Mon, 11 May 2015 17:57:11 +0000

locking/qrwlock: Rename QUEUE_RWLOCK to QUEUED_RWLOCKSTo be consistent with the queued spinlocks which useCONFIG_QUEUED_SPINLOCKS config parameter, the one for the queuedrwlocks is now renamed to CONFIG_QUEUED_RWLOCKS.Signed-off-by: Waiman Long Cc: Borislav Petkov Cc: Douglas Hatch Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Scott J Norton Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1431367031-36697-1-git-send-email-Waiman.Long@hp.comSigned-off-by: Ingo Molnar List of files: /linux-6.15/kernel/locking/Makefile

62c7a1e9 - locking/pvqspinlock: Rename QUEUED_SPINLOCK to QUEUED_SPINLOCKS

Mon, 11 May 2015 07:47:23 +0000

locking/pvqspinlock: Rename QUEUED_SPINLOCK to QUEUED_SPINLOCKSValentin Rothberg reported that we use CONFIG_QUEUED_SPINLOCKSin arch/x86/kernel/paravirt_patch_32.c, while the symbol iscalled CONFIG_QUEUED_SPINLOCK. (Note the extra 'S')But the typo was natural: the proper English term for sucha generic object would be 'queued spinlocks' - so renamethis and related symbols accordingly to the plural form.Reported-by: Valentin Rothberg Cc: Douglas Hatch Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Scott J Norton Cc: Thomas Gleixner Cc: Waiman Long Cc: linux-kernel@vger.kernel.orgSigned-off-by: Ingo Molnar List of files: /linux-6.15/kernel/locking/Makefile