- 05 11月, 2017 1 次提交
-
-
由 Josh Poimboeuf 提交于
There have been some cases where external tooling (e.g., kpatch-build) creates a corrupt relocation which targets the wrong address. This is a silent failure which can corrupt memory in unexpected places. On x86, the bytes of data being overwritten by relocations are always initialized to zero beforehand. Use that knowledge to add sanity checks to detect such cases before they corrupt memory. Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: jeyu@kernel.org Cc: live-patching@vger.kernel.org Link: http://lkml.kernel.org/r/37450d6c6225e54db107fba447ce9e56e5f758e9.1509713553.git.jpoimboe@redhat.com [ Restructured the messages, as it's unclear whether the relocation or the target is corrupted. ] Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
- 04 11月, 2017 3 次提交
-
-
由 Andy Lutomirski 提交于
This reverts commit 43858b4f. The reason I removed the leave_mm() calls in question is because the heuristic wasn't needed after that patch. With the original version of my PCID series, we never flushed a "lazy cpu" (i.e. a CPU running kernel thread) due a flush on the loaded mm. Unfortunately, that caused architectural issues, so now I've reinstated these flushes on non-PCID systems in: commit b956575b ("x86/mm: Flush more aggressively in lazy TLB mode"). That, in turn, gives us a power management and occasionally performance regression as compared to old kernels: a process that goes into a deep idle state on a given CPU and gets its mm flushed due to activity on a different CPU will wake the idle CPU. Reinstate the old ugly heuristic: if a CPU goes into ACPI C3 or an intel_idle state that is likely to cause a TLB flush gets its mm switched to init_mm before going idle. FWIW, this heuristic is lousy. Whether we should change CR3 before idle isn't a good hint except insofar as the performance hit is a bit lower if the TLB is getting flushed by the idle code anyway. What we really want to know is whether we anticipate being idle long enough that the mm is likely to be flushed before we wake up. This is more a matter of the expected latency than the idle state that gets chosen. This heuristic also completely fails on systems that don't know whether the TLB will be flushed (e.g. AMD systems?). OTOH it may be a bit obsolete anyway -- PCID systems don't presently benefit from this heuristic at all. We also shouldn't do this callback from innermost bit of the idle code due to the RCU nastiness it causes. All the information need is available before rcu_idle_enter() needs to happen. Signed-off-by: NAndy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Borislav Petkov <bpetkov@suse.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.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> Fixes: 43858b4f "x86/mm: Stop calling leave_mm() in idle code" Link: http://lkml.kernel.org/r/c513bbd4e653747213e05bc7062de000bf0202a5.1509793738.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Chris Metcalf 提交于
set_state_oneshot_stopped() is called by the clkevt core, when the next event is required at an expiry time of 'KTIME_MAX'. This normally happens with NO_HZ_{IDLE|FULL} in both LOWRES/HIGHRES modes. This patch makes the clockevent device to stop on such an event, to avoid spurious interrupts, as explained by: commit 8fff52fd ("clockevents: Introduce CLOCK_EVT_STATE_ONESHOT_STOPPED state"). Signed-off-by: NChris Metcalf <cmetcalf@mellanox.com>
-
由 Paul Burton 提交于
MIPS will soon not be a part of Imagination Technologies, and as such many @imgtec.com email addresses will no longer be valid. This patch updates the addresses for those who: - Have 10 or more patches in mainline authored using an @imgtec.com email address, or any patches dated within the past year. - Are still with Imagination but leaving as part of the MIPS business unit, as determined from an internal email address list. - Haven't already updated their email address (ie. JamesH) or expressed a desire to be excluded (ie. Maciej). - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt & myself. New addresses are of the form firstname.lastname@mips.com, and all verified against an internal email address list. An entry is added to .mailmap for each person such that get_maintainer.pl will report the new addresses rather than @imgtec.com addresses which will soon be dead. Instances of the affected addresses throughout the tree are then mechanically replaced with the new @mips.com address. Signed-off-by: NPaul Burton <paul.burton@mips.com> Cc: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com> Cc: Deng-Cheng Zhu <dengcheng.zhu@mips.com> Acked-by: NDengcheng Zhu <dengcheng.zhu@mips.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Matt Redfearn <matt.redfearn@mips.com> Acked-by: NMatt Redfearn <matt.redfearn@mips.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: trivial@kernel.org Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 03 11月, 2017 9 次提交
-
-
由 Rafael J. Wysocki 提交于
Commit 890da9cf (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"") is not sufficient to restore the previous behavior of "cpu MHz" in /proc/cpuinfo on x86 due to some changes made after the commit it has reverted. To address this, make the code in question use arch_freq_get_on_cpu() which also is used by cpufreq for reporting the current frequency of CPUs and since that function doesn't really depend on cpufreq in any way, drop the CONFIG_CPU_FREQ dependency for the object file containing it. Also refactor arch_freq_get_on_cpu() somewhat to avoid IPIs and return cached values right away if it is called very often over a short time (to prevent user space from triggering IPI storms through it). Fixes: 890da9cf (Revert "x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz"") Cc: stable@kernel.org # 4.13 - together with 890da9cfSigned-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Andrey Ryabinin 提交于
struct sha1_ctx_mgr allocated in sha1_mb_mod_init() via kzalloc() and later passed in sha1_mb_flusher_mgr_flush_avx2() function where instructions vmovdqa used to access the struct. vmovdqa requires 16-bytes aligned argument, but nothing guarantees that struct sha1_ctx_mgr will have that alignment. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: 2249cbb5 ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2") Signed-off-by: NAndrey Ryabinin <aryabinin@virtuozzo.com> Cc: <stable@vger.kernel.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Andrey Ryabinin 提交于
struct sha256_ctx_mgr allocated in sha256_mb_mod_init() via kzalloc() and later passed in sha256_mb_flusher_mgr_flush_avx2() function where instructions vmovdqa used to access the struct. vmovdqa requires 16-bytes aligned argument, but nothing guarantees that struct sha256_ctx_mgr will have that alignment. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: a377c6b1 ("crypto: sha256-mb - submit/flush routines for AVX2") Reported-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NAndrey Ryabinin <aryabinin@virtuozzo.com> Cc: <stable@vger.kernel.org> Acked-by: Tim Chen Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Madhavan Srinivasan 提交于
Call trace observed during boot: nest_capp0_imc performance monitor hardware support registered nest_capp1_imc performance monitor hardware support registered core_imc memory allocation for cpu 56 failed Unable to handle kernel paging request for data at address 0xffa400010 Faulting instruction address: 0xc000000000bf3294 0:mon> e cpu 0x0: Vector: 300 (Data Access) at [c000000ff38ff8d0] pc: c000000000bf3294: mutex_lock+0x34/0x90 lr: c000000000bf3288: mutex_lock+0x28/0x90 sp: c000000ff38ffb50 msr: 9000000002009033 dar: ffa400010 dsisr: 80000 current = 0xc000000ff383de00 paca = 0xc000000007ae0000 softe: 0 irq_happened: 0x01 pid = 13, comm = cpuhp/0 Linux version 4.11.0-39.el7a.ppc64le (mockbuild@ppc-058.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) ) #1 SMP Tue Oct 3 07:42:44 EDT 2017 0:mon> t [c000000ff38ffb80] c0000000002ddfac perf_pmu_migrate_context+0xac/0x470 [c000000ff38ffc40] c00000000011385c ppc_core_imc_cpu_offline+0x1ac/0x1e0 [c000000ff38ffc90] c000000000125758 cpuhp_invoke_callback+0x198/0x5d0 [c000000ff38ffd00] c00000000012782c cpuhp_thread_fun+0x8c/0x3d0 [c000000ff38ffd60] c0000000001678d0 smpboot_thread_fn+0x290/0x2a0 [c000000ff38ffdc0] c00000000015ee78 kthread+0x168/0x1b0 [c000000ff38ffe30] c00000000000b368 ret_from_kernel_thread+0x5c/0x74 While registering the cpuhoplug callbacks for core-imc, if we fails in the cpuhotplug online path for any random core (either because opal call to initialize the core-imc counters fails or because memory allocation fails for that core), ppc_core_imc_cpu_offline() will get invoked for other cpus who successfully returned from cpuhotplug online path. But in the ppc_core_imc_cpu_offline() path we are trying to migrate the event context, when core-imc counters are not even initialized. Thus creating the above stack dump. Add a check to see if core-imc counters are enabled or not in the cpuhotplug offline path before migrating the context to handle this failing scenario. Fixes: 885dcd70 ("powerpc/perf: Add nest IMC PMU support") Signed-off-by: NMadhavan Srinivasan <maddy@linux.vnet.ibm.com> Signed-off-by: NAnju T Sudhakar <anju@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Linus Torvalds 提交于
This reverts commit 51204e06. There wasn't really any good reason for it, and people are complaining (rightly) that it broke existing practice. Cc: Len Brown <len.brown@intel.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Mark Rutland 提交于
It's possible for a user to deliberately trigger __dump_instr with a chosen kernel address. Let's avoid problems resulting from this by using get_user() rather than __get_user(), ensuring that we don't erroneously access kernel memory. Where we use __dump_instr() on kernel text, we already switch to KERNEL_DS, so this shouldn't adversely affect those cases. Fixes: 60ffc30d ("arm64: Exception handling") Cc: stable@vger.kernel.org Acked-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NMark Rutland <mark.rutland@arm.com> Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
-
由 Jan H. Schönherr 提交于
In kvm_apic_set_state() we update the hardware virtualized APIC after the full APIC state has been overwritten. Do the same, when the full APIC state has been reset in kvm_lapic_reset(). This updates some hardware state that was previously forgotten, as far as I can tell. Also, this allows removing some APIC-related reset code from vmx_vcpu_reset(). Signed-off-by: NJan H. Schönherr <jschoenh@amazon.de> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Jan H. Schönherr 提交于
Parts of the posted interrupt descriptor configure host behavior, such as the notification vector and destination. Overwriting them with zero as done during vCPU reset breaks posted interrupts. KVM (re-)writes these fields on certain occasions and belatedly fixes the situation in many cases. However, if you have a guest configured with "idle=poll", for example, the fields might stay zero forever. Do not reset the full descriptor in vmx_vcpu_reset(). Instead, reset only the outstanding notifications and leave everything else untouched. Signed-off-by: NJan H. Schönherr <jschoenh@amazon.de> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Jason Gunthorpe 提交于
kvm does not support setting the RTC, so the correct result is -ENODEV. Returning -1 will cause sync_cmos_clock to keep trying to set the RTC every second. Signed-off-by: NJason Gunthorpe <jgg@ziepe.ca> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 02 11月, 2017 10 次提交
-
-
由 Marcin Nowakowski 提交于
MIPS is no longer part of Imagination Technologies and my @imgtec.com address will soon stop working. Update any files containing my address as well as the .mailmap to point to my new @mips.com address. Signed-off-by: NMarcin Nowakowski <marcin.nowakowski@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/17579/Signed-off-by: NJames Hogan <jhogan@kernel.org>
-
由 Greg Kroah-Hartman 提交于
Many user space API headers have licensing information, which is either incomplete, badly formatted or just a shorthand for referring to the license under which the file is supposed to be. This makes it hard for compliance tools to determine the correct license. Update these files with an SPDX license identifier. The identifier was chosen based on the license information in the file. GPL/LGPL licensed headers get the matching GPL/LGPL SPDX license identifier with the added 'WITH Linux-syscall-note' exception, which is the officially assigned exception identifier for the kernel syscall exception: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". This exception makes it possible to include GPL headers into non GPL code, without confusing license compliance tools. Headers which have either explicit dual licensing or are just licensed under a non GPL license are updated with the corresponding SPDX identifier and the GPLv2 with syscall exception identifier. The format is: ((GPL-2.0 WITH Linux-syscall-note) OR SPDX-ID-OF-OTHER-LICENSE) SPDX license identifiers are a legally binding shorthand, which can be used instead of the full boiler plate text. The update does not remove existing license information as this has to be done on a case by case basis and the copyright holders might have to be consulted. This will happen in a separate step. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. See the previous patch in this series for the methodology of how this patch was researched. Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
Many user space API headers are missing licensing information, which makes it hard for compliance tools to determine the correct license. By default are files without license information under the default license of the kernel, which is GPLV2. Marking them GPLV2 would exclude them from being included in non GPLV2 code, which is obviously not intended. The user space API headers fall under the syscall exception which is in the kernels COPYING file: NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". otherwise syscall usage would not be possible. Update the files which contain no license information with an SPDX license identifier. The chosen identifier is 'GPL-2.0 WITH Linux-syscall-note' which is the officially assigned identifier for the Linux syscall exception. SPDX license identifiers are a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. See the previous patch in this series for the methodology of how this patch was researched. Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Greg Kroah-Hartman 提交于
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license 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 binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the 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 cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base 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 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately 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 license identifiers 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 the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version 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 correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
由 Russell King 提交于
Add an additional symbol to the decompressor image, which will allow future debugging of non-bootable problems similar to the one encountered with the EFI stub. Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
由 James Hogan 提交于
The smp-cmp build has been (further) broken since commit 856fbcee ("MIPS: Store core & VP IDs in GlobalNumber-style variable") in v4.14-rc1 like so: arch/mips/kernel/smp-cmp.c: In function ‘cmp_init_secondary’: arch/mips/kernel/smp-cmp.c:53:4: error: ‘struct cpuinfo_mips’ has no member named ‘vpe_id’ c->vpe_id = (read_c0_tcbind() >> TCBIND_CURVPE_SHIFT) & ^ Fix by replacing vpe_id with cpu_set_vpe_id(). Fixes: 856fbcee ("MIPS: Store core & VP IDs in GlobalNumber-style variable") Signed-off-by: NJames Hogan <jhogan@kernel.org> Reviewed-by: NPaul Burton <paul.burton@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17569/Signed-off-by: NJames Hogan <jhogan@kernel.org>
-
由 Jason A. Donenfeld 提交于
When task_struct was moved, this MIPS code was neglected. Evidently nobody is using it anymore. This fixes this build error: In file included from ./arch/mips/include/asm/thread_info.h:15:0, from ./include/linux/thread_info.h:37, from ./include/asm-generic/current.h:4, from ./arch/mips/include/generated/asm/current.h:1, from ./include/linux/sched.h:11, from arch/mips/kernel/smp-cmp.c:22: arch/mips/kernel/smp-cmp.c: In function ‘cmp_boot_secondary’: ./arch/mips/include/asm/processor.h:384:41: error: implicit declaration of function ‘task_stack_page’ [-Werror=implicit-function-declaration] #define __KSTK_TOS(tsk) ((unsigned long)task_stack_page(tsk) + \ ^ arch/mips/kernel/smp-cmp.c:84:21: note: in expansion of macro ‘__KSTK_TOS’ unsigned long sp = __KSTK_TOS(idle); ^~~~~~~~~~ Fixes: f3ac6067 ("sched/headers: Move task-stack related APIs from <linux/sched.h> to <linux/sched/task_stack.h>") Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com> Cc: <stable@vger.kernel.org> # 4.11+ Patchwork: https://patchwork.linux-mips.org/patch/17522/Signed-off-by: NJames Hogan <jhogan@kernel.org>
-
由 Matt Redfearn 提交于
Commit 1ec9dd80 ("MIPS: CPS: Detect CPUs in secondary clusters") added a check in cps_boot_secondary() that the secondary being booted is in the same cluster as the CPU running this code. This check is performed using current_cpu_data without disabling preemption. As such when CONFIG_PREEMPT=y, a BUG is triggered: [ 57.991693] BUG: using smp_processor_id() in preemptible [00000000] code: hotplug/1749 <snip> [ 58.063077] Call Trace: [ 58.065842] [<8040cdb4>] show_stack+0x84/0x114 [ 58.070830] [<80b11b38>] dump_stack+0xf8/0x140 [ 58.075796] [<8079b12c>] check_preemption_disabled+0xec/0x118 [ 58.082204] [<80415110>] cps_boot_secondary+0x84/0x44c [ 58.087935] [<80413a14>] __cpu_up+0x34/0x98 [ 58.092624] [<80434240>] bringup_cpu+0x38/0x114 [ 58.097680] [<80434af0>] cpuhp_invoke_callback+0x168/0x8f0 [ 58.103801] [<804362d0>] _cpu_up+0x154/0x1c8 [ 58.108565] [<804363dc>] do_cpu_up+0x98/0xa8 [ 58.113333] [<808261f8>] device_online+0x84/0xc0 [ 58.118481] [<80826294>] online_store+0x60/0x98 [ 58.123562] [<8062261c>] kernfs_fop_write+0x158/0x1d4 [ 58.129196] [<805a2ae4>] __vfs_write+0x4c/0x168 [ 58.134247] [<805a2dc8>] vfs_write+0xe0/0x190 [ 58.139095] [<805a2fe0>] SyS_write+0x68/0xc4 [ 58.143854] [<80415d58>] syscall_common+0x34/0x58 In reality we don't currently support running the kernel on CPUs not in cluster 0, so the answer to cpu_cluster(¤t_cpu_data) will always be 0, even if this task being preempted and continues running on a different CPU. Regardless, the BUG should not be triggered, so fix this by switching to raw_current_cpu_data. When multicluster support lands upstream this check will need removing or changing anyway. Fixes: 1ec9dd80 ("MIPS: CPS: Detect CPUs in secondary clusters") Signed-off-by: NMatt Redfearn <matt.redfearn@mips.com> Reviewed-by: NPaul Burton <paul.burton@mips.com> CC: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17563/Signed-off-by: NJames Hogan <jhogan@kernel.org>
-
由 Borislav Petkov 提交于
Jeremy reported a suspicious RCU usage warning in mcelog. /dev/mcelog is called in process context now as part of the notifier chain and doesn't need any of the fancy RCU and lockless accesses which it did in atomic context. Axe it all in favor of a simple mutex synchronization which cures the problem reported. Fixes: 5de97c9f ("x86/mce: Factor out and deprecate the /dev/mcelog driver") Reported-by: NJeremy Cline <jcline@redhat.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Reviewed-and-tested-by: NTony Luck <tony.luck@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: linux-edac@vger.kernel.org Cc: Laura Abbott <labbott@redhat.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20171101164754.xzzmskl4ngrqc5br@pd.tnic Link: https://bugzilla.redhat.com/show_bug.cgi?id=1498969
-
由 Luc Van Oostenryck 提交于
ARM depends on the macros '__ARMEL__' & '__ARMEB__' being defined or not to correctly select or define endian-specific macros, structures or pieces of code. These macros are predefined by the compiler but sparse knows nothing about them and thus may pre-process files differently from what gcc would. Fix this by passing '-D__ARMEL__' or '-D__ARMEB__' to sparse, depending on the endianness of the kernel, like defined by GCC. Note: In most case it won't change anything since most ARMs use little-endian (but an allyesconfig would use big-endian!). To: Russell King <linux@armlinux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
-
- 01 11月, 2017 12 次提交
-
-
由 Vlastimil Babka 提交于
Syzkaller with KASAN has reported a use-after-free of vma->vm_flags in __do_page_fault() with the following reproducer: mmap(&(0x7f0000000000/0xfff000)=nil, 0xfff000, 0x3, 0x32, 0xffffffffffffffff, 0x0) mmap(&(0x7f0000011000/0x3000)=nil, 0x3000, 0x1, 0x32, 0xffffffffffffffff, 0x0) r0 = userfaultfd(0x0) ioctl$UFFDIO_API(r0, 0xc018aa3f, &(0x7f0000002000-0x18)={0xaa, 0x0, 0x0}) ioctl$UFFDIO_REGISTER(r0, 0xc020aa00, &(0x7f0000019000)={{&(0x7f0000012000/0x2000)=nil, 0x2000}, 0x1, 0x0}) r1 = gettid() syz_open_dev$evdev(&(0x7f0000013000-0x12)="2f6465762f696e7075742f6576656e742300", 0x0, 0x0) tkill(r1, 0x7) The vma should be pinned by mmap_sem, but handle_userfault() might (in a return to userspace scenario) release it and then acquire again, so when we return to __do_page_fault() (with other result than VM_FAULT_RETRY), the vma might be gone. Specifically, per Andrea the scenario is "A return to userland to repeat the page fault later with a VM_FAULT_NOPAGE retval (potentially after handling any pending signal during the return to userland). The return to userland is identified whenever FAULT_FLAG_USER|FAULT_FLAG_KILLABLE are both set in vmf->flags" However, since commit a3c4fb7c ("x86/mm: Fix fault error path using unsafe vma pointer") there is a vma_pkey() read of vma->vm_flags after that point, which can thus become use-after-free. Fix this by moving the read before calling handle_mm_fault(). Reported-by: Nsyzbot <bot+6a5269ce759a7bb12754ed9622076dc93f65a1f6@syzkaller.appspotmail.com> Reported-by: NDmitry Vyukov <dvyukov@google.com> Suggested-by: NKirill A. Shutemov <kirill@shutemov.name> Fixes: 3c4fb7c9c2e ("x86/mm: Fix fault error path using unsafe vma pointer") Reviewed-by: NAndrea Arcangeli <aarcange@redhat.com> Signed-off-by: NVlastimil Babka <vbabka@suse.cz> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Naveen N. Rao 提交于
This makes the changes introduced in commit 83e840c7 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols") to be specific to the kprobe subsystem. We previously changed ppc_function_entry() to always check the provided address to confirm if it needed to be dereferenced. This is actually only an issue for kprobe blacklisted asm labels (through use of _ASM_NOKPROBE_SYMBOL) and can cause other issues with ftrace. Also, the additional checks are not really necessary for our other uses. As such, move this check to the kprobes subsystem. Fixes: 83e840c7 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols") Cc: stable@vger.kernel.org # v4.13+ Signed-off-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Naveen N. Rao 提交于
This reverts commit 83e840c7 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols"). Chandan reported that on newer kernels, trying to enable function_graph tracer on ppc64 (BE) locks up the system with the following trace: Unable to handle kernel paging request for data at address 0x600000002fa30010 Faulting instruction address: 0xc0000000001f1300 Thread overran stack, or stack corrupted Oops: Kernel access of bad area, sig: 11 [#1] BE SMP NR_CPUS=2048 DEBUG_PAGEALLOC NUMA pSeries Modules linked in: CPU: 1 PID: 6586 Comm: bash Not tainted 4.14.0-rc3-00162-g6e51f1f-dirty #20 task: c000000625c07200 task.stack: c000000625c07310 NIP: c0000000001f1300 LR: c000000000121cac CTR: c000000000061af8 REGS: c000000625c088c0 TRAP: 0380 Not tainted (4.14.0-rc3-00162-g6e51f1f-dirty) MSR: 8000000000001032 <SF,ME,IR,DR,RI> CR: 28002848 XER: 00000000 CFAR: c0000000001f1320 SOFTE: 0 ... NIP [c0000000001f1300] .__is_insn_slot_addr+0x30/0x90 LR [c000000000121cac] .kernel_text_address+0x18c/0x1c0 Call Trace: [c000000625c08b40] [c0000000001bd040] .is_module_text_address+0x20/0x40 (unreliable) [c000000625c08bc0] [c000000000121cac] .kernel_text_address+0x18c/0x1c0 [c000000625c08c50] [c000000000061960] .prepare_ftrace_return+0x50/0x130 [c000000625c08cf0] [c000000000061b10] .ftrace_graph_caller+0x14/0x34 [c000000625c08d60] [c000000000121b40] .kernel_text_address+0x20/0x1c0 [c000000625c08df0] [c000000000061960] .prepare_ftrace_return+0x50/0x130 ... [c000000625c0ab30] [c000000000061960] .prepare_ftrace_return+0x50/0x130 [c000000625c0abd0] [c000000000061b10] .ftrace_graph_caller+0x14/0x34 [c000000625c0ac40] [c000000000121b40] .kernel_text_address+0x20/0x1c0 [c000000625c0acd0] [c000000000061960] .prepare_ftrace_return+0x50/0x130 [c000000625c0ad70] [c000000000061b10] .ftrace_graph_caller+0x14/0x34 [c000000625c0ade0] [c000000000121b40] .kernel_text_address+0x20/0x1c0 This is because ftrace is using ppc_function_entry() for obtaining the address of return_to_handler() in prepare_ftrace_return(). The call to kernel_text_address() itself gets traced and we end up in a recursive loop. Fixes: 83e840c7 ("powerpc64/elfv1: Only dereference function descriptor for non-text symbols") Cc: stable@vger.kernel.org # v4.13+ Reported-by: NChandan Rajendra <chandan@linux.vnet.ibm.com> Signed-off-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Matt Redfearn 提交于
Commit 6f542ebe ("MIPS: Fix race on setting and getting cpu_online_mask") effectively reverted commit 8f46cca1 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online") and thus has reinstated the possibility of deadlock. The commit was based on testing of kernel v4.4, where the CPU hotplug core code issued a BUG() if the starting CPU is not marked online when the boot CPU returns from __cpu_up. The commit fixes this race (in v4.4), but re-introduces the deadlock situation. As noted in the commit message, upstream differs in this area. Commit 8df3e07e ("cpu/hotplug: Let upcoming cpu bring itself fully up") adds a completion event in the CPU hotplug core code, making this race impossible. However, people were unhappy with relying on the core code to do the right thing. To address the issues both commits were trying to fix, add a second completion event in the MIPS smp hotplug path. It removes the possibility of a race, since the MIPS smp hotplug code now synchronises both the boot and secondary CPUs before they return to the hotplug core code. It also addresses the deadlock by ensuring that the secondary CPU is not marked online before it's counters are synchronised. This fix should also be backported to fix the race condition introduced by the backport of commit 8f46cca1 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online"), through really that race only existed before commit 8df3e07e ("cpu/hotplug: Let upcoming cpu bring itself fully up"). Signed-off-by: NMatt Redfearn <matt.redfearn@imgtec.com> Fixes: 6f542ebe ("MIPS: Fix race on setting and getting cpu_online_mask") CC: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com> Cc: <stable@vger.kernel.org> # v4.1+: 8f46cca1: "MIPS: SMP: Fix possibility of deadlock when bringing CPUs online" Cc: <stable@vger.kernel.org> # v4.1+: a00eeede: "MIPS: SMP: Use a completion event to signal CPU up" Cc: <stable@vger.kernel.org> # v4.1+: 6f542ebe: "MIPS: Fix race on setting and getting cpu_online_mask" Cc: <stable@vger.kernel.org> # v4.1+ Patchwork: https://patchwork.linux-mips.org/patch/17376/Signed-off-by: NJames Hogan <jhogan@kernel.org>
-
由 Wei Yongjun 提交于
Fix a typo in build_one_insn(). Fixes: b6bd53f9 ("MIPS: Add missing file for eBPF JIT.") Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com> Cc: <stable@vger.kernel.org> # 4.13+ Patchwork: https://patchwork.linux-mips.org/patch/17491/Signed-off-by: NJames Hogan <jhogan@kernel.org>
-
由 Gustavo A. R. Silva 提交于
It seems that this is a typo error and the proper bit masking is "RT | RS" instead of "RS | RS". This issue was detected with the help of Coccinelle. Fixes: d6b3314b ("MIPS: uasm: Add lh uam instruction") Reported-by: NJulia Lawall <julia.lawall@lip6.fr> Signed-off-by: NGustavo A. R. Silva <garsilva@embeddedor.com> Reviewed-by: NJames Hogan <jhogan@kernel.org> Cc: <stable@vger.kernel.org> # 3.16+ Patchwork: https://patchwork.linux-mips.org/patch/17551/Signed-off-by: NJames Hogan <jhogan@kernel.org>
-
由 Paul Burton 提交于
The default CM target field in the GCR_BASE register is encoded with 0 meaning memory & 1 being reserved. However the definitions we use for those bits effectively get these two values backwards - likely because they were copied from the definitions for the CM regions where the target is encoded differently. This results in use setting up GCR_BASE with the reserved target value by default, rather than targeting memory as intended. Although we currently seem to get away with this it's not a great idea to rely upon. Fix this by changing our macros to match the documentated target values. The incorrect encoding became used as of commit 9f98f3dd ("MIPS: Add generic CM probe & access code") in the Linux v3.15 cycle, and was likely carried forwards from older but unused code introduced by commit 39b8d525 ("[MIPS] Add support for MIPS CMP platform.") in the v2.6.26 cycle. Fixes: 9f98f3dd ("MIPS: Add generic CM probe & access code") Signed-off-by: NPaul Burton <paul.burton@mips.com> Reported-by: NMatt Redfearn <matt.redfearn@mips.com> Reviewed-by: NJames Hogan <jhogan@kernel.org> Cc: Matt Redfearn <matt.redfearn@mips.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: linux-mips@linux-mips.org Cc: <stable@vger.kernel.org> # v3.15+ Patchwork: https://patchwork.linux-mips.org/patch/17562/Signed-off-by: NJames Hogan <jhogan@kernel.org>
-
由 Matt Redfearn 提交于
Commit e83f7e02 ("MIPS: CPS: Have asm/mips-cps.h include CM & CPC headers") adds a #error to arch/mips/include/asm/mips-cpc.h if it is included directly. While this commit replaced almost all direct includes of mips-cm.h and mips-cpc.h, 2 remain. With some defconfigs, mips-cps.h is indirectly included before mips-cpc.h, but in others this results in compilation errors: In file included from arch/mips/generic/init.c:23:0: ./arch/mips/include/asm/mips-cpc.h:12:3: error: #error Please include asm/mips-cps.h rather than asm/mips-cpc.h # error Please include asm/mips-cps.h rather than asm/mips-cpc.h In file included from arch/mips/kernel/smp.c:23:0: ./arch/mips/include/asm/mips-cpc.h:12:3: error: #error Please include asm/mips-cps.h rather than asm/mips-cpc.h # error Please include asm/mips-cps.h rather than asm/mips-cpc.h In both cases, fix this by including mips-cps.h instead. Fixes: e83f7e02 ("MIPS: CPS: Have asm/mips-cps.h include CM & CPC headers") Signed-off-by: NMatt Redfearn <matt.redfearn@mips.com> Patchwork: https://patchwork.linux-mips.org/patch/17492/Signed-off-by: NJames Hogan <jhogan@kernel.org>
-
由 Matt Redfearn 提交于
Commit 9fef6868 ("MIPS: Make SAVE_SOME more standard") made several changes to the order in which registers are saved in the SAVE_SOME macro, used by exception handlers to save the processor state. In particular, it removed the move k1, sp in the delay slot of the branch testing if the processor is already in kernel mode. This is replaced later in the macro by a move k0, sp When CONFIG_EVA is disabled, this instruction actually appears in the delay slot of the branch. However, when CONFIG_EVA is enabled, instead the RPS workaround of MFC0 k0, CP0_ENTRYHI appears in the delay slot. This results in k0 not containing the stack pointer, but some unrelated value, which is then saved to the kernel stack. On exit from the exception, this bogus value is restored to the stack pointer, resulting in an OOPS. Fix this by moving the save of SP in k0 explicitly in the delay slot of the branch, outside of the CONFIG_EVA section, restoring the expected instruction ordering when CONFIG_EVA is active. Fixes: 9fef6868 ("MIPS: Make SAVE_SOME more standard") Signed-off-by: NMatt Redfearn <matt.redfearn@mips.com> Reported-by: NVladimir Kondratiev <vladimir.kondratiev@intel.com> Reviewed-by: NCorey Minyard <cminyard@mvista.com> Reviewed-by: NJames Hogan <jhogan@kernel.org> Patchwork: https://patchwork.linux-mips.org/patch/17471/Signed-off-by: NJames Hogan <jhogan@kernel.org>
-
由 James Hogan 提交于
Since commit 04a85e08 ("MIPS: generic: Move NI 169445 FIT image source to its own file"), a generic 32r2el_defconfig kernel fails to build with the following build error: ITB arch/mips/boot/vmlinux.gz.itb Error: arch/mips/boot/vmlinux.gz.its:111.1-2 syntax error FATAL ERROR: Unable to parse input tree mkimage Can't read arch/mips/boot/vmlinux.gz.itb.tmp: Invalid argument Fix arch/mips/generic/board-ni169445.its.S to include the necessary "/" node path before the first open brace. The original issue in arch/mips/generic/vmlinux.its.S was fixed directly in the original commit 7aacf86b ("MIPS: NI 169445 board support") after https://patchwork.linux-mips.org/patch/16941/ was submitted, but the separate its.S file wasn't correctly fixed when resolving the conflict in commit 04a85e08 ("MIPS: generic: Move NI 169445 FIT image source to its own file"). Fixes: 04a85e08 ("MIPS: generic: Move NI 169445 FIT image source to its own file") Signed-off-by: NJames Hogan <jhogan@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Paul Burton <paul.burton@mips.com> Cc: Nathan Sullivan <nathan.sullivan@ni.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/17561/Signed-off-by: NJames Hogan <jhogan@kernel.org>
-
由 Paul Burton 提交于
MIPS will soon not be a part of Imagination Technologies, and as such many @imgtec.com email addresses will no longer be valid. This patch updates the addresses for those who: - Have 10 or more patches in mainline authored using an @imgtec.com email address, or any patches dated within the past year. - Are still with Imagination but leaving as part of the MIPS business unit, as determined from an internal email address list. - Haven't already updated their email address (ie. JamesH) or expressed a desire to be excluded (ie. Maciej). - Acked v2 or earlier of this patch, which leaves Deng-Cheng, Matt & myself. New addresses are of the form firstname.lastname@mips.com, and all verified against an internal email address list. An entry is added to .mailmap for each person such that get_maintainer.pl will report the new addresses rather than @imgtec.com addresses which will soon be dead. Instances of the affected addresses throughout the tree are then mechanically replaced with the new @mips.com address. Signed-off-by: NPaul Burton <paul.burton@mips.com> Cc: Deng-Cheng Zhu <dengcheng.zhu@imgtec.com> Cc: Deng-Cheng Zhu <dengcheng.zhu@mips.com> Acked-by: NDengcheng Zhu <dengcheng.zhu@mips.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Matt Redfearn <matt.redfearn@mips.com> Acked-by: NMatt Redfearn <matt.redfearn@mips.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org Cc: trivial@kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17540/Signed-off-by: NJames Hogan <jhogan@kernel.org>
-
由 Luc Van Oostenryck 提交于
By default, sparse assumes a 64bit machine when compiled on x86-64 and 32bit when compiled on anything else. This can of course create all sort of problems, like issuing false warnings like: 'constant ... is so big it is unsigned long long' or 'shift too big (32) for type unsigned long' when the architecture is 64bit while sparse was compiled on a 32bit machine, or worse, to not emit legitimate warnings in the reverse situation. Fix this by passing to sparse the appropriate -m32/-m64 flag. To: Chris Metcalf <cmetcalf@mellanox.com> Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: NChris Metcalf <cmetcalf@mellanox.com>
-
- 27 10月, 2017 3 次提交
-
-
由 Ingo Molnar 提交于
This reverts commit ce56a86e. There's unanticipated interaction with some boot parameters like 'mem=', which now cause the new checks via valid_mmap_phys_addr_range() to be too restrictive, crashing a Qemu bootup in fact, as reported by Fengguang Wu. So while the motivation of the change is still entirely valid, we need a few more rounds of testing to get it right - it's way too late after -rc6, so revert it for now. Reported-by: NFengguang Wu <fengguang.wu@intel.com> Signed-off-by: NIngo Molnar <mingo@kernel.org> Acked-by: NCraig Bergstrom <craigb@google.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Luis R. Rodriguez <mcgrof@suse.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Toshi Kani <toshi.kani@hp.com> Cc: dsafonov@virtuozzo.com Cc: kirill.shutemov@linux.intel.com Cc: mhocko@suse.com Cc: oleg@redhat.com Cc: linux-kernel@vger.kernel.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
rwlock.h should not be included directly. Instead linux/splinlock.h should be included. One thing it does is to break the RT build. Cc: Stefano Stabellini <sstabellini@kernel.org> Cc: xen-devel@lists.xenproject.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de> Reviewed-by: NStefano Stabellini <sstabellini@kernel.org> Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
-
由 Lorenzo Pieralisi 提交于
The introduction of {map/swizzle}_irq() hooks in the struct pci_host_bridge allowed to replace the pci_fixup_irqs() PCI IRQ allocation in alpha arch PCI code with per-bridge map/swizzle functions with commit 0e4c2eeb ("alpha/PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks"). As a side effect of converting PCI IRQ allocation to the struct pci_host_bridge {map/swizzle}_irq() hooks mechanism, the actual PCI IRQ allocation function (ie pci_assign_irq()) is carried out per-device in pci_device_probe() that is called when a PCI device driver is about to be probed. This means that, for drivers compiled as loadable modules, the actual PCI device IRQ allocation can now happen after the system has booted so the struct pci_host_bridge {map/swizzle}_irq() hooks pci_assign_irq() relies on must stay valid after the system has booted so that PCI core can carry out PCI IRQ allocation correctly. Most of the alpha board structures pci_map_irq() and pci_swizzle() hooks (that are used to initialize their struct pci_host_bridge equivalent through the alpha_mv global variable - that represents the struct alpha_machine_vector of the running kernel) are marked as __init/__initdata; this causes freed memory dereferences when PCI IRQ allocation is carried out after the kernel has booted (ie when loading PCI drivers as loadable module) because when the kernel tries to bind the PCI device to its (module) driver, the function pci_assign_irq() is called, that in turn retrieves the struct pci_host_bridge {map/swizzle}_irq() hooks to carry out PCI IRQ allocation; if those hooks are marked as __init code/__initdata they point at freed/invalid memory. Fix the issue by removing the __init/__initdata markers from all subarch struct alpha_machine_vector.pci_map_irq()/pci_swizzle() functions (and data). Fixes: 0e4c2eeb ("alpha/PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks") Link: http://lkml.kernel.org/r/alpine.LRH.2.21.1710251043170.7098@math.ut.eeReported-by: NMeelis Roos <mroos@linux.ee> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Meelis Roos <mroos@linux.ee> Cc: Matt Turner <mattst88@gmail.com>
-
- 26 10月, 2017 2 次提交
-
-
由 Yan Markman 提交于
Under heavy system stress mvebu SoC using Cortex A9 sporadically encountered instability issues. The "double linefill" feature of L2 cache was identified as causing dependency between read and write which lead to the deadlock. Especially, it was the cause of deadlock seen under heavy PCIe traffic, as this dependency violates PCIE overtaking rule. Fixes: c8f5a878 ("ARM: mvebu: use DT properties to fine-tune the L2 configuration") Cc: stable@vger.kernel.org Signed-off-by: NYan Markman <ymarkman@marvell.com> Signed-off-by: NIgal Liberman <igall@marvell.com> Signed-off-by: NNadav Haklai <nadavh@marvell.com> [gregory.clement@free-electrons.com: reformulate commit log, add Armada 375 and add Fixes tag] Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
-
由 Nicholas Piggin 提交于
Fixes: 424de9c6 ("powerpc/mm/radix: Avoid flushing the PWC on every flush_tlb_range") Signed-off-by: NNicholas Piggin <npiggin@gmail.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-