This patch handles 3) and 4) for BPF programs loaded after 'perf
record|top'.
For timely process of these information, a dedicated event is added to
the side band evlist.
When PERF_RECORD_BPF_EVENT is received via the side band event, the
polling thread gathers 3) and 4) vis sys_bpf and store them in perf_env.
This information is saved to perf.data at the end of 'perf record'.
Committer testing:
The 'wakeup_watermark' member in 'struct perf_event_attr' is inside a
unnamed union, so can't be used in a struct designated initialization
with older gccs, get it out of that, isolating as 'attr.wakeup_watermark
= 1;' to work with all gcc versions.
We also need to add '--no-bpf-event' to the 'perf record'
perf_event_attr tests in 'perf test', as the way that that test goes is
to intercept the events being setup and looking if they match the fields
described in the control files, since now it finds first the side band
event used to catch the PERF_RECORD_BPF_EVENT, they all fail.
With these issues fixed:
Same scenario as for testing BPF programs loaded before 'perf record' or
'perf top' starts, only start the BPF programs after 'perf record|top',
so that its information get collected by the sideband threads, the rest
works as for the programs loaded before start monitoring.
Add missing 'inline' to the bpf_event__add_sb_event() when
HAVE_LIBBPF_SUPPORT is not defined, fixing the build in systems without
binutils devel files installed.
Song Liu [Tue, 12 Mar 2019 05:30:50 +0000 (22:30 -0700)]
perf evlist: Introduce side band thread
This patch introduces side band thread that captures extended
information for events like PERF_RECORD_BPF_EVENT.
This new thread uses its own evlist that uses ring buffer with very low
watermark for lower latency.
To use side band thread, we need to:
1. add side band event(s) by calling perf_evlist__add_sb_event();
2. calls perf_evlist__start_sb_thread();
3. at the end of perf run, perf_evlist__stop_sb_thread().
In the next patch, we use this thread to handle PERF_RECORD_BPF_EVENT.
Committer notes:
Add fix by Jiri Olsa for when te sb_tread can't get started and then at
the end the stop_sb_thread() segfaults when joining the (non-existing)
thread.
That can happen when running 'perf top' or 'perf record' as a normal
user, for instance.
Further checks need to be done on top of this to more graciously handle
these possible failure scenarios.
This is because it expands the macro into a non-functioning calling
sequence. The calling order must be:
outb(CX86_CCR2, 0x22);
inb(0x23);
From the comments:
* When using the old macros a line like
* setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
* gets expanded to:
* do {
* outb((CX86_CCR2), 0x22);
* outb((({
* outb((CX86_CCR2), 0x22);
* inb(0x23);
* }) | 0x88), 0x23);
* } while (0);
The new macros fix this problem, so use them instead. Tested on an
actual Geode processor.
Nick Desaulniers [Thu, 14 Mar 2019 22:14:57 +0000 (15:14 -0700)]
x86/boot: Restrict header scope to make Clang happy
The inclusion of <linux/kernel.h> was causing issue as the definition of
__arch_hweight64 from arch/x86/include/asm/arch_hweight.h eventually gets
included. The definition is problematic when compiled with -m16 (all code
in arch/x86/boot/ is) as the "D" inline assembly constraint is rejected
by both compilers when passed an argument of type long long (regardless
of signedness, anything smaller is fine).
Because GCC performs inlining before semantic analysis, and
__arch_hweight64 is dead in this translation unit, GCC does not report
any issues at compile time. Clang does the semantic analysis in the
front end, before inlining (run in the middle) can determine the code is
dead. I consider this another case of PR33587, which I think we can do
more work to solve.
It turns out that arch/x86/boot/string.c doesn't actually need
linux/kernel.h, simply linux/limits.h and linux/compiler.h.
Jianguo Chen [Wed, 20 Mar 2019 18:54:21 +0000 (18:54 +0000)]
irqchip/mbigen: Don't clear eventid when freeing an MSI
mbigen_write_msg clears eventid bits of a mbigen register
when free a interrupt, because msi_domain_deactivate memset
struct msg to zero. Then multiple mbigen pins with zero eventid
will report the same interrupt number.
Fabien Dessenne [Thu, 7 Mar 2019 18:40:36 +0000 (19:40 +0100)]
irqchip/stm32: Don't set rising configuration registers at init
The rising configuration status register (rtsr) is not banked.
As it is shared with the co-processor, it should not be written at probe
time, else the co-processor configuration will be lost.
Fixes: f9fc1745501e ("irqchip/stm32: Add host and driver data structures") Signed-off-by: Fabien Dessenne <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
Fabien Dessenne [Thu, 7 Mar 2019 18:40:35 +0000 (19:40 +0100)]
irqchip/stm32: Don't clear rising/falling config registers at init
Falling and rising configuration and status registers are not banked.
As they are shared with M4 co-processor, they should not be cleared
at probe time, else M4 co-processor configuration will be lost.
Fixes: f9fc1745501e ("irqchip/stm32: Add host and driver data structures") Signed-off-by: Loic Pallardy <[email protected]> Signed-off-by: Fabien Dessenne <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
YueHaibing [Wed, 20 Mar 2019 14:22:20 +0000 (22:22 +0800)]
irqchip/brcmstb-l2: Make two init functions static
Fix sparse warnings:
drivers/irqchip/irq-brcmstb-l2.c:278:12: warning:
symbol 'brcmstb_l2_edge_intc_of_init' was not declared. Should it be static?
drivers/irqchip/irq-brcmstb-l2.c:285:12: warning:
symbol 'brcmstb_l2_lvl_intc_of_init' was not declared. Should it be static?
Josh Poimboeuf [Tue, 19 Mar 2019 00:09:38 +0000 (19:09 -0500)]
objtool: Move objtool_file struct off the stack
Objtool uses over 512k of stack, thanks to the hash table embedded in
the objtool_file struct. This causes an unnecessarily large stack
allocation and breaks users with low stack limits.
Bart Van Assche [Mon, 11 Mar 2019 23:02:55 +0000 (16:02 -0700)]
workqueue: Only unregister a registered lockdep key
The recent change to prevent use after free and a memory leak introduced an
unconditional call to wq_unregister_lockdep() in the error handling
path. If the lockdep key had not been registered yet, then the lockdep core
emits a warning.
Only call wq_unregister_lockdep() if wq_register_lockdep() has been
called first.
Wolfram Sang [Tue, 19 Mar 2019 10:12:59 +0000 (11:12 +0100)]
mmc: renesas_sdhi: limit block count to 16 bit for old revisions
R-Car Gen2 has two different SDHI incarnations in the same chip. The
older one does not support the recently introduced 32 bit register
access to the block count register. Make sure we use this feature only
after the first known version.
Thanks to the Renesas Testing team for this bug report!
Daniel Drake [Wed, 20 Mar 2019 06:36:53 +0000 (14:36 +0800)]
mmc: alcor: fix DMA reads
Setting max_blk_count to 1 here was causing the mmc block layer
to always use the MMC_READ_SINGLE_BLOCK command here, which the
driver does not DMA-accelerate.
Drop the max_blk_ settings here. The mmc host defaults suffice,
along with the max_segs and max_seg_size settings, which I have
now documented in more detail.
Now each MMC command reads 4 512-byte blocks, using DMA instead of
PIO. On my SD card, this increases read performance (measured with dd)
from 167kb/sec to 4.6mb/sec.
mmc: sdhci-omap: Set caps2 to indicate no physical write protect pin
After commit 6d5cd068ee59fba ("mmc: sdhci: use WP GPIO in
sdhci_check_ro()") and commit 39ee32ce486756f ("mmc: sdhci-omap: drop
->get_ro() implementation"), sdhci-omap relied on SDHCI_PRESENT_STATE
to check if the card is read-only, if wp-gpios is not populated
in device tree. However SDHCI_PRESENT_STATE in sdhci-omap does not have
correct read-only state.
sdhci-omap can be used by platforms with both micro SD slot and standard
SD slot with physical write protect pin (using GPIO). Set caps2 to
MMC_CAP2_NO_WRITE_PROTECT based on if wp-gpios property is populated or
not.
This fix is required since existing device-tree node doesn't have
"disable-wp" property and to preserve old-dt compatibility.
Fixes: 6d5cd068ee59fba ("mmc: sdhci: use WP GPIO in sdhci_check_ro()") Fixes: 39ee32ce486756f ("mmc: sdhci-omap: drop ->get_ro() implementation") Signed-off-by: Kishon Vijay Abraham I <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
Michael Ellerman [Thu, 21 Mar 2019 04:24:33 +0000 (15:24 +1100)]
powerpc/security: Fix spectre_v2 reporting
When I updated the spectre_v2 reporting to handle software count cache
flush I got the logic wrong when there's no software count cache
enabled at all.
The result is that on systems with the software count cache flush
disabled we print:
Which correctly indicates that the count cache is disabled, but
incorrectly says the software count cache flush is enabled.
The root of the problem is that we are trying to handle all
combinations of options. But we know now that we only expect to see
the software count cache flush enabled if the other options are false.
So split the two cases, which simplifies the logic and fixes the bug.
We were also missing a space before "(hardware accelerated)".
Jian-Hong Pan [Fri, 15 Mar 2019 09:51:09 +0000 (17:51 +0800)]
ALSA: hda/realtek: Enable headset MIC of Acer AIO with ALC286
Some Acer AIO desktops like Veriton Z6860G, Z4860G and Z4660G cannot
record sound from headset MIC. This patch adds the
ALC286_FIXUP_ACER_AIO_HEADSET_MIC quirk to fix this issue.
Fixes: 9f8aefed9623 ("ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4660G") Fixes: b72f936f6b32 ("ALSA: hda/realtek: Fix mic issue on Acer AIO Veriton Z4860G/Z6860G") Signed-off-by: Jian-Hong Pan <[email protected]> Reviewed-by: Kailang Yang <[email protected]> Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4
to update internal state (shadow registers).
Apparently the driver implements it incorrectly. The rule should be
as follows:
- do not request updating registers until previous request was finished,
ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0.
- before setting registers synchronisation on VSYNC should be turned off,
ie. MXR_STATUS_SYNC_ENABLE should be reset,
- after finishing MXR_STATUS_SYNC_ENABLE should be set again.
The patch hopefully implements it correctly.
Below sample kernel log from page fault caused by the bug:
[ 25.670038] exynos-sysmmu 14650000.sysmmu: 14450000.mixer: PAGE FAULT occurred at 0x2247b800
[ 25.677888] ------------[ cut here ]------------
[ 25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450!
[ 25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 25.693778] Modules linked in:
[ 25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted 5.0.0-rc7-01157-g5f86b1566bdd #136
[ 25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264
[ 25.716470] LR is at lock_is_held_type+0x44/0x64
v2: added missing MXR_CFG_LAYER_UPDATE bit setting in mixer_enable_sync
Tyrel Datwyler [Wed, 20 Mar 2019 18:41:51 +0000 (13:41 -0500)]
scsi: ibmvscsi: Fix empty event pool access during host removal
The event pool used for queueing commands is destroyed fairly early in the
ibmvscsi_remove() code path. Since, this happens prior to the call so
scsi_remove_host() it is possible for further calls to queuecommand to be
processed which manifest as a panic due to a NULL pointer dereference as
seen here:
PANIC: "Unable to handle kernel paging request for data at address
0x00000000"
The kernel buffer log is overfilled with this log:
[11261.952732] ibmvscsi: found no event struct in pool!
This patch reorders the operations during host teardown. Start by calling
the SRP transport and Scsi_Host remove functions to flush any outstanding
work and set the host offline. LLDD teardown follows including destruction
of the event pool, freeing the Command Response Queue (CRQ), and unmapping
any persistent buffers. The event pool destruction is protected by the
scsi_host lock, and the pool is purged prior of any requests for which we
never received a response. Finally, move the removal of the scsi host from
our global list to the end so that the host is easily locatable for
debugging purposes during teardown.
Tyrel Datwyler [Wed, 20 Mar 2019 18:41:50 +0000 (13:41 -0500)]
scsi: ibmvscsi: Protect ibmvscsi_head from concurrent modificaiton
For each ibmvscsi host created during a probe or destroyed during a remove
we either add or remove that host to/from the global ibmvscsi_head
list. This runs the risk of concurrent modification.
This patch adds a simple spinlock around the list modification calls to
prevent concurrent updates as is done similarly in the ibmvfc driver and
ipr driver.
Fixes: 32d6e4b6e4ea ("scsi: ibmvscsi: add vscsi hosts to global list_head") Cc: <[email protected]> # v4.10+ Signed-off-by: Tyrel Datwyler <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
Bart Van Assche [Wed, 20 Mar 2019 20:18:45 +0000 (13:18 -0700)]
blkcg: Fix kernel-doc warnings
Avoid that the following warnings are reported when building with W=1:
block/blk-cgroup.c:1755: warning: Function parameter or member 'q' not described in 'blkcg_schedule_throttle'
block/blk-cgroup.c:1755: warning: Function parameter or member 'use_memdelay' not described in 'blkcg_schedule_throttle'
block/blk-cgroup.c:1779: warning: Function parameter or member 'blkg' not described in 'blkcg_add_delay'
block/blk-cgroup.c:1779: warning: Function parameter or member 'now' not described in 'blkcg_add_delay'
block/blk-cgroup.c:1779: warning: Function parameter or member 'delta' not described in 'blkcg_add_delay'
Yufen Yu [Mon, 18 Mar 2019 14:44:41 +0000 (22:44 +0800)]
block: add BLK_MQ_POLL_CLASSIC for hybrid poll and return EINVAL for unexpected value
For q->poll_nsec == -1, means doing classic poll, not hybrid poll.
We introduce a new flag BLK_MQ_POLL_CLASSIC to replace -1, which
may make code much easier to read.
Additionally, since val is an int obtained with kstrtoint(), val can be
a negative value other than -1, so return -EINVAL for that case.
Thanks to Damien Le Moal for some good suggestion.
Song Liu [Tue, 12 Mar 2019 05:30:48 +0000 (22:30 -0700)]
perf annotate: Enable annotation of BPF programs
In symbol__disassemble(), DSO_BINARY_TYPE__BPF_PROG_INFO dso calls into
a new function symbol__disassemble_bpf(), where annotation line
information is filled based on the bpf_prog_info and btf data saved in
given perf_env.
symbol__disassemble_bpf() uses binutils's libopcodes to disassemble bpf
programs.
We'll see the two BPF programs that augmented_raw_syscalls.o puts in
place, one attached to the raw_syscalls:sys_enter and another to the
raw_syscalls:sys_exit tracepoints, as expected.
Now we can finally do, from the command line, annotation for one of
those two symbols, with the original BPF program source coude intermixed
with the disassembled JITed code:
Please see 'man perf-config' to see how to control what should be seen,
via ~/.perfconfig [annotate] section, for instance, one can suppress the
source code and see just the disassembly, etc.
Alternatively, use the TUI bu just using 'perf annotate', press
'/bpf_prog' to see the bpf symbols, press enter and do the interactive
annotation, which allows for dumping to a file after selecting the
the various output tunables, for instance, the above without source code
intermixed, plus showing all the instruction offsets:
Then press: 's' to hide the source code + 'O' twice to show all
instruction offsets, then 'P' to print to the
bpf_prog_819967866022f1e1_sys_enter.annotation file, which will have:
Song Liu [Tue, 12 Mar 2019 05:30:48 +0000 (22:30 -0700)]
perf build: Check what binutils's 'disassembler()' signature to use
Commit 003ca0fd2286 ("Refactor disassembler selection") in the binutils
repo, which changed the disassembler() function signature, so we must
use the feature test introduced in fb982666e380 ("tools/bpftool: fix
bpftool build with bintutils >= 2.9") to deal with that.
Committer testing:
After adding the missing function call to test-all.c, and:
Auto-detecting system features:
... dwarf: [ on ]
... dwarf_getlocations: [ on ]
... glibc: [ on ]
... gtk2: [ on ]
... libaudit: [ on ]
... libbfd: [ on ]
... libelf: [ on ]
... libnuma: [ on ]
... numa_num_possible_cpus: [ on ]
... libperl: [ on ]
... libpython: [ on ]
... libslang: [ on ]
... libcrypto: [ on ]
... libunwind: [ on ]
... libdw-dwarf-unwind: [ on ]
... zlib: [ on ]
... lzma: [ on ]
... get_cpuid: [ on ]
... bpf: [ on ]
... libaio: [ on ]
... disassembler-four-args: [ on ]
CC /tmp/build/perf/jvmti/libjvmti.o
CC /tmp/build/perf/builtin-bench.o
<SNIP>
$
$
The feature detection test-all.bin gets successfully built and linked:
$ ls -la /tmp/build/perf/feature/test-all.bin
-rwxrwxr-x. 1 acme acme 2680352 Mar 19 11:07 /tmp/build/perf/feature/test-all.bin
$ nm /tmp/build/perf/feature/test-all.bin | grep -w disassembler 0000000000061f90 T disassembler
$
Time to move on to the patches that make use of this disassembler()
routine in binutils's libopcodes.
Luo Jiaxing [Wed, 20 Mar 2019 10:21:34 +0000 (18:21 +0800)]
scsi: hisi_sas: Add softreset in hisi_sas_I_T_nexus_reset()
We found out that for v2 hw, a SATA disk can not be written to after the
system comes up.
In commit ffb1c820b8b6 ("scsi: hisi_sas: remove the check of sas_dev status
in hisi_sas_I_T_nexus_reset()"), we introduced a path where we may issue an
internal abort for a SATA device, but without following it with a
softreset.
We need to always follow an internal abort with a software reset, as per HW
programming flow, so add this.
Fixes: ffb1c820b8b6 ("scsi: hisi_sas: remove the check of sas_dev status in hisi_sas_I_T_nexus_reset()") Signed-off-by: Luo Jiaxing <[email protected]> Signed-off-by: John Garry <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
Rasmus Villemoes [Tue, 12 Mar 2019 17:33:46 +0000 (18:33 +0100)]
irqchip/gic-v3-its: Fix comparison logic in lpi_range_cmp
The lpi_range_list is supposed to be sorted in ascending order of
->base_id (at least if the range merging is to work), but the current
comparison function returns a positive value if rb->base_id >
ra->base_id, which means that list_sort() will put A after B in that
case - and vice versa, of course.
Linus Torvalds [Wed, 20 Mar 2019 18:01:52 +0000 (11:01 -0700)]
Merge tag 'arc-5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
Pull ARC updates from Vineet Gupta:
- unaligned access support for HS cores
- Removed extra memory barrier around spinlock code
- HSDK platform updates: enable dmac, reset
- some more boot logging updates
- misc minor fixes
* tag 'arc-5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
arch: arc: Kconfig: pedantic formatting
ARCv2: spinlock: remove the extra smp_mb before lock, after unlock
ARC: unaligned: relax the check for gcc supporting -mno-unaligned-access
ARC: boot log: cut down on verbosity
ARCv2: boot log: refurbish HS core/release identification
arc: hsdk_defconfig: Enable CONFIG_BLK_DEV_RAM
ARC: u-boot args: check that magic number is correct
ARC: perf: bpok condition only exists for ARCompact
ARCv2: Add explcit unaligned access support (and ability to disable too)
ARCv2: lib: introduce memcpy optimized for unaligned access
ARC: [plat-hsdk]: Enable AXI DW DMAC support
ARC: [plat-hsdk]: Add reset controller handle to manage USB reset
ARC: DTB: [scripted] fix node name and address spelling
arm64: remove obsolete selection of MULTI_IRQ_HANDLER
The arm64 config selects MULTI_IRQ_HANDLER, which was renamed to
GENERIC_IRQ_MULTI_HANDLER by commit 4c301f9b6a94 ("ARM: Convert
to GENERIC_IRQ_MULTI_HANDLER"). The 'new' option is already
selected, so just remove the obsolete entry.
YueHaibing [Wed, 20 Mar 2019 14:18:13 +0000 (22:18 +0800)]
KVM: arm/arm64: vgic-its: Make attribute accessors static
Fix sparse warnings:
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-its.c:1732:5: warning:
symbol 'vgic_its_has_attr_regs' was not declared. Should it be static?
arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-its.c:1753:5: warning:
symbol 'vgic_its_attr_regs_access' was not declared. Should it be static?
Suzuki K Poulose [Wed, 20 Mar 2019 14:57:19 +0000 (14:57 +0000)]
KVM: arm/arm64: Fix handling of stage2 huge mappings
We rely on the mmu_notifier call backs to handle the split/merge
of huge pages and thus we are guaranteed that, while creating a
block mapping, either the entire block is unmapped at stage2 or it
is missing permission.
However, we miss a case where the block mapping is split for dirty
logging case and then could later be made block mapping, if we cancel the
dirty logging. This not only creates inconsistent TLB entries for
the pages in the the block, but also leakes the table pages for
PMD level.
Handle this corner case for the huge mappings at stage2 by
unmapping the non-huge mapping for the block. This could potentially
release the upper level table. So we need to restart the table walk
once we unmap the range.
Ilya Dryomov [Wed, 20 Mar 2019 08:46:58 +0000 (09:46 +0100)]
libceph: wait for latest osdmap in ceph_monc_blacklist_add()
Because map updates are distributed lazily, an OSD may not know about
the new blacklist for quite some time after "osd blacklist add" command
is completed. This makes it possible for a blacklisted but still alive
client to overwrite a post-blacklist update, resulting in data
corruption.
Waiting for latest osdmap in ceph_monc_blacklist_add() and thus using
the post-blacklist epoch for all post-blacklist requests ensures that
all such requests "wait" for the blacklist to come into force on their
respective OSDs.
Ben Hutchings [Sun, 17 Mar 2019 01:17:56 +0000 (01:17 +0000)]
powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations
MAX_PHYSMEM_BITS only needs to be defined if CONFIG_SPARSEMEM is
enabled, and that was the case before commit 4ffe713b7587
("powerpc/mm: Increase the max addressable memory to 2PB").
On 32-bit systems, where CONFIG_SPARSEMEM is not enabled, we now
define it as 46. That is larger than the real number of physical
address bits, and breaks calculations in zsmalloc:
mm/zsmalloc.c:130:49: warning: right shift count is negative
MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
^~
...
mm/zsmalloc.c:253:21: error: variably modified 'size_class' at file scope
struct size_class *size_class[ZS_SIZE_CLASSES];
^~~~~~~~~~
Fixes: 4ffe713b7587 ("powerpc/mm: Increase the max addressable memory to 2PB") Cc: [email protected] # v4.20+ Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
drm/vmwgfx: Don't double-free the mode stored in par->set_mode
When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd
twice. The first free is in vmw_fb_kms_detach(), the second is near the
end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code
only works correctly if the mode doesn't actually change. Removing
'old_mode' in favor of using par->set_mode directly fixes the problem.
Jiada Wang [Tue, 12 Mar 2019 06:51:28 +0000 (15:51 +0900)]
PM / Domains: Avoid a potential deadlock
Lockdep warns that prepare_lock and genpd->mlock can cause a deadlock
the deadlock scenario is like following:
First thread is probing cs2000
cs2000_probe()
clk_register()
__clk_core_init()
clk_prepare_lock() ----> acquires prepare_lock
cs2000_recalc_rate()
i2c_smbus_read_byte_data()
rcar_i2c_master_xfer()
dma_request_chan()
rcar_dmac_of_xlate()
rcar_dmac_alloc_chan_resources()
pm_runtime_get_sync()
__pm_runtime_resume()
rpm_resume()
rpm_callback()
genpd_runtime_resume() ----> acquires genpd->mlock
Second thread is attaching any device to the same PM domain
genpd_add_device()
genpd_lock() ----> acquires genpd->mlock
cpg_mssr_attach_dev()
of_clk_get_from_provider()
__of_clk_get_from_provider()
__clk_create_clk()
clk_prepare_lock() ----> acquires prepare_lock
Since currently no PM provider access genpd's critical section
in .attach_dev, and .detach_dev callbacks, so there is no need to protect
these two callbacks with genpd->mlock.
This patch avoids a potential deadlock by moving out .attach_dev and .detach_dev
from genpd->mlock, so that genpd->mlock won't be held when prepare_lock is acquired
in .attach_dev and .detach_dev
Andy Shevchenko [Mon, 18 Mar 2019 18:47:09 +0000 (21:47 +0300)]
ACPI / utils: Drop reference in test for device presence
When commit 8661423eea1a ("ACPI / utils: Add new acpi_dev_present
helper") introduced acpi_dev_present(), it missed the fact that
bus_find_device() took a reference on the device found by it and
the callers of acpi_dev_present() don't drop that reference.
Drop the reference on the device in acpi_dev_present().
Fixes: 8661423eea1a ("ACPI / utils: Add new acpi_dev_present helper") Signed-off-by: Andy Shevchenko <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]>
Song Liu [Tue, 12 Mar 2019 05:30:49 +0000 (22:30 -0700)]
perf bpf: Process PERF_BPF_EVENT_PROG_LOAD for annotation
This patch adds processing of PERF_BPF_EVENT_PROG_LOAD, which sets
proper DSO type/id/etc of memory regions mapped to BPF programs to
DSO_BINARY_TYPE__BPF_PROG_INFO.
Introduce a new dso type DSO_BINARY_TYPE__BPF_PROG_INFO for BPF programs. In
symbol__disassemble(), DSO_BINARY_TYPE__BPF_PROG_INFO dso will call into a new
function symbol__disassemble_bpf() in an upcoming patch, where annotation line
information is filled based bpf_prog_info and btf saved in given perf_env.
Committer notes:
Removed the unnamed union with 'bpf_prog' and 'cache' in 'struct dso',
to fix this bug when exiting 'perf top':
Song Liu [Tue, 12 Mar 2019 05:30:47 +0000 (22:30 -0700)]
perf feature detection: Add -lopcodes to feature-libbfd
Both libbfd and libopcodes are distributed with binutil-dev/devel. When
libbfd is present, it is OK to assume that libopcodes also present. This
has been a safe assumption for bpftool.
This patch adds -lopcodes to perf/Makefile.config. libopcodes will be
used in the next commit for BPF annotation.
Just to compile and load a BPF program that attaches to the
raw_syscalls:sys_{enter,exit} tracepoints to trace the syscalls ending
in "msg" (recvmsg, sendmsg, recvmmsg, sendmmsg, etc).
Make sure you have a recent enough clang, say version 9, to get the
BTF ELF sections needed for this testing:
Song Liu [Tue, 12 Mar 2019 05:30:43 +0000 (22:30 -0700)]
perf bpf: Save bpf_prog_info information as headers to perf.data
This patch enables perf-record to save bpf_prog_info information as
headers to perf.data. A new header type HEADER_BPF_PROG_INFO is
introduced for this data.
Committer testing:
As root, being on the kernel sources top level directory, run:
Just to compile and load a BPF program that attaches to the
raw_syscalls:sys_{enter,exit} tracepoints to trace the syscalls ending
in "msg" (recvmsg, sendmsg, recvmmsg, sendmmsg, etc).
Then do a systemwide perf record session for a few seconds:
# perf record -a sleep 2s
Then look at:
# perf report --header-only | grep -i bpf
# bpf_prog_info of id 13
# bpf_prog_info of id 14
# bpf_prog_info of id 15
# bpf_prog_info of id 16
# bpf_prog_info of id 17
# bpf_prog_info of id 18
# bpf_prog_info of id 21
# bpf_prog_info of id 22
# bpf_prog_info of id 208
# bpf_prog_info of id 209
#
We need to show more info about these programs, like bpftool does for
the ones running on the system, i.e. 'perf record/perf report' become a
way of saving the BPF state in a machine to then analyse on another,
together with all the other information that is already saved in the
perf.data header:
# perf report --header-only
# ========
# captured on : Tue Mar 12 11:42:13 2019
# header version : 1
# data offset : 296
# data size : 16294184
# feat offset : 16294480
# hostname : quaco
# os release : 5.0.0+
# perf version : 5.0.gd783c8
# arch : x86_64
# nrcpus online : 8
# nrcpus avail : 8
# cpudesc : Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz
# cpuid : GenuineIntel,6,142,10
# total memory : 24555720 kB
# cmdline : /home/acme/bin/perf (deleted) record -a
# event : name = cycles:ppp, , id = { 3190123, 3190124, 3190125, 3190126, 3190127, 3190128, 3190129, 3190130 }, size = 112, { sample_period, sample_freq } = 4000, sample_type = IP|TID|TIME|CPU|PERIOD, read_format = ID, disabled = 1, inherit = 1, mmap = 1, comm = 1, freq = 1, task = 1, precise_ip = 3, sample_id_all = 1, exclude_guest = 1, mmap2 = 1, comm_exec = 1
# CPU_TOPOLOGY info available, use -I to display
# NUMA_TOPOLOGY info available, use -I to display
# pmu mappings: intel_pt = 8, software = 1, power = 11, uprobe = 7, uncore_imc = 12, cpu = 4, cstate_core = 18, uncore_cbox_2 = 15, breakpoint = 5, uncore_cbox_0 = 13, tracepoint = 2, cstate_pkg = 19, uncore_arb = 17, kprobe = 6, i915 = 10, msr = 9, uncore_cbox_3 = 16, uncore_cbox_1 = 14
# CACHE info available, use -I to display
# time of first sample : 116392.441701
# time of last sample : 116400.932584
# sample duration : 8490.883 ms
# MEM_TOPOLOGY info available, use -I to display
# bpf_prog_info of id 13
# bpf_prog_info of id 14
# bpf_prog_info of id 15
# bpf_prog_info of id 16
# bpf_prog_info of id 17
# bpf_prog_info of id 18
# bpf_prog_info of id 21
# bpf_prog_info of id 22
# bpf_prog_info of id 208
# bpf_prog_info of id 209
# missing features: TRACING_DATA BRANCH_STACK GROUP_DESC AUXTRACE STAT CLOCKID DIR_FORMAT
# ========
#
Committer notes:
We can't use the libbpf unconditionally, as the build may have been with
NO_LIBBPF, when we end up with linking errors, so provide dummy
{process,write}_bpf_prog_info() wrapped by HAVE_LIBBPF_SUPPORT for that
case.
Printing are not affected by this, so can continue as is.
Before this set, 1) and 2) in the list are already saved to perf.data
file. For BPF programs that are already loaded before perf run, 1) and 2)
are synthesized by perf_event__synthesize_bpf_events(). For short living
BPF programs, 1) and 2) are generated by kernel.
This set handles 3) and 4) from the list. Again, it is necessary to handle
existing BPF program and short living program separately.
This patch handles 3) for exising BPF programs while synthesizing 1) and
2) in perf_event__synthesize_bpf_events(). These data are stored in
perf_env. The next patch saves these data from perf_env to perf.data as
headers.
Similarly, the two patches after the next saves 4) of existing BPF
programs to perf_env and perf.data.
Another patch later will handle 3) and 4) for short living BPF programs
by monitoring 1) and 2) in a dedicate thread.
Song Liu [Tue, 12 Mar 2019 05:30:41 +0000 (22:30 -0700)]
perf bpf: Make synthesize_bpf_events() receive perf_session pointer instead of perf_tool
This patch changes the arguments of perf_event__synthesize_bpf_events()
to include perf_session* instead of perf_tool*. perf_session will be
used in the next patch.
util/bpf-event.c: In function 'perf_event__synthesize_one_bpf_prog':
util/bpf-event.c:143:35: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
u8 (*prog_tags)[BPF_TAG_SIZE] = (void *)(info->prog_tags);
^
util/bpf-event.c:144:22: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
__u32 *prog_lens = (__u32 *)(info->jited_func_lens);
^
util/bpf-event.c:145:23: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
__u64 *prog_addrs = (__u64 *)(info->jited_ksyms);
^
util/bpf-event.c:146:22: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
void *func_infos = (void *)(info->func_info);
^
cc1: all warnings being treated as errors
Currently, bpf_prog_info includes 9 arrays. The user has the option to
fetch any combination of these arrays. However, this requires a lot of
handling.
This work becomes more tricky when we need to store bpf_prog_info to a
file, because these arrays are allocated independently.
This patch introduces 'struct bpf_prog_info_linear', which stores arrays
of bpf_prog_info in continuous memory.
Helper functions are introduced to unify the work to get different sets
of bpf_prog_info. Specifically, bpf_program__get_prog_info_linear()
allows the user to select which arrays to fetch, and handles details for
the user.
Please see the comments right before 'enum bpf_prog_info_array' for more
details and examples.
Song Liu [Tue, 12 Mar 2019 05:30:37 +0000 (22:30 -0700)]
perf record: Replace option --bpf-event with --no-bpf-event
Currently, monitoring of BPF programs through bpf_event is off by
default for 'perf record'.
To turn it on, the user need to use option "--bpf-event". As BPF gets
wider adoption in different subsystems, this option becomes
inconvenient.
This patch makes bpf_event on by default, and adds option "--no-bpf-event"
to turn it off. Since option --bpf-event is not released yet, it is safe
to remove it.
Direct leak of 1160 byte(s) in 1 object(s) allocated from:
#0 0x7f1b6fc84138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
#1 0x55bd50005599 in zalloc util/util.h:23
#2 0x55bd500068f5 in perf_evsel__newtp_idx util/evsel.c:327
#3 0x55bd4ff810fc in perf_evsel__newtp /home/work/linux/tools/perf/util/evsel.h:216
#4 0x55bd4ff81608 in test__perf_evsel__tp_sched_test tests/evsel-tp-sched.c:69
#5 0x55bd4ff528e6 in run_test tests/builtin-test.c:358
#6 0x55bd4ff52baf in test_and_print tests/builtin-test.c:388
#7 0x55bd4ff543fe in __cmd_test tests/builtin-test.c:583
#8 0x55bd4ff5572f in cmd_test tests/builtin-test.c:722
#9 0x55bd4ffc4087 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#10 0x55bd4ffc45c6 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#11 0x55bd4ffc49ca in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#12 0x55bd4ffc5138 in main /home/changbin/work/linux/tools/perf/perf.c:520
#13 0x7f1b6e34809a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Indirect leak of 19 byte(s) in 1 object(s) allocated from:
#0 0x7f1b6fc83f30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
#1 0x7f1b6e3ac30f in vasprintf (/lib/x86_64-linux-gnu/libc.so.6+0x8830f)
Direct leak of 13 byte(s) in 3 object(s) allocated from:
#0 0x7f03339d6070 in __interceptor_strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3b070)
#1 0x5625e53aaef0 in expr__find_other util/expr.y:221
#2 0x5625e51bcd3f in test__expr tests/expr.c:52
#3 0x5625e51528e6 in run_test tests/builtin-test.c:358
#4 0x5625e5152baf in test_and_print tests/builtin-test.c:388
#5 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
#6 0x5625e515572f in cmd_test tests/builtin-test.c:722
#7 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#8 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#9 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#10 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#11 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a88f30 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedf30)
#1 0x5625e5326213 in cpu_map__trim_new util/cpumap.c:45
#2 0x5625e5326703 in cpu_map__read util/cpumap.c:103
#3 0x5625e53267ef in cpu_map__read_all_cpu_map util/cpumap.c:120
#4 0x5625e5326915 in cpu_map__new util/cpumap.c:135
#5 0x5625e517b355 in test__openat_syscall_event_on_all_cpus tests/openat-syscall-all-cpus.c:36
#6 0x5625e51528e6 in run_test tests/builtin-test.c:358
#7 0x5625e5152baf in test_and_print tests/builtin-test.c:388
#8 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
#9 0x5625e515572f in cmd_test tests/builtin-test.c:722
#10 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#11 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#12 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#13 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#14 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a89138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
#1 0x5625e5330a5e in zalloc util/util.h:23
#2 0x5625e5330a9b in perf_counts__new util/counts.c:10
#3 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47
#4 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505
#5 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347
#6 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47
#7 0x5625e51528e6 in run_test tests/builtin-test.c:358
#8 0x5625e5152baf in test_and_print tests/builtin-test.c:388
#9 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
#10 0x5625e515572f in cmd_test tests/builtin-test.c:722
#11 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#12 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#13 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#14 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#15 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Indirect leak of 72 byte(s) in 1 object(s) allocated from:
#0 0x7f0333a89138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
#1 0x5625e532560d in zalloc util/util.h:23
#2 0x5625e532566b in xyarray__new util/xyarray.c:10
#3 0x5625e5330aba in perf_counts__new util/counts.c:15
#4 0x5625e5330ca0 in perf_evsel__alloc_counts util/counts.c:47
#5 0x5625e520d8e5 in __perf_evsel__read_on_cpu util/evsel.c:1505
#6 0x5625e517a985 in perf_evsel__read_on_cpu /home/work/linux/tools/perf/util/evsel.h:347
#7 0x5625e517ad1a in test__openat_syscall_event tests/openat-syscall.c:47
#8 0x5625e51528e6 in run_test tests/builtin-test.c:358
#9 0x5625e5152baf in test_and_print tests/builtin-test.c:388
#10 0x5625e51543fe in __cmd_test tests/builtin-test.c:583
#11 0x5625e515572f in cmd_test tests/builtin-test.c:722
#12 0x5625e51c3fb8 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#13 0x5625e51c44f7 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#14 0x5625e51c48fb in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#15 0x5625e51c5069 in main /home/changbin/work/linux/tools/perf/perf.c:520
#16 0x7f033214d09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
His patch took care of evsel->prev_raw_counts, but the above backtraces
are about evsel->counts, so fix that instead.
Changbin Du [Sat, 16 Mar 2019 08:05:52 +0000 (16:05 +0800)]
perf top: Fix global-buffer-overflow issue
The array str[] should have six elements.
=================================================================
==4322==ERROR: AddressSanitizer: global-buffer-overflow on address 0x56463844e300 at pc 0x564637e7ad0d bp 0x7f30c8c89d10 sp 0x7f30c8c89d00
READ of size 8 at 0x56463844e300 thread T9
#0 0x564637e7ad0c in __ordered_events__flush util/ordered-events.c:316
#1 0x564637e7b0e4 in ordered_events__flush util/ordered-events.c:338
#2 0x564637c6a57d in process_thread /home/changbin/work/linux/tools/perf/builtin-top.c:1073
#3 0x7f30d173a163 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8163)
#4 0x7f30cfffbdee in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x11adee)
0x56463844e300 is located 32 bytes to the left of global variable 'flags' defined in 'util/trace-event-parse.c:229:26' (0x56463844e320) of size 192
0x56463844e300 is located 0 bytes to the right of global variable 'str' defined in 'util/ordered-events.c:268:28' (0x56463844e2e0) of size 32
SUMMARY: AddressSanitizer: global-buffer-overflow util/ordered-events.c:316 in __ordered_events__flush
Shadow bytes around the buggy address:
0x0ac947081c10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac947081c20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac947081c30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac947081c40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac947081c50: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 00 00 00 00
=>0x0ac947081c60:[f9]f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac947081c70: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
0x0ac947081c80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac947081c90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac947081ca0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ac947081cb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Thread T9 created by T0 here:
#0 0x7f30d179de5f in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x4ae5f)
#1 0x564637c6b954 in __cmd_top /home/changbin/work/linux/tools/perf/builtin-top.c:1253
#2 0x564637c7173c in cmd_top /home/changbin/work/linux/tools/perf/builtin-top.c:1642
#3 0x564637d85038 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#4 0x564637d85577 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#5 0x564637d8597b in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#6 0x564637d860e9 in main /home/changbin/work/linux/tools/perf/perf.c:520
#7 0x7f30cff0509a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Changbin Du [Sat, 16 Mar 2019 08:05:47 +0000 (16:05 +0800)]
perf top: Delete the evlist before perf_session, fixing heap-use-after-free issue
The evlist should be destroyed before the perf session.
Detected with gcc's ASan:
=================================================================
==27350==ERROR: AddressSanitizer: heap-use-after-free on address 0x62b000002e38 at pc 0x5611da276999 bp 0x7ffce8f1d1a0 sp 0x7ffce8f1d190
WRITE of size 8 at 0x62b000002e38 thread T0
#0 0x5611da276998 in __list_del /home/work/linux/tools/include/linux/list.h:89
#1 0x5611da276d4a in __list_del_entry /home/work/linux/tools/include/linux/list.h:102
#2 0x5611da276e77 in list_del_init /home/work/linux/tools/include/linux/list.h:145
#3 0x5611da2781cd in thread__put util/thread.c:130
#4 0x5611da2cc0a8 in __thread__zput util/thread.h:68
#5 0x5611da2d2dcb in hist_entry__delete util/hist.c:1148
#6 0x5611da2cdf91 in hists__delete_entry util/hist.c:337
#7 0x5611da2ce19e in hists__delete_entries util/hist.c:365
#8 0x5611da2db2ab in hists__delete_all_entries util/hist.c:2639
#9 0x5611da2db325 in hists_evsel__exit util/hist.c:2651
#10 0x5611da1c5352 in perf_evsel__exit util/evsel.c:1304
#11 0x5611da1c5390 in perf_evsel__delete util/evsel.c:1309
#12 0x5611da1b35f0 in perf_evlist__purge util/evlist.c:124
#13 0x5611da1b38e2 in perf_evlist__delete util/evlist.c:148
#14 0x5611da069781 in cmd_top /home/changbin/work/linux/tools/perf/builtin-top.c:1645
#15 0x5611da17d038 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#16 0x5611da17d577 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#17 0x5611da17d97b in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#18 0x5611da17e0e9 in main /home/changbin/work/linux/tools/perf/perf.c:520
#19 0x7fdcc970f09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
#20 0x5611d9ff35c9 in _start (/home/work/linux/tools/perf/perf+0x3e95c9)
0x62b000002e38 is located 11320 bytes inside of 27448-byte region [0x62b000000200,0x62b000006d38)
freed by thread T0 here:
#0 0x7fdccb04ab70 in free (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xedb70)
#1 0x5611da260df4 in perf_session__delete util/session.c:201
#2 0x5611da063de5 in __cmd_top /home/changbin/work/linux/tools/perf/builtin-top.c:1300
#3 0x5611da06973c in cmd_top /home/changbin/work/linux/tools/perf/builtin-top.c:1642
#4 0x5611da17d038 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#5 0x5611da17d577 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#6 0x5611da17d97b in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#7 0x5611da17e0e9 in main /home/changbin/work/linux/tools/perf/perf.c:520
#8 0x7fdcc970f09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
previously allocated by thread T0 here:
#0 0x7fdccb04b138 in calloc (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xee138)
#1 0x5611da26010c in zalloc util/util.h:23
#2 0x5611da260824 in perf_session__new util/session.c:118
#3 0x5611da0633a6 in __cmd_top /home/changbin/work/linux/tools/perf/builtin-top.c:1192
#4 0x5611da06973c in cmd_top /home/changbin/work/linux/tools/perf/builtin-top.c:1642
#5 0x5611da17d038 in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#6 0x5611da17d577 in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#7 0x5611da17d97b in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#8 0x5611da17e0e9 in main /home/changbin/work/linux/tools/perf/perf.c:520
#9 0x7fdcc970f09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Changbin Du [Sat, 16 Mar 2019 08:05:46 +0000 (16:05 +0800)]
perf build-id: Fix memory leak in print_sdt_events()
Detected with gcc's ASan:
Direct leak of 4356 byte(s) in 120 object(s) allocated from:
#0 0x7ff1a2b5a070 in __interceptor_strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3b070)
#1 0x55719aef4814 in build_id_cache__origname util/build-id.c:215
#2 0x55719af649b6 in print_sdt_events util/parse-events.c:2339
#3 0x55719af66272 in print_events util/parse-events.c:2542
#4 0x55719ad1ecaa in cmd_list /home/changbin/work/linux/tools/perf/builtin-list.c:58
#5 0x55719aec745d in run_builtin /home/changbin/work/linux/tools/perf/perf.c:302
#6 0x55719aec7d1a in handle_internal_command /home/changbin/work/linux/tools/perf/perf.c:354
#7 0x55719aec8184 in run_argv /home/changbin/work/linux/tools/perf/perf.c:398
#8 0x55719aeca41a in main /home/changbin/work/linux/tools/perf/perf.c:520
#9 0x7ff1a07ae09a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Changbin Du [Sat, 16 Mar 2019 08:05:45 +0000 (16:05 +0800)]
perf config: Fix a memory leak in collect_config()
Detected with gcc's ASan:
Direct leak of 66 byte(s) in 5 object(s) allocated from:
#0 0x7ff3b1f32070 in __interceptor_strdup (/usr/lib/x86_64-linux-gnu/libasan.so.5+0x3b070)
#1 0x560c8761034d in collect_config util/config.c:597
#2 0x560c8760d9cb in get_value util/config.c:169
#3 0x560c8760dfd7 in perf_parse_file util/config.c:285
#4 0x560c8760e0d2 in perf_config_from_file util/config.c:476
#5 0x560c876108fd in perf_config_set__init util/config.c:661
#6 0x560c87610c72 in perf_config_set__new util/config.c:709
#7 0x560c87610d2f in perf_config__init util/config.c:718
#8 0x560c87610e5d in perf_config util/config.c:730
#9 0x560c875ddea0 in main /home/changbin/work/linux/tools/perf/perf.c:442
#10 0x7ff3afb8609a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2409a)
Changbin Du [Sat, 16 Mar 2019 08:05:43 +0000 (16:05 +0800)]
perf tools: Fix errors under optimization level '-Og'
Optimization level '-Og' offers a reasonable level of optimization while
maintaining fast compilation and a good debugging experience. This patch
tries to make it work.
$ make DEBUG=1 EXTRA_CFLAGS='-Og'
bench/epoll-ctl.c: In function ‘do_threads’:
bench/epoll-ctl.c:274:9: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
return ret;
^~~
...
Changbin Du [Sat, 16 Mar 2019 08:05:41 +0000 (16:05 +0800)]
perf tools: Add doc about how to build perf with Asan and UBSan
AddressSanitizer (or ASan) and UndefinedBehaviorSanitizer (or UBSan) are
very useful tools to detect program bugs:
- AddressSanitizer (or ASan) is a GCC feature that detects memory
corruption bugs such as buffer overflows and memory leaks.
- UndefinedBehaviorSanitizer (or UBSan) is a fast undefined behavior
detector supported by GCC. UBSan detects undefined behaviors of programs
at runtime.
This patch adds a document about how to use them on perf. Later patches will fix
some of the issues disclosed by them.
Andi Kleen [Thu, 14 Mar 2019 22:50:02 +0000 (15:50 -0700)]
perf stat: Improve scaling
The multiplexing scaling in perf stat mysteriously adds 0.5 to the
value. This dates back to the original perf tool. Other scaling code
doesn't use that strange convention. Remove the extra 0.5.
Before:
$ perf stat -e 'cycles,cycles,cycles,cycles,cycles,cycles' grep -rq foo
Andi Kleen [Thu, 14 Mar 2019 22:50:01 +0000 (15:50 -0700)]
perf stat: Fix --no-scale
The -c option to enable multiplex scaling has been useless for quite
some time because scaling is default.
It's only useful as --no-scale to disable scaling. But the non scaling
code path has bitrotted and doesn't print anything because perf output
code relies on value run/ena information.
Also even when we don't want to scale a value it's still useful to show
its multiplex percentage.
This patch:
- Fixes help and documentation to show --no-scale instead of -c
- Removes -c, only keeps the long option because -c doesn't support negatives.
- Enables running/enabled even with --no-scale
- And fixes some other problems in the no-scale output.
Do not use 'time' as the name of a variable, as this breaks the build on
older glibcs:
cc1: warnings being treated as errors
builtin-script.c: In function 'perf_sample__fprintf_start':
builtin-script.c:691: warning: declaration of 'time' shadows a global declaration
/usr/include/time.h:187: warning: shadowed declaration is here
Andi Kleen [Thu, 14 Mar 2019 22:49:56 +0000 (15:49 -0700)]
perf record: Clarify help for --switch-output
The help description for --switch-output looks like there are multiple
comma separated fields. But it's actually a choice of different options.
Make it clear and less confusing.
Before:
% perf record -h
...
--switch-output[=<signal,size,time>]
Switch output when receive SIGUSR2 or cross size,time threshold
After:
% perf record -h
...
--switch-output[=<signal or size[BKMG] or time[smhd]>]
Switch output when receiving SIGUSR2 (signal) or cross a size or time threshold
Himanshu Madhani [Fri, 15 Mar 2019 22:04:19 +0000 (15:04 -0700)]
scsi: qla2xxx: Fix NULL pointer crash due to stale CPUID
This patch fixes crash due to NULL pointer derefrence because CPU pointer
is not set and used by driver. Instead, driver is passes CPU as tag via
ha->isp_ops->{lun_reset|target_reset}
Commit 7f147f9bfd44 ("scsi: qla2xxx: Fix N2N target discovery with Local
loop") fixed N2N target discovery for local loop. However, same code is
used for FC-AL discovery as well. Added check to make sure we are bypassing
area and domain check only in N2N topology for target discovery.
Linus Torvalds [Tue, 19 Mar 2019 18:28:15 +0000 (11:28 -0700)]
Merge tag 'tag-chrome-platform-fixes-for-v5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux
Pull chrome platform fixes from Benson Leung:
"Two fixes:
- Fix locking and close a potential race condition in the new
wilco_ec driver.
- Fix a warning in cros_ec_debugfs on systems that do not support
console logging, such as the Asus C201"
* tag 'tag-chrome-platform-fixes-for-v5.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
platform/chrome: cros_ec_debugfs: cancel/schedule logging work only if supported
platform/chrome: Fix locking pattern in wilco_ec_mailbox()
Bart Van Assche [Fri, 15 Mar 2019 23:27:58 +0000 (16:27 -0700)]
scsi: core: Avoid that a kernel warning appears during system resume
Since scsi_device_quiesce() skips SCSI devices that have another state than
RUNNING, OFFLINE or TRANSPORT_OFFLINE, scsi_device_resume() should not
complain about SCSI devices that have been skipped. Hence this patch. This
patch avoids that the following warning appears during resume:
Bart Van Assche [Mon, 18 Mar 2019 16:29:26 +0000 (09:29 -0700)]
scsi: core: Also call destroy_rcu_head() for passthrough requests
cmd->rcu is initialized by scsi_initialize_rq(). For passthrough
requests, blk_get_request() calls scsi_initialize_rq(). For filesystem
requests, scsi_init_command() calls scsi_initialize_rq(). Make sure
that destroy_rcu_head() is called for passthrough requests.
Suzuki K Poulose [Tue, 12 Mar 2019 09:52:51 +0000 (09:52 +0000)]
KVM: arm/arm64: Enforce PTE mappings at stage2 when needed
commit 6794ad5443a2118 ("KVM: arm/arm64: Fix unintended stage 2 PMD mappings")
made the checks to skip huge mappings, stricter. However it introduced
a bug where we still use huge mappings, ignoring the flag to
use PTE mappings, by not reseting the vma_pagesize to PAGE_SIZE.
Also, the checks do not cover the PUD huge pages, that was
under review during the same period. This patch fixes both
the issues.
Guenter Roeck [Tue, 19 Mar 2019 16:32:36 +0000 (09:32 -0700)]
platform/chrome: cros_ec_debugfs: cancel/schedule logging work only if supported
The following traceback was reported on ASUS C201, which does not support
console logging.
------------[ cut here ]------------
WARNING: CPU: 2 PID: 361 at kernel/workqueue.c:3030 __flush_work+0x38/0x154
Modules linked in: snd_soc_hdmi_codec cros_ec_debugfs cros_ec_sysfs uvcvideo dw_hdmi_cec dw_hdmi_i2s_audio videobuf2_vmalloc cfg80211 gpio_charger rk_crypto rfkill videobuf2_memops videobuf2_v4l2 des_generic videobuf2_common ofpart m25p80 spi_nor tpm_i2c_infineon sbs_battery mtd tpm joydev cros_ec_dev coreboot_table evdev mousedev ip_tables x_tables [last unloaded: brcmutil]
CPU: 2 PID: 361 Comm: systemd-sleep Not tainted 5.1.0-rc1-1-ARCH+ #1
Hardware name: Rockchip (Device Tree)
[<c020e4b0>] (unwind_backtrace) from [<c020ac18>] (show_stack+0x10/0x14)
[<c020ac18>] (show_stack) from [<c07a3e04>] (dump_stack+0x7c/0x9c)
[<c07a3e04>] (dump_stack) from [<c0222748>] (__warn+0xd0/0xec)
[<c0222748>] (__warn) from [<c022279c>] (warn_slowpath_null+0x38/0x44)
[<c022279c>] (warn_slowpath_null) from [<c02365d0>] (__flush_work+0x38/0x154)
[<c02365d0>] (__flush_work) from [<c023786c>] (__cancel_work_timer+0x114/0x1a4)
[<c023786c>] (__cancel_work_timer) from [<bf33233c>] (cros_ec_debugfs_suspend+0x14/0x1c [cros_ec_debugfs])
[<bf33233c>] (cros_ec_debugfs_suspend [cros_ec_debugfs]) from [<c056a888>] (dpm_run_callback+0x64/0xcc)
[<c056a888>] (dpm_run_callback) from [<c056ad2c>] (__device_suspend+0x174/0x3a8)
[<c056ad2c>] (__device_suspend) from [<c056b9e0>] (dpm_suspend+0x174/0x1e0)
[<c056b9e0>] (dpm_suspend) from [<c026b3e0>] (suspend_devices_and_enter+0x6c/0x50c)
[<c026b3e0>] (suspend_devices_and_enter) from [<c026ba8c>] (pm_suspend+0x20c/0x274)
[<c026ba8c>] (pm_suspend) from [<c026a628>] (state_store+0x54/0x88)
[<c026a628>] (state_store) from [<c03cd2d0>] (kernfs_fop_write+0x114/0x180)
[<c03cd2d0>] (kernfs_fop_write) from [<c035d48c>] (__vfs_write+0x1c/0x154)
[<c035d48c>] (__vfs_write) from [<c035f9e8>] (vfs_write+0xb8/0x198)
[<c035f9e8>] (vfs_write) from [<c035fbc0>] (ksys_write+0x3c/0x74)
[<c035fbc0>] (ksys_write) from [<c0201000>] (ret_fast_syscall+0x0/0x4c)
Exception stack(0xe9365fa8 to 0xe9365ff0)
5fa0: 00000004beef8b2800000004beef8b280000000400000000
5fc0: 00000004beef8b280231917000000004beef8b2800000004b6f3d900beef8b74
5fe0: 0000006cbeef8a98b6c0adacb6c66534
---[ end trace f4ee5df14e8ea0ec ]---
If console logging is not supported, the work structure is never
initialized, resulting in the traceback. Calling cancel/schedule functions
conditionally fixes the problem.
While at it, also fix error handling in the probe function.
The fix is to obviously take the srcu lock, just like we do on the
read side of things since bf308242ab98. One wonders why this wasn't
fixed at the same time, but hey...
Fixes: bf308242ab98 ("KVM: arm/arm64: VGIC/ITS: protect kvm_read_guest() calls with SRCU lock") Signed-off-by: Marc Zyngier <[email protected]>
Marc Zyngier [Wed, 13 Mar 2019 18:07:50 +0000 (18:07 +0000)]
arm64: KVM: Always set ICH_HCR_EL2.EN if GICv4 is enabled
The normal interrupt flow is not to enable the vgic when no virtual
interrupt is to be injected (i.e. the LRs are empty). But when a guest
is likely to use GICv4 for LPIs, we absolutely need to switch it on
at all times. Otherwise, VLPIs only get delivered when there is something
in the LRs, which doesn't happen very often.
Marc Zyngier [Mon, 4 Mar 2019 17:37:44 +0000 (17:37 +0000)]
KVM: arm64: Reset the PMU in preemptible context
We've become very cautious to now always reset the vcpu when nothing
is loaded on the physical CPU. To do so, we now disable preemption
and do a kvm_arch_vcpu_put() to make sure we have all the state
in memory (and that it won't be loaded behind out back).
This now causes issues with resetting the PMU, which calls into perf.
Perf itself uses mutexes, which clashes with the lack of preemption.
It is worth realizing that the PMU is fully emulated, and that
no PMU state is ever loaded on the physical CPU. This means we can
perfectly reset the PMU outside of the non-preemptible section.
Fixes: e761a927bc9a ("KVM: arm/arm64: Reset the VCPU without preemption and vcpu state loaded") Reported-by: Julien Grall <[email protected]> Tested-by: Julien Grall <[email protected]> Signed-off-by: Marc Zyngier <[email protected]>
Linus Torvalds [Tue, 19 Mar 2019 17:50:15 +0000 (10:50 -0700)]
Merge tag 'mips_fixes_5.1_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
Pull MIPS fixes from Paul Burton:
"A small batch of MIPS fixes for 5.1:
- An interrupt masking fix for Loongson-based Lemote 2F systems
(fixing a regression from v3.19)
- A relocation fix for configurations in which the devicetree is
stored in an ELF section (fixing a regression from v4.7)
- Fix jump labels for MIPSr6 kernels where they previously could
inadvertently place a control transfer instruction in a forbidden
slot & take unexpected exceptions (fixing MIPSr6 support added in
v4.0)
- Extend an existing USB power workaround for the Netgear WNDR3400 to
v2 boards in addition to the v3 ones that already used it
- Remove the custom MIPS32 definition of __kernel_fsid_t to make it
consistent with MIPS64 & every other architecture, in particular
resolving issues for code which tries to print the val field whose
type previously differed (though had identical memory layout)"
* tag 'mips_fixes_5.1_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: Remove custom MIPS32 __kernel_fsid_t type
mips: bcm47xx: Enable USB power on Netgear WNDR3400v2
MIPS: Fix kernel crash for R6 in jump label branch function
MIPS: Ensure ELF appended dtb is relocated
mips: loongson64: lemote-2f: Add IRQF_NO_SUSPEND to "cascade" irqaction.
David Arcari [Tue, 12 Feb 2019 14:34:39 +0000 (09:34 -0500)]
tools/power turbostat: return the exit status of a command
turbostat failed to return a non-zero exit status even though the
supplied command (turbostat <command>) failed. Currently when turbostat
forks a command it returns zero instead of the actual exit status of the
command. Modify the code to return the exit status.
YueHaibing [Tue, 19 Mar 2019 15:20:42 +0000 (23:20 +0800)]
drivers: base: swnode: Make two functions static
Fix sparse warning:
drivers/base/swnode.c:475:22: warning: symbol 'software_node_get_parent' was not declared. Should it be static?
drivers/base/swnode.c:484:22: warning: symbol 'software_node_get_next_child' was not declared. Should it be static?
Dongli Zhang [Tue, 19 Mar 2019 15:05:18 +0000 (23:05 +0800)]
blk-mq: remove unused 'nr_expired' from blk_mq_hw_ctx
There is no usage of 'nr_expired'.
The 'nr_expired' was introduced by commit 1d9bd5161ba3 ("blk-mq: replace
timeout synchronization with a RCU and generation based scheme"). Its usage
was removed since commit 12f5b9314545 ("blk-mq: Remove generation
seqeunce").
projects / linux.git / log