summaryrefslogtreecommitdiffstats
path: root/drivers/net/nlmon.c (unfollow)
Commit message (Collapse)AuthorFilesLines
2017-05-31efi-pstore: Refactor erase routineKees Cook1-46/+38
Right now, every pass through the EFI variables during erase would build a copy of the old format variable name. Instead, try each name one time through the EFI variables list. Additionally bump up the buffer size to avoid truncation in pathological cases, and wipe the write name buffer. Signed-off-by: Kees Cook <keescook@chromium.org>
2017-05-31pstore: Avoid potential infinite loopKees Cook1-2/+6
If a backend does not correctly iterate through its records, pstore will get stuck loading entries. Detect this with a large record count, and announce if we ever hit the limit. This will let future backend reading bugs less annoying to debug. Additionally adjust the error about pstore_mkfile() failing. Signed-off-by: Kees Cook <keescook@chromium.org>
2017-05-31pstore: Fix leaked pstore_record in pstore_get_backend_records()Douglas Anderson1-1/+3
When the "if (record->size <= 0)" test is true in pstore_get_backend_records() it's pretty clear that nobody holds a reference to the allocated pstore_record, yet we don't free it. Let's free it. Fixes: 2a2b0acf768c ("pstore: Allocate records on heap instead of stack") Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org
2017-05-31pstore: Don't warn if data is uncompressed and type is not PSTORE_TYPE_DMESGAnkit Kumar1-1/+4
commit 9abdcccc3d5f ("pstore: Extract common arguments into structure") moved record decompression to function. decompress_record() gets called without checking type and compressed flag. Warning will be reported if data is uncompressed. Pstore type PSTORE_TYPE_PPC_OPAL, PSTORE_TYPE_PPC_COMMON doesn't contain compressed data and warning get printed part of dmesg. Partial dmesg log: [ 35.848914] pstore: ignored compressed record type 6 [ 35.848927] pstore: ignored compressed record type 8 Above warning should not get printed as it is known that data won't be compressed for above type and it is valid condition. This patch returns if data is not compressed and print warning only if data is compressed and type is not PSTORE_TYPE_DMESG. Reported-by: Anton Blanchard <anton@au1.ibm.com> Signed-off-by: Ankit Kumar <ankit@linux.vnet.ibm.com> Reviewed-by: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com> Signed-off-by: Kees Cook <keescook@chromium.org> Fixes: 9abdcccc3d5f ("pstore: Extract common arguments into structure") Cc: stable@vger.kernel.org
2017-05-29Linux 4.12-rc3v4.12-rc3Linus Torvalds1-1/+1
2017-05-27x86/ftrace: Make sure that ftrace trampolines are not RWXThomas Gleixner1-6/+14
ftrace use module_alloc() to allocate trampoline pages. The mapping of module_alloc() is RWX, which makes sense as the memory is written to right after allocation. But nothing makes these pages RO after writing to them. Add proper set_memory_rw/ro() calls to protect the trampolines after modification. Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1705251056410.1862@nanos Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2017-05-27x86/mm/ftrace: Do not bug in early boot on irqs_disabled in cpu_flush_range()Steven Rostedt (VMware)1-1/+1
With function tracing starting in early bootup and having its trampoline pages being read only, a bug triggered with the following: kernel BUG at arch/x86/mm/pageattr.c:189! invalid opcode: 0000 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 4.12.0-rc2-test+ #3 Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014 task: ffffffffb4222500 task.stack: ffffffffb4200000 RIP: 0010:change_page_attr_set_clr+0x269/0x302 RSP: 0000:ffffffffb4203c88 EFLAGS: 00010046 RAX: 0000000000000046 RBX: 0000000000000000 RCX: 00000001b6000000 RDX: ffffffffb4203d40 RSI: 0000000000000000 RDI: ffffffffb4240d60 RBP: ffffffffb4203d18 R08: 00000001b6000000 R09: 0000000000000001 R10: ffffffffb4203aa8 R11: 0000000000000003 R12: ffffffffc029b000 R13: ffffffffb4203d40 R14: 0000000000000001 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff9a639ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9a636b384000 CR3: 00000001ea21d000 CR4: 00000000000406b0 Call Trace: change_page_attr_clear+0x1f/0x21 set_memory_ro+0x1e/0x20 arch_ftrace_update_trampoline+0x207/0x21c ? ftrace_caller+0x64/0x64 ? 0xffffffffc029b000 ftrace_startup+0xf4/0x198 register_ftrace_function+0x26/0x3c function_trace_init+0x5e/0x73 tracer_init+0x1e/0x23 tracing_set_tracer+0x127/0x15a register_tracer+0x19b/0x1bc init_function_trace+0x90/0x92 early_trace_init+0x236/0x2b3 start_kernel+0x200/0x3f5 x86_64_start_reservations+0x29/0x2b x86_64_start_kernel+0x17c/0x18f secondary_startup_64+0x9f/0x9f ? secondary_startup_64+0x9f/0x9f Interrupts should not be enabled at this early in the boot process. It is also fine to leave interrupts enabled during this time as there's only one CPU running, and on_each_cpu() means to only run on the current CPU. If early_boot_irqs_disabled is set, it is safe to run cpu_flush_range() with interrupts disabled. Don't trigger a BUG_ON() in that case. Link: http://lkml.kernel.org/r/20170526093717.0be3b849@gandalf.local.home Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>