Skip to content

Support for OP-TEE generic linux driver #11

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 97 commits into from

Conversation

vchong
Copy link

@vchong vchong commented Mar 31, 2016

Hi @docularxu,

As discussed with @fboudra last night, here are the patches required to support OP-TEE's new generic linux driver. Please review.

Thanks!

xin3liang and others added 30 commits January 11, 2016 15:13
This patch add a config to support to create multi buffer for cma fbdev.
Such as double buffer and triple buffer.

Cma fbdev is convient to add a legency fbdev. And still many Android
devices use fbdev now and at least double buffer is needed for these
Android devices, so that a buffer flip can be operated. It will need some
time for Android device vendors to abondon legency fbdev. So multi buffer
for fbdev is needed.

Signed-off-by: Xinliang Liu <[email protected]>
Add the device tree binding documentation for hi6220 SoC display subsystem.
drm master device binding doc.
ADE display controller binding doc.
DSI controller binding doc.

Signed-off-by: Xinliang Liu <[email protected]>
Add DRM master driver for hi6220 SoC which used in HiKey board.
Add dumb buffer feature.
Add prime dmabuf feature.

Signed-off-by: Xinliang Liu <[email protected]>
Add crtc funcs and helper funcs for ADE.

Signed-off-by: Xinliang Liu <[email protected]>
Add plane funcs and helper funcs for ADE.

Signed-off-by: Xinliang Liu <[email protected]>
Add vblank handle for ADE.

Signed-off-by: Xinliang Liu <[email protected]>
Add cma Fbdev, Fbdev is legency and optional, you can enable/disable it by
configuring DRM_FBDEV_EMULATION.
Add hotplug.

Signed-off-by: Xinliang Liu <[email protected]>
Add dsi encoder driver for hi6220 SoC.

Signed-off-by: Xinliang Liu <[email protected]>
Add dsi host driver for hi6220 SoC.

Signed-off-by: Xinliang Liu <[email protected]>
Add support for external HDMI bridge.

Signed-off-by: Xinliang Liu <[email protected]>
ion_buffer_create() will allocate a buffer and then create a DMA
mapping for it, but it forgot to set the length of the page entries.

Signed-off-by: Liviu Dudau <[email protected]>
[jstultz: Cherrypicked to 4.4]
Signed-off-by: John Stultz <[email protected]>
Early at boot, during the sys_clk initialization, make sure UART1 uses the
higher frequency clock.

This enables support for higher baud rates (up to 3Mbps) required to support
faster bluetooth transfers.

Signed-off-by: Jorge Ramirez-Ortiz <[email protected]>

Conflicts:
	drivers/clk/hisilicon/clk-hi6220.c
Adds clk support for the pl031 RTC on hi6220

Signed-off-by: John Stultz <[email protected]>
Add DT bindings documentation for hi6220 SoC reset controller.

Signed-off-by: Chen Feng <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
Acked-by: Rob Herring <[email protected]>
Add reset driver for hi6220-hikey board,this driver supply deassert
of IP on hi6220 SoC.

Signed-off-by: Chen Feng <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
We need to include <linux/module.h> to build the driver as a loadable
module:

drivers/reset/hisilicon/hi6220_reset.c:108:1: warning: data definition has no type or storage class
 postcore_initcall(hi6220_reset_init);

Signed-off-by: Arnd Bergmann <[email protected]>
Workaround/Hack

Disable hispeed to make usb host mode work with mice/keyboard

Signed-off-by: John Stultz <[email protected]>
Add Hi6220 gpio configuration nodes

Signed-off-by: Zhong Kaihua <[email protected]>
Signed-off-by: Kong Xinwei <[email protected]>

Acked-by: Rob Herring <[email protected]>
Signed-off-by: Wei Xu <[email protected]>
Add Hi6220 pinctrl configuration nodes

Signed-off-by: Zhong Kaihua <[email protected]>
Add Hi6220 spi configuration nodes

Signed-off-by: Zhong Kaihua <[email protected]>
Signed-off-by: Wei Xu <[email protected]>
This patch adds all I2C nodes for the Hi6220 SoC. This hi6220 Soc
use this I2C IP of Synopsys Designware for HiKey board.

Signed-off-by: Xinwei Kong <[email protected]>
Signed-off-by: Chen Feng <[email protected]>
Signed-off-by: Wei Xu <[email protected]>
…ards

