- Nov 23, 2017
-
-
Borislav Petkov authored
In order to save on redundant structs definitions insn_get_code_seg_params() was made to return two 4-bit values in a char but clang complains: arch/x86/lib/insn-eval.c:780:10: warning: implicit conversion from 'int' to 'char' changes value from 132 to -124 [-Wconstant-conversion] return INSN_CODE_SEG_PARAMS(4, 8); ~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~ ./arch/x86/include/asm/insn-eval.h:16:57: note: expanded from macro 'INSN_CODE_SEG_PARAMS' #define INSN_CODE_SEG_PARAMS(oper_sz, addr_sz) (oper_sz | (addr_sz << 4)) Those two values do get picked apart afterwards the opposite way of how they were ORed so wrt to the LSByte, the return value is the same. But this function returns -EINVAL in the error case, which is an int. So make it return an int which is the native word size anyway and thus fix the clang warning. Reported-by:Kees Cook <keescook@google.com> Reported-by:
Nick Desaulniers <nick.desaulniers@gmail.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Cc: ricardo.neri-calderon@linux.intel.com Link: https://lkml.kernel.org/r/20171123091951.1462-1-bp@alien8.de
-
Chao Fan authored
There are two variables "rc" in mem_avoid_memmap. One at the top of the function and another one inside the while() loop. Drop the outer one as it is unused. Cleanup some whitespace damage while at it. Signed-off-by:
Chao Fan <fanc.fnst@cn.fujitsu.com> Signed-off-by:
-
Andy Lutomirski authored
Running this code with IRQs enabled (where dummy_lock is a spinlock): static void check_load_gs_index(void) { /* This will fail. */ load_gs_index(0xffff); spin_lock(&dummy_lock); spin_unlock(&dummy_lock); } Will generate a lockdep warning. The issue is that the actual write to %gs would cause an exception with IRQs disabled, and the exception handler would, as an inadvertent side effect, update irqflag tracing to reflect the IRQs-off status. native_load_gs_index() would then turn IRQs back on and return with irqflag tracing still thinking that IRQs were off. The dummy lock-and-unlock causes lockdep to notice the error and warn. Fix it by adding the missing tracing. Apparently nothing did this in a context where it mattered. I haven't tried to find a code path that would actually exhibit the warning if appropriately nasty user code were running. I suspect that the security impact of this bug is very, very low -- production systems don't run with lockdep enabled, and the warning is mostly harmless anyway. Found during a quick audit of the entry code to try to track down an unrelated bug that Ingo found in some still-in-development code. Signed-off-by:Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bpetkov@suse.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/e1aeb0e6ba8dd430ec36c8a35e63b429698b4132.1511411918.git.luto@kernel.org Signed-off-by:
Ingo Molnar <mingo@kernel.org>
-
- Nov 22, 2017
-
-
Andrey Ryabinin authored
[ Note, this commit is a cherry-picked version of: d17a1d97: ("x86/mm/kasan: don't use vmemmap_populate() to initialize shadow") ... for easier x86 entry code testing and back-porting. ] The KASAN shadow is currently mapped using vmemmap_populate() since that provides a semi-convenient way to map pages into init_top_pgt. However, since that no longer zeroes the mapped pages, it is not suitable for KASAN, which requires zeroed shadow memory. Add kasan_populate_shadow() interface and use it instead of vmemmap_populate(). Besides, this allows us to take advantage of gigantic pages and use them to populate the shadow, which should save us some memory wasted on page tables and reduce TLB pressure. Link: http://lkml.kernel.org/r/20171103185147.2688-2-pasha.tatashin@oracle.com Signed-off-by:Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by:
Pavel Tatashin <pasha.tatashin@oracle.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Steven Sistare <steven.sistare@oracle.com> Cc: Daniel Jordan <daniel.m.jordan@oracle.com> Cc: Bob Picco <bob.picco@oracle.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Alexander Potapenko <glider@google.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christian Borntraeger <borntraeger@de.ibm.com> Cc: David S. Miller <davem@davemloft.net> Cc: Dmitry Vyukov <dvyukov@google.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Matthew Wilcox <willy@infradead.org> Cc: Mel Gorman <mgorman@techsingularity.net> Cc: Michal Hocko <mhocko@kernel.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Andy Lutomirski authored
When I added entry_SYSCALL_64_after_hwframe(), I left TRACE_IRQS_OFF before it. This means that users of entry_SYSCALL_64_after_hwframe() were responsible for invoking TRACE_IRQS_OFF, and the one and only user (Xen, added in the same commit) got it wrong. I think this would manifest as a warning if a Xen PV guest with CONFIG_DEBUG_LOCKDEP=y were used with context tracking. (The context tracking bit is to cause lockdep to get invoked before we turn IRQs back on.) I haven't tested that for real yet because I can't get a kernel configured like that to boot at all on Xen PV. Move TRACE_IRQS_OFF below the label. Signed-off-by:
-
- Nov 21, 2017
-
-
Ricardo Neri authored
Print a rate-limited warning when a user-space program attempts to execute any of the instructions that UMIP protects (i.e., SGDT, SIDT, SLDT, STR and SMSW). This is useful, because when CONFIG_X86_INTEL_UMIP=y is selected and supported by the hardware, user space programs that try to execute such instructions will receive a SIGSEGV signal that they might not expect. In the specific cases for which emulation is provided (instructions SGDT, SIDT and SMSW in protected and virtual-8086 modes), no signal is generated. However, a warning is helpful to encourage updates in such programs to avoid the use of such instructions. Warnings are printed via a customized printk() function that also provides information about the program that attempted to use the affected instructions. Utility macros are defined to wrap umip_printk() for the error and warning kernel log levels. While here, replace an existing call to the generic rate-limited pr_err() with the new umip_pr_err(). Suggested-by:
Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Reviewed-by:
-
- Nov 17, 2017
-
-
Prarit Bhargava authored
A system booted with a small number of cores enabled per package panics because the estimate of __max_logical_packages is too low. This occurs when the total number of active cores across all packages is less than the maximum core count for a single package. e.g.: On a 4 package system with 20 cores/package where only 4 cores are enabled on each package, the value of __max_logical_packages is calculated as DIV_ROUND_UP(16 / 20) = 1 and not 4. Calculate __max_logical_packages after the cpu enumeration has completed. Use the boot cpu's data to extrapolate the number of packages. Signed-off-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
-
Andi Kleen authored
Analyzing large early boot allocations unveiled the logical package id storage as a prominent memory waste. Since commit 1f12e32f ("x86/topology: Create logical package id") every 64-bit system allocates a 128k array to convert logical package ids. This happens because the array is sized for MAX_LOCAL_APIC which is always 32k on 64bit systems, and it needs 4 bytes for each entry. This is fairly wasteful, especially for the common case of having only one socket, which uses exactly 4 byte out of 128K. There is no user of the package id map which is performance critical, so the lookup is not required to be O(1). Store the logical processor id in cpu_data and use a loop based lookup. To keep the mapping stable accross cpu hotplug operations, add a flag to cpu_data which is set when the CPU is brought up the first time. When the flag is set, then cpu_data is not reinitialized by copying boot_cpu_data on subsequent bringups. [ tglx: Rename the flag to 'initialized', use proper pointers instead of repeated cpu_data(x) evaluation and massage changelog. ] Signed-off-by:
Andi Kleen <ak@linux.intel.com> Signed-off-by:
-
Andi Kleen authored
The SNB-EP uncore driver is the only user of topology_phys_to_logical_pkg in a performance critical path. Change it query the logical pkg ID only once at initialization time and then cache it in box structure. This allows to change the logical package management without affecting the performance critical path. Signed-off-by:
-
Vikas C Sajjan authored
The new function mp_register_ioapic_irq() is a subset of the code in mp_override_legacy_irq(). Replace the code duplication by invoking mp_register_ioapic_irq() from mp_override_legacy_irq(). Signed-off-by:
Vikas C Sajjan <vikas.cha.sajjan@hpe.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: linux-pm@vger.kernel.org Cc: kkamagui@gmail.com Cc: linux-acpi@vger.kernel.org Link: https://lkml.kernel.org/r/1510848825-21965-3-git-send-email-vikas.cha.sajjan@hpe.com
-
Vikas C Sajjan authored
Platforms which support only IOAPIC mode, pass the SCI information above the legacy space (0-15) via the FADT mechanism and not via MADT. In such cases mp_override_legacy_irq() which is invoked from acpi_sci_ioapic_setup() to register SCI interrupts fails for interrupts greater equal 16, since it is meant to handle only the legacy space and emits error "Invalid bus_irq %u for legacy override". Add a new function to handle SCI interrupts >= 16 and invoke it conditionally in acpi_sci_ioapic_setup(). The code duplication due to this new function will be cleaned up in a separate patch. Co-developed-by:
Sunil V L <sunil.vl@hpe.com> Signed-off-by:
Abdul Lateef Attar <abdul-lateef.attar@hpe.com> Acked-by:
-
Tom Lendacky authored
When crosvm is used to boot a kernel as a VM, the SMP MP-table is found at physical address 0x0. This causes mpf_base to be set to 0 and a subsequent "if (!mpf_base)" check in default_get_smp_config() results in the MP-table not being parsed. Further into the boot this results in an oops when attempting a read_apic_id(). Add a boolean variable that is set to true when the MP-table is found. Use this variable for testing if the MP-table was found so that even a value of 0 for mpf_base will result in continued parsing of the MP-table. Fixes: 5997efb9 ("x86/boot: Use memremap() to map the MPF and MPC data") Reported-by:
Tomeu Vizoso <tomeu@tomeuvizoso.net> Signed-off-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
- Nov 16, 2017
-
-
Craig Bergstrom authored
One thing /dev/mem access APIs should verify is that there's no way that excessively large pfn's can leak into the high bits of the page table entry. In particular, if people can use "very large physical page addresses" through /dev/mem to set the bits past bit 58 - SOFTW4 and permission key bits and NX bit, that could *really* confuse the kernel. We had an earlier attempt: ce56a86e ("x86/mm: Limit mmap() of /dev/mem to valid physical addresses") ... which turned out to be too restrictive (breaking mem=... bootups for example) and had to be reverted in: 90edaac6 ("Revert "x86/mm: Limit mmap() of /dev/mem to valid physical addresses"") This v2 attempt modifies the original patch and makes sure that mmap(/dev/mem) limits the pfns so that it at least fits in the actual pteval_t architecturally: - Make sure mmap_mem() actually validates that the offset fits in phys_addr_t ( This may be indirectly true due to some other check, but it's not entirely obvious. ) - Change valid_mmap_phys_addr_range() to just use phys_addr_valid() on the top byte ( Top byte is sufficient, because mmap_mem() has already checked that it cannot wrap. ) - Add a few comments about what the valid_phys_addr_range() vs. valid_mmap_phys_addr_range() difference is. Signed-off-by:
Craig Bergstrom <craigb@google.com> [ Fixed the checks and added comments. ] Signed-off-by:
-
Kirill A. Shutemov authored
In case of 5-level paging, the kernel does not place any mapping above 47-bit, unless userspace explicitly asks for it. Userspace can request an allocation from the full address space by specifying the mmap address hint above 47-bit. Nicholas noticed that the current implementation violates this interface: If user space requests a mapping at the end of the 47-bit address space with a length which causes the mapping to cross the 47-bit border (DEFAULT_MAP_WINDOW), then the vma is partially in the address space below and above. Sanity check the mmap address hint so that start and end of the resulting vma are on the same side of the 47-bit border. If that's not the case fall back to the code path which ignores the address hint and allocate from the regular address space below 47-bit. To make the checks consistent, mask out the address hints lower bits (either PAGE_MASK or huge_page_mask()) instead of using ALIGN() which can push them up to the next boundary. [ tglx: Moved the address check to a function and massaged comment and changelog ] Reported-by:
Nicholas Piggin <npiggin@gmail.com> Signed-off-by:
Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by:
-
- Nov 14, 2017
-
-
Ricardo Neri authored
The STR and SLDT instructions are not emulated by the UMIP code, thus there's no functionality in the decoder to identify them. However, a subsequent commit will introduce a warning about the use of all the instructions that UMIP protect/changes, not only those that are emulated. A first step for that is to add the ability to decode/identify them. Plus, now that STR and SLDT are identified, we need to explicitly avoid their emulation (i.e., not rely on successful identification). Group together all the cases that we do not want to emulate: STR, SLDT and user long mode processes. Signed-off-by:
-
Ricardo Neri authored
Indicate that this feature has been enabled. Suggested-by:
-
Ricardo Neri authored
UMIP does cause any performance penalty to the vast majority of x86 code that does not use the legacy instructions affected by UMIP. Also describe UMIP more accurately and explain the behavior that can be expected by the (few) applications that use the affected instructions. Suggested-by:
-
Rafael J. Wysocki authored
Even though aperfmperf_snapshot_khz() caches the samples.khz value to return if called again in a sufficiently short time, its caller, arch_freq_get_on_cpu(), still uses smp_call_function_single() to run it which may allow user space to trigger an IPI storm by reading from the scaling_cur_freq cpufreq sysfs file in a tight loop. To avoid that, move the decision on whether or not to return the cached samples.khz value to arch_freq_get_on_cpu(). This change was part of commit 941f5f0f ("x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo"), but it was not the reason for the revert and it remains applicable. Fixes: 4815d3c5 (cpufreq: x86: Make scaling_cur_freq behave more as expected) Signed-off-by:
WANG Chao <chao.wang@ucloud.cn> Signed-off-by:
-
- Nov 12, 2017
-
-
Xiaochen Shen authored
Writing an invalid schemata with no domain values (e.g., "(L3|MB):"), results in a silent failure, i.e. the last_cmd_status returns OK, Check for an empty value and set the result string with a proper error message and return -EINVAL. Before the fix: # mkdir /sys/fs/resctrl/p1 # echo "L3:" > /sys/fs/resctrl/p1/schemata (silent failure) # cat /sys/fs/resctrl/info/last_cmd_status ok # echo "MB:" > /sys/fs/resctrl/p1/schemata (silent failure) # cat /sys/fs/resctrl/info/last_cmd_status ok After the fix: # mkdir /sys/fs/resctrl/p1 # echo "L3:" > /sys/fs/resctrl/p1/schemata -bash: echo: write error: Invalid argument # cat /sys/fs/resctrl/info/last_cmd_status Missing 'L3' value # echo "MB:" > /sys/fs/resctrl/p1/schemata -bash: echo: write error: Invalid argument # cat /sys/fs/resctrl/info/last_cmd_status Missing 'MB' value [ Tony: This is an unintended side effect of the patch earlier to allow the user to just write the value they want to change. While allowing user to specify less than all of the values, it also allows an empty value. ] Fixes: c4026b7b ("x86/intel_rdt: Implement "update" mode when writing schemata file") Signed-off-by:Xiaochen Shen <xiaochen.shen@intel.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Signed-off-by:
-
- Nov 10, 2017
-
-
Linus Torvalds authored
This reverts commit 941f5f0f. Sadly, it turns out that we really can't just do the cross-CPU IPI to all CPU's to get their proper frequencies, because it's much too expensive on systems with lots of cores. So we'll have to revert this for now, and revisit it using a smarter model (probably doing one system-wide IPI at open time, and doing all the frequency calculations in parallel). Reported-by:
-
Heiko Carstens authored
Rebooting into a new kernel with kexec fails (system dies) if tried on a machine that has no-execute support. Reason for this is that the so called datamover code gets executed with DAT on (MMU is active) and the page that contains the datamover is marked as non-executable. Therefore when branching into the datamover an unexpected program check happens and afterwards the machine is dead. This can be simply avoided by disabling DAT, which also disables any no-execute checks, just before the datamover gets executed. In fact the first thing done by the datamover is to disable DAT. The code in the datamover that disables DAT can be removed as well. Thanks to Michael Holzheu and Gerald Schaefer for tracking this down. Reviewed-by:
Michael Holzheu <holzheu@linux.vnet.ibm.com> Reviewed-by:
Philipp Rudo <prudo@linux.vnet.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Fixes: 57d7f939 ("s390: add no-execute support") Cc: <stable@vger.kernel.org> # v4.11+ Signed-off-by:
Heiko Carstens <heiko.carstens@de.ibm.com>
-
Heiko Carstens authored
Dan Horák reported the following crash related to transactional execution: User process fault: interruption code 0013 ilc:3 in libpthread-2.26.so[3ff93c00000+1b000] CPU: 2 PID: 1 Comm: /init Not tainted 4.13.4-300.fc27.s390x #1 Hardware name: IBM 2827 H43 400 (z/VM 6.4.0) task: 00000000fafc8000 task.stack: 00000000fafc4000 User PSW : 0705200180000000 000003ff93c14e70 R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:1 AS:0 CC:2 PM:0 RI:0 EA:3 User GPRS: 0000000000000077 000003ff00000000 000003ff93144d48 000003ff93144d5e 0000000000000000 0000000000000002 0000000000000000 000003ff00000000 0000000000000000 0000000000000418 0000000000000000 000003ffcc9fe770 000003ff93d28f50 000003ff9310acf0 000003ff92b0319a 000003ffcc9fe6d0 User Code: 000003ff93c14e62: 60e0b030 std %f14,48(%r11) 000003ff93c14e66: 60f0b038 std %f15,56(%r11) #000003ff93c14e6a: e5600000ff0e tbegin 0,65294 >000003ff93c14e70: a7740006 brc 7,3ff93c14e7c 000003ff93c14e74: a7080000 lhi %r0,0 000003ff93c14e78: a7f40023 brc 15,3ff93c14ebe 000003ff93c14e7c: b2220000 ipm %r0 000003ff93c14e80: 8800001c srl %r0,28 There are several bugs with control register handling with respect to transactional execution: - on task switch update_per_regs() is only called if the next task has an mm (is not a kernel thread). This however is incorrect. This breaks e.g. for user mode helper handling, where the kernel creates a kernel thread and then execve's a user space program. Control register contents related to transactional execution won't be updated on execve. If the previous task ran with transactional execution disabled then the new task will also run with transactional execution disabled, which is incorrect. Therefore call update_per_regs() unconditionally within switch_to(). - on startup the transactional execution facility is not enabled for the idle thread. This is not really a bug, but an inconsistency to other facilities. Therefore enable the facility if it is available. - on fork the new thread's per_flags field is not cleared. This means that a child process inherits the PER_FLAG_NO_TE flag. This flag can be set with a ptrace request to disable transactional execution for the current process. It should not be inherited by new child processes in order to be consistent with the handling of all other PER related debugging options. Therefore clear the per_flags field in copy_thread_tls(). Reported-and-tested-by:Dan Horák <dan@danny.cz> Fixes: d35339a4 ("s390: add support for transactional memory") Cc: <stable@vger.kernel.org> # v3.7+ Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Reviewed-by:
Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by:
Hendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by:
-
Michael Holzheu authored
Make use of the "stack_depth" tracking feature introduced with commit 8726679a ("bpf: teach verifier to track stack depth") for the s390 JIT, so that stack usage can be reduced. Signed-off-by:
-
Michael S. Tsirkin authored
MFENCE appears to be way slower than a locked instruction - let's use LOCK ADD unconditionally, as we always did on old 32-bit. Performance testing results: perf stat -r 10 -- ./virtio_ring_0_9 --sleep --host-affinity 0 --guest-affinity 0 Before: 0.922565990 seconds time elapsed ( +- 1.15% ) After: 0.578667024 seconds time elapsed ( +- 1.21% ) i.e. about ~60% faster. Just poking at SP would be the most natural, but if we then read the value from SP, we get a false dependency which will slow us down. This was noted in this article: http://shipilev.net/blog/2014/on-the-fence-with-dependencies/ And is easy to reproduce by sticking a barrier in a small non-inline function. So let's use a negative offset - which avoids this problem since we build with the red zone disabled. For userspace, use an address just below the redzone. The one difference between LOCK ADD and MFENCE is that LOCK ADD does not affect CLFLUSH, previous patches converted all uses of CLFLUSH to call mb(), such that changes to smp_mb() won't affect it. Update mb/rmb/wmb() on 32-bit to use the negative offset, too, for consistency. As a follow-up, it might be worth considering switching users of CLFLUSH to another API (e.g. clflush_mb()?) - we will then be able to convert mb() to smp_mb() again. Also arguably, GCC should switch to use LOCK ADD for __sync_synchronize(). This might be worth pursuing separately. Suggested-by:Andy Lutomirski <luto@amacapital.net> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Acked-by:
Peter Zijlstra <peterz@infradead.org> Acked-by:
-
Juergen Gross authored
In case we are booted via the default boot entry by a generic loader like grub or OVMF it is necessary to distinguish between a HVM guest with a device model supporting legacy devices and a PVH guest without device model. PVH guests will always have x86_platform.legacy.no_vga set and x86_platform.legacy.rtc cleared, while both won't be true for HVM guests. Test for both conditions in the guest_late_init hook and set xen_pvh to true if they are met. Move some of the early PVH initializations to the new hook in order to avoid duplicated code. Signed-off-by:
Juergen Gross <jgross@suse.com> Acked-by:
-
Juergen Gross authored
Add a new guest_late_init callback to the hypervisor_x86 structure. It will replace the current kvm_guest_init() call which is changed to make use of the new callback. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: kvm@vger.kernel.org Cc: rkrcmar@redhat.com Link: http://lkml.kernel.org/r/20171109132739.23465-5-jgross@suse.com Signed-off-by:
-
Juergen Gross authored
Add a test for ACPI_FADT_NO_VGA when scanning the FADT and set the new flag x86_platform.legacy.no_vga accordingly. Signed-off-by:
-
Juergen Gross authored
The x86_hyper pointer is only used for checking whether a virtual device is supporting the hypervisor the system is running on. Use an enum for that purpose instead and drop the x86_hyper pointer. Signed-off-by:
Xavier Deguillard <xdeguillard@vmware.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: akataria@vmware.com Cc: arnd@arndb.de Cc: boris.ostrovsky@oracle.com Cc: devel@linuxdriverproject.org Cc: dmitry.torokhov@gmail.com Cc: gregkh@linuxfoundation.org Cc: haiyangz@microsoft.com Cc: kvm@vger.kernel.org Cc: kys@microsoft.com Cc: linux-graphics-maintainer@vmware.com Cc: linux-input@vger.kernel.org Cc: moltmann@vmware.com Cc: pbonzini@redhat.com Cc: pv-drivers@vmware.com Cc: rkrcmar@redhat.com Cc: sthemmin@microsoft.com Cc: virtualization@lists.linux-foundation.org Cc: xen-devel@lists.xenproject.org Link: http://lkml.kernel.org/r/20171109132739.23465-3-jgross@suse.com Signed-off-by:
-
Juergen Gross authored
Instead of x86_hyper being either NULL on bare metal or a pointer to a struct hypervisor_x86 in case of the kernel running as a guest merge the struct into x86_platform and x86_init. This will remove the need for wrappers making it hard to find out what is being called. With dummy functions added for all callbacks testing for a NULL function pointer can be removed, too. Suggested-by:
-
Dou Liyang authored
These two functions are only called by tsc_init(), which is an __init function during boot time, so mark them __init as well. Signed-off-by:
Dou Liyang <douly.fnst@cn.fujitsu.com> Acked-by:
-
Alexander Shishkin authored
Commit: 9a93848f ("x86/debug: Implement __WARN() using UD0") turned warnings into UD0, but the fixup code only runs after the notify_die() chain. This is a problem, in particular, with kgdb, which kicks in as if it was a BUG(). Fix this by running the fixup code before the notifier chain in the invalid op handler path. Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Tested-by:
Ilya Dryomov <idryomov@gmail.com> Acked-by:
Daniel Thompson <daniel.thompson@linaro.org> Acked-by:
-
- Nov 09, 2017
-
-
Geert Uytterhoeven authored
Signed-off-by:Geert Uytterhoeven <geert@linux-m68k.org>
-
Finn Thain authored
The IOP interrupt handler iop_ism_irq() is used by the adb-iop driver to poll for ADB request completion. Unfortunately, it is not re-entrant. Fix the race condition by adding an iop_ism_irq_poll() function with suitable mutual exclusion. Tested-by:
Stan Johnson <userm57@yahoo.com> Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
-
Finn Thain authored
The Nubus subsystem should not be concerned with differences between VIA, RBV and OSS platforms. It should be portable across Macs and PowerMacs. This goal has implications for the initialization code relating to bus locking and slot interrupts. During Nubus initialization, bus transactions are "unlocked": on VIA2 and RBV machines, via_nubus_init() sets a bit in the via2[gBufB] register to allow bus-mastering Nubus cards to arbitrate for the bus. This happens upon subsys_initcall(nubus_init). But because nubus_init() has no effect on card state, this sequence is arbitrary. Moreover, when Penguin is used to boot Linux, the bus is already unlocked when Linux starts. On OSS machines there's no attempt to unlock Nubus transactions at all. (Maybe there's no benefit on that platform or maybe no-one knows how.) All of this demonstrates that there's no benefit in locking out bus-mastering cards, as yet. (If the need arises, we could lock the bus for the duration of a timing-critical operation.) NetBSD unlocks the Nubus early (at VIA initialization) and we can do the same. via_nubus_init() is also responsible for some VIA interrupt setup that should happen earlier than subsys_initcall(nubus_init). And actually, the Nubus subsystem need not be involved with slot interrupts: SLOT2IRQ works fine because Nubus slot IRQs are geographically assigned (regardless of platform). For certain platforms with PDS slots, some Nubus IRQs may be platform IRQs and this is not something that the NuBus subsystem should worry about. So let's invoke via_nubus_init() earlier and make the platform responsible for bus unlocking and interrupt setup instead of the NuBus subsystem. Tested-by:
-
Finn Thain authored
macintosh_config->via_type is meaningless on Mac IIfx (i.e. the only model with OSS chip), so skip the via_type switch statement. Call oss_init() before via_init() because it is more important and because that is the right place to initialize the oss_present flag. On this model, bringing forward oss_init() and delaying via_init() is no problem because those functions are independent. The only requirement here is that oss_register_interrupts() happens after via_init(). That is, mac_init_IRQ() happens after config_mac(). Tested-by:
-
Finn Thain authored
Log message fragments used to be printed on one line but now get split up. Fix this. Also, suppress log spam that merely prints known pointer values. Tested-by:
-
Kirill A. Shutemov authored
On machines with 5-level paging we don't want to allocate mapping above 47-bit unless user explicitly asked for it. See b569bab7 ("x86/mm: Prepare to expose larger address space to userspace") for details. c715b72c ("mm: revert x86_64 and arm64 ELF_ET_DYN_BASE base changes") broke the behaviour. After the commit elf binary and heap got mapped above 47-bits. Use DEFAULT_MAP_WINDOW instead of TASK_SIZE to determine ELF_ET_DYN_BASE so it's forced to be below 47-bits unconditionally. Fixes: c715b72c ("mm: revert x86_64 and arm64 ELF_ET_DYN_BASE base changes") Signed-off-by:
Michal Hocko <mhocko@suse.com> Cc: Kees Cook <keescook@chromium.org> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: linux-mm@kvack.org Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.kernel.org/r/20171107103804.47341-1-kirill.shutemov@linux.intel.com
-
Heiko Carstens authored
Just use MACHINE_HAS_TE to decide if HWCAP_S390_TE needs to be added to elf_hwcap. Suggested-by:
-
Christian Borntraeger authored
With commit 7fb2b2d5 ("s390/virtio: remove the old KVM virtio transport") the pre-ccw virtio transport for s390 was removed. To complete the removal the uapi header file that contains the related data structures must also be removed. Signed-off-by:
-
Changbin Du authored
This change suppresses the 'dd' output and adds the '-quiet' parameter to mkisofs tool. It also removes the 'Using ...' messages, as none of the messages matter to the user normally. "make V=1" can still be used for a more verbose build. The new build messages are now a streamlined set of: $ make isoimage ... Kernel: arch/x86/boot/bzImage is ready (#75) GENIMAGE arch/x86/boot/image.iso Kernel: arch/x86/boot/image.iso is ready Signed-off-by:Changbin Du <changbin.du@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/1510207751-22166-1-git-send-email-changbin.du@intel.com Signed-off-by:
-
