aboutsummaryrefslogtreecommitdiff
path: root/include/linux/kernel.h
AgeCommit message (Collapse)AuthorFilesLines
2020-12-15kernel.h: split out mathematical helpersAndy Shevchenko1-170/+3
kernel.h is being used as a dump for all kinds of stuff for a long time. Here is the attempt to start cleaning it up by splitting out mathematical helpers. At the same time convert users in header and lib folder to use new header. Though for time being include new header back to kernel.h to avoid twisted indirected includes for existing users. [[email protected]: fix powerpc build] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Cc: "Paul E. McKenney" <[email protected]> Cc: Trond Myklebust <[email protected]> Cc: Jeff Layton <[email protected]> Cc: Rasmus Villemoes <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-12-14Merge tag 'sched-core-2020-12-14' of ↵Linus Torvalds1-7/+14
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler updates from Thomas Gleixner: - migrate_disable/enable() support which originates from the RT tree and is now a prerequisite for the new preemptible kmap_local() API which aims to replace kmap_atomic(). - A fair amount of topology and NUMA related improvements - Improvements for the frequency invariant calculations - Enhanced robustness for the global CPU priority tracking and decision making - The usual small fixes and enhancements all over the place * tag 'sched-core-2020-12-14' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (61 commits) sched/fair: Trivial correction of the newidle_balance() comment sched/fair: Clear SMT siblings after determining the core is not idle sched: Fix kernel-doc markup x86: Print ratio freq_max/freq_base used in frequency invariance calculations x86, sched: Use midpoint of max_boost and max_P for frequency invariance on AMD EPYC x86, sched: Calculate frequency invariance for AMD systems irq_work: Optimize irq_work_single() smp: Cleanup smp_call_function*() irq_work: Cleanup sched: Limit the amount of NUMA imbalance that can exist at fork time sched/numa: Allow a floating imbalance between NUMA nodes sched: Avoid unnecessary calculation of load imbalance at clone time sched/numa: Rename nr_running and break out the magic number sched: Make migrate_disable/enable() independent of RT sched/topology: Condition EAS enablement on FIE support arm64: Rebuild sched domains on invariance status changes sched/topology,schedutil: Wrap sched domains rebuild sched/uclamp: Allow to reset a task uclamp constraint value sched/core: Fix typos in comments Documentation: scheduler: fix information on arch SD flags, sched_domain and sched_debug ...
2020-11-24sched: Make migrate_disable/enable() independent of RTThomas Gleixner1-7/+14
Now that the scheduler can deal with migrate disable properly, there is no real compelling reason to make it only available for RT. There are quite some code pathes which needlessly disable preemption in order to prevent migration and some constructs like kmap_atomic() enforce it implicitly. Making it available independent of RT allows to provide a preemptible variant of kmap_atomic() and makes the code more consistent in general. Signed-off-by: Thomas Gleixner <[email protected]> Grudgingly-Acked-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-11-19rcu: Panic after fixed number of stallschao1-0/+1
Some stalls are transient, so that system fully recovers. This commit therefore allows users to configure the number of stalls that must happen in order to trigger kernel panic. Signed-off-by: chao <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]>
2020-10-25treewide: Convert macro and uses of __section(foo) to __section("foo")Joe Perches1-3/+3
Use a more generic form for __section that requires quotes to avoid complications with clang and gcc differences. Remove the quote operator # from compiler_attributes.h __section macro. Convert all unquoted __section(foo) uses to quoted __section("foo"). Also convert __attribute__((section("foo"))) uses to __section("foo") even if the __attribute__ has multiple list entry forms. Conversion done using the script at: https://lore.kernel.org/lkml/[email protected]/2-convert_section.pl Signed-off-by: Joe Perches <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Miguel Ojeda <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-10-16kernel.h: split out min()/max() et al. helpersAndy Shevchenko1-149/+1
kernel.h is being used as a dump for all kinds of stuff for a long time. Here is the attempt to start cleaning it up by splitting out min()/max() et al. helpers. At the same time convert users in header and lib folder to use new header. Though for time being include new header back to kernel.h to avoid twisted indirected includes for other existing users. Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Rasmus Villemoes <[email protected]> Cc: Joe Perches <[email protected]> Cc: Linus Torvalds <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-10-13Merge tag 'printk-for-5.10' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux Pull printk updates from Petr Mladek: "The big new thing is the fully lockless ringbuffer implementation, including the support for continuous lines. It will allow to store and read messages in any situation wihtout the risk of deadlocks and without the need of temporary per-CPU buffers. The access is still serialized by logbuf_lock. It synchronizes few more operations, for example, temporary buffer for formatting the message, syslog and kmsg_dump operations. The lock removal is being discussed and should be ready for the next release. The continuous lines are handled exactly the same way as before to avoid regressions in user space. It means that they are appended to the last message when the caller is the same. Only the last message can be extended. The data ring includes plain text of the messages. Except for an integer at the beginning of each message that points back to the descriptor ring with other metadata. The dictionary has to stay. journalctl uses it to filter the log. It allows to show messages related to a given device. The dictionary values are stored in the descriptor ring with the other metadata. This is the first part of the printk rework as discussed at Plumbers 2019, see https://lore.kernel.org/r/[email protected]. The next big step will be handling consoles by kthreads during the normal system operation. It will require special handling of situations when the kthreads could not get scheduled, for example, early boot, suspend, panic. Other changes: - Add John Ogness as a reviewer for printk subsystem. He is author of the rework and is familiar with the code and history. - Fix locking in serial8250_do_startup() to prevent lockdep report. - Few code cleanups" * tag 'printk-for-5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux: (27 commits) printk: Use fallthrough pseudo-keyword printk: reduce setup_text_buf size to LOG_LINE_MAX printk: avoid and/or handle record truncation printk: remove dict ring printk: move dictionary keys to dev_printk_info printk: move printk_info into separate array printk: reimplement log_cont using record extension printk: ringbuffer: add finalization/extension support printk: ringbuffer: change representation of states printk: ringbuffer: clear initial reserved fields printk: ringbuffer: add BLK_DATALESS() macro printk: ringbuffer: relocate get_data() printk: ringbuffer: avoid memcpy() on state_var printk: ringbuffer: fix setting state in desc_read() kernel.h: Move oops_in_progress to printk.h scripts/gdb: update for lockless printk ringbuffer scripts/gdb: add utils.read_ulong() docs: vmcoreinfo: add lockless printk ringbuffer vmcoreinfo printk: reduce LOG_BUF_SHIFT range for H8300 printk: ringbuffer: support dataless records ...
2020-09-15kernel.h: Move oops_in_progress to printk.hAndy Shevchenko1-1/+0
The oops_in_progress is defined in printk.c, so it's logical to move oops_in_progress to printk.h. Signed-off-by: Andy Shevchenko <[email protected]> Acked-by: Sergey Senozhatsky <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-08-28kernel.h: Silence sparse warning in lower_32_bitsHerbert Xu1-1/+1
I keep getting sparse warnings in crypto such as: CHECK drivers/crypto/ccree/cc_hash.c drivers/crypto/ccree/cc_hash.c:49:9: warning: cast truncates bits from constant value (47b5481dbefa4fa4 becomes befa4fa4) drivers/crypto/ccree/cc_hash.c:49:26: warning: cast truncates bits from constant value (db0c2e0d64f98fa7 becomes 64f98fa7) [.. many more ..] This patch removes the warning by adding a mask to keep sparse happy. Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12panic: make print_oops_end_marker() staticYue Hu1-1/+0
Since print_oops_end_marker() is not used externally, also remove it in kernel.h at the same time. Signed-off-by: Yue Hu <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Cc: Kees Cook <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12kernel/panic.c: make oops_may_print() return boolTiezhu Yang1-1/+1
The return value of oops_may_print() is true or false, so change its type to reflect that. Signed-off-by: Tiezhu Yang <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Xuefeng Li <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12kstrto*: do not describe simple_strto*() as obsolete/replacedKars Mulder1-2/+2
The documentation of the kstrto*() functions describes kstrto*() as "replacements" of the "obsolete" simple_strto*() functions. Both of these terms are inaccurate: they're not replacements because they have different behaviour, and the simple_strto*() are not obsolete because there are cases where they have benefits over kstrto*(). Remove usage of the terms "replacement" and "obsolete" in reference to simple_strto*(), and instead use the term "preferred over". Fixes: 4c925d6031f71 ("kstrto*: add documentation") Fixes: 885e68e8b7b13 ("kernel.h: update comment about simple_strto<foo>() functions") Signed-off-by: Kars Mulder <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: Eldad Zack <[email protected]> Cc: Miguel Ojeda <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Mans Rullgard <[email protected]> Cc: Petr Mladek <[email protected]> Link: http://lkml.kernel.org/r/29b9-5f234c80-13-4e3aa200@244003027 Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12kstrto*: correct documentation references to simple_strto*()Kars Mulder1-2/+2
The documentation of the kstrto*() functions reference the simple_strtoull function by "used as a replacement for [the obsolete] simple_strtoull". All these functions describes themselves as replacements for the function simple_strtoull, even though a function like kstrtol() would be more aptly described as a replacement of simple_strtol(). Fix these references by making the documentation of kstrto*() reference the closest simple_strto*() equivalent available. The functions kstrto[u]int() do not have direct simple_strto[u]int() equivalences, so these are made to refer to simple_strto[u]l() instead. Furthermore, add parentheses after function names, as is standard in kernel documentation. Fixes: 4c925d6031f71 ("kstrto*: add documentation") Signed-off-by: Kars Mulder <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Cc: Eldad Zack <[email protected]> Cc: Miguel Ojeda <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Mans Rullgard <[email protected]> Cc: Petr Mladek <[email protected]> Link: http://lkml.kernel.org/r/1ee1-5f234c00-f3-165a6440@234394593 Signed-off-by: Linus Torvalds <[email protected]>
2020-08-12kernel.h: remove duplicate include of asm/div64.hArvind Sankar1-1/+0
This seems to have been added inadvertently in commit 72deb455b5ec ("block: remove CONFIG_LBDAF") Fixes: 72deb455b5ec ("block: remove CONFIG_LBDAF") Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-07-27linux/kernel.h: Add PTR_ALIGN_DOWN macroKishon Vijay Abraham I1-0/+1
Add a macro for aligning down a pointer. This is useful to get an aligned register address when a device allows only word access and doesn't allow half word or byte access. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kishon Vijay Abraham I <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Rob Herring <[email protected]>
2020-06-08panic: add sysctl to dump all CPUs backtraces on oops eventGuilherme G. Piccoli1-0/+6
Usually when the kernel reaches an oops condition, it's a point of no return; in case not enough debug information is available in the kernel splat, one of the last resorts would be to collect a kernel crash dump and analyze it. The problem with this approach is that in order to collect the dump, a panic is required (to kexec-load the crash kernel). When in an environment of multiple virtual machines, users may prefer to try living with the oops, at least until being able to properly shutdown their VMs / finish their important tasks. This patch implements a way to collect a bit more debug details when an oops event is reached, by printing all the CPUs backtraces through the usage of NMIs (on architectures that support that). The sysctl added (and documented) here was called "oops_all_cpu_backtrace", and when set will (as the name suggests) dump all CPUs backtraces. Far from ideal, this may be the last option though for users that for some reason cannot panic on oops. Most of times oopses are clear enough to indicate the kernel portion that must be investigated, but in virtual environments it's possible to observe hypervisor/KVM issues that could lead to oopses shown in other guests CPUs (like virtual APIC crashes). This patch hence aims to help debug such complex issues without resorting to kdump. Signed-off-by: Guilherme G. Piccoli <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Kees Cook <[email protected]> Cc: Luis Chamberlain <[email protected]> Cc: Iurii Zaikin <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Matthew Wilcox <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-06-08kernel: add panic_on_taintRafael Aquini1-0/+3
Analogously to the introduction of panic_on_warn, this patch introduces a kernel option named panic_on_taint in order to provide a simple and generic way to stop execution and catch a coredump when the kernel gets tainted by any given flag. This is useful for debugging sessions as it avoids having to rebuild the kernel to explicitly add calls to panic() into the code sites that introduce the taint flags of interest. For instance, if one is interested in proceeding with a post-mortem analysis at the point a given code path is hitting a bad page (i.e. unaccount_page_cache_page(), or slab_bug()), a coredump can be collected by rebooting the kernel with 'panic_on_taint=0x20' amended to the command line. Another, perhaps less frequent, use for this option would be as a means for assuring a security policy case where only a subset of taints, or no single taint (in paranoid mode), is allowed for the running system. The optional switch 'nousertaint' is handy in this particular scenario, as it will avoid userspace induced crashes by writes to sysctl interface /proc/sys/kernel/tainted causing false positive hits for such policies. [[email protected]: tweak kernel-parameters.txt wording] Suggested-by: Qian Cai <[email protected]> Signed-off-by: Rafael Aquini <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Reviewed-by: Luis Chamberlain <[email protected]> Cc: Dave Young <[email protected]> Cc: Baoquan He <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Kees Cook <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: "Theodore Ts'o" <[email protected]> Cc: Adrian Bunk <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Laura Abbott <[email protected]> Cc: Jeff Mahoney <[email protected]> Cc: Jiri Kosina <[email protected]> Cc: Takashi Iwai <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Linus Torvalds <[email protected]>
2020-02-20sched: Provide cant_migrate()Thomas Gleixner1-0/+7
Some code pathes rely on preempt_disable() to prevent migration on a non RT enabled kernel. These preempt_disable/enable() pairs are substituted by migrate_disable/enable() pairs or other forms of RT specific protection. On RT these protections prevent migration but not preemption. Obviously a cant_sleep() check in such a section will trigger on RT because preemption is not disabled. Provide a cant_migrate() macro which maps to cant_sleep() on a non RT kernel and an empty placeholder for RT for now. The placeholder will be changed to a proper debug check along with the RT specific migration protection mechanism. Signed-off-by: Thomas Gleixner <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-12-30kernel.h: Remove unused FIELD_SIZEOF()Kees Cook1-9/+0
Now that all callers of FIELD_SIZEOF() have been converted to sizeof_field(), remove the unused prior macro. Signed-off-by: Kees Cook <[email protected]>
2019-12-04kernel.h: update comment about simple_strto<foo>() functionsAndy Shevchenko1-5/+14
There were discussions in the past about use cases for simple_strto<foo>() functions and, in some rare cases, they have a benefit over kstrto<foo>() ones. Update a comment to reduce confusion about special use cases. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Suggested-by: Miguel Ojeda <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Cc: Mans Rullgard <[email protected]> Cc: Petr Mladek <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-11-25locking/refcount: Remove unused 'refcount_error_report()' functionWill Deacon1-7/+0
'refcount_error_report()' has no callers. Remove it. Signed-off-by: Will Deacon <[email protected]> Reviewed-by: Ard Biesheuvel <[email protected]> Acked-by: Kees Cook <[email protected]> Tested-by: Hanjun Guo <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Elena Reshetova <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2019-09-07kernel.h: Add non_block_start/end()Daniel Vetter1-1/+22
In some special cases we must not block, but there's not a spinlock, preempt-off, irqs-off or similar critical section already that arms the might_sleep() debug checks. Add a non_block_start/end() pair to annotate these. This will be used in the oom paths of mmu-notifiers, where blocking is not allowed to make sure there's forward progress. Quoting Michal: "The notifier is called from quite a restricted context - oom_reaper - which shouldn't depend on any locks or sleepable conditionals. The code should be swift as well but we mostly do care about it to make a forward progress. Checking for sleepable context is the best thing we could come up with that would describe these demands at least partially." Peter also asked whether we want to catch spinlocks on top, but Michal said those are less of a problem because spinlocks can't have an indirect dependency upon the page allocator and hence close the loop with the oom reaper. Suggested by Michal Hocko. Link: https://lore.kernel.org/r/[email protected] Acked-by: Christian König <[email protected]> (v1) Acked-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Acked-by: Michal Hocko <[email protected]> Signed-off-by: Jason Gunthorpe <[email protected]>
2019-07-16include/linux/kernel.h: add typeof_member() macroAlexey Dobriyan1-0/+2
Add typeof_member() macro so that types can be extracted without introducing dummy variables. Link: http://lkml.kernel.org/r/20190529190720.GA5703@avx2 Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-06-29linux/kernel.h: fix overflow for DIV_ROUND_UP_ULLVinod Koul1-1/+2
DIV_ROUND_UP_ULL adds the two arguments and then invokes DIV_ROUND_DOWN_ULL. But on a 32bit system the addition of two 32 bit values can overflow. DIV_ROUND_DOWN_ULL does it correctly and stashes the addition into a unsigned long long so cast the result to unsigned long long here to avoid the overflow condition. [[email protected]: DIV_ROUND_UP_ULL must be an rval] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Bjorn Andersson <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-05-14lib/math: move int_pow() from pwm_bl.c for wider useAndy Shevchenko1-0/+1
The integer exponentiation is used in few places and might be used in the future by other call sites. Move it to wider use. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Andy Shevchenko <[email protected]> Cc: Daniel Thompson <[email protected]> Cc: Lee Jones <[email protected]> Cc: Ray Jui <[email protected]> Cc: Thierry Reding <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-04-22Merge tag 'v5.1-rc6' into for-5.2/blockJens Axboe1-2/+2
Pull in v5.1-rc6 to resolve two conflicts. One is in BFQ, in just a comment, and is trivial. The other one is a conflict due to a later fix in the bio multi-page work, and needs a bit more care. * tag 'v5.1-rc6': (770 commits) Linux 5.1-rc6 block: make sure that bvec length can't be overflow block: kill all_q_node in request_queue x86/cpu/intel: Lower the "ENERGY_PERF_BIAS: Set to normal" message's log priority coredump: fix race condition between mmget_not_zero()/get_task_mm() and core dumping mm/kmemleak.c: fix unused-function warning init: initialize jump labels before command line option parsing kernel/watchdog_hld.c: hard lockup message should end with a newline kcov: improve CONFIG_ARCH_HAS_KCOV help text mm: fix inactive list balancing between NUMA nodes and cgroups mm/hotplug: treat CMA pages as unmovable proc: fixup proc-pid-vm test proc: fix map_files test on F29 mm/vmstat.c: fix /proc/vmstat format for CONFIG_DEBUG_TLBFLUSH=y CONFIG_SMP=n mm/memory_hotplug: do not unlock after failing to take the device_hotplug_lock mm: swapoff: shmem_unuse() stop eviction without igrab() mm: swapoff: take notice of completion sooner mm: swapoff: remove too limiting SWAP_UNUSE_MAX_TRIES mm: swapoff: shmem_find_swap_entries() filter out other types slab: store tagged freelist for off-slab slabmgmt ... Signed-off-by: Jens Axboe <[email protected]>
2019-04-06block: remove CONFIG_LBDAFChristoph Hellwig1-12/+2
Currently support for 64-bit sector_t and blkcnt_t is optional on 32-bit architectures. These types are required to support block device and/or file sizes larger than 2 TiB, and have generally defaulted to on for a long time. Enabling the option only increases the i386 tinyconfig size by 145 bytes, and many data structures already always use 64-bit values for their in-core and on-disk data structures anyway, so there should not be a large change in dynamic memory usage either. Dropping this option removes a somewhat weird non-default config that has cause various bugs or compiler warnings when actually used. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2019-04-03linux/kernel.h: Use parentheses around argument in u64_to_user_ptr()Jann Horn1-2/+2
Use parentheses around uses of the argument in u64_to_user_ptr() to ensure that the cast doesn't apply to part of the argument. There are existing uses of the macro of the form u64_to_user_ptr(A + B) which expands to (void __user *)(uintptr_t)A + B (the cast applies to the first operand of the addition, the addition is a pointer addition). This happens to still work as intended, the semantic difference doesn't cause a difference in behavior. But I want to use u64_to_user_ptr() with a ternary operator in the argument, like so: u64_to_user_ptr(A ? B : C) This currently doesn't work as intended. Signed-off-by: Jann Horn <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Mukesh Ojha <[email protected]> Cc: Andrei Vagin <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Dan Carpenter <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: "H. Peter Anvin" <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Kees Cook <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: NeilBrown <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Qiaowei Ren <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: x86-ml <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2019-03-07linux/kernel.h: split *_MAX and *_MIN macros into <linux/limits.h>Masahiro Yamada1-28/+1
<linux/kernel.h> tends to be cluttered because we often put various sort of unrelated stuff in it. So, we have split out a sensible chunk of code into a separate header from time to time. This commit splits out the *_MAX and *_MIN defines. The standard header <limits.h> contains various MAX, MIN constants including numerial limits. [1] I think it makes sense to move in-kernel MAX, MIN constants into include/linux/limits.h. We already have include/uapi/linux/limits.h to contain some user-space constants. I changed its include guard to _UAPI_LINUX_LIMITS_H. This change has no impact to the user-space because scripts/headers_install.sh rips off the '_UAPI' prefix from the include guards of exported headers. [1] http://pubs.opengroup.org/onlinepubs/009604499/basedefs/limits.h.html Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Masahiro Yamada <[email protected]> Cc: Alex Elder <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: Zhang Yanmin <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-03-07linux/kernel.h: use 'short' to define USHRT_MAX, SHRT_MAX, SHRT_MINMasahiro Yamada1-3/+3
The commit log of 44f564a4bf6a ("ipc: add definitions of USHORT_MAX and others") did not explain why it used (s16) and (u16) instead of (short) and (unsigned short). Let's use (short) and (unsigned short), which is more sensible, and more consistent with the other MAX/MIN defines. As you see in include/uapi/asm-generic/int-ll64.h, s16/u16 are typedef'ed as signed/unsigned short. So, this commit does not have a functional change. Remove the unneeded parentheses around ~0U while we are here. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Masahiro Yamada <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: Zhang Yanmin <[email protected]> Cc: Alex Elder <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-03-07<linux/kernel.h>: drop the gcc-3.3 'const' hack in roundup()Randy Dunlap1-3/+1
The single quotation marks around "const" were causing a documentation markup warning with reST. Instead of fixing that warning, just delete that comment line and the gcc-3.3 hack of using "const" in the roundup() macro since gcc-3.3 is no longer supported for kernel builds. I did around 20 different $arch builds with no problems, but we'll just have to see if this causes problems for anyone else out there. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Randy Dunlap <[email protected]> Suggested-by: Matthew Wilcox <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-03-07kernel.h: unconditionally include asm/div64.h for do_div()Jani Nikula1-1/+1
Include asm/div64.h for do_div() usage in DIV_ROUND_DOWN_ULL() and DIV_ROUND_CLOSEST_ULL(). Remove the old CONFIG_LBDAF=y conditional include. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2019-02-19bpf: check that BPF programs run with preemption disabledPeter Zijlstra1-2/+12
Introduce cant_sleep() macro for annotation of functions that cannot sleep. Use it in BPF_PROG_RUN to catch execution of BPF programs in preemptable context. Suggested-by: Jann Horn <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Acked-by: Song Liu <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2019-01-04kernel/sysctl: add panic_print into sysctlFeng Tang1-0/+1
So that we can also runtime chose to print out the needed system info for panic, other than setting the kernel cmdline. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Feng Tang <[email protected]> Suggested-by: Steven Rostedt <[email protected]> Acked-by: Steven Rostedt (VMware) <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: John Stultz <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Kees Cook <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-08-22kernel.h: documentation for roundup() vs round_up()Kees Cook1-1/+34
Things like 3619dec5103d ("dh key: fix rounding up KDF output length") expose the lack of explicit documentation for roundup() vs round_up(). At least we can try to document it better if anyone goes looking. Link: http://lkml.kernel.org/r/20180703041950.GA43464@beast Signed-off-by: Kees Cook <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-06-21kernel.h: Fix a typo in commentWei Wang1-1/+1
Signed-off-by: Wei Wang <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Crt Mori <[email protected]> Cc: Josh Poimboeuf <[email protected]> Cc: Kees Cook <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Randy Dunlap <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://lkml.kernel.org/lkml/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2018-06-09Merge tag 'staging-4.18-rc1' of ↵Linus Torvalds1-0/+16
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging/IIO updates from Greg KH: "Here is the big staging and IIO driver update for 4.18-rc1. It was delayed as I wanted to make sure the final driver deletions did not cause any major merge issues, and all now looks good. There are a lot of patches here, just over 1000. The diffstat summary shows the major changes here: 1007 files changed, 16828 insertions(+), 227770 deletions(-) Because of this, we might be close to shrinking the overall kernel source code size for two releases in a row. There was loads of work in this release cycle, primarily: - tons of ks7010 driver cleanups - lots of mt7621 driver fixes and cleanups - most driver cleanups - wilc1000 fixes and cleanups - lots and lots of IIO driver cleanups and new additions - debugfs cleanups for all staging drivers - lots of other staging driver cleanups and fixes, the shortlog has the full details. but the big user-visable things here are the removal of 3 chunks of code: - ncpfs and ipx were removed on schedule, no one has cared about this code since it moved to staging last year, and if it needs to come back, it can be reverted. - lustre file system is removed. I've ranted at the lustre developers about once a year for the past 5 years, with no real forward progress at all to clean things up and get the code into the "real" part of the kernel. Given that the lustre developers continue to work on an external tree and try to port those changes to the in-kernel tree every once in a while, this whole thing really really is not working out at all. So I'm deleting it so that the developers can spend the time working in their out-of-tree location and get things cleaned up properly to get merged into the tree correctly at a later date. Because of these file removals, you will have merge issues on some of these files (2 in the ipx code, 1 in the ncpfs code, and 1 in the atomisp driver). Just delete those files, it's a simple merge :) All of this has been in linux-next for a while with no reported problems" * tag 'staging-4.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (1011 commits) staging: ipx: delete it from the tree ncpfs: remove uapi .h files ncpfs: remove Documentation ncpfs: remove compat functionality staging: ncpfs: delete it staging: lustre: delete the filesystem from the tree. staging: vc04_services: no need to save the log debufs dentries staging: vc04_services: vchiq_debugfs_log_entry can be a void * staging: vc04_services: remove struct vchiq_debugfs_info staging: vc04_services: move client dbg directory into static variable staging: vc04_services: remove odd vchiq_debugfs_top() wrapper staging: vc04_services: no need to check debugfs return values staging: mt7621-gpio: reorder includes alphabetically staging: mt7621-gpio: change gc_map to don't use pointers staging: mt7621-gpio: use GPIOF_DIR_OUT and GPIOF_DIR_IN macros instead of custom values staging: mt7621-gpio: change 'to_mediatek_gpio' to make just a one line return staging: mt7621-gpio: dt-bindings: update documentation for #interrupt-cells property staging: mt7621-gpio: update #interrupt-cells for the gpio node staging: mt7621-gpio: dt-bindings: complete documentation for the gpio staging: mt7621-dts: add missing properties to gpio node ...
2018-06-07mm/memblock: introduce PHYS_ADDR_MAXStefan Agner1-0/+1
So far code was using ULLONG_MAX and type casting to obtain a phys_addr_t with all bits set. The typecast is necessary to silence compiler warnings on 32-bit platforms. Use the simpler but still type safe approach "~(phys_addr_t)0" to create a preprocessor define for all bits set. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Stefan Agner <[email protected]> Suggested-by: Linus Torvalds <[email protected]> Acked-by: Michal Hocko <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Pavel Tatashin <[email protected]> Cc: Ard Biesheuvel <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-05-27PM / suspend: Prevent might sleep splatsThomas Gleixner1-0/+1
timekeeping suspend/resume calls read_persistent_clock() which takes rtc_lock. That results in might sleep warnings because at that point we run with interrupts disabled. We cannot convert rtc_lock to a raw spinlock as that would trigger other might sleep warnings. As a workaround we disable the might sleep warnings by setting system_state to SYSTEM_SUSPEND before calling sysdev_suspend() and restoring it to SYSTEM_RUNNING afer sysdev_resume(). There is no lock contention because hibernate / suspend to RAM is single-CPU at this point. In s2idle's case the system_state is set to SYSTEM_SUSPEND before timekeeping_suspend() which is invoked by the last CPU. In the resume case it set back to SYSTEM_RUNNING after timekeeping_resume() which is invoked by the first CPU in the resume case. The other CPUs will block on tick_freeze_lock. Signed-off-by: Thomas Gleixner <[email protected]> [bigeasy: cover s2idle in tick_freeze() / tick_unfreeze()] Signed-off-by: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
2018-04-26staging: kernel.h: Prevent macro expantion bug in container_of_safe()Dan Carpenter1-1/+1
There aren't many users of this so it doesn't cause a problem, but we obviously want to use "__mptr" here instead of "ptr" to prevent the parameter from being executed twice. Signed-off-by: Dan Carpenter <[email protected]> Acked-by: NeilBrown <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-04-23staging: lustre: add container_of_safe()NeilBrown1-0/+16
Luster has a container_of0() function which is similar to container_of() but passes an IS_ERR_OR_NULL() pointer through unchanged. This could be generally useful: bcache at last has a similar function. Naming is hard, but the precedent set by hlist_entry_safe() suggests a _safe suffix might be most consistent. So add container_of_safe() to kernel.h, and replace all occurrences of container_of0() with one of - list_first_entry, list_next_entry, when that is a better fit, - container_of(), when the pointer is used as a validpointer in surrounding code, - container_of_safe() when there is no obviously better alternative. Signed-off-by: NeilBrown <[email protected]> Reviewed-by: James Simmons <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-04-11taint: add taint for randstructKees Cook1-1/+2
Since the randstruct plugin can intentionally produce extremely unusual kernel structure layouts (even performance pathological ones), some maintainers want to be able to trivially determine if an Oops is coming from a randstruct-built kernel, so as to keep their sanity when debugging. This adds the new flag and initializes taint_mask immediately when built with randstruct. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Al Viro <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-04-11taint: convert to indexed initializationKees Cook1-0/+1
This converts to using indexed initializers instead of comments, adds a comment on why the taint flags can't be an enum, and make sure that no one forgets to update the taint_flags when adding new bits. Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Reviewed-by: Andrew Morton <[email protected]> Cc: Al Viro <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: Jonathan Corbet <[email protected]> Cc: Randy Dunlap <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-04-11proc: add seq_put_decimal_ull_width to speed up /proc/pid/smapsAndrei Vagin1-1/+2
seq_put_decimal_ull_w(m, str, val, width) prints a decimal number with a specified minimal field width. It is equivalent of seq_printf(m, "%s%*d", str, width, val), but it works much faster. == test_smaps.py num = 0 with open("/proc/1/smaps") as f: for x in xrange(10000): data = f.read() f.seek(0, 0) == == Before patch == $ time python test_smaps.py real 0m4.593s user 0m0.398s sys 0m4.158s == After patch == $ time python test_smaps.py real 0m3.828s user 0m0.413s sys 0m3.408s $ perf -g record python test_smaps.py == Before patch == - 79.01% 3.36% python [kernel.kallsyms] [k] show_smap.isra.33 - 75.65% show_smap.isra.33 + 48.85% seq_printf + 15.75% __walk_page_range + 9.70% show_map_vma.isra.23 0.61% seq_puts == After patch == - 75.51% 4.62% python [kernel.kallsyms] [k] show_smap.isra.33 - 70.88% show_smap.isra.33 + 24.82% seq_put_decimal_ull_w + 19.78% __walk_page_range + 12.74% seq_printf + 11.08% show_map_vma.isra.23 + 1.68% seq_puts [[email protected]: fix drivers/of/unittest.c build] Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Andrei Vagin <[email protected]> Cc: Alexey Dobriyan <[email protected]> Cc: KAMEZAWA Hiroyuki <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-04-09Fix subtle macro variable shadowing in min_not_zero()Linus Torvalds1-8/+9
Commit 3c8ba0d61d04 ("kernel.h: Retain constant expression output for max()/min()") rewrote our min/max macros to be very clever, but in the meantime resurrected a variable name shadow issue that we had had previously fixed in commit 589a9785ee3a ("min/max: remove sparse warnings when they're nested"). That commit talks about the sparse warnings that this shadowing causes, which we ignored as just a minor annoyance. But it turns out that the sparse warning is the least of our problems. We actually have a real bug due to the shadowing through the interaction with "min_not_zero()", which ends up doing min(__x, __y) internally, and then the new declaration of "__x" and "__y" as new variables in __cmp_once() results in a complete mess of an expression, and "min_not_zero()" doesn't work at all. For some odd reason, this only ever caused (reported) problems on s390, even though it is a generic issue and most of the (obviously successful) testing of the problematic commit had happened on other architectures. Quoting Sebastian Ott: "What happened is that the bio build by the partition detection code was attempted to be split by the block layer because the block queue had a max_sector setting of 0. blk_queue_max_hw_sectors uses min_not_zero." So re-introduce the use of __UNIQUE_ID() to make sure that the min/max macros do not have these kinds of clashes. [ That said, __UNIQUE_ID() itself has several issues that make it less than wonderful. In particular, the "uniqueness" has a fallback on the line number, which means that it's not actually unique in more complex cases if you don't build with gcc or clang (which have working unique counters that aren't tied to line numbers). That historical broken fallback also means that we have that pointless "prefix" argument that doesn't actually make much sense _except_ for the known-broken case. Oh well. ] Fixes: 3c8ba0d61d04 ("kernel.h: Retain constant expression output for max()/min()") Reported-and-tested-by: Sebastian Ott <[email protected]> Cc: Kees Cook <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Miguel Ojeda <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-04-05kernel.h: Retain constant expression output for max()/min()Kees Cook1-30/+41
In the effort to remove all VLAs from the kernel[1], it is desirable to build with -Wvla. However, this warning is overly pessimistic, in that it is only happy with stack array sizes that are declared as constant expressions, and not constant values. One case of this is the evaluation of the max() macro which, due to its construction, ends up converting constant expression arguments into a constant value result. All attempts to rewrite this macro with __builtin_constant_p() failed with older compilers (e.g. gcc 4.4)[2]. However, Martin Uecker, constructed[3] a mind-shattering solution that works everywhere. Cthulhu fhtagn! This patch updates the min()/max() macros to evaluate to a constant expression when called on constant expression arguments. This removes several false-positive stack VLA warnings from an x86 allmodconfig build when -Wvla is added: $ diff -u before.txt after.txt | grep ^- -drivers/input/touchscreen/cyttsp4_core.c:871:2: warning: ISO C90 forbids variable length array ‘ids’ [-Wvla] -fs/btrfs/tree-checker.c:344:4: warning: ISO C90 forbids variable length array ‘namebuf’ [-Wvla] -lib/vsprintf.c:747:2: warning: ISO C90 forbids variable length array ‘sym’ [-Wvla] -net/ipv4/proc.c:403:2: warning: ISO C90 forbids variable length array ‘buff’ [-Wvla] -net/ipv6/proc.c:198:2: warning: ISO C90 forbids variable length array ‘buff’ [-Wvla] -net/ipv6/proc.c:218:2: warning: ISO C90 forbids variable length array ‘buff64’ [-Wvla] This also updates two cases where different enums were being compared and explicitly casts them to int (which matches the old side-effect of the single-evaluation code): one in tpm/tpm_tis_core.h, and one in drm/drm_color_mgmt.c. [1] https://lkml.org/lkml/2018/3/7/621 [2] https://lkml.org/lkml/2018/3/10/170 [3] https://lkml.org/lkml/2018/3/20/845 Co-Developed-by: Linus Torvalds <[email protected]> Co-Developed-by: Martin Uecker <[email protected]> Signed-off-by: Kees Cook <[email protected]> Acked-by: Ingo Molnar <[email protected]> Acked-by: Miguel Ojeda <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2018-04-04Merge tag 'staging-4.17-rc1' of ↵Linus Torvalds1-0/+9
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging Pull staging/IIO updates from Greg KH: "Here is the big set of Staging/IIO driver patches for 4.17-rc1. It is a lot, over 500 changes, but not huge by previous kernel release standards. We deleted more lines than we added again (27k added vs. 91k remvoed), thanks to finally being able to delete the IRDA drivers and networking code. We also deleted the ccree crypto driver, but that's coming back in through the crypto tree to you, in a much cleaned-up form. Added this round is at lot of "mt7621" device support, which is for an embedded device that Neil Brown cares about, and of course a handful of new IIO drivers as well. And finally, the fsl-mc core code moved out of the staging tree to the "real" part of the kernel, which is nice to see happen as well. Full details are in the shortlog, which has all of the tiny cleanup patches described. All of these have been in linux-next for a while with no reported issues" * tag 'staging-4.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (579 commits) staging: rtl8723bs: Remove yield call, replace with cond_resched() staging: rtl8723bs: Replace yield() call with cond_resched() staging: rtl8723bs: Remove unecessary newlines from 'odm.h'. staging: rtl8723bs: Rework 'struct _ODM_Phy_Status_Info_' coding style. staging: rtl8723bs: Rework 'struct _ODM_Per_Pkt_Info_' coding style. staging: rtl8723bs: Replace NULL pointer comparison with '!'. staging: rtl8723bs: Factor out rtl8723bs_recv_tasklet() sections. staging: rtl8723bs: Fix function signature that goes over 80 characters. staging: rtl8723bs: Fix lines too long in update_recvframe_attrib(). staging: rtl8723bs: Remove unnecessary blank lines in 'rtl8723bs_recv.c'. staging: rtl8723bs: Change camel case to snake case in 'rtl8723bs_recv.c'. staging: rtl8723bs: Add missing braces in else statement. staging: rtl8723bs: Add spaces around ternary operators. staging: rtl8723bs: Fix lines with trailing open parentheses. staging: rtl8723bs: Remove unnecessary length #define's. staging: rtl8723bs: Fix IEEE80211 authentication algorithm constants. staging: rtl8723bs: Fix alignment in rtw_wx_set_auth(). staging: rtl8723bs: Remove braces from single statement conditionals. staging: rtl8723bs: Remove unecessary braces from switch statement. staging: rtl8723bs: Fix newlines in rtw_wx_set_auth(). ...
2018-03-28macro: introduce COUNT_ARGS() macroAlexei Starovoitov1-0/+7
move COUNT_ARGS() macro from apparmor to generic header and extend it to count till twelve. COUNT() was an alternative name for this logic, but it's used for different purpose in many other places. Similarly for CONCATENATE() macro. Suggested-by: Linus Torvalds <[email protected]> Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]>
2018-03-19Merge 4.16-rc6 into staging-nextGreg Kroah-Hartman1-0/+1
We want the staging fixes in here as well to handle merge/test issues. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2018-02-21extable: Make init_kernel_text() globalJosh Poimboeuf1-0/+1
Convert init_kernel_text() to a global function and use it in a few places instead of manually comparing _sinittext and _einittext. Note that kallsyms.h has a very similar function called is_kernel_inittext(), but its end check is inclusive. I'm not sure whether that's intentional behavior, so I didn't touch it. Suggested-by: Jason Baron <[email protected]> Signed-off-by: Josh Poimboeuf <[email protected]> Acked-by: Peter Zijlstra <[email protected]> Acked-by: Steven Rostedt (VMware) <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/4335d02be8d45ca7d265d2f174251d0b7ee6c5fd.1519051220.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <[email protected]>