1. 23 Oct, 2017 18 commits
  2. 20 Oct, 2017 11 commits
  3. 19 Oct, 2017 5 commits
  4. 18 Oct, 2017 6 commits
    • Linus Torvalds's avatar
      Merge tag 'xfs-4.14-fixes-6' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux · 73d3393a
      Linus Torvalds authored
      Pull xfs fixes from Darrick Wong:
      
       - fix some more CONFIG_XFS_RT related build problems
      
       - fix data loss when writeback at eof races eofblocks gc and loses
      
       - invalidate page cache after fs finishes a dio write
      
       - remove dirty page state when invalidating pages so releasepage does
         the right thing when handed a dirty page
      
      * tag 'xfs-4.14-fixes-6' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
        xfs: move two more RT specific functions into CONFIG_XFS_RT
        xfs: trim writepage mapping to within eof
        fs: invalidate page cache after end_io() in dio completion
        xfs: cancel dirty pages on invalidation
      73d3393a
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · 020b3023
      Linus Torvalds authored
      Pull block fixes from Jens Axboe:
       "Three small fixes:
      
         - A fix for skd, it was using kfree() to free a structure allocate
           with kmem_cache_alloc().
      
         - Stable fix for nbd, fixing a regression using the normal ioctl
           based tools.
      
         - Fix for a previous fix in this series, that fixed up
           inconsistencies between buffered and direct IO"
      
      * 'for-linus' of git://git.kernel.dk/linux-block:
        fs: Avoid invalidation in interrupt context in dio_complete()
        nbd: don't set the device size until we're connected
        skd: Use kmem_cache_free
      020b3023
    • Naveen N. Rao's avatar
      Revert "kprobes: Warn if optprobe handler tries to change execution path" · 4f3a8714
      Naveen N. Rao authored
      This reverts commit:
      
        e863d539 ("kprobes: Warn if optprobe handler tries to change execution path")
      
      On PowerPC, we place a probe at kretprobe_trampoline to catch function
      returns and with CONFIG_OPTPROBES=y, this probe gets optimized. This
      works for us due to the way we handle the optprobe as described in
      commit:
      
        762df10b ("powerpc/kprobes: Optimize kprobe in kretprobe_trampoline()")
      
      With the above commit, we end up with a warning. As such, revert this change.
      Reported-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20171017081834.3629-1-naveen.n.rao@linux.vnet.ibm.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      4f3a8714
    • Li Zhijian's avatar
      perf test shell trace+probe_libc_inet_pton.sh: Be compatible with Debian/Ubuntu · 74f8e22c
      Li Zhijian authored
      In debian/ubuntu, libc.so is located at a different place,
      /lib/x86_64-linux-gnu/libc-2.23.so, so it outputs like this when testing:
      
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.040 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.040/0.040/0.040/0.000 ms
        0.000 probe_libc:inet_pton:(7f0e2db741c0))
        __GI___inet_pton (/lib/x86_64-linux-gnu/libc-2.23.so)
        getaddrinfo (/lib/x86_64-linux-gnu/libc-2.23.so)
        [0xffffa9d40f34ff4d] (/bin/ping)
      
      Fix up the libc path to make sure this test works in more OSes.
      
      Committer testing:
      
      When this test fails one can use 'perf test -v', i.e. in verbose mode, where
      it'll show the expected backtrace, so, after applying this test:
      
      On Fedora 26:
      
        # perf test -v ping
        62: probe libc's inet_pton & backtrace it with ping       :
        --- start ---
        test child forked, pid 23322
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.058 ms
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.058/0.058/0.058/0.000 ms
        0.000 probe_libc:inet_pton:(7fe344310d80))
        __GI___inet_pton (/usr/lib64/libc-2.25.so)
        getaddrinfo (/usr/lib64/libc-2.25.so)
        _init (/usr/bin/ping)
        test child finished with 0
        ---- end ----
        probe libc's inet_pton & backtrace it with ping: Ok
        #
      Signed-off-by: default avatarLi Zhijian <lizhijian@cn.fujitsu.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Li Zhijian <lizhijian@cn.fujitsu.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Philip Li <philip.li@intel.com>
      Link: http://lkml.kernel.org/r/1508315649-18836-1-git-send-email-lizhijian@cn.fujitsu.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      74f8e22c
    • Jin Yao's avatar
      perf xyarray: Fix wrong processing when closing evsel fd · 3d8bba95
      Jin Yao authored
      In current xyarray code, xyarray__max_x() returns max_y, and xyarray__max_y()
      returns max_x.
      
      It's confusing and for code logic it looks not correct.
      
      Error happens when closing evsel fd. Let's see this scenario:
      
      1. Allocate an fd (pseudo-code)
      
        perf_evsel__alloc_fd(struct perf_evsel *evsel, int ncpus, int nthreads)
        {
      	evsel->fd = xyarray__new(ncpus, nthreads, sizeof(int));
        }
      
        xyarray__new(int xlen, int ylen, size_t entry_size)
        {
      	size_t row_size = ylen * entry_size;
      	struct xyarray *xy = zalloc(sizeof(*xy) + xlen * row_size);
      
      	xy->entry_size = entry_size;
      	xy->row_size   = row_size;
      	xy->entries    = xlen * ylen;
      	xy->max_x      = xlen;
      	xy->max_y      = ylen;
      	......
        }
      
      So max_x is ncpus, max_y is nthreads and row_size = nthreads * 4.
      
      2. Use perf syscall and get the fd
      
        int perf_evsel__open(struct perf_evsel *evsel, struct cpu_map *cpus,
      		     struct thread_map *threads)
        {
      	for (cpu = 0; cpu < cpus->nr; cpu++) {
      
      		for (thread = 0; thread < nthreads; thread++) {
      			int fd, group_fd;
      
      			fd = sys_perf_event_open(&evsel->attr, pid, cpus->map[cpu],
      						 group_fd, flags);
      
      			FD(evsel, cpu, thread) = fd;
      	}
        }
      
        static inline void *xyarray__entry(struct xyarray *xy, int x, int y)
        {
      	return &xy->contents[x * xy->row_size + y * xy->entry_size];
        }
      
      These codes don't have issues. The issue happens in the closing of fd.
      
      3. Close fd.
      
        void perf_evsel__close_fd(struct perf_evsel *evsel)
        {
      	int cpu, thread;
      
      	for (cpu = 0; cpu < xyarray__max_x(evsel->fd); cpu++)
      		for (thread = 0; thread < xyarray__max_y(evsel->fd); ++thread) {
      			close(FD(evsel, cpu, thread));
      			FD(evsel, cpu, thread) = -1;
      		}
        }
      
        Since xyarray__max_x() returns max_y (nthreads) and xyarry__max_y()
        returns max_x (ncpus), so above code is actually to be:
      
              for (cpu = 0; cpu < nthreads; cpu++)
                      for (thread = 0; thread < ncpus; ++thread) {
                              close(FD(evsel, cpu, thread));
                              FD(evsel, cpu, thread) = -1;
                      }
      
        It's not correct!
      
      This change is introduced by "475fb533" ("perf evsel: Fix buffer overflow
      while freeing events")
      
      This fix is to let xyarray__max_x() return max_x (ncpus) and
      let xyarry__max_y() return max_y (nthreads)
      
      Committer note:
      
      This was also fixed by Ravi Bangoria, who provided the same patch,
      noticing the problem with 'perf record':
      
      <quote Ravi>
      I see 'perf record -p <pid>' crashes with following log:
      
         *** Error in `./perf': free(): invalid next size (normal): 0x000000000298b340 ***
         ======= Backtrace: =========
         /lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f7fd85c87e5]
         /lib/x86_64-linux-gnu/libc.so.6(+0x8037a)[0x7f7fd85d137a]
         /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f7fd85d553c]
         ./perf(perf_evsel__close+0xb4)[0x4b7614]
         ./perf(perf_evlist__delete+0x100)[0x4ab180]
         ./perf(cmd_record+0x1d9)[0x43a5a9]
         ./perf[0x49aa2f]
         ./perf(main+0x631)[0x427841]
         /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f7fd8571830]
         ./perf(_start+0x29)[0x427a59]
      </>
      Signed-off-by: default avatarJin Yao <yao.jin@linux.intel.com>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Fixes: d74be476 ("perf xyarray: Save max_x, max_y")
      Link: http://lkml.kernel.org/r/1508339478-26674-1-git-send-email-yao.jin@linux.intel.com
      Link: http://lkml.kernel.org/r/1508327446-15302-1-git-send-email-ravi.bangoria@linux.vnet.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      3d8bba95
    • Linus Torvalds's avatar
      Merge tag 'enforcement-4.14-rc6' of... · 3e0cc09a
      Linus Torvalds authored
      Merge tag 'enforcement-4.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
      
      Pull enforcement policy update from Greg KH:
       "Documentation: Add a file explaining the requested Linux kernel
        license enforcement policy
      
        Here's a new file to the kernel's Documentation directory. It adds a
        short document describing the views of how the Linux kernel community
        feels about enforcing the license of the kernel.
      
        The patch has been reviewed by a large number of kernel developers
        already, as seen by their acks on the patch, and their agreement of
        the statement with their names on it. The location of the file was
        also agreed upon by the Documentation maintainer, so all should be
        good there.
      
        For some background information about this statement, see this article
        written by some of the kernel developers involved in drafting it:
      
      	http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement/
      
        and this article that answers a number of questions that came up in
        the discussion of this statement with the kernel developer community:
      
      	http://kroah.com/log/blog/2017/10/16/linux-kernel-community-enforcement-statement-faq/
      
        If anyone has any further questions about it, please let me, and the
        TAB members, know and we will be glad to help answer them"
      
      * tag 'enforcement-4.14-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
        Documentation: Add a file explaining the Linux kernel license enforcement policy
      3e0cc09a