Michael Jeanson [Mon, 31 Aug 2020 15:41:38 +0000 (11:41 -0400)]
fix: writeback: Drop I_DIRTY_TIME_EXPIRE (v5.9)
See upstream commit:
commit
5fcd57505c002efc5823a7355e21f48dd02d5a51
Author: Jan Kara <jack@suse.cz>
Date: Fri May 29 16:24:43 2020 +0200
writeback: Drop I_DIRTY_TIME_EXPIRE
The only use of I_DIRTY_TIME_EXPIRE is to detect in
__writeback_single_inode() that inode got there because flush worker
decided it's time to writeback the dirty inode time stamps (either
because we are syncing or because of age). However we can detect this
directly in __writeback_single_inode() and there's no need for the
strange propagation with I_DIRTY_TIME_EXPIRE flag.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I92e37c2ff3ec36d431e8f9de5c8e37c5a2da55ea
Michael Jeanson [Tue, 25 Aug 2020 14:56:29 +0000 (10:56 -0400)]
fix: removal of [smp_]read_barrier_depends (v5.9)
See upstream commits:
commit
76ebbe78f7390aee075a7f3768af197ded1bdfbb
Author: Will Deacon <will@kernel.org>
Date: Tue Oct 24 11:22:47 2017 +0100
locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()
In preparation for the removal of lockless_dereference(), which is the
same as READ_ONCE() on all architectures other than Alpha, add an
implicit smp_read_barrier_depends() to READ_ONCE() so that it can be
used to head dependency chains on all architectures.
commit
76ebbe78f7390aee075a7f3768af197ded1bdfbb
Author: Will Deacon <will.deacon@arm.com>
Date: Tue Oct 24 11:22:47 2017 +0100
locking/barriers: Add implicit smp_read_barrier_depends() to READ_ONCE()
In preparation for the removal of lockless_dereference(), which is the
same as READ_ONCE() on all architectures other than Alpha, add an
implicit smp_read_barrier_depends() to READ_ONCE() so that it can be
used to head dependency chains on all architectures.
Change-Id: Ife8880bd9378dca2972da8838f40fc35ccdfaaac
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Mon, 24 Aug 2020 19:37:50 +0000 (15:37 -0400)]
fix: ext4: indicate via a block bitmap read is prefetched… (v5.9)
See upstream commit:
commit
ab74c7b23f3770935016e3eb3ecdf1e42b73efaa
Author: Theodore Ts'o <tytso@mit.edu>
Date: Wed Jul 15 11:48:55 2020 -0400
ext4: indicate via a block bitmap read is prefetched via a tracepoint
Modify the ext4_read_block_bitmap_load tracepoint so that it tells us
whether a block bitmap is being prefetched.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I0e5e2c5b8004223d0928235c092449ee16a940e1
Michael Jeanson [Mon, 24 Aug 2020 19:26:04 +0000 (15:26 -0400)]
fix: ext4: limit the length of per-inode prealloc list (v5.9)
See upstream commit:
commit
27bc446e2def38db3244a6eb4bb1d6312936610a
Author: brookxu <brookxu.cn@gmail.com>
Date: Mon Aug 17 15:36:15 2020 +0800
ext4: limit the length of per-inode prealloc list
In the scenario of writing sparse files, the per-inode prealloc list may
be very long, resulting in high overhead for ext4_mb_use_preallocated().
To circumvent this problem, we limit the maximum length of per-inode
prealloc list to 512 and allow users to modify it.
After patching, we observed that the sys ratio of cpu has dropped, and
the system throughput has increased significantly. We created a process
to write the sparse file, and the running time of the process on the
fixed kernel was significantly reduced, as follows:
Running time on unfixed kernel:
[root@TENCENT64 ~]# time taskset 0x01 ./sparse /data1/sparce.dat
real 0m2.051s
user 0m0.008s
sys 0m2.026s
Running time on fixed kernel:
[root@TENCENT64 ~]# time taskset 0x01 ./sparse /data1/sparce.dat
real 0m0.471s
user 0m0.004s
sys 0m0.395s
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I5169cb24853d4da32e2862a6626f1f058689b053
Michael Jeanson [Mon, 10 Aug 2020 15:36:03 +0000 (11:36 -0400)]
fix: KVM: x86/mmu: Make kvm_mmu_page definition and accessor internal-only (v5.9)
commit
985ab2780164698ec6e7d73fad523d50449261dd
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date: Mon Jun 22 13:20:32 2020 -0700
KVM: x86/mmu: Make kvm_mmu_page definition and accessor internal-only
Make 'struct kvm_mmu_page' MMU-only, nothing outside of the MMU should
be poking into the gory details of shadow pages.
Change-Id: Ia5c1b9c49c2b00dad1d5b17c50c3dc730dafda20
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Mon, 10 Aug 2020 15:22:05 +0000 (11:22 -0400)]
fix: Move mmutrace.h into the mmu/ sub-directory (v5.9)
commit
33e3042dac6bcc33b80835f7d7b502b1d74c457c
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date: Mon Jun 22 13:20:29 2020 -0700
KVM: x86/mmu: Move mmu_audit.c and mmutrace.h into the mmu/ sub-directory
Move mmu_audit.c and mmutrace.h under mmu/ where they belong.
Change-Id: I582525ccca34e1e3bd62870364108a7d3e9df2e4
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Beniamin Sandu [Thu, 13 Aug 2020 13:24:39 +0000 (16:24 +0300)]
Kconfig: fix dependency issue when building in-tree without CONFIG_FTRACE
When building in-tree, one could disable CONFIG_FTRACE from kernel
config which will leave CONFIG_TRACEPOINTS selected by LTTNG modules,
but generate a lot of linker errors like below because it leaves out
other stuff, e.g.:
trace.c:(.text+0xd86b): undefined reference to `trace_event_buffer_reserve'
ld: trace.c:(.text+0xd8de): undefined reference to `trace_event_buffer_commit'
ld: trace.c:(.text+0xd926): undefined reference to `event_triggers_call'
ld: trace.c:(.text+0xd942): undefined reference to `trace_event_ignore_this_pid'
ld: net/mac80211/trace.o: in function `trace_event_raw_event_drv_tdls_cancel_channel_switch':
It appears to be caused by the fact that TRACE_EVENT macros in the Linux
kernel depend on the Ftrace ring buffer as soon as CONFIG_TRACEPOINTS is
enabled.
Steps to reproduce:
- Get a clone of an upstream stable kernel and use scripts/built-in.sh on it
- Configure a standard x86-64 build, enable built-in LTTNG but disable
CONFIG_FTRACE from Kernel Hacking-->Tracers using menuconfig
- Build will fail at linking stage
Signed-off-by: Beniamin Sandu <beniaminsandu@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Tue, 4 Aug 2020 13:51:09 +0000 (09:51 -0400)]
Version 2.11.5
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Wed, 8 Jul 2020 18:45:22 +0000 (14:45 -0400)]
fix: no __lttng_vmalloc_node_range() prior to v2.6.38
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I9747c89f7b57448f4f1a5c1573ba2e81afe09a08
Mathieu Desnoyers [Mon, 13 Jul 2020 18:59:33 +0000 (14:59 -0400)]
Fix: Lock metadata cache on session destroy
commit
92143b2c5656 ("Fix: metadata stream leak, missing list removal and locking")
missed taking a lock protecting the metadata stream list iteration on
session destroy. This opens a race window between iteration and item
removal/free which triggers kernel OOPS.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Fri, 10 Jul 2020 15:15:40 +0000 (11:15 -0400)]
Fix: metadata stream leak, missing list removal and locking
The metadata stream is part of a list of metadata streams in the
metadata cache. Its addition to the list should be protected by
the metadata cache lock. It needs to be paired with protection
of list iteration with the same lock.
Removal from the list is entirely missing, and should be added
to lttng_metadata_ring_buffer_release (with proper locking).
This missing list removal was probably not causing issues because the
metadata stream structure was leaked: a kfree() is missing from
lttng_metadata_ring_buffer_release as well.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Fri, 10 Jul 2020 14:51:26 +0000 (10:51 -0400)]
Fix: coherent state not changed atomically with metadata written
commit
122c63cb4310 ("Fix: Implement RING_BUFFER_GET_NEXT_SUBBUF_METADATA_CHECK")
introduces a new ioctl which returns a flag indicating whether the
metadata is in consistent state at the end of the sub-buffer.
That commit is meant to address metadata consistency issues observable
in live sessions.
However, the "consistent" state is false as soon as a producer is
active (between an outermost metadata_begin/end pair). Unfortunately,
if the last "RING_BUFFER_GET_NEXT_SUBBUF_METADATA_CHECK" operation is
done between the last metadata printf and "end" of the transaction, the
last consistency state will be false, and the consumer daemon will never
send metadata to the relay daemon. This in turn causes a live viewer to
wait for metadata endlessly.
This issue can be reproduced by running lttng-tools:
tests/regression/tools/live/test_kernel
as root in a loop.
We observe two things:
1) the poll operation blocks when there is no more metadata to send,
which means there is no mean to unblock when the consistency state
changes back to "true" without producing additional metadata,
2) Even if (1) was fixed, the expectation from an ABI perspective is
that the "coherent" state is only populated when
RING_BUFFER_GET_NEXT_SUBBUF_METADATA_CHECK succeeds. Therefore,
there is no way to let user-space know about conherency transition
unless additional metadata is generated.
Fixing this requires to hold the metadata cache lock across the entire
production of a coherent metadata transaction. This simpler scheme is
possible because the metadata is generated in a reallocated memory area
and not directly into a ring buffer anymore. This was not the case in
earlier lttng-modules versions, when the metadata was generated directly
into a ring buffer, which explains why this simpler scheme was not
implemented.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 7 Jul 2020 18:18:37 +0000 (14:18 -0400)]
fix: include module.h for EXPORT_SYMBOL_GPL
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ic337e1eb375791ace08560555dd02b37cbefcf25
Michael Jeanson [Tue, 7 Jul 2020 17:50:15 +0000 (13:50 -0400)]
fix: __lttng_vmalloc_node_range const caller introduced in v3.6
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ib13cf03b5ab11830a8732318a12713720cf1b3e3
Michael Jeanson [Tue, 7 Jul 2020 18:07:01 +0000 (14:07 -0400)]
fix: version range for overflow_callback
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I1b8f1d59552a1723d3f4ed74780a2b57d13d0e52
Michael Jeanson [Tue, 7 Jul 2020 17:00:10 +0000 (13:00 -0400)]
fix: global_dirty_limit was introduced in v3.1
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Id97dbb2d0181a45c45cfed36c4be8753cabac283
Michael Jeanson [Tue, 7 Jul 2020 16:21:54 +0000 (12:21 -0400)]
fix: wrapper_uprobe_unregister is a void function
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ib4438da02aac3defd1245324d1b48f400f806d58
Michael Jeanson [Tue, 7 Jul 2020 15:58:03 +0000 (11:58 -0400)]
fix: prior to v4.0, __vmalloc_node_range had no vm_flags param
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ib476e32d109298d9ca3e6b6ab7ac8f63c50fb09f
Michael Jeanson [Tue, 7 Jul 2020 15:15:39 +0000 (11:15 -0400)]
fix: vmalloc on v5.8 without KALLSYMS
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ic945dad92e78a5bc2895a969a10c527e1349decf
Michael Jeanson [Thu, 14 May 2020 17:47:35 +0000 (13:47 -0400)]
Detect missing symbols used with kallsyms_lookup at compile time
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I19a9a31c386196899517899d861fe63611272139
Michael Jeanson [Thu, 2 Jul 2020 16:06:42 +0000 (12:06 -0400)]
Use exported symbol bdevname() instead of disk_name()
bdevname() is a simple wrapper over disk_name() but has the honor to be
exported. Using it removes the need for a kallsym wrapper.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ic2b2233c4db7826175c68edea69751ddcb17a5e6
Michael Jeanson [Fri, 3 Jul 2020 14:46:12 +0000 (10:46 -0400)]
Add git-review config
Add .gitreview for contributors wishing to use gerrit for patch
reviews.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I663e66a433ddb645f580c4b9f885db9c3a08e02f
Michael Jeanson [Thu, 2 Jul 2020 15:21:42 +0000 (11:21 -0400)]
fix: mm: remove vmalloc_sync_(un)mappings() (v5.8)
See upstream commit:
commit
73f693c3a705756032c2863bfb37570276902d7d
Author: Joerg Roedel <jroedel@suse.de>
Date: Mon Jun 1 21:52:36 2020 -0700
mm: remove vmalloc_sync_(un)mappings()
These functions are not needed anymore because the vmalloc and ioremap
mappings are now synchronized when they are created or torn down.
Remove all callers and function definitions.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ifdefa35b25b4906cde407360e608b77e47cc3808
Michael Jeanson [Thu, 18 Jun 2020 14:19:47 +0000 (10:19 -0400)]
fix: backport of block_bio_complete for <= v2.6.38
The stable-2.11 branch still supports kernel before 3.0,
add the proper version checks to a patch that was backported
from master.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I9c5a66d9b68ba132bd9e752af6c069826961869a
Michael Jeanson [Mon, 15 Jun 2020 15:12:24 +0000 (11:12 -0400)]
fix: mm/writeback: discard NR_UNSTABLE_NFS, use NR_WRITEBACK (v5.8)
See upstream commit:
commit
8d92890bd6b8502d6aee4b37430ae6444ade7a8c
Author: NeilBrown <neilb@suse.de>
Date: Mon Jun 1 21:48:21 2020 -0700
mm/writeback: discard NR_UNSTABLE_NFS, use NR_WRITEBACK instead
After an NFS page has been written it is considered "unstable" until a
COMMIT request succeeds. If the COMMIT fails, the page will be
re-written.
These "unstable" pages are currently accounted as "reclaimable", either
in WB_RECLAIMABLE, or in NR_UNSTABLE_NFS which is included in a
'reclaimable' count. This might have made sense when sending the COMMIT
required a separate action by the VFS/MM (e.g. releasepage() used to
send a COMMIT). However now that all writes generated by ->writepages()
will automatically be followed by a COMMIT (since commit
919e3bd9a875
("NFS: Ensure we commit after writeback is complete")) it makes more
sense to treat them as writeback pages.
So this patch removes NR_UNSTABLE_NFS and accounts unstable pages in
NR_WRITEBACK and WB_WRITEBACK.
A particular effect of this change is that when
wb_check_background_flush() calls wb_over_bg_threshold(), the latter
will report 'true' a lot less often as the 'unstable' pages are no
longer considered 'dirty' (as there is nothing that writeback can do
about them anyway).
Currently wb_check_background_flush() will trigger writeback to NFS even
when there are relatively few dirty pages (if there are lots of unstable
pages), this can result in small writes going to the server (10s of
Kilobytes rather than a Megabyte) which hurts throughput. With this
patch, there are fewer writes which are each larger on average.
Where the NR_UNSTABLE_NFS count was included in statistics
virtual-files, the entry is retained, but the value is hard-coded as
zero. static trace points and warning printks which mentioned this
counter no longer report it.
Change-Id: I18080ca62bc6c1cd7d6da4cb27cc1521fbdca5e1
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Mon, 15 Jun 2020 15:06:13 +0000 (11:06 -0400)]
fix: block: remove the error argument to the block_bio_complete (v5.8)
See upstream commit:
commit
d24de76af836260a99ca2ba281a937bd5bc55591
Author: Christoph Hellwig <hch@lst.de>
Date: Wed Jun 3 07:14:43 2020 +0200
block: remove the error argument to the block_bio_complete tracepoint
The status can be trivially derived from the bio itself. That also avoid
callers like NVMe to incorrectly pass a blk_status_t instead of the errno,
and the overhead of translating the blk_status_t to the errno in the I/O
completion fast path when no tracing is enabled.
Fixes: 35fe0d12c8a3 ("nvme: trace bio completion")
Change-Id: I8d1463184d79bfab418a1755bfc6a0200170fff3
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Mon, 15 Jun 2020 14:51:41 +0000 (10:51 -0400)]
fix: pipe_buf_operations rework (v5.8)
See upstream commits:
commit
c928f642c29a5ffb02e16f2430b42b876dde69de
Author: Christoph Hellwig <hch@lst.de>
Date: Wed May 20 17:58:16 2020 +0200
fs: rename pipe_buf ->steal to ->try_steal
And replace the arcane return value convention with a simple bool
where true means success and false means failure.
[AV: braino fix folded in]
commit
b8d9e7f2411b0744df2ec33e80d7698180fef21a
Author: Christoph Hellwig <hch@lst.de>
Date: Wed May 20 17:58:15 2020 +0200
fs: make the pipe_buf_operations ->confirm operation optional
Just return 0 for success if it is not present.
commit
76887c256744740d6121af9bc4aa787712a1f694
Author: Christoph Hellwig <hch@lst.de>
Date: Wed May 20 17:58:14 2020 +0200
fs: make the pipe_buf_operations ->steal operation optional
Just return 1 for failure if it is not present.
Change-Id: Ic185632202470db1eb5b012e95e793ff2cb26be7
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Wed, 3 Jun 2020 02:56:54 +0000 (22:56 -0400)]
Version 2.11.4
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Fri, 24 Apr 2020 19:49:42 +0000 (15:49 -0400)]
Fix: Implement RING_BUFFER_GET_NEXT_SUBBUF_METADATA_CHECK
Get next metadata subbuffer, returning a flag indicating whether the
metadata is guaranteed to be in a consistent state at the end of this
sub-buffer (can be parsed).
This can be used by the consumer to know whether the metadata can be
parsed at the end of this sub-buffer, which is useful to distinguish
between errors and incomplete metadata in live tracing.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Fri, 15 May 2020 19:12:53 +0000 (15:12 -0400)]
fix: vmalloc_sync_mappings was backported to v5.5.12
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ie554d9c956afc2a8e114fe41e4b3c225d8af40a1
Stefan Bader [Mon, 18 May 2020 14:03:16 +0000 (16:03 +0200)]
Update: Additional kernel ranges for vmalloc_sync_mappings
Some Ubuntu kernels cannot be directly mapped to an upstream stable
version. Define distro specific ranges for those (4.15, 5.0, 5.3).
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Ovidiu Panait [Thu, 14 May 2020 11:27:17 +0000 (14:27 +0300)]
Update: Use vmalloc_sync_mappings for stable kernels
Starting from v5.4.28/v5.2.37/v4.19.113/v4.14.175/v4.9.218/v4.4.218, stable
kernel branches backported v5.6 upstream commit [1], causing the following
warnings:
...
[ 483.242037] LTTng: vmalloc_sync_all symbol lookup failed.
[ 483.257056] Page fault handler and NMI tracing might trigger faults.
...
Extend check for vmalloc_sync_mappings for stable kernels as well.
[1] https://github.com/torvalds/linux/commit/
763802b53a427ed3cbd419dbba255c414fdd9e7c
[ Edit: minor coding style fix by Mathieu Desnoyers. ]
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Ovidiu Panait [Thu, 14 May 2020 10:05:24 +0000 (13:05 +0300)]
Fix: Use vmalloc_sync_mappings on kernel 5.6 as well
Upstream commit [1], that got rid of vmalloc_sync_all and introduced
vmalloc_sync_mappings, is a v5.6 commit:
$ git tag --contains
763802b53a427ed3cbd419dbba255c414fdd9e7c
v5.6
v5.6-rc7
v5.7-rc1
v5.7-rc2
v5.7-rc3
Extend the LINUX_VERSION_CODE check to v5.6 to fix the following warnings:
...
[ 483.242037] LTTng: vmalloc_sync_all symbol lookup failed.
[ 483.257056] Page fault handler and NMI tracing might trigger faults.
...
[1] https://github.com/torvalds/linux/commit/
763802b53a427ed3cbd419dbba255c414fdd9e7c
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Wed, 6 May 2020 15:11:29 +0000 (11:11 -0400)]
fix: add missing guid_t type to wrapper
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I0de39c24a7925b580fabbdaa12dbe05c43cfcd98
Michael Jeanson [Wed, 6 May 2020 15:03:32 +0000 (11:03 -0400)]
Fix: missing wrapper rename to wrapper_vmalloc_sync_mappings
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Idf7082a980c5a604bfef5c69906678b5083a9bbf
Mathieu Desnoyers [Tue, 5 May 2020 17:38:31 +0000 (13:38 -0400)]
Update for kernel 5.7: use vmalloc_sync_mappings on kernels >= 5.7
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Mon, 4 May 2020 19:00:53 +0000 (15:00 -0400)]
Unbreak LTTng for kernel 5.7
Linux commit
0bd476e6c67190b5eb7b6e105c8db8ff61103281 ("kallsyms:
unexport kallsyms_lookup_name() and kallsyms_on_each_symbol()") breaks
LTTng-modules by removing symbols used by the LTTng-modules out-of-tree
tracer.
I pointed this out when the change was originally considered before the
5.7 merge window. This generated some discussion but it did not lead to
any concrete proposal to fix the issue. [1]
The commit has been merged in the 5.7 merge window. At that point, as
maintainer of LTTng, I immediately raised a flag about this issue,
proposing an alternative approach to solve this: expose the few symbols
needed by LTTng to GPL modules. This was NACKed on the ground that the
Linux kernel cannot export GPL symbols when there are no in-tree
users. [2]
Steven Rostedt has shown interest in merging LTTng-modules upstream.
LTTng-modules being LGPL, this is very much doable. I have prepared a
tree of LTTng-modules "for upstreaming" and sent it to him privately so
he can review it. Even if in an ideal scenario LTTng-modules is merged
for the following merge window, it leaves LTTng-modules broken on the
5.7 kernel.
In order to ensure that the LTTng-modules kernel tracer continues working
for my end users on kernels 5.7 onwards, as a very last resort, this is
with great reluctance that I created this fix for LTTng modules. It
basically uses kprobes to lookup the kallsyms_lookup_name symbol, and
continues using kallsyms_lookup_name as before.
Link: https://lore.kernel.org/r/20200302192811.n6o5645rsib44vco@localhost
Link: https://lore.kernel.org/r/20200409193543.18115-1-mathieu.desnoyers@efficios.com
Link: https://lwn.net/Articles/817988/
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Will Deacon <will@kernel.org>
CC: akpm@linux-foundation.org
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Masami Hiramatsu <mhiramat@kernel.org>
CC: rostedt@goodmis.org
CC: Alexei Starovoitov <ast@kernel.org>
Mathieu Desnoyers [Mon, 4 May 2020 18:52:13 +0000 (14:52 -0400)]
Move lttng wrappers into own module
Currently, we only pull the wrapper symbols into a single sub-module,
either:
lttng-tracer.o:
- wrapper/random.o
- wrapper/trace-clock.o
- wrapper/page_alloc.o
or
lttng-statedump.o:
- wrapper/irqdesc.o
- wrapper/fdtable.o
Because lttng-tracer depends on lttng-statedump, we cannot just put all
wrappers into lttng-tracer.o, because it would create a circular
dependency. This will be an issue if we introduce common wrappers which
are used in both lttng-tracer.o and in lttng-statedump.o.
Introduce a new lttng-wrapper.o to contain all wrapper symbols for all
lttng modules.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Mon, 13 Apr 2020 16:16:43 +0000 (12:16 -0400)]
Introduce lttng_guid_gen wrapper for kernels >= 5.7.0
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Thu, 8 Nov 2018 20:35:14 +0000 (15:35 -0500)]
Drop uuid.h wrapper
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Mon, 13 Apr 2020 15:44:23 +0000 (11:44 -0400)]
instrumentation: update x86 kvm instrumentation for kernel >= 5.7.0
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Mon, 13 Apr 2020 15:38:48 +0000 (11:38 -0400)]
instrumentation: update mm_vmscan for kernel >= 5.7.0
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Wed, 8 Apr 2020 13:40:39 +0000 (09:40 -0400)]
Version 2.11.3
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Thu, 2 Apr 2020 18:08:36 +0000 (14:08 -0400)]
fix: uaccess wrapper for CentOS >= 4.18.0-147
Fixes: #1253
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I2a79c1c0e897a6148e60e5599949cd2778d09d50
Michael Jeanson [Thu, 2 Apr 2020 18:08:09 +0000 (14:08 -0400)]
fix: ext4 instrumentation for CentOS >= 4.18.0-147
Fixes: #1253
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I1fd54af16fbb02cd4b3ab7fc7d9232708088f1fd
Michael Jeanson [Thu, 2 Apr 2020 18:07:47 +0000 (14:07 -0400)]
fix: signal instrumentation for CentOS >= 4.18.0-147
Fixes: #1253
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I280013402df6f14222fbb912cdf64d80af3ab265
Michael Jeanson [Thu, 2 Apr 2020 18:07:21 +0000 (14:07 -0400)]
fix: kvm instrumentation for CentOS >= 4.18.0-147
Fixes: #1253
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ide20ebf51bec503866ffc96dda3e0b09ebeb14d6
Michael Jeanson [Thu, 2 Apr 2020 18:06:17 +0000 (14:06 -0400)]
fix: rcu instrumentation for CentOS >= 4.18.0-80
Fixes: #1253
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I1735d2caa7215ce94272aaaa98cbbc8f3a10743d
Michael Jeanson [Mon, 30 Mar 2020 21:43:16 +0000 (17:43 -0400)]
Fix: update kvm instrumentation for Ubuntu 5.3.0-45
This commit introduced in 5.3.0-43 was dropped in 5.3.0-45 and reintroduced
in 5.3.0-46:
commit
795f8a34f279e17c279bba46da10f15c5dd00264
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date: Fri Dec 6 15:57:14 2019 -0800
KVM: x86: Use gpa_t for cr2/gpa to fix TDP support on 32-bit KVM
BugLink: https://bugs.launchpad.net/bugs/1867051
[ Upstream commit
736c291c9f36b07f8889c61764c28edce20e715d ]
Fun times!
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ia5f1a4ba355f592f09e964038b6334ddb3ad5153
Michael Jeanson [Tue, 24 Mar 2020 18:20:48 +0000 (14:20 -0400)]
Fix: update kvm instrumentation for Ubuntu 5.3.0-43
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I1ce5f9ebba997fcc4cfbae6901eed479e2e1a79e
Michael Jeanson [Mon, 23 Mar 2020 18:48:24 +0000 (14:48 -0400)]
Fix: update kvm instrumentation for Ubuntu 4.15.0-92
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ib367b9a0ce3846f45313906e710a9a6d644e3955
Mathieu Desnoyers [Mon, 2 Mar 2020 16:26:39 +0000 (11:26 -0500)]
Remove lttng-ftrace integration
The lttng-ftrace integration (LTTNG_KERNEL_FUNCTION instrumentation
type) was unused for a while now. The "function" probing is actually
done with kprobes and kretprobes (LTTNG_KERNEL_KPROBE and
LTTNG_KERNEL_KRETPROBE).
Remove it so a use of kallsyms_lookup_name() can be removed as well.
Note that in the future we could add back this support by using
register_ftrace_function() which is exported to kernel modules, but
considering that we have not been using this code for a while,
just remove the implementation for now.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Mon, 2 Mar 2020 16:03:19 +0000 (11:03 -0500)]
Remove dependency on kallsyms for splice_to_pipe (kernel 4.2+)
Upstream commit
2b514574f7e88 "net: af_unix: implement splice for stream
af_unix sockets" exported the "splice_to_pipe" symbol, so use it to
remove a dependency on kallsyms_lookup_name().
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Mon, 2 Mar 2020 15:52:54 +0000 (10:52 -0500)]
Remove dependency on kallsyms for irq_to_desc (kernel 3.4+)
Upstream commit
3911ff30f5d "genirq: export handle_edge_irq() and
irq_to_desc()" exported the irq_to_desc symbol, so use it to remove a
dependency on kallsyms_lookup_name().
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Mon, 2 Mar 2020 15:40:26 +0000 (10:40 -0500)]
Remove work-around for signed tracepoint module tainting (kernel 3.15+)
Upstream commit
66cc69e34e86a "Fix: module signature vs tracepoints: add
new TAINT_UNSIGNED_MODULE" fixed an issue where the kernel was
considering unsigned modules as tainting the kernel in the same way as a
force-loaded modules, which was causing the tracepoints within those
modules to be hidden.
This fix was merged in kernel 3.15, so there is no use in applying this
work-around starting from that kernel.
This removes a dependency on kallsyms_lookup_name() for the symbol
"tracepoint_module_notify".
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Tue, 25 Feb 2020 20:15:17 +0000 (15:15 -0500)]
Version 2.11.2
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Tue, 25 Feb 2020 15:18:11 +0000 (10:18 -0500)]
Fix: rcu: Fix data-race due to atomic_t copy-by-value (5.5.6, 5.4.22)
The following upstream commit has been backported to stable kernels
5.5.6 and 5.4.22:
commit
6cf539a87a61a4fbc43f625267dbcbcf283872ed
Author: Marco Elver <elver@google.com>
Date: Wed Oct 9 17:57:43 2019 +0200
rcu: Fix data-race due to atomic_t copy-by-value
This fixes a data-race where `atomic_t dynticks` is copied by value. The
copy is performed non-atomically, resulting in a data-race if `dynticks`
is updated concurrently.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 11 Feb 2020 20:35:11 +0000 (15:35 -0500)]
fix: workqueue: add worker function to workqueue_execute_end tracepoint (v5.6)
See upstream commit :
commit
1c5da0ec7f20dfb56030fb93f7f52f48e12deb52
Author: Daniel Jordan <daniel.m.jordan@oracle.com>
Date: Mon Jan 13 17:52:39 2020 -0500
workqueue: add worker function to workqueue_execute_end tracepoint
It's surprising that workqueue_execute_end includes only the work when
its counterpart workqueue_execute_start has both the work and the worker
function.
You can't set a tracing filter or trigger based on the function, and
postprocessing scripts interested in specific functions are harder to
write since they have to remember the work from _start and match it up
with the same field in _end.
Add the function name, taking care to use the copy stashed in the
worker since the work is no longer safe to touch.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 11 Feb 2020 20:13:53 +0000 (15:13 -0500)]
fix: media: v4l2: abstract timeval handling in v4l2_buffer (v5.6)
See upstream commit :
commit
77cdffcb0bfb87fe3645894335cb8cb94917e6ac
Author: Arnd Bergmann <arnd@arndb.de>
Date: Mon Dec 16 15:15:00 2019 +0100
media: v4l2: abstract timeval handling in v4l2_buffer
As a preparation for adding 64-bit time_t support in the uapi,
change the drivers to no longer care about the format of the
timestamp field in struct v4l2_buffer.
The v4l2_timeval_to_ns() function is no longer needed in the
kernel after this, but there is userspace code relying on
it to be part of the uapi header.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 11 Feb 2020 20:08:04 +0000 (15:08 -0500)]
fix: rcu: Remove kfree_rcu() special casing and lazy-callback (v5.6)
See upstream commit :
commit
77a40f97030b27b3fc1640a3ed203870f0817f57
Author: Joel Fernandes (Google) <joel@joelfernandes.org>
Date: Fri Aug 30 12:36:32 2019 -0400
rcu: Remove kfree_rcu() special casing and lazy-callback handling
This commit removes kfree_rcu() special-casing and the lazy-callback
handling from Tree RCU. It moves some of this special casing to Tiny RCU,
the removal of which will be the subject of later commits.
This results in a nice negative delta.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 11 Feb 2020 19:51:01 +0000 (14:51 -0500)]
fix: rcu: Fix data-race due to atomic_t copy-by-value (v5.6)
See upstream commit :
commit
6cf539a87a61a4fbc43f625267dbcbcf283872ed
Author: Marco Elver <elver@google.com>
Date: Wed Oct 9 17:57:43 2019 +0200
rcu: Fix data-race due to atomic_t copy-by-value
This fixes a data-race where `atomic_t dynticks` is copied by value. The
copy is performed non-atomically, resulting in a data-race if `dynticks`
is updated concurrently.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 11 Feb 2020 19:47:23 +0000 (14:47 -0500)]
fix: btrfs: make btrfs_ordered_extent naming consistent (v5.6)
See upstream commit :
commit
bffe633e00fb6b904817137fc17a44b42efcd985
Author: Omar Sandoval <osandov@fb.com>
Date: Mon Dec 2 17:34:19 2019 -0800
btrfs: make btrfs_ordered_extent naming consistent with btrfs_file_extent_item
ordered->start, ordered->len, and ordered->disk_len correspond to
fi->disk_bytenr, fi->num_bytes, and fi->disk_num_bytes, respectively.
It's confusing to translate between the two naming schemes. Since a
btrfs_ordered_extent is basically a pending btrfs_file_extent_item,
let's make the former use the naming from the latter.
Note that I didn't touch the names in tracepoints just in case there are
scripts depending on the current naming.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 11 Feb 2020 19:41:29 +0000 (14:41 -0500)]
fix: KVM: x86: Use gpa_t for cr2/gpa to fix TDP support on 32-bit (v5.6)
See upstream commit :
commit
736c291c9f36b07f8889c61764c28edce20e715d
Author: Sean Christopherson <sean.j.christopherson@intel.com>
Date: Fri Dec 6 15:57:14 2019 -0800
KVM: x86: Use gpa_t for cr2/gpa to fix TDP support on 32-bit KVM
Convert a plethora of parameters and variables in the MMU and page fault
flows from type gva_t to gpa_t to properly handle TDP on 32-bit KVM.
Thanks to PSE and PAE paging, 32-bit kernels can access 64-bit physical
addresses. When TDP is enabled, the fault address is a guest physical
address and thus can be a 64-bit value, even when both KVM and its guest
are using 32-bit virtual addressing, e.g. VMX's VMCS.GUEST_PHYSICAL is a
64-bit field, not a natural width field.
Using a gva_t for the fault address means KVM will incorrectly drop the
upper 32-bits of the GPA. Ditto for gva_to_gpa() when it is used to
translate L2 GPAs to L1 GPAs.
Opportunistically rename variables and parameters to better reflect the
dual address modes, e.g. use "cr2_or_gpa" for fault addresses and plain
"addr" instead of "vaddr" when the address may be either a GVA or an L2
GPA. Similarly, use "gpa" in the nonpaging_page_fault() flows to avoid
a confusing "gpa_t gva" declaration; this also sets the stage for a
future patch to combing nonpaging_page_fault() and tdp_page_fault() with
minimal churn.
Sprinkle in a few comments to document flows where an address is known
to be a GVA and thus can be safely truncated to a 32-bit value. Add
WARNs in kvm_handle_page_fault() and FNAME(gva_to_gpa_nested)() to help
document such cases and detect bugs.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 11 Feb 2020 16:20:41 +0000 (11:20 -0500)]
fix: proc: decouple proc from VFS with "struct proc_ops" (v5.6)
See upstream commit :
commit
d56c0d45f0e27f814e87a1676b6bdccccbc252e9
Author: Alexey Dobriyan <adobriyan@gmail.com>
Date: Mon Feb 3 17:37:14 2020 -0800
proc: decouple proc from VFS with "struct proc_ops"
Currently core /proc code uses "struct file_operations" for custom hooks,
however, VFS doesn't directly call them. Every time VFS expands
file_operations hook set, /proc code bloats for no reason.
Introduce "struct proc_ops" which contains only those hooks which /proc
allows to call into (open, release, read, write, ioctl, mmap, poll). It
doesn't contain module pointer as well.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Mon, 24 Feb 2020 20:11:03 +0000 (15:11 -0500)]
fix: y2038: hide timeval/timespec/itimerval/itimerspec types (v5.6)
See upstream commit:
commit
c766d1472c70d25ad475cf56042af1652e792b23
Author: Arnd Bergmann <arnd@arndb.de>
Date: Thu Feb 20 20:03:57 2020 -0800
y2038: hide timeval/timespec/itimerval/itimerspec types
There are no in-kernel users remaining, but there may still be users that
include linux/time.h instead of sys/time.h from user space, so leave the
types available to user space while hiding them from kernel space.
Only the __kernel_old_* versions of these types remain now.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I986a813ad8b1c753ab1fa07f726b0cc481f049cb
Michael Jeanson [Mon, 24 Feb 2020 19:50:20 +0000 (14:50 -0500)]
fix: use timespec64 on kernels that have it
This fixes v5.6 which has hidden 'struct timespec' from kernel code and
makes 32bit archs y2038 compliant on v3.17 and newer.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I1daedc4a93cbbebb8f5a1d99c4619cb27f6a9e07
Michael Jeanson [Mon, 24 Feb 2020 20:15:36 +0000 (15:15 -0500)]
fix: move lttng_close_on_exec to proper wrapper
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I330c6d63fc9c1af00c9a9471563d322d036b9a9c
Michael Jeanson [Mon, 24 Feb 2020 16:30:22 +0000 (11:30 -0500)]
fix: 'struct timex' removed upstream (v5.6)
The 'timex' struct was remove in v5.6 and replaced by 2 variants, one
that is y2038 compliant and a compat version for 32bit archs.
Add this temporary fix while we update our syscalls tracepoint headers,
the type of this struct has limited importance since it's only used to
record the adress in the trace.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Change-Id: I085b22f282db57985f1c3d341e7c0866cb20e3c9
Mathieu Desnoyers [Thu, 20 Feb 2020 14:58:42 +0000 (09:58 -0500)]
Fix: statedump: check task_active_pid_ns return value for NULL
The lttng-statedump checks the return value of task_active_pid_ns()
before each use within trace_lttng_statedump_process_state(), but misses
the NULL check before dereferencing pid_ns->parent.
This race happens if a task exists in "dead" state while the statedump
iterates on that task.
Reported-by: Li Zhou <li.zhou@windriver.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Francis Deslauriers [Tue, 28 Jan 2020 22:19:20 +0000 (17:19 -0500)]
Fix: lttng-syscalls.c: marking wrong syscall probe as unregistered
When calling `lttng_syscalls_unregister()` we currently mark as
unregistered the wrong syscall probe type.
Concretely, when we unregister "sys_exit" we wrongfully mark that
sys_enter is unregistered and vice versa.
Given than currently entry and exit probes are always enabled together
(except on internal errors), the effect of this bug is not user-visible.
Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I64acf6a941a3d1fa1bf8be424f834ddb7fb92ace
Mathieu Desnoyers [Wed, 29 Jan 2020 15:12:29 +0000 (10:12 -0500)]
Version 2.11.1
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 17 Dec 2019 17:11:10 +0000 (12:11 -0500)]
fix: function prototype in wrapper/mm.h
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Thu, 12 Dec 2019 15:39:38 +0000 (10:39 -0500)]
sunrpc: introduce lttng_get_clid helper
Introduce the lttng_get_clid helper to always check for NULL pointer
when getting the client id. While not always strictly needed depending
on the tracepoint callsite, prefer robustness of instrumentation and
always check for NULL rather than play whack-a-mole.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Thu, 12 Dec 2019 15:29:37 +0000 (10:29 -0500)]
Fix: sunrpc: use signed integer for client id
Within include/linux/sunrpc/clnt.h:struct rpc_cltn, the cl_clid field
is an unsigned integer, which is the type expected by the tracepoint
signature.
However, looking into net/sunrpc/clnt.c:rpc_alloc_clid(), its allocation
considers negative signed integer as errors.
Therefore, in order to properly show "-1" in the trace output (rather
than MAX_INT) when called with a NULL task->tk_client, move to a
signed integer as backing type for the client_id field.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Thu, 12 Dec 2019 15:29:02 +0000 (10:29 -0500)]
Fix: sunrpc: null rpc_clnt dereference in rpc_task_queued tracepoint
Based on upstream Linux commit:
commit
0be283f676a1e7b208db0c992283197ef8b52158
Author: Benjamin Coddington <bcodding@redhat.com>
Date: Tue Jan 23 09:32:35 2018 -0500
SUNRPC: Fix null rpc_clnt dereference in rpc_task_queued tracepoint
Backchannel tasks will not have a reference to the rpc_clnt. Return -1 for
cl_clid in that case.
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Trond Myklebust <trondmy@gmail.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Quanyang Wang [Thu, 5 Dec 2019 07:35:32 +0000 (15:35 +0800)]
Fix: SUNRPC: Fix oops when trace sunrpc_task events in nfs client
See upstream commit :
commit
2ca310fc4160ed0420da65534a21ae77b24326a8
Author: Ditang Chen <chendt.fnst@cn.fujitsu.com>
Date: Fri, 7 Mar 2014 13:27:57 +0800
Subject: SUNRPC: Fix oops when trace sunrpc_task events in nfs client
When tracking sunrpc_task events in nfs client, the clnt pointer may be NULL.
[ 139.269266] BUG: unable to handle kernel NULL pointer dereference at
0000000000000004
[ 139.269915] IP: [<
ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
[ 139.269915] PGD
1d293067 PUD
1d294067 PMD 0
[ 139.269915] Oops: 0000 [#1] SMP
[ 139.269915] Modules linked in: nfsv4 dns_resolver nfs lockd sunrpc fscache sg ppdev e1000
serio_raw pcspkr parport_pc parport i2c_piix4 i2c_core microcode xfs libcrc32c sd_mod sr_mod
cdrom ata_generic crc_t10dif crct10dif_common pata_acpi ahci libahci ata_piix libata dm_mirror
dm_region_hash dm_log dm_mod
[ 139.269915] CPU: 0 PID: 59 Comm: kworker/0:2 Not tainted 3.10.0-84.el7.x86_64 #1
[ 139.269915] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
[ 139.269915] Workqueue: rpciod rpc_async_schedule [sunrpc]
[ 139.269915] task:
ffff88001b598000 ti:
ffff88001b632000 task.ti:
ffff88001b632000
[ 139.269915] RIP: 0010:[<
ffffffffa026f216>] [<
ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
[ 139.269915] RSP: 0018:
ffff88001b633d70 EFLAGS:
00010206
[ 139.269915] RAX:
ffff88001dfc5338 RBX:
ffff88001cc37a00 RCX:
ffff88001dfc5334
[ 139.269915] RDX:
ffff88001dfc5338 RSI:
0000000000000000 RDI:
ffff88001dfc533c
[ 139.269915] RBP:
ffff88001b633db0 R08:
000000000000002c R09:
000000000000000a
[ 139.269915] R10:
0000000000062180 R11:
00000020759fb9dc R12:
ffffffffa0292c20
[ 139.269915] R13:
ffff88001dfc5334 R14:
0000000000000000 R15:
0000000000000000
[ 139.269915] FS:
0000000000000000(0000) GS:
ffff88001fc00000(0000) knlGS:
0000000000000000
[ 139.269915] CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
[ 139.269915] CR2:
0000000000000004 CR3:
000000001d290000 CR4:
00000000000006f0
[ 139.269915] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 139.269915] DR3:
0000000000000000 DR6:
00000000ffff0ff0 DR7:
0000000000000400
[ 139.269915] Stack:
[ 139.269915]
000000001b633d98 0000000000000246 ffff88001df1dc00 ffff88001cc37a00
[ 139.269915]
ffff88001bc35e60 0000000000000000 ffff88001ffa0a48 ffff88001bc35ee0
[ 139.269915]
ffff88001b633e08 ffffffffa02704b5 0000000000010000 ffff88001cc37a70
[ 139.269915] Call Trace:
[ 139.269915] [<
ffffffffa02704b5>] __rpc_execute+0x1d5/0x400 [sunrpc]
[ 139.269915] [<
ffffffffa0270706>] rpc_async_schedule+0x26/0x30 [sunrpc]
[ 139.269915] [<
ffffffff8107867b>] process_one_work+0x17b/0x460
[ 139.269915] [<
ffffffff8107942b>] worker_thread+0x11b/0x400
[ 139.269915] [<
ffffffff81079310>] ? rescuer_thread+0x3e0/0x3e0
[ 139.269915] [<
ffffffff8107fc80>] kthread+0xc0/0xd0
[ 139.269915] [<
ffffffff8107fbc0>] ? kthread_create_on_node+0x110/0x110
[ 139.269915] [<
ffffffff815d122c>] ret_from_fork+0x7c/0xb0
[ 139.269915] [<
ffffffff8107fbc0>] ? kthread_create_on_node+0x110/0x110
[ 139.269915] Code: 4c 8b 45 c8 48 8d 7d d0 89 4d c4 41 89 c9 b9 28 00 00 00 e8 9d b4 e9
e0 48 85 c0 49 89 c5 74 a2 48 89 c7 e8 9d 3f e9 e0 48 89 c2 <41> 8b 46 04 48 8b 7d d0 4c
89 e9 4c 89 e6 89 42 0c 0f b7 83 d4
[ 139.269915] RIP [<
ffffffffa026f216>] ftrace_raw_event_rpc_task_running+0x86/0xf0 [sunrpc]
[ 139.269915] RSP <
ffff88001b633d70>
[ 139.269915] CR2:
0000000000000004
[ 140.946406] ---[ end trace
ba486328b98d7622 ]---
Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 10 Dec 2019 16:41:14 +0000 (11:41 -0500)]
fix: ext4: Reserve revoke credits for freed blocks (v5.5)
See upstream commit:
commit
83448bdfb59731c2f54784ed3f4a93ff95be6e7e
Author: Jan Kara <jack@suse.cz>
Date: Tue Nov 5 17:44:29 2019 +0100
ext4: Reserve revoke credits for freed blocks
So far we have reserved only relatively high fixed amount of revoke
credits for each transaction. We over-reserved by large amount for most
cases but when freeing large directories or files with data journalling,
the fixed amount is not enough. In fact the worst case estimate is
inconveniently large (maximum extent size) for freeing of one extent.
We fix this by doing proper estimate of the amount of blocks that need
to be revoked when removing blocks from the inode due to truncate or
hole punching and otherwise reserve just a small amount of revoke
credits for each transaction to accommodate freeing of xattrs block or
so.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 10 Dec 2019 16:41:12 +0000 (11:41 -0500)]
fix: btrfs: tracepoints: constify all pointers (v5.5)
See upstream commit:
commit
1d2e7c7c3ed73cc510a4dc093df2a935092ff5ad
Author: David Sterba <dsterba@suse.com>
Date: Thu Oct 17 13:28:57 2019 +0200
btrfs: tracepoints: constify all pointers
We don't modify the data passed to tracepoints, some of the declarations
are already const, add it to the rest.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 10 Dec 2019 16:41:13 +0000 (11:41 -0500)]
fix: btrfs block group struct refactor (v5.5)
See upstream commits:
commit
32da5386d9a4fd5c1155cecf703df104d918954c
Author: David Sterba <dsterba@suse.com>
Date: Tue Oct 29 19:20:18 2019 +0100
btrfs: rename btrfs_block_group_cache
The type name is misleading, a single entry is named 'cache' while this
normally means a collection of objects. Rename that everywhere. Also the
identifier was quite long, making function prototypes harder to format.
commit
b3470b5dbe1300dea94191ae4b7d070be9a5cdc9
Author: David Sterba <dsterba@suse.com>
Date: Wed Oct 23 18:48:22 2019 +0200
btrfs: add dedicated members for start and length of a block group
The on-disk format of block group item makes use of the key that stores
the offset and length. This is further used in the code, although this
makes thing harder to understand. The key is also packed so the
offset/length is not properly aligned as u64.
Add start (key.objectid) and length (key.offset) members to block group
and remove the embedded key. When the item is searched or written, a
local variable for key is used.
commit
bf38be65f3703d5ef3661c0a2802bc28e76b8f19
Author: David Sterba <dsterba@suse.com>
Date: Wed Oct 23 18:48:11 2019 +0200
btrfs: move block_group_item::used to block group
For unknown reasons, the member 'used' in the block group struct is
stored in the b-tree item and accessed everywhere using the special
accessor helper. Let's unify it and make it a regular member and only
update the item before writing it to the tree.
The item is still being used for flags and chunk_objectid, there's some
duplication until the item is removed in following patches.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 10 Dec 2019 16:41:11 +0000 (11:41 -0500)]
fix: y2038: itimer: change implementation to timespec64 (v5.5)
See upstream commit:
commit
bd40a175769d411b2a37e1c087082ac7ee2c15bb
Author: Arnd Bergmann <arnd@arndb.de>
Date: Thu Nov 7 15:27:39 2019 +0100
y2038: itimer: change implementation to timespec64
There is no 64-bit version of getitimer/setitimer since that is not
actually needed. However, the implementation is built around the
deprecated 'struct timeval' type.
Change the code to use timespec64 internally to reduce the dependencies
on timeval and associated helper functions.
Minor adjustments in the code are needed to make the native and compat
version work the same way, and to keep the range check working after
the conversion.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Tue, 10 Dec 2019 16:41:10 +0000 (11:41 -0500)]
Update .gitignore from upstream
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Fri, 18 Oct 2019 19:23:59 +0000 (15:23 -0400)]
Fix: LTTNG_KERNEL_ADD_CALLSITE: Handle unknown event type
Return -ENOSYS for unknown event type (similarly to other commands)
rather than falling-through the switch statement.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Thu, 17 Oct 2019 19:22:00 +0000 (15:22 -0400)]
Version 2.11.0
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Fri, 11 Oct 2019 20:13:16 +0000 (16:13 -0400)]
Version 2.11.0-rc7
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Michael Jeanson [Mon, 30 Sep 2019 19:15:34 +0000 (15:15 -0400)]
Fix: btrfs: move basic block_group definitions to their own header (v5.4)
commit
aac0023c2106952538414254960c51dcf0dc39e9
Author: Josef Bacik <josef@toxicpanda.com>
Date: Thu Jun 20 15:37:44 2019 -0400
btrfs: move basic block_group definitions to their own header
This is prep work for moving all of the block group cache code into its
own file.
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Tue, 17 Sep 2019 18:12:07 +0000 (14:12 -0400)]
Cleanup: Silence gcc fall-through warning
Use a comment pattern recognized by gcc 7.4.0 to silence the
fall-through warning.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Gabriel-Andrew Pollo-Guilbert [Mon, 16 Sep 2019 17:57:38 +0000 (13:57 -0400)]
Fix: update sched prev_state instrumentation for upstream kernel
Introduced in upstream Linux kernel 4.14.
commit
efb40f588b4370ffaeffafbd50f6ff213d954254
Author: Peter Zijlstra <peterz@infradead.org>
Date: Fri Sep 22 18:19:53 2017 +0200
sched/tracing: Fix trace_sched_switch task-state printing
Introduced in upstream Linux kernel 4.15.
Backported in
13f12749af15 (4.14.64).
commit
3f5fe9fef5b2da06b6319fab8123056da5217c3f
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed Nov 22 13:05:48 2017 +0100
sched/debug: Fix task state recording/printout
Introduced in upstream Linux kernel 4.20.
Backported in
e1e5fa73e466 (4.14.102) and
fd8152818f11 (4.19.9).
commit
3054426dc68e5d63aa6a6e9b91ac4ec78e3f3805
Author: Pavankumar Kondeti <pkondeti@codeaurora.org>
Date: Tue Oct 30 12:24:33 2018 +0530
sched, trace: Fix prev_state output in sched_switch tracepoint
Signed-off-by: Gabriel-Andrew Pollo-Guilbert <gabriel.pollo-guilbert@efficios.com>
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Sat, 7 Sep 2019 12:13:01 +0000 (13:13 +0100)]
Version 2.11.0-rc6
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Fri, 6 Sep 2019 01:01:47 +0000 (21:01 -0400)]
Fix: gcc-9.1 stack frame size warning
gcc-9.1.0 warns about lttng_session_ioctl taking a too large frame size.
lttng-modules/lttng-abi.c:622:1: warning: the frame size of 2240 bytes
is larger than 2048 bytes [-Wframe-larger-than=]
Combine the variables used in the various case of the switch so they are
not duplicated on the stack by the compiler.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Jonathan Rajotte [Tue, 13 Aug 2019 18:14:25 +0000 (14:14 -0400)]
Introduce LTTNG_KERNEL_SESSION_SET_CREATION_TIME
Add trace_creation_datetime to the metadata env field
This allows a viewer to get more information regarding the creation time
of a trace. This information is normally inferred from the trace
hierarchy.
The ABI expects an ISO8601 compliant string value. We leave the
formatting to the trace controller.
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Jonathan Rajotte [Tue, 13 Aug 2019 18:14:24 +0000 (14:14 -0400)]
Add metadata env fields
Add the following fields:
- tracer_buffering_scheme
The buffering scheme used by the tracer. lttng-modules sole
buffering scheme is "global".
- trace_name
The name of the trace. Use the session name.
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Jonathan Rajotte [Tue, 13 Aug 2019 18:14:23 +0000 (14:14 -0400)]
Introduce LTTNG_KERNEL_SESSION_SET_NAME
The tracer controller (lttng-sessiond) can now inform the kernel tracer
of the name of the created session. This will allow the tracer to
propagate the information inside the trace metadata under a "env" field.
This information is normally inferred from the generated folder
structure where a trace rests.
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Jonathan Rajotte [Thu, 4 Jul 2019 20:02:13 +0000 (16:02 -0400)]
Fix: do not use diagnostic pragma when GCC version is lower than 4.6.0
Officially the diagnostic pragma are supported starting in 4.6. [1]
But they were present before 4.6 with limitation which we cannot
honour easily.
[1] https://gcc.gnu.org/gcc-4.6/changes.html
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Jonathan Rajotte [Thu, 4 Jul 2019 20:02:12 +0000 (16:02 -0400)]
Fix: missing define when not building with gcc
Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Mon, 24 Jun 2019 13:43:45 +0000 (09:43 -0400)]
Fix: lttng-tracepoint module notifier should return NOTIFY_OK
Module notifiers should return NOTIFY_OK on success rather than the
value 0. The return value 0 does not seem to have any ill side-effects
in the notifier chain caller, but it is preferable to respect the API
requirements in case this changes in the future.
Notifiers can encapsulate a negative errno value with
notifier_from_errno(), but this is not needed by the LTTng tracepoint
notifier.
The approach taken in this notifier is to just print a console warning
on error, because tracing failure should not prevent loading a module.
So we definitely do not want to stop notifier iteration. Returning
an error without stopping iteration is not really that useful, because
only the return value of the last callback is returned to notifier chain
caller.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Tue, 11 Jun 2019 22:36:22 +0000 (00:36 +0200)]
Version 2.11.0-rc5
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Jérémie Galarneau [Tue, 11 Jun 2019 22:34:32 +0000 (18:34 -0400)]
Fix: Don't print ring-buffer's records count when it is not used
The teardown of a ring buffer causes a number of diagnostic messages
to be printed using printk. One of those contains the "records
count", which is only updated when lttng-modules is built with
LTTNG_RING_BUFFER_COUNT_EVENTS defined.
Move the "records count" printing to a different function and stub it
out when LTTNG_RING_BUFFER_COUNT_EVENTS is not defined
(default configuration).
This eliminates messages of the following form from the dmesg output
when an LTTng session is torn down.
[...] ring buffer relay-discard, cpu 0: 0 records written, 0 records overrun
Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Tue, 11 Jun 2019 21:44:56 +0000 (23:44 +0200)]
Fix: do not set quiescent state on channel destroy
Setting the quiescent state to true for each stream at channel
destruction is not useful: there are no readers left anyway at
that stage.
The side-effect perceived of setting this quiescent state on
destroy is that the metadata stream ends up with an empty last
packet (due to flush_empty performed when setting the quiescent state)
which is never consumed. This shows up in the lttng-modules error
reporting.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Tue, 4 Jun 2019 18:59:26 +0000 (14:59 -0400)]
Fix: ring_buffer_frontend.c: init read timer with uninitialized flags
For the config->alloc RING_BUFFER_ALLOC_GLOBAL (metadata channel), the
read timer flags argument is uninitialized.
Found by Coverity:
CID
1401114 (#1 of 1): Uninitialized scalar variable (UNINIT)
6. uninit_use_in_call: Using uninitialized value flags when calling init_timer_key.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Mathieu Desnoyers [Wed, 22 May 2019 01:16:15 +0000 (21:16 -0400)]
Introduce callstack stackwalk implementation header
Introduce a new implementation header for the stackwalk-based API, added
in Linux 5.2 and gradually integrated within each architecture.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
This page took 0.060077 seconds and 4 git commands to generate.