- 31 Jan, 2017 8 commits
-
-
Taeung Song authored
Similar to for_each_subsystem and for_each_event in util/parse-events.c, add new macro 'for_each_event' for easy iteration over the tracepoints in order to be more compact and readable. Signed-off-by:
Taeung Song <treeze.taeung@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/1485862711-20216-2-git-send-email-treeze.taeung@gmail.com [ Slight change to keep existing style for checking strcmp() return ] Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com>
-
Joe Stringer authored
Add a test for the newly added BPF object pinning functionality. For example: # tools/perf/perf test 37 37: BPF filter : 37.1: Basic BPF filtering : Ok 37.2: BPF pinning : Ok 37.3: BPF prologue generation : Ok 37.4: BPF relocation checker : Ok # tools/perf/perf test 37 -v 2>&1 | grep pinned libbpf: pinned map '/sys/fs/bpf/perf_test/flip_table' libbpf: pinned program '/sys/fs/bpf/perf_test/func=SyS_epoll_wait/0' Signed-off-by:Joe Stringer <joe@ovn.org> Requested-and-Tested-by:
-
Joe Stringer authored
Allow mounting of the BPF filesystem at /sys/fs/bpf. Signed-off-by:
-
Joe Stringer authored
rm_rf() doesn't modify its path argument, and a future caller will pass a string constant into it to delete. Signed-off-by:
-
Joe Stringer authored
Add a new API to pin a BPF object to the filesystem. The user can specify the path within a BPF filesystem to pin the object. Programs will be pinned under a subdirectory named the same as the program, with each instance appearing as a numbered file under that directory, and maps will be pinned under the path using the name of the map as the file basename. For example, with the directory '/sys/fs/bpf/foo' and a BPF object which contains two instances of a program named 'bar', and a map named 'baz': /sys/fs/bpf/foo/bar/0 /sys/fs/bpf/foo/bar/1 /sys/fs/bpf/foo/baz Signed-off-by:
-
Joe Stringer authored
Add a new API to pin a BPF map to the filesystem. The user can specify the path full path within a BPF filesystem to pin the map. Signed-off-by:
-
Joe Stringer authored
Add new APIs to pin a BPF program (or specific instances) to the filesystem. The user can specify the path full path within a BPF filesystem to pin the program. bpf_program__pin_instance(prog, path, n) will pin the nth instance of 'prog' to the specified path. bpf_program__pin(prog, path) will create the directory 'path' (if it does not exist) and pin each instance within that directory. For instance, path/0, path/1, path/2. Committer notes: - Add missing headers for mkdir() - Check strdup() for failure - Check snprintf >= size, not >, as == also means truncated, see 'man snprintf', return value. - Conditionally define BPF_FS_MAGIC, as it isn't in magic.h in older systems and we're not yet having a tools/include/uapi/linux/magic.h copy. - Do not include linux/magic.h, not present in older distros. Signed-off-by:
-
Krister Johansen authored
If dso__load_kcore frees all of the existing maps, but one has already been attached to a callchain cursor node, then we can get a SIGSEGV in any function that happens to try to use this invalid cursor. Use the existing map refcount mechanism to forestall cleanup of a map until the cursor iterates past the node. Signed-off-by:
Krister Johansen <kjlx@templeofstupid.com> Tested-by:
-
- 30 Jan, 2017 1 commit
-
-
Ingo Molnar authored
tools headers: Sync {tools/,}arch/powerpc/include/uapi/asm/kvm.h, {tools/,}arch/x86/include/asm/cpufeatures.h and {tools/,}arch/arm/include/uapi/asm/kvm.h The following upstream headers were updated: - The x86 cpufeatures.h file picked up a couple of new feature entries - The PowerPC and ARM KVM headers picked up new features None of which requires changes to perf tooling, so refresh the tooling copy. Solves these build time warnings: Warning: arch/x86/include/asm/cpufeatures.h differs from kernel Warning: arch/powerpc/include/uapi/asm/kvm.h differs from kernel Warning: arch/arm/include/uapi/asm/kvm.h differs from kernel Signed-off-by:Ingo Molnar <mingo@kernel.org> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20170130081131.GA8322@gmail.com [ resync tools/arch/x86/include/asm/cpufeatures.h ] Signed-off-by:
-
- 27 Jan, 2017 2 commits
-
-
Arnaldo Carvalho de Melo authored
Previously these were being ignored, sometimes silently. Stop doing that, emitting debug messages and handling the errors. Testing it: $ cat ~/.perfconfig cat: /home/acme/.perfconfig: No such file or directory $ perf stat -e cycles usleep 1 Performance counter stats for 'usleep 1': 938,996 cycles:u 0.003813731 seconds time elapsed $ perf top --stdio Error: You may not have permission to collect system-wide stats. Consider tweaking /proc/sys/kernel/perf_event_paranoid, <SNIP> [ perf record: Captured and wrote 0.019 MB perf.data (7 samples) ] [acme@jouet linux]$ perf report --stdio # To display the perf.data header info, please use --header/--header-only options. # Overhead Command Shared Object Symbol # ........ ....... ................. ......................... 71.77% usleep libc-2.24.so [.] _dl_addr 27.07% usleep ld-2.24.so [.] _dl_next_ld_env_entry 1.13% usleep [kernel.kallsyms] [k] page_fault $ $ touch ~/.perfconfig $ ls -la ~/.perfconfig -rw-rw-r--. 1 acme acme 0 Jan 27 12:14 /home/acme/.perfconfig $ $ perf stat -e instructions usleep 1 Performance counter stats for 'usleep 1': 244,610 instructions:u 0.000805383 seconds time elapsed $ [root@jouet ~]# chown acme.acme ~/.perfconfig [root@jouet ~]# perf stat -e cycles usleep 1 Warning: File /root/.perfconfig not owned by current user or root, ignoring it. Performance counter stats for 'usleep 1': 937,615 cycles 0.000836931 seconds time elapsed # Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-j2rq96so6xdqlr8p8rd6a3jx@git.kernel.orgSigned-off-by: -
Arnaldo Carvalho de Melo authored
While propagating the errors from perf_config(), which were being completely ignored, everything stopped working for people without a ~/.perfconfig file, because the perf_config_set__init() was considering an error not to have a .perfconfig file, duh, fix it by checking the errno after the failed stat() call. It should also not return an error when it says it is ignoring the file, and also a empty file should not return an error either. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Taeung Song <treeze.taeung@gmail.com> Cc: Wang Nan <wangnan0@huawei.com> Fixes: 8beeb00f ("perf config: Use new perf_config_set__init() to initialize config set") Link: http://lkml.kernel.org/n/tip-ygpbab3apbs6l8wr97xedwks@git.kernel.orgSigned-off-by:
-
- 26 Jan, 2017 15 commits
-
-
Josh Poimboeuf authored
When doing a kernel build with 'make -s', everything is silenced except the objtool build. That's because the tools tree support for silent builds is some combination of missing and broken. Three changes are needed to fix it: - Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the tools Makefiles can see it. - tools/scripts/Makefile.include: fix the tools Makefiles' ability to recognize '-s'. The MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences the "DESCEND objtool" message. - tools/build/Makefile.build: add support to the tools Build files for recognizing '-s'. Again the MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences all the object compile/link messages. Reported-and-Tested-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Josh Poimboeuf <jpoimboe@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Michal Marek <mmarek@suse.com> Link: http://lkml.kernel.org/r/e8967562ef640c3ae9a76da4ae0f4e47df737c34.1484799200.git.jpoimboe@redhat.comSigned-off-by:
-
Taeung Song authored
As a result of commit a3497642c261 ("perf ftrace: Make 'function_graph' be the default tracer") the ftrace.tracer variable can't be NULL but the other code setting default tracer remained. Signed-off-by: -
Ingo Molnar authored
Merge tag 'perf-core-for-mingo-4.11-20170126' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull the latest perf/core updates from Arnaldo Carvalho de Melo: New features: - Introduce 'perf ftrace' a perf front end to the kernel's ftrace function and function_graph tracer, defaulting to the "function_graph" tracer, more work will be done in reviving this effort, forward porting it from its initial patch submission (Namhyung Kim) - Add 'e' and 'c' hotkeys to expand/collapse call chains for a single hist entry in the 'perf report' and 'perf top' TUI (Jiri Olsa) Fixes: - Fix wrong register name for arm64, used in 'perf probe' (He Kuang) - Fix map offsets in relocation in libbpf (Joe Stringer) - Fix looking up dwarf unwind stack info (Matija Glavinic Pecotic) Infrastructure changes: - libbpf prog functions sync with what is exported via uapi (Joe Stringer) Trivial changes: - Remove unnecessary checks and assignments in 'perf probe's try_to_find_absolute_address() (Markus Elfring) Signed-off-by:
-
Arnaldo Carvalho de Melo authored
So that we can suppress the '-t function_graph' and get a more compact command line: # perf ftrace usleep 123456 | grep raw_spin_lock | sort -k2 -nr | head -5 2) 0.555 us | _raw_spin_lock(); 2) 0.516 us | _raw_spin_lock(); 2) 0.410 us | _raw_spin_lock_irq(); 2) 0.374 us | _raw_spin_lock_irqsave(); # Tested-by:
Masami Hiramatsu <mhiramat@kernel.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Jeremy Eder <jeder@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Stephane Eranian <eranian@google.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-ss9xgx5htpxcv86x42pnh3m6@git.kernel.orgSigned-off-by:
-
Namhyung Kim authored
The 'perf ftrace' command is a simple wrapper of kernel's ftrace functionality. It only supports single thread tracing currently and just reads trace_pipe in text and then write it to stdout. Committer notes: Testing it: # perf ftrace -f function_graph usleep 123456 <SNIP> 2) | SyS_nanosleep() { 2) | _copy_from_user() { <SNIP> 2) 0.900 us | } 2) 1.354 us | } 2) | hrtimer_nanosleep() { 2) 0.062 us | __hrtimer_init(); 2) | do_nanosleep() { 2) | hrtimer_start_range_ns() { <SNIP> 2) 5.025 us | } 2) | schedule() { 2) 0.125 us | rcu_note_context_switch(); 2) 0.057 us | _raw_spin_lock(); 2) | deactivate_task() { 2) 0.369 us | update_rq_clock.part.77(); 2) | dequeue_task_fair() { <SNIP> 2) + 22.453 us | } 2) + 23.736 us | } 2) | pick_next_task_fair() { <SNIP> 2) + 47.167 us | } 2) | pick_next_task_idle() { <SNIP> 2) 4.462 us | } ------------------------------------------ 2) usleep-20387 => <idle>-0 ------------------------------------------ 2) 0.806 us | switch_mm_irqs_off(); ------------------------------------------ 2) <idle>-0 => usleep-20387 ------------------------------------------ 2) 0.151 us | finish_task_switch(); 2) @ 123597.2 us | } 2) 0.037 us | _cond_resched(); 2) | hrtimer_try_to_cancel() { 2) 0.064 us | hrtimer_active(); 2) 0.353 us | } 2) @ 123605.3 us | } 2) @ 123606.2 us | } 2) @ 123608.3 us | } /* SyS_nanosleep */ 2) | __do_page_fault() { <SNIP> Signed-off-by:Namhyung Kim <namhyung@kernel.org> Tested-by:
-
Namhyung Kim authored
It's helpful for debugging on tracing features. Signed-off-by:
-
Namhyung Kim authored
Current trace info data lacks the saved cmdline mapping which is needed for pevent to find out the comm of a task. Add this and bump up the version number so that perf can determine its presence when reading. This is mostly corresponding to trace.dat file version 6, but still lacks 4 byte of number of cpus, and 10 bytes of type string - and I think we don't need those anyway. Signed-off-by:
-
Arnaldo Carvalho de Melo authored
Do just like handling other cases i.e. print some debug message and ignore the sample. Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/n/tip-t7kzlm3cxyvbd7d9n9554ai9@git.kernel.orgSigned-off-by:
-
Joe Stringer authored
This function will turn a libbpf pointer into a standard error code (or 0 if the pointer is valid). This also allows removal of the dependency on linux/err.h in the public header file, which causes problems in userspace programs built against libbpf. Signed-off-by:
Wang Nan <wangnan0@huawei.com> Cc: Alexei Starovoitov <ast@fb.com> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: netdev@vger.kernel.org Link: http://lkml.kernel.org/r/20170123011128.26534-5-joe@ovn.orgSigned-off-by:
-
Joe Stringer authored
These bpf_prog_types were exposed in the uapi but there were no corresponding functions to set these types for programs in libbpf. Signed-off-by:
-
Joe Stringer authored
Turning this into a macro allows future prog types to be added with a single line per type. Signed-off-by:
-
Joe Stringer authored
Commit 4708bbda ("tools lib bpf: Fix maps resolution") attempted to fix map resolution by identifying the number of symbols that point to maps, and using this number to resolve each of the maps. However, during relocation the original definition of the map size was still in use. For up to two maps, the calculation was correct if there was a small difference in size between the map definition in libbpf and the one that the client library uses. However if the difference was large, particularly if more than two maps were used in the BPF program, the relocation would fail. For example, when using a map definition with size 28, with three maps, map relocation would count: (sym_offset / sizeof(struct bpf_map_def) => map_idx) (0 / 16 => 0), ie map_idx = 0 (28 / 16 => 1), ie map_idx = 1 (56 / 16 => 3), ie map_idx = 3 So, libbpf reports: libbpf: bpf relocation: map_idx 3 large than 2 Fix map relocation by checking the exact offset of maps when doing relocation. Signed-off-by:
-
Markus Elfring authored
Remove an error code assignment which is redundant in an if branch for the handling of a memory allocation failure because the same value was set for the local variable "err" before. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Acked-by:
-
Markus Elfring authored
Remove a condition check which is unnecessary at the end because this source code place should usually only be reached with a non-zero pointer. Signed-off-by:
-
He Kuang authored
The register name of arm64 architecture is x0-x31 not r0-r31, this patch changes this typo. Before this patch: # perf probe --definition 'sys_write count' p:probe/sys_write _text+1502872 count=%r2:s64 # echo 'p:probe/sys_write _text+1502872 count=%r2:s64' > \ /sys/kernel/debug/tracing/kprobe_events Parse error at argument[0]. (-22) After this patch: # perf probe --definition 'sys_write count' p:probe/sys_write _text+1502872 count=%x2:s64 # echo 'p:probe/sys_write _text+1502872 count=%x2:s64' > \ /sys/kernel/debug/tracing/kprobe_events # echo 1 >/sys/kernel/debug/tracing/events/probe/enable # cat /sys/kernel/debug/tracing/trace ... sh-422 [000] d... 650.495930: sys_write: (SyS_write+0x0/0xc8) count=22 sh-422 [000] d... 651.102389: sys_write: (SyS_write+0x0/0xc8) count=26 sh-422 [000] d... 651.358653: sys_write: (SyS_write+0x0/0xc8) count=86 Signed-off-by:He Kuang <hekuang@huawei.com> Acked-by:
Will Deacon <will.deacon@arm.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Bintian Wang <bintian.wang@huawei.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Wang Nan <wangnan0@huawei.com> Link: http://lkml.kernel.org/r/20170124103015.1936-2-hekuang@huawei.comSigned-off-by:
-
- 25 Jan, 2017 14 commits
-
-
Ingo Molnar authored
Signed-off-by: -
Linus Torvalds authored
Merge fixes from Andrew Morton: "26 fixes" * emailed patches from Andrew Morton <akpm@linux-foundation.org>: (26 commits) MAINTAINERS: add Dan Streetman to zbud maintainers MAINTAINERS: add Dan Streetman to zswap maintainers mm: do not export ioremap_page_range symbol for external module mn10300: fix build error of missing fpu_save() romfs: use different way to generate fsid for BLOCK or MTD frv: add missing atomic64 operations mm, page_alloc: fix premature OOM when racing with cpuset mems update mm, page_alloc: move cpuset seqcount checking to slowpath mm, page_alloc: fix fast-path race with cpuset update or removal mm, page_alloc: fix check for NULL preferred_zone kernel/panic.c: add missing \n fbdev: color map copying bounds checking frv: add atomic64_add_unless() mm/mempolicy.c: do not put mempolicy before using its nodemask radix-tree: fix private list warnings Documentation/filesystems/proc.txt: add VmPin mm, memcg: do not retry precharge charges proc: add a schedule point in proc_pid_readdir() mm: alloc_contig: re-allow CMA to compact FS pages mm/slub.c: trace free objects at KERN_INFO ...
-
Dan Streetman authored
Add myself as zbud maintainer. Link: http://lkml.kernel.org/r/20170124221705.26523-1-ddstreet@ieee.orgSigned-off-by:
Dan Streetman <ddstreet@ieee.org> Cc: Seth Jennings <sjenning@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Dan Streetman authored
Add myself as zswap maintainer. Link: http://lkml.kernel.org/r/20170124212200.19052-1-ddstreet@ieee.orgSigned-off-by:
Seth Jennings <sjenning@redhat.com> Signed-off-by:
-
zhong jiang authored
Recently, I've found cases in which ioremap_page_range was used incorrectly, in external modules, leading to crashes. This can be partly attributed to the fact that ioremap_page_range is lower-level, with fewer protections, as compared to the other functions that an external module would typically call. Those include: ioremap_cache ioremap_nocache ioremap_prot ioremap_uc ioremap_wc ioremap_wt ...each of which wraps __ioremap_caller, which in turn provides a safer way to achieve the mapping. Therefore, stop EXPORT-ing ioremap_page_range. Link: http://lkml.kernel.org/r/1485173220-29010-1-git-send-email-zhongjiang@huawei.comSigned-off-by:zhong jiang <zhongjiang@huawei.com> Reviewed-by:
John Hubbard <jhubbard@nvidia.com> Suggested-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
-
Randy Dunlap authored
When CONFIG_FPU is not enabled on arch/mn10300, <asm/switch_to.h> causes a build error with a call to fpu_save(): kernel/built-in.o: In function `.L410': core.c:(.sched.text+0x28a): undefined reference to `fpu_save' Fix this by including <asm/fpu.h> in <asm/switch_to.h> so that an empty static inline fpu_save() is defined. Link: http://lkml.kernel.org/r/dc421c4f-4842-4429-1b99-92865c2f24b6@infradead.orgSigned-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Reviewed-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Coly Li authored
Commit 8a59f5d2 ("fs/romfs: return f_fsid for statfs(2)") generates a 64bit id from sb->s_bdev->bd_dev. This is only correct when romfs is defined with CONFIG_ROMFS_ON_BLOCK. If romfs is only defined with CONFIG_ROMFS_ON_MTD, sb->s_bdev is NULL, referencing sb->s_bdev->bd_dev will triger an oops. Richard Weinberger points out that when CONFIG_ROMFS_BACKED_BY_BOTH=y, both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD are defined. Therefore when calling huge_encode_dev() to generate a 64bit id, I use the follow order to choose parameter, - CONFIG_ROMFS_ON_BLOCK defined use sb->s_bdev->bd_dev - CONFIG_ROMFS_ON_BLOCK undefined and CONFIG_ROMFS_ON_MTD defined use sb->s_dev when, - both CONFIG_ROMFS_ON_BLOCK and CONFIG_ROMFS_ON_MTD undefined leave id as 0 When CONFIG_ROMFS_ON_MTD is defined and sb->s_mtd is not NULL, sb->s_dev is set to a device ID generated by MTD_BLOCK_MAJOR and mtd index, otherwise sb->s_dev is 0. This is a try-best effort to generate a uniq file system ID, if all the above conditions are not meet, f_fsid of this romfs instance will be 0. Generally only one romfs can be built on single MTD block device, this method is enough to identify multiple romfs instances in a computer. Link: http://lkml.kernel.org/r/1482928596-115155-1-git-send-email-colyli@suse.deSigned-off-by:
Coly Li <colyli@suse.de> Reported-by:
Nong Li <nongli1031@gmail.com> Tested-by:
-
Sudip Mukherjee authored
Some more atomic64 operations were missing and as a result frv allmodconfig was failing. Add the missing operations. Link: http://lkml.kernel.org/r/1485193844-12850-1-git-send-email-sudip.mukherjee@codethink.co.ukSigned-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Cc: David Howells <dhowells@redhat.com> Signed-off-by:
-
Vlastimil Babka authored
Ganapatrao Kulkarni reported that the LTP test cpuset01 in stress mode triggers OOM killer in few seconds, despite lots of free memory. The test attempts to repeatedly fault in memory in one process in a cpuset, while changing allowed nodes of the cpuset between 0 and 1 in another process. The problem comes from insufficient protection against cpuset changes, which can cause get_page_from_freelist() to consider all zones as non-eligible due to nodemask and/or current->mems_allowed. This was masked in the past by sufficient retries, but since commit 682a3385 ("mm, page_alloc: inline the fast path of the zonelist iterator") we fix the preferred_zoneref once, and don't iterate over the whole zonelist in further attempts, thus the only eligible zones might be placed in the zonelist before our starting point and we always miss them. A previous patch fixed this problem for current->mems_allowed. However, cpuset changes also update the task's mempolicy nodemask. The fix has two parts. We have to repeat the preferred_zoneref search when we detect cpuset update by way of seqcount, and we have to check the seqcount before considering OOM. [akpm@linux-foundation.org: fix typo in comment] Link: http://lkml.kernel.org/r/20170120103843.24587-5-vbabka@suse.cz Fixes: c33d6c06 ("mm, page_alloc: avoid looking up the first zone in a zonelist twice") Signed-off-by:
Vlastimil Babka <vbabka@suse.cz> Reported-by:
Ganapatrao Kulkarni <gpkulkarni@gmail.com> Acked-by:
Mel Gorman <mgorman@techsingularity.net> Acked-by:
Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Michal Hocko <mhocko@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Vlastimil Babka authored
This is a preparation for the following patch to make review simpler. While the primary motivation is a bug fix, this also simplifies the fast path, although the moved code is only enabled when cpusets are in use. Link: http://lkml.kernel.org/r/20170120103843.24587-4-vbabka@suse.czSigned-off-by:
-
Vlastimil Babka authored
Ganapatrao Kulkarni reported that the LTP test cpuset01 in stress mode triggers OOM killer in few seconds, despite lots of free memory. The test attempts to repeatedly fault in memory in one process in a cpuset, while changing allowed nodes of the cpuset between 0 and 1 in another process. One possible cause is that in the fast path we find the preferred zoneref according to current mems_allowed, so that it points to the middle of the zonelist, skipping e.g. zones of node 1 completely. If the mems_allowed is updated to contain only node 1, we never reach it in the zonelist, and trigger OOM before checking the cpuset_mems_cookie. This patch fixes the particular case by redoing the preferred zoneref search if we switch back to the original nodemask. The condition is also slightly changed so that when the last non-root cpuset is removed, we don't miss it. Note that this is not a full fix, and more patches will follow. Link: http://lkml.kernel.org/r/20170120103843.24587-3-vbabka@suse.cz Fixes: 682a3385 ("mm, page_alloc: inline the fast path of the zonelist iterator") Signed-off-by:
-
Vlastimil Babka authored
Patch series "fix premature OOM regression in 4.7+ due to cpuset races". This is v2 of my attempt to fix the recent report based on LTP cpuset stress test [1]. The intention is to go to stable 4.9 LTSS with this, as triggering repeated OOMs is not nice. That's why the patches try to be not too intrusive. Unfortunately why investigating I found that modifying the testcase to use per-VMA policies instead of per-task policies will bring the OOM's back, but that seems to be much older and harder to fix problem. I have posted a RFC [2] but I believe that fixing the recent regressions has a higher priority. Longer-term we might try to think how to fix the cpuset mess in a better and less error prone way. I was for example very surprised to learn, that cpuset updates change not only task->mems_allowed, but also nodemask of mempolicies. Until now I expected the parameter to alloc_pages_nodemask() to be stable. I wonder why do we then treat cpusets specially in get_page_from_freelist() and distinguish HARDWALL etc, when there's unconditional intersection between mempolicy and cpuset. I would expect the nodemask adjustment for saving overhead in g_p_f(), but that clearly doesn't happen in the current form. So we have both crazy complexity and overhead, AFAICS. [1] https://lkml.kernel.org/r/CAFpQJXUq-JuEP=QPidy4p_=FN0rkH5Z-kfB4qBvsf6jMS87Edg@mail.gmail.com [2] https://lkml.kernel.org/r/7c459f26-13a6-a817-e508-b65b903a8378@suse.cz This patch (of 4): Since commit c33d6c06 ("mm, page_alloc: avoid looking up the first zone in a zonelist twice") we have a wrong check for NULL preferred_zone, which can theoretically happen due to concurrent cpuset modification. We check the zoneref pointer which is never NULL and we should check the zone pointer. Also document this in first_zones_zonelist() comment per Michal Hocko. Fixes: c33d6c06 ("mm, page_alloc: avoid looking up the first zone in a zonelist twice") Link: http://lkml.kernel.org/r/20170120103843.24587-2-vbabka@suse.czSigned-off-by:
-
Jiri Slaby authored
When a system panics, the "Rebooting in X seconds.." message is never printed because it lacks a new line. Fix it. Link: http://lkml.kernel.org/r/20170119114751.2724-1-jslaby@suse.czSigned-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Kees Cook authored
Copying color maps to userspace doesn't check the value of to->start, which will cause kernel heap buffer OOB read due to signedness wraps. CVE-2016-8405 Link: http://lkml.kernel.org/r/20170105224249.GA50925@beast Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Kees Cook <keescook@chromium.org> Reported-by: Peter Pi (@heisecode) of Trend Micro Cc: Min Chong <mchong@google.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
