1. 23 Oct, 2017 3 commits
  2. 20 Oct, 2017 11 commits
  3. 19 Oct, 2017 5 commits
  4. 18 Oct, 2017 13 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
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux · 96b0e525
      Linus Torvalds authored
      Pull s390 fixes from Martin Schwidefsky:
       "Two bug fixes:
      
         - A fix for cputime accounting vs CPU hotplug
      
         - Add two options to zfcpdump_defconfig to make SCSI dump work again"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
        s390: fix zfcpdump-config
        s390/cputime: fix guest/irq/softirq times after CPU hotplug
      96b0e525
    • Linus Torvalds's avatar
      Merge tag 'trace-v4.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · 503f7e29
      Linus Torvalds authored
      Pull tracing fix from Steven Rostedt:
       "Testing a new trace event format, I triggered a bug by doing:
      
          # modprobe trace-events-sample
          # echo 1 > /sys/kernel/debug/tracing/events/sample-trace/enable
          # rmmod trace-events-sample
      
        This would cause an oops. The issue is that I added another trace
        event sample that reused a reg function of another trace event to
        create a thread to call the tracepoints. The problem was that the reg
        function couldn't handle nested calls (reg; reg; unreg; unreg;) and
        created two threads (instead of one) and only removed one on exit.
      
        This isn't a critical bug as the bug is only in sample code. But
        sample code should be free of known bugs to prevent others from
        copying it. This is why this is also marked for stable"
      
      * tag 'trace-v4.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        tracing/samples: Fix creation and deletion of simple_thread_fn creation
      503f7e29
    • Takashi Iwai's avatar
      ALSA: hda - Fix incorrect TLV callback check introduced during set_fs() removal · a91d6612
      Takashi Iwai authored
      The commit 99b5c5bb ("ALSA: hda - Remove the use of set_fs()")
      converted the get_kctl_0dB_offset() call for killing set_fs() usage in
      HD-audio codec code.  The conversion assumed that the TLV callback
      used in HD-audio code is only snd_hda_mixer_amp() and applies the TLV
      calculation locally.
      
      Although this assumption is correct, and all slave kctls are actually
      with that callback, the current code is still utterly buggy; it
      doesn't hit this condition and falls back to the next check.  It's
      because the function gets called after adding slave kctls to vmaster.
      By assigning a slave kctl, the slave kctl object is faked inside
      vmaster code, and the whole kctl ops are overridden.  Thus the
      callback op points to a different value from what we've assumed.
      
      More badly, as reported by the KERNEXEC and UDEREF features of PaX,
      the code flow turns into the unexpected pitfall.  The next fallback
      check is SNDRV_CTL_ELEM_ACCESS_TLV_READ access bit, and this always
      hits for each kctl with TLV.  Then it evaluates the callback function
      pointer wrongly as if it were a TLV array.  Although currently its
      side-effect is fairly limited, this incorrect reference may lead to an
      unpleasant result.
      
      For addressing the regression, this patch introduces a new helper to
      vmaster code, snd_ctl_apply_vmaster_slaves().  This works similarly
      like the existing map_slaves() in hda_codec.c: it loops over the slave
      list of the given master, and applies the given function to each
      slave.  Then the initializer function receives the right kctl object
      and we can compare the correct pointer instead of the faked one.
      
      Also, for catching the similar breakage in future, give an error
      message when the unexpected TLV callback is found and bail out
      immediately.
      
      Fixes: 99b5c5bb ("ALSA: hda - Remove the use of set_fs()")
      Reported-by: default avatarPaX Team <pageexec@freemail.hu>
      Cc: <stable@vger.kernel.org> # v4.13
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      a91d6612
    • Takashi Iwai's avatar
      ALSA: hda: Remove superfluous '-' added by printk conversion · 6bf88a34
      Takashi Iwai authored
      While converting the error messages to the standard macros in the
      commit 4e76a883 ("ALSA: hda - Replace with standard printk"), a
      superfluous '-' slipped in the code mistakenly.  Its influence is
      almost negligible, merely shows a dB value as negative integer instead
      of positive integer (or vice versa) in the rare error message.
      So let's kill this embarrassing byte to show more correct value.
      
      Fixes: 4e76a883 ("ALSA: hda - Replace with standard printk")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      6bf88a34
    • Takashi Iwai's avatar
      ALSA: hda: Abort capability probe at invalid register read · 098a0a62
      Takashi Iwai authored
      The loop in snd_hdac_bus_parse_capabilities() may go to nirvana when
      it hits an invalid register value read:
      
       BUG: unable to handle kernel paging request at ffffad5dc41f3fff
       IP: pci_azx_readl+0x5/0x10 [snd_hda_intel]
       Call Trace:
        snd_hdac_bus_parse_capabilities+0x3c/0x1f0 [snd_hda_core]
        azx_probe_continue+0x7d5/0x940 [snd_hda_intel]
        .....
      
      This happened on a new Intel machine, and we need to check the value
      and abort the loop accordingly.
      
      [Note: the fixes tag below indicates only the commit where this patch
       can be applied; the original problem was introduced even before that
       commit]
      
      Fixes: 6720b384 ("ALSA: hda - move bus_parse_capabilities to core")
      Cc: <stable@vger.kernel.org>
      Acked-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      098a0a62
    • Ben Hutchings's avatar
      ALSA: seq: Enable 'use' locking in all configurations · 8009d506
      Ben Hutchings authored
      The 'use' locking macros are no-ops if neither SMP or SND_DEBUG is
      enabled.  This might once have been OK in non-preemptible
      configurations, but even in that case snd_seq_read() may sleep while
      relying on a 'use' lock.  So always use the proper implementations.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBen Hutchings <ben.hutchings@codethink.co.uk>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      8009d506
    • Len Brown's avatar
      Revert "tools/power turbostat: stop migrating, unless '-m'" · c97cc7db
      Len Brown authored
      This reverts commit c91fc851.
      
      That change caused a C6 and PC6 residency regression on large idle systems.
      
      Users also complained about new output indicating jitter:
      
      turbostat: cpu6 jitter 3794 9142
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Cc: 4.13+ <stable@vger.kernel.org> # v4.13+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c97cc7db
  5. 17 Oct, 2017 6 commits
    • Linus Torvalds's avatar
      Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi · ebe6e90c
      Linus Torvalds authored
      Pull SCSI fixes from James Bottomley:
       "Four mostly error leg fixes and one more important regression in a
        prior commit (the qla2xxx one)"
      
      * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
        scsi: fc: check for rport presence in fc_block_scsi_eh
        scsi: qla2xxx: Fix uninitialized work element
        scsi: libiscsi: fix shifting of DID_REQUEUE host byte
        scsi: libfc: fix a deadlock in fc_rport_work
        scsi: fixup kernel warning during rmmod()
      ebe6e90c
    • Steven Rostedt (VMware)'s avatar
      tracing/samples: Fix creation and deletion of simple_thread_fn creation · 6575257c
      Steven Rostedt (VMware) authored
      Commit 7496946a ("tracing: Add samples of DECLARE_EVENT_CLASS() and
      DEFINE_EVENT()") added template examples for all the events. It created a
      DEFINE_EVENT_FN() example which reused the foo_bar_reg and foo_bar_unreg
      functions.
      
      Enabling both the TRACE_EVENT_FN() and DEFINE_EVENT_FN() example trace
      events caused the foo_bar_reg to be called twice, creating the test thread
      twice. The foo_bar_unreg would remove it only once, even if it was called
      multiple times, leaving a thread existing when the module is unloaded,
      causing an oops.
      
      Add a ref count and allow foo_bar_reg() and foo_bar_unreg() be called by
      multiple trace events.
      
      Cc: stable@vger.kernel.org
      Fixes: 7496946a ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      6575257c
    • Lukas Czerner's avatar
      fs: Avoid invalidation in interrupt context in dio_complete() · ffe51f01
      Lukas Czerner authored
      Currently we try to defer completion of async DIO to the process context
      in case there are any mapped pages associated with the inode so that we
      can invalidate the pages when the IO completes. However the check is racy
      and the pages can be mapped afterwards. If this happens we might end up
      calling invalidate_inode_pages2_range() in dio_complete() in interrupt
      context which could sleep. This can be reproduced by generic/451.
      
      Fix this by passing the information whether we can or can't invalidate
      to the dio_complete(). Thanks Eryu Guan for reporting this and Jan Kara
      for suggesting a fix.
      
      Fixes: 332391a9 ("fs: Fix page cache inconsistency when mixing buffered and AIO DIO")
      Reported-by: default avatarEryu Guan <eguan@redhat.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Tested-by: default avatarEryu Guan <eguan@redhat.com>
      Signed-off-by: default avatarLukas Czerner <lczerner@redhat.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      ffe51f01
    • Namhyung Kim's avatar
      perf buildid-list: Fix crash when processing PERF_RECORD_NAMESPACE · 7f0cd236
      Namhyung Kim authored
      Thomas reported that 'perf buildid-list' gets a SEGFAULT due to NULL
      pointer deref when he ran it on a data with namespace events.  It was
      because the buildid_id__mark_dso_hit_ops lacks the namespace event
      handler and perf_too__fill_default() didn't set it.
      
        Program received signal SIGSEGV, Segmentation fault.
        0x0000000000000000 in ?? ()
        Missing separate debuginfos, use: dnf debuginfo-install audit-libs-2.7.7-1.fc25.s390x bzip2-libs-1.0.6-21.fc25.s390x elfutils-libelf-0.169-1.fc25.s390x
        +elfutils-libs-0.169-1.fc25.s390x libcap-ng-0.7.8-1.fc25.s390x numactl-libs-2.0.11-2.ibm.fc25.s390x openssl-libs-1.1.0e-1.1.ibm.fc25.s390x perl-libs-5.24.1-386.fc25.s390x
        +python-libs-2.7.13-2.fc25.s390x slang-2.3.0-7.fc25.s390x xz-libs-5.2.3-2.fc25.s390x zlib-1.2.8-10.fc25.s390x
        (gdb) where
        #0  0x0000000000000000 in ?? ()
        #1  0x00000000010fad6a in machines__deliver_event (machines=<optimized out>, machines@entry=0x2c6fd18,
            evlist=<optimized out>, event=event@entry=0x3fffdf00470, sample=0x3ffffffe880, sample@entry=0x3ffffffe888,
            tool=tool@entry=0x1312968 <build_id.mark_dso_hit_ops>, file_offset=1136) at util/session.c:1287
        #2  0x00000000010fbf4e in perf_session__deliver_event (file_offset=1136, tool=0x1312968 <build_id.mark_dso_hit_ops>,
            sample=0x3ffffffe888, event=0x3fffdf00470, session=0x2c6fc30) at util/session.c:1340
        #3  perf_session__process_event (session=0x2c6fc30, session@entry=0x0, event=event@entry=0x3fffdf00470,
            file_offset=file_offset@entry=1136) at util/session.c:1522
        #4  0x00000000010fddde in __perf_session__process_events (file_size=11880, data_size=<optimized out>,
            data_offset=<optimized out>, session=0x0) at util/session.c:1899
        #5  perf_session__process_events (session=0x0, session@entry=0x2c6fc30) at util/session.c:1953
        #6  0x000000000103b2ac in perf_session__list_build_ids (with_hits=<optimized out>, force=<optimized out>)
            at builtin-buildid-list.c:83
        #7  cmd_buildid_list (argc=<optimized out>, argv=<optimized out>) at builtin-buildid-list.c:115
        #8  0x00000000010a026c in run_builtin (p=0x1311f78 <commands+24>, argc=argc@entry=2, argv=argv@entry=0x3fffffff3c0)
            at perf.c:296
        #9  0x000000000102bc00 in handle_internal_command (argv=<optimized out>, argc=2) at perf.c:348
        #10 run_argv (argcp=<synthetic pointer>, argv=<synthetic pointer>) at perf.c:392
        #11 main (argc=<optimized out>, argv=0x3fffffff3c0) at perf.c:536
        (gdb)
      
      Fix it by adding a stub event handler for namespace event.
      
      Committer testing:
      
      Further clarifying, plain using 'perf buildid-list' will not end up in a
      SEGFAULT when processing a perf.data file with namespace info:
      
        # perf record -a --namespaces sleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 2.024 MB perf.data (1058 samples) ]
        # perf buildid-list | wc -l
        38
        # perf buildid-list | head -5
        e2a171c7b905826fc8494f0711ba76ab6abbd604 /lib/modules/4.14.0-rc3+/build/vmlinux
        874840a02d8f8a31cedd605d0b8653145472ced3 /lib/modules/4.14.0-rc3+/kernel/arch/x86/kvm/kvm-intel.ko
        ea7223776730cd8a22f320040aae4d54312984bc /lib/modules/4.14.0-rc3+/kernel/drivers/gpu/drm/i915/i915.ko
        5961535e6732a8edb7f22b3f148bb2fa2e0be4b9 /lib/modules/4.14.0-rc3+/kernel/drivers/gpu/drm/drm.ko
        f045f54aa78cf1931cc893f78b6cbc52c72a8cb1 /usr/lib64/libc-2.25.so
        #
      
      It is only when one asks for checking what of those entries actually had
      samples, i.e. when we use either -H or --with-hits, that we will process
      all the PERF_RECORD_ events, and since tools/perf/builtin-buildid-list.c
      neither explicitely set a perf_tool.namespaces() callback nor the
      default stub was set that we end up, when processing a
      PERF_RECORD_NAMESPACE record, causing a SEGFAULT:
      
        # perf buildid-list -H
        Segmentation fault (core dumped)
        ^C
        #
      Reported-and-Tested-by: default avatarThomas-Mich Richter <tmricht@linux.vnet.ibm.com>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Hari Bathini <hbathini@linux.vnet.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
      Fixes: f3b3614a ("perf tools: Add PERF_RECORD_NAMESPACES to include namespaces related info")
      Link: http://lkml.kernel.org/r/20171017132900.11043-1-namhyung@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      7f0cd236
    • Taeung Song's avatar
      perf record: Fix documentation for a inexistent option '-l' · 3f50f614
      Taeung Song authored
      'perf record' had a '-l' option that meant "scale counter values" a very
      long time ago, but it currently belongs to 'perf stat' as '-c'.  So
      remove it. I found this problem in the below case.
      
          $ perf record -e cycles -l sleep 3
            Error: unknown switch `l
      Signed-off-by: default avatarTaeung Song <treeze.taeung@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/1507907412-19813-1-git-send-email-treeze.taeung@gmail.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      3f50f614
    • Linus Torvalds's avatar
      Merge tag 'media/v4.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media · 3728e6a2
      Linus Torvalds authored
      Pull media fixes from Mauro Carvalho Chehab:
       "Core fixes:
         - cec: Respond to unregistered initiators, when applicable
         - dvb_frontend: only use kref after initialized
      
        Driver-specific fixes:
         - qcom, camss: Make function vfe_set_selection static
         - qcom: VIDEO_QCOM_CAMSS should depend on HAS_DMA
         - s5p-cec: add NACK detection support
         - media: staging/imx: Fix uninitialized variable warning
         - dib3000mc: i2c transfers over usb cannot be done from stack
         - venus: init registered list on streamoff"
      
      * tag 'media/v4.14-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
        media: dvb_frontend: only use kref after initialized
        media: platform: VIDEO_QCOM_CAMSS should depend on HAS_DMA
        media: cec: Respond to unregistered initiators, when applicable
        media: s5p-cec: add NACK detection support
        media: staging/imx: Fix uninitialized variable warning
        media: qcom: camss: Make function vfe_set_selection static
        media: venus: init registered list on streamoff
        media: dvb: i2c transfers over usb cannot be done from stack
      3728e6a2
  6. 16 Oct, 2017 2 commits
    • Arnd Bergmann's avatar
      xfs: move two more RT specific functions into CONFIG_XFS_RT · 785545c8
      Arnd Bergmann authored
      The last cleanup introduced two harmless warnings:
      
      fs/xfs/xfs_fsmap.c:480:1: warning: '__xfs_getfsmap_rtdev' defined but not used
      fs/xfs/xfs_fsmap.c:372:1: warning: 'xfs_getfsmap_rtdev_rtbitmap_helper' defined but not used
      
      This moves those two functions as well.
      
      Fixes: bb9c2e54 ("xfs: move more RT specific code under CONFIG_XFS_RT")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarBrian Foster <bfoster@redhat.com>
      Acked-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      785545c8
    • Brian Foster's avatar
      xfs: trim writepage mapping to within eof · 40214d12
      Brian Foster authored
      The writeback rework in commit fbcc0256 ("xfs: Introduce
      writeback context for writepages") introduced a subtle change in
      behavior with regard to the block mapping used across the
      ->writepages() sequence. The previous xfs_cluster_write() code would
      only flush pages up to EOF at the time of the writepage, thus
      ensuring that any pages due to file-extending writes would be
      handled on a separate cycle and with a new, updated block mapping.
      
      The updated code establishes a block mapping in xfs_writepage_map()
      that could extend beyond EOF if the file has post-eof preallocation.
      Because we now use the generic writeback infrastructure and pass the
      cached mapping to each writepage call, there is no implicit EOF
      limit in place. If eofblocks trimming occurs during ->writepages(),
      any post-eof portion of the cached mapping becomes invalid. The
      eofblocks code has no means to serialize against writeback because
      there are no pages associated with post-eof blocks. Therefore if an
      eofblocks trim occurs and is followed by a file-extending buffered
      write, not only has the mapping become invalid, but we could end up
      writing a page to disk based on the invalid mapping.
      
      Consider the following sequence of events:
      
      - A buffered write creates a delalloc extent and post-eof
        speculative preallocation.
      - Writeback starts and on the first writepage cycle, the delalloc
        extent is converted to real blocks (including the post-eof blocks)
        and the mapping is cached.
      - The file is closed and xfs_release() trims post-eof blocks. The
        cached writeback mapping is now invalid.
      - Another buffered write appends the file with a delalloc extent.
      - The concurrent writeback cycle picks up the just written page
        because the writeback range end is LLONG_MAX. xfs_writepage_map()
        attributes it to the (now invalid) cached mapping and writes the
        data to an incorrect location on disk (and where the file offset is
        still backed by a delalloc extent).
      
      This problem is reproduced by xfstests test generic/464, which
      triggers racing writes, appends, open/closes and writeback requests.
      
      To address this problem, trim the mapping used during writeback to
      within EOF when the mapping is validated. This ensures the mapping
      is revalidated for any pages encountered beyond EOF as of the time
      the current mapping was cached or last validated.
      Reported-by: default avatarEryu Guan <eguan@redhat.com>
      Diagnosed-by: default avatarEryu Guan <eguan@redhat.com>
      Signed-off-by: default avatarBrian Foster <bfoster@redhat.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      Signed-off-by: default avatarDarrick J. Wong <darrick.wong@oracle.com>
      40214d12