Signed-off-by: Guodong Xu <[email protected]>

Conflicts:
	arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
Signed-off-by: Zhangfei Gao <[email protected]>
Signed-off-by: Wei Xu <[email protected]>
This patch add device mailbox node for Hi6220 in DT.

Signed-off-by: Leo Yan <[email protected]>
Signed-off-by: Wei Xu <[email protected]>
Enable SRAM node and stub clock node for Hi6220, which uses mailbox
channel 1 for CPU's frequency change.

Furthermore, add the CPU clock phandle in CPU's node and using
operating-points-v2 to register operating points. So can be used by
cpufreq-dt driver.

Signed-off-by: Leo Yan <[email protected]>
Signed-off-by: Wei Xu <[email protected]>
Add pinctrl for uart2 uart3 and uart4. Enable uart1 uart2 and uart3.

Signed-off-by: Guodong Xu <[email protected]>
Add all three dwmmc nodes description for hi6220

Signed-off-by: Guodong Xu <[email protected]>
Signed-off-by: Xinwei Kong <[email protected]>
Add resets property into dwmmc_0, dwmmc_1 and dwmmc_2 for hi6220

Signed-off-by: Guodong Xu <[email protected]>

arm64: dts: hi6220: add resets in dwmmc_2

Signed-off-by: Guodong Xu <[email protected]>
Add wifi nodes support for hi6220-hikey

Signed-off-by: Guodong Xu <[email protected]>
jenswi-linaro and others added 3 commits March 25, 2016 15:43
Configures foundation-v8 with OP-TEE.

Signed-off-by: Jens Wiklander <[email protected]>
Adds qemu-v8 with OP-TEE and PSCI.

Signed-off-by: Jens Wiklander <[email protected]>
Signed-off-by: Jerome Forissier <[email protected]>
Reviewed-by: Jens Wiklander <[email protected]>
Reviewed-by: Pascal Brand <[email protected]>
@vchong
Copy link
Author

vchong commented Mar 31, 2016

This PR is based on following topic branch: https://github.com/linaro-swg/linux/commits/optee

@vchong
Copy link
Author

vchong commented Mar 31, 2016

Add @jenswi-linaro @jbech-linaro @rsalveti
fyi..

Configures Juno with OP-TEE.

Reviewed-by: Pascal Brand <[email protected]>
Signed-off-by: Jens Wiklander <[email protected]>
@docularxu
Copy link

In HiKey project, I don't want to include modifications to other dt.

d8813b6 arm64: dt: Add OP-TEE firmware to mt8173 not for mainline
979842a arm64: dt: OP-TEE for Juno not for mainline
9416756 arm64: dt: OP-TEE for qemu-v8 not for mainline
037ccd1 arm64: dt: OP-TEE for foundation-v8 not for mainline
4b06c8f arm64: dt: use GICv2 for foundation-v8 not for mainline
83eb922 arm64: dt: PSCI for foundation-v8 not for mainline

Victor, and @jenswi-linaro @jbech-linaro @rsalveti
Would you submit these dt changes to RP (Amit K is maintainer) directly?

-Guodong

@vchong
Copy link
Author

vchong commented Apr 29, 2016

@docularxu That's fine. I have them here for consistency sake with the https://github.com/linaro-swg/linux/commits/optee reference branch, but if you don't want those, do you want me to remove them, or you will remove them yourself?

These changes are already merged by @idlethread (Amit) to RPK (https://github.com/96boards/linux/commits/96b/releases/2016.06) on April 21st.

Thanks!

@idlethread
Copy link

Since SWG doesn't want to maintain an OP-TEE branch on a vanilla 4.4 and I
don't really want all the LSK changes into RPK, I'm maintaining OP-TEE on
vanilla 4.4 at https://github.com/96boards/linux/tree/projects/op-tee. This
branch has been merged into 96b/releases/16.06 for the next RPB release.

On Fri, Apr 29, 2016 at 3:00 PM, Victor [email protected] wrote:

@docularxu https://github.com/docularxu That's fine. I have them here
for consistency sake with the
https://github.com/linaro-swg/linux/commits/optee reference branch, but
if you don't want those, do you want me to remove them, or you will remove
them yourself?

These changes are already merged by @idlethread
https://github.com/idlethread (Amit) to RPK (
https://github.com/96boards/linux) on April 21st.

Thanks!


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#11 (comment)

@docularxu docularxu force-pushed the hikey-mainline-rebase branch 2 times, most recently from f5d0b7f to 8ad4c62 Compare May 4, 2016 12:46
@docularxu docularxu force-pushed the hikey-mainline-rebase branch 3 times, most recently from 4d18c02 to 55b65ae Compare May 11, 2016 14:53
@docularxu docularxu force-pushed the hikey-mainline-rebase branch from 55b65ae to f841975 Compare May 19, 2016 02:11
@docularxu docularxu force-pushed the hikey-mainline-rebase branch from 4ac587b to 3828f09 Compare June 6, 2016 04:21
@docularxu docularxu force-pushed the hikey-mainline-rebase branch 2 times, most recently from 212b200 to 3a75664 Compare June 21, 2016 06:54
@vchong
Copy link
Author

vchong commented Jun 22, 2016

Closing this PR as it's not required anymore due to this repo now having its own op-tee tracking branch @ https://github.com/96boards-hikey/linux/commits/hikey-tracking-optee.

@vchong vchong closed this Jun 22, 2016
@vchong vchong deleted the gendrv branch June 22, 2016 03:13
gaozhangfei pushed a commit that referenced this pull request Jan 17, 2017
Starting with commit d94a461 ("ath9k: use ieee80211_tx_status_noskb
where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on
returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls
and suspicious RCU usage:

 ===============================
 [ INFO: suspicious RCU usage. ]
 4.9.0-rc8 #11 Not tainted
 -------------------------------
 kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!

 other info that might help us debug this:

 RCU used illegally from idle CPU!
 rcu_scheduler_active = 1, debug_locks = 0
 RCU used illegally from extended quiescent state!
 1 lock held by swapper/7/0:
 #0:
  (
 rcu_read_lock
 ){......}
 , at:
 [<ffffffffa06ed110>] ath_tx_edma_tasklet+0x0/0x450 [ath9k]

 stack backtrace:
 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
 Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
  ffff88025efc3f38 ffffffff8132b1e5 ffff88017ede4540 0000000000000001
  ffff88025efc3f68 ffffffff810a25f7 ffff88025efcee60 ffff88017edebdd8
  ffff88025eeb5400 0000000000000091 ffff88025efc3f88 ffffffff810c3cd4
 Call Trace:
  <IRQ>
  [<ffffffff8132b1e5>] dump_stack+0x68/0x93
  [<ffffffff810a25f7>] lockdep_rcu_suspicious+0xd7/0x110
  [<ffffffff810c3cd4>] rcu_eqs_enter_common.constprop.85+0x154/0x200
  [<ffffffff810c5a54>] rcu_irq_exit+0x44/0xa0
  [<ffffffff81058631>] irq_exit+0x61/0xd0
  [<ffffffff81018d25>] do_IRQ+0x65/0x110
  [<ffffffff81672189>] common_interrupt+0x89/0x89
  <EOI>
  [<ffffffff814ffe11>] ? cpuidle_enter_state+0x151/0x200
  [<ffffffff814ffee2>] cpuidle_enter+0x12/0x20
  [<ffffffff8109a6ae>] call_cpuidle+0x1e/0x40
  [<ffffffff8109a8f6>] cpu_startup_entry+0x146/0x220
  [<ffffffff810336f8>] start_secondary+0x148/0x170

Signed-off-by: Tobias Klausmann <[email protected]>
Fixes: d94a461 ("ath9k: use ieee80211_tx_status_noskb where possible")
Cc: <[email protected]> # v4.9
Acked-by: Felix Fietkau <[email protected]>
Acked-by: Paul E. McKenney <[email protected]>
Tested-by: Gabriel Craciunescu <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
docularxu pushed a commit that referenced this pull request Apr 10, 2017
[ Upstream commit 45caeaa ]

As Eric Dumazet pointed out this also needs to be fixed in IPv6.
v2: Contains the IPv6 tcp/Ipv6 dccp patches as well.

We have seen a few incidents lately where a dst_enty has been freed
with a dangling TCP socket reference (sk->sk_dst_cache) pointing to that
dst_entry. If the conditions/timings are right a crash then ensues when the
freed dst_entry is referenced later on. A Common crashing back trace is:

 #8 [] page_fault at ffffffff8163e648
    [exception RIP: __tcp_ack_snd_check+74]
.
.
 #9 [] tcp_rcv_established at ffffffff81580b64
#10 [] tcp_v4_do_rcv at ffffffff8158b54a
#11 [] tcp_v4_rcv at ffffffff8158cd02
#12 [] ip_local_deliver_finish at ffffffff815668f4
#13 [] ip_local_deliver at ffffffff81566bd9
#14 [] ip_rcv_finish at ffffffff8156656d
#15 [] ip_rcv at ffffffff81566f06
#16 [] __netif_receive_skb_core at ffffffff8152b3a2
#17 [] __netif_receive_skb at ffffffff8152b608
#18 [] netif_receive_skb at ffffffff8152b690
#19 [] vmxnet3_rq_rx_complete at ffffffffa015eeaf [vmxnet3]
#20 [] vmxnet3_poll_rx_only at ffffffffa015f32a [vmxnet3]
#21 [] net_rx_action at ffffffff8152bac2
#22 [] __do_softirq at ffffffff81084b4f
#23 [] call_softirq at ffffffff8164845c
#24 [] do_softirq at ffffffff81016fc5
#25 [] irq_exit at ffffffff81084ee5
#26 [] do_IRQ at ffffffff81648ff8

Of course it may happen with other NIC drivers as well.

It's found the freed dst_entry here:

 224 static bool tcp_in_quickack_mode(struct sock *sk)↩
 225 {↩
 226 ▹       const struct inet_connection_sock *icsk = inet_csk(sk);↩
 227 ▹       const struct dst_entry *dst = __sk_dst_get(sk);↩
 228 ↩
 229 ▹       return (dst && dst_metric(dst, RTAX_QUICKACK)) ||↩
 230 ▹       ▹       (icsk->icsk_ack.quick && !icsk->icsk_ack.pingpong);↩
 231 }↩

But there are other backtraces attributed to the same freed dst_entry in
netfilter code as well.

All the vmcores showed 2 significant clues:

- Remote hosts behind the default gateway had always been redirected to a
different gateway. A rtable/dst_entry will be added for that host. Making
more dst_entrys with lower reference counts. Making this more probable.

- All vmcores showed a postitive LockDroppedIcmps value, e.g:

LockDroppedIcmps                  267

A closer look at the tcp_v4_err() handler revealed that do_redirect() will run
regardless of whether user space has the socket locked. This can result in a
race condition where the same dst_entry cached in sk->sk_dst_entry can be
decremented twice for the same socket via:

do_redirect()->__sk_dst_check()-> dst_release().

Which leads to the dst_entry being prematurely freed with another socket
pointing to it via sk->sk_dst_cache and a subsequent crash.

To fix this skip do_redirect() if usespace has the socket locked. Instead let
the redirect take place later when user space does not have the socket
locked.

The dccp/IPv6 code is very similar in this respect, so fixing it there too.

As Eric Garver pointed out the following commit now invalidates routes. Which
can set the dst->obsolete flag so that ipv4_dst_check() returns null and
triggers the dst_release().

Fixes: ceb3320 ("ipv4: Kill routes during PMTU/redirect updates.")
Cc: Eric Garver <[email protected]>
Cc: Hannes Sowa <[email protected]>
Signed-off-by: Jon Maxwell <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
docularxu pushed a commit that referenced this pull request Apr 10, 2017
commit 4dfce57 upstream.

There have been several reports over the years of NULL pointer
dereferences in xfs_trans_log_inode during xfs_fsr processes,
when the process is doing an fput and tearing down extents
on the temporary inode, something like:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
PID: 29439  TASK: ffff880550584fa0  CPU: 6   COMMAND: "xfs_fsr"
    [exception RIP: xfs_trans_log_inode+0x10]
 #9 [ffff8800a57bbbe0] xfs_bunmapi at ffffffffa037398e [xfs]
#10 [ffff8800a57bbce8] xfs_itruncate_extents at ffffffffa0391b29 [xfs]
#11 [ffff8800a57bbd88] xfs_inactive_truncate at ffffffffa0391d0c [xfs]
#12 [ffff8800a57bbdb8] xfs_inactive at ffffffffa0392508 [xfs]
#13 [ffff8800a57bbdd8] xfs_fs_evict_inode at ffffffffa035907e [xfs]
#14 [ffff8800a57bbe00] evict at ffffffff811e1b67
#15 [ffff8800a57bbe28] iput at ffffffff811e23a5
#16 [ffff8800a57bbe58] dentry_kill at ffffffff811dcfc8
#17 [ffff8800a57bbe88] dput at ffffffff811dd06c
#18 [ffff8800a57bbea8] __fput at ffffffff811c823b
#19 [ffff8800a57bbef0] ____fput at ffffffff811c846e
#20 [ffff8800a57bbf00] task_work_run at ffffffff81093b27
#21 [ffff8800a57bbf30] do_notify_resume at ffffffff81013b0c
#22 [ffff8800a57bbf50] int_signal at ffffffff8161405d

As it turns out, this is because the i_itemp pointer, along
with the d_ops pointer, has been overwritten with zeros
when we tear down the extents during truncate.  When the in-core
inode fork on the temporary inode used by xfs_fsr was originally
set up during the extent swap, we mistakenly looked at di_nextents
to determine whether all extents fit inline, but this misses extents
generated by speculative preallocation; we should be using if_bytes
instead.

This mistake corrupts the in-memory inode, and code in
xfs_iext_remove_inline eventually gets bad inputs, causing
it to memmove and memset incorrect ranges; this became apparent
because the two values in ifp->if_u2.if_inline_ext[1] contained
what should have been in d_ops and i_itemp; they were memmoved due
to incorrect array indexing and then the original locations
were zeroed with memset, again due to an array overrun.

Fix this by properly using i_df.if_bytes to determine the number
of extents, not di_nextents.

Thanks to dchinner for looking at this with me and spotting the
root cause.

[nborisov: backported to 4.4]

Cc: [email protected]
Signed-off-by: Eric Sandeen <[email protected]>
Reviewed-by: Brian Foster <[email protected]>
Signed-off-by: Dave Chinner <[email protected]>
Signed-off-by: Nikolay Borisov <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
--
 fs/xfs/xfs_bmap_util.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
docularxu pushed a commit that referenced this pull request Jun 8, 2017
On powerpc we can build the kernel with two different ABIs for mcount(), which
is used by ftrace. Kernels built with one ABI do not know how to load modules
built with the other ABI. The new style ABI is called "mprofile-kernel", for
want of a better name.

Currently if we build a module using the old style ABI, and the kernel with
mprofile-kernel, when we load the module we'll oops something like:

  # insmod autofs4-no-mprofile-kernel.ko
  ftrace-powerpc: Unexpected instruction f8810028 around bl _mcount
  ------------[ cut here ]------------
  WARNING: CPU: 6 PID: 3759 at ../kernel/trace/ftrace.c:2024 ftrace_bug+0x2b8/0x3c0
  CPU: 6 PID: 3759 Comm: insmod Not tainted 4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269 #11
  ...
  NIP [c0000000001eaa48] ftrace_bug+0x2b8/0x3c0
  LR [c0000000001eaff8] ftrace_process_locs+0x4a8/0x590
  Call Trace:
    alloc_pages_current+0xc4/0x1d0 (unreliable)
    ftrace_process_locs+0x4a8/0x590
    load_module+0x1c8c/0x28f0
    SyS_finit_module+0x110/0x140
    system_call+0x38/0xfc
  ...
  ftrace failed to modify
  [<d000000002a31024>] 0xd000000002a31024
   actual:   35:65:00:48

We can avoid this by including in the vermagic whether the kernel/module was
built with mprofile-kernel. Which results in:

  # insmod autofs4-pg.ko
  autofs4: version magic
  '4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269 SMP mod_unload modversions '
  should be
  '4.11.0-rc3-gcc-5.4.1-00017-g5a61ef74f269-dirty SMP mod_unload modversions mprofile-kernel'
  insmod: ERROR: could not insert module autofs4-pg.ko: Invalid module format

Fixes: 8c50b72 ("powerpc/ftrace: Add Kconfig & Make glue for mprofile-kernel")
Signed-off-by: Michael Ellerman <[email protected]>
Acked-by: Balbir Singh <[email protected]>
Acked-by: Jessica Yu <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
docularxu pushed a commit that referenced this pull request Nov 3, 2017
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: Thomas-Mich Richter <[email protected]>
Signed-off-by: Namhyung Kim <[email protected]>
Tested-by: Arnaldo Carvalho de Melo <[email protected]>
Cc: Hari Bathini <[email protected]>
Cc: Hendrik Brueckner <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas-Mich Richter <[email protected]>
Fixes: f3b3614 ("perf tools: Add PERF_RECORD_NAMESPACES to include namespaces related info")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.