Document last supported kernel version for stable-2.10 branch

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ie554bb04840f799c34b0f28657cf982969991797

Fix: do not use bdi_unknown_name symbol

Use the GPL-exported bdi_dev_name introduced in kernel 5.7. Do not use
static inline bdi_dev_name in prior kernels because it uses the bdi_unknown_name
symbol which is not exported to GPL modules.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I8b4e4fd84ecacef7942b308e615ca88db8dce7b6

fix: memcg: fix a crash in wb_workfn when a device disappears (5.6)

See upstream commit:

commit 68f23b89067fdf187763e75a56087550624fdbee
("memcg: fix a crash in wb_workfn when a device disappears")

It is currently backported into stable branches 5.4 and 5.5, but appears
to be missing from the 4.4, 4.9, 4.14, 4.19 LTS branches.

Implement our own lttng_bdi_dev_name wrapper to provide this fix on
builds against stable kernels which do not have this fix.

There is one user-visible change with this commit: for builds against
kernels < 4.4.0, the writeback_work_class events did use the
default_backing_dev_info to handle cases where the device is NULL,
writing "default" into the trace. This behavior is now aligned to
match what is done in kernels >= 4.4.0, which is to write "(unknown)"
into the name field.

Link: https://lore.kernel.org/r/537870616.15400.1612973059419.JavaMail.zimbra@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I0823643aa2f9d4c2b9f2005748a2adfd4457979a

Fix: writeback: out-of-bound reads

Use ctf_string rather than ctf_array_text for name fields, because the
source strings are not guaranteed to be at least 32 bytes.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

fix: Add one digit to RHEL major release version

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I641d0a98e1a7b610b373b85bc4c8325c8dd77955

fix: Add one digit to SLES minor release version

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I150b5b5d2bd5a3fc3cadaef5fcb26a29baccba3c

fix: RT_PATCH_VERSION is close to overflow

We allocated only 8bits for RT_PATCH_VERSION in LTTNG_RT_VERSION_CODE,
the current RT patch version for the 4.4 branch is currently 214 which
is getting close to 256. Bump it to 16bits to avoid breakage in the
future.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: If0154ab5d8970134bf27a97c9ebd4310150ca126

fix: cast LTTNG_KERNEL_VERSION/LTTNG_LINUX_VERSION_CODE to uint64_t

Cast our version macros to an unsigned 64bits value to prevent
overflowing when we append distro specific version information.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ia76058c7b019e16545786d16d4b49aefb7c36e14

fix: UTS_UBUNTU_RELEASE_ABI is close to overflow

We allocated only 8bits for UTS_UBUNTU_RELEASE_ABI in
LTTNG_UBUNTU_KERNEL_VERSION, the current Xenial kernel has an ABI of 207
which is getting close to 256. Bump it to 16bits to avoid breakage in
the future.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ib094b73d42e81aeeb74206224373a032d5c65dee

fix: sublevel version overflow in LINUX_VERSION_CODE

The 4.4.256 and 4.9.256 stable release overflow the 8bits allocated to
the sublevel in LINUX_VERSION_CODE which ends means they report
themselves as 4.5.0 and 4.10.0 respectively. The next releases in these
stables branches will have sublevel clamped at 255 and will thus report
themselves as 4.4.255 and 4.9.255 for all subsequent releases.

We need a way to way to properly detect these release since I doubt they
will stop breaking tracepoints declarations. As a workaround, extract
the version information from the Makefile in the kernel headers and use
this information to generate a version code when the sublevel is equal
or greater than 256.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I07c0747b0aba00fc2efa3b084edaf61be4e4c570

Namespace kernel version macros

This patch replaces all uses of the LINUX_VERSION_CODE and
KERNEL_VERSION macros by an 'LTTNG_' prefixed version, this will allow
us to override them.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ie74cd03d830366117dc78d084977bc596ad34b85

fix: btrfs: tracepoints: output proper root owner for trace_find_free_extent() (v5.10)

See upstream commit :

  commit 437490fed3b0c9ae21af8f70e0f338d34560842b
  Author: Qu Wenruo <wqu@suse.com>
  Date:   Tue Jul 28 09:42:49 2020 +0800

    btrfs: tracepoints: output proper root owner for trace_find_free_extent()

    The current trace event always output result like this:

     find_free_extent: root=2(EXTENT_TREE) len=16384 empty_size=0 flags=4(METADATA)
     find_free_extent: root=2(EXTENT_TREE) len=16384 empty_size=0 flags=4(METADATA)
     find_free_extent: root=2(EXTENT_TREE) len=8192 empty_size=0 flags=1(DATA)
     find_free_extent: root=2(EXTENT_TREE) len=8192 empty_size=0 flags=1(DATA)
     find_free_extent: root=2(EXTENT_TREE) len=4096 empty_size=0 flags=1(DATA)
     find_free_extent: root=2(EXTENT_TREE) len=4096 empty_size=0 flags=1(DATA)

    T's saying we're allocating data extent for EXTENT tree, which is not
    even possible.

    It's because we always use EXTENT tree as the owner for
    trace_find_free_extent() without using the @root from
    btrfs_reserve_extent().

    This patch will change the parameter to use proper @root for
    trace_find_free_extent():

    Now it looks much better:

     find_free_extent: root=5(FS_TREE) len=16384 empty_size=0 flags=36(METADATA|DUP)
     find_free_extent: root=5(FS_TREE) len=8192 empty_size=0 flags=1(DATA)
     find_free_extent: root=5(FS_TREE) len=16384 empty_size=0 flags=1(DATA)
     find_free_extent: root=5(FS_TREE) len=4096 empty_size=0 flags=1(DATA)
     find_free_extent: root=5(FS_TREE) len=8192 empty_size=0 flags=1(DATA)
     find_free_extent: root=5(FS_TREE) len=16384 empty_size=0 flags=36(METADATA|DUP)
     find_free_extent: root=7(CSUM_TREE) len=16384 empty_size=0 flags=36(METADATA|DUP)
     find_free_extent: root=2(EXTENT_TREE) len=16384 empty_size=0 flags=36(METADATA|DUP)
     find_free_extent: root=1(ROOT_TREE) len=16384 empty_size=0 flags=36(METADATA|DUP)

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I1d674064d29b31417e2acffdeb735f5052a87032

fix: don't allow userspace copy to read kernel memory

This patch fixes a security issue which allows the root user to read
arbitrary kernel memory. Considering the security model used in LTTng
userspace tooling for kernel tracing, this bug also allows members of
the 'tracing' group to read arbitrary kernel memory.

Calls to __copy_from_user_inatomic() where wrongly enclosed in
set_fs(KERNEL_DS) defeating the access_ok() calls and allowing to read
from kernel memory if a kernel address is provided.

Remove all set_fs() calls around __copy_from_user_inatomic().

As a side effect this will allow us to support v5.10 which should remove
set_fs().

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I35e4562c835217352c012ed96a7b8f93e941381e

fix: Adjust ranges for Ubuntu HWE 5.0 kernels

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I475663967df6e7851728c28b7ff8cad3cd99ed04

fix: writeback: Fix sync livelock due to b_dirty_time processing (v5.9)

See upstream commit:

  commit f9cae926f35e8230330f28c7b743ad088611a8de
  Author: Jan Kara <jack@suse.cz>
  Date:   Fri May 29 16:08:58 2020 +0200

    writeback: Fix sync livelock due to b_dirty_time processing

    When we are processing writeback for sync(2), move_expired_inodes()
    didn't set any inode expiry value (older_than_this). This can result in
    writeback never completing if there's steady stream of inodes added to
    b_dirty_time list as writeback rechecks dirty lists after each writeback
    round whether there's more work to be done. Fix the problem by using
    sync(2) start time is inode expiry value when processing b_dirty_time
    list similarly as for ordinarily dirtied inodes. This requires some
    refactoring of older_than_this handling which simplifies the code
    noticeably as a bonus.

Change-Id: I99e505965d278565ae512a30842cdce888e0c84a
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Version 2.10.15

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

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

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

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

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

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

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

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

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

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>

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>

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>

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>

Version 2.10.14

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

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>

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>

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>

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>

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>

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>

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>

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>

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

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

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

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

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>

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

Version 2.10.13

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

fix: function prototype in wrapper/mm.h

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

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>

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>

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>

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>

fix: missing 'lttng_fs_info_fsid' wrapper in btrfs backport

The following backported patch was missing the use of the
'lttng_fs_info_fsid' wrapper to enable compatibility with upstream
stable kernels.

  commit 065436fd07d58a9a17427ad386ffcc8d29e25a9d
  Author: Michael Jeanson <mjeanson@efficios.com>
  Date:   Mon Jun 18 14:53:18 2018 -0400

    Fix: btrfs: use fs_info for btrfs_handle_em_exist tracepoint

    See upstream commit:

      commit f46b24c9457143a367c6707eac82d546e2bcf280
      Author: David Sterba <dsterba@suse.com>
      Date:   Tue Apr 3 21:45:57 2018 +0200

        btrfs: use fs_info for btrfs_handle_em_exist tracepoint

        We really want to know to which filesystem the extent map events belong,
        but as it cannot be reached from the extent_map pointers, we need to
        pass it down the callchain.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

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>

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>

Fix: btrfs: use fs_info for btrfs_handle_em_exist tracepoint

See upstream commit:

  commit f46b24c9457143a367c6707eac82d546e2bcf280
  Author: David Sterba <dsterba@suse.com>
  Date:   Tue Apr 3 21:45:57 2018 +0200

    btrfs: use fs_info for btrfs_handle_em_exist tracepoint

    We really want to know to which filesystem the extent map events belong,
    but as it cannot be reached from the extent_map pointers, we need to
    pass it down the callchain.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Add btrfs tracepoint for em's EEXIST case

See upstream commits:

  commit 393da91819e35af538ef97c7c6a04899e2fbfe0e
  Author: Liu Bo <bo.li.liu@oracle.com>
  Date:   Fri Jan 5 12:51:16 2018 -0700

    Btrfs: add tracepoint for em's EEXIST case

    This is adding a tracepoint 'btrfs_handle_em_exist' to help debug the
    subtle bugs around merge_extent_mapping.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

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>

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>

Update .gitignore from upstream

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Version 2.10.12

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

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>

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>

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>

Version 2.10.11

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

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>

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>

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>

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>

Version 2.10.10

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

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>

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>

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>

fix: random: only read from /dev/random after its pool has received 128 bits (v5.2)

See upstream commit:

  commit eb9d1bf079bb438d1a066d72337092935fc770f6
  Author: Theodore Ts'o <tytso@mit.edu>
  Date:   Wed Feb 20 16:06:38 2019 -0500

    random: only read from /dev/random after its pool has received 128 bits

    Immediately after boot, we allow reads from /dev/random before its
    entropy pool has been fully initialized.  Fix this so that we don't
    allow this until the blocking pool has received 128 bits.

    We do this by repurposing the initialized flag in the entropy pool
    struct, and use the initialized flag in the blocking pool to indicate
    whether it is safe to pull from the blocking pool.

    To do this, we needed to rework when we decide to push entropy from the
    input pool to the blocking pool, since the initialized flag for the
    input pool was used for this purpose.  To simplify things, we no
    longer use the initialized flag for that purpose, nor do we use the
    entropy_total field any more.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

fix: mm: move recent_rotated pages calculation to shrink_inactive_list() (v5.2)

See upstream commit:

  commit 886cf1901db962cee5f8b82b9b260079a5e8a4eb
  Author: Kirill Tkhai <ktkhai@virtuozzo.com>
  Date:   Mon May 13 17:16:51 2019 -0700

    mm: move recent_rotated pages calculation to shrink_inactive_list()

    Patch series "mm: Generalize putback functions"]

    putback_inactive_pages() and move_active_pages_to_lru() are almost
    similar, so this patchset merges them ina single function.

    This patch (of 4):

    The patch moves the calculation from putback_inactive_pages() to
    shrink_inactive_list().  This makes putback_inactive_pages() looking more
    similar to move_active_pages_to_lru().

    To do that, we account activated pages in reclaim_stat::nr_activate.
    Since a page may change its LRU type from anon to file cache inside
    shrink_page_list() (see ClearPageSwapBacked()), we have to account pages
    for the both types.  So, nr_activate becomes an array.

    Previously we used nr_activate to account PGACTIVATE events, but now we
    account them into pgactivate variable (since they are about number of
    pages in general, not about sum of hpage_nr_pages).

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

fix: mm/vmscan: simplify trace_reclaim_flags and trace_shrink_flags (v5.2)

See upstream commit:

  commit 60b62ff7cc4217ac3de76535fa4c1510a798dbcb
  Author: Yafang Shao <laoar.shao@gmail.com>
  Date:   Mon May 13 17:23:08 2019 -0700

    mm/vmscan: simplify trace_reclaim_flags and trace_shrink_flags

    trace_reclaim_flags and trace_shrink_flags are almost the same.
    We can simplify them to avoid redundant code.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

fix: mm/vmscan: drop may_writepage and classzone_idx from direct reclaim begin template (v5.2)

See upstream commit:

  commit 3481c37ffa1de58ef140d0fe9eabf56305e74666
  Author: Yafang Shao <laoar.shao@gmail.com>
  Date:   Mon May 13 17:19:14 2019 -0700

    mm/vmscan: drop may_writepage and classzone_idx from direct reclaim begin template

    There are three tracepoints using this template, which are
    mm_vmscan_direct_reclaim_begin,
    mm_vmscan_memcg_reclaim_begin,
    mm_vmscan_memcg_softlimit_reclaim_begin.

    Regarding mm_vmscan_direct_reclaim_begin,
    sc.may_writepage is !laptop_mode, that's a static setting, and
    reclaim_idx is derived from gfp_mask which is already show in this
    tracepoint.

    Regarding mm_vmscan_memcg_reclaim_begin,
    may_writepage is !laptop_mode too, and reclaim_idx is (MAX_NR_ZONES-1),
    which are both static value.

    mm_vmscan_memcg_softlimit_reclaim_begin is the same with
    mm_vmscan_memcg_reclaim_begin.

    So we can drop them all.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

fix: timer/trace: Improve timer tracing (v5.2)

See upstream commit:

  commit f28d3d5346e97e60c81f933ac89ccf015430e5cf
  Author: Anna-Maria Gleixner <anna-maria@linutronix.de>
  Date:   Thu Mar 21 13:09:21 2019 +0100

    timer/trace: Improve timer tracing

    Timers are added to the timer wheel off by one. This is required in
    case a timer is queued directly before incrementing jiffies to prevent
    early timer expiry.

    When reading a timer trace and relying only on the expiry time of the timer
    in the timer_start trace point and on the now in the timer_expiry_entry
    trace point, it seems that the timer fires late. With the current
    timer_expiry_entry trace point information only now=jiffies is printed but
    not the value of base->clk. This makes it impossible to draw a conclusion
    to the index of base->clk and makes it impossible to examine timer problems
    without additional trace points.

    Therefore add the base->clk value to the timer_expire_entry trace
    point, to be able to calculate the index the timer base is located at
    during collecting expired timers.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Cleanup: bitfields: streamline use of underscores

Do not prefix macro arguments with underscores. Use one leading
underscore as prefix for local variables defined within macros.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Silence compiler "always false comparison" warning

Compiling the bitfield test with gcc -Wextra generates those warnings:

 ../../include/babeltrace/bitfield-internal.h:38:45: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
 #define _bt_is_signed_type(type) ((type) -1 < (type) 0)

This is the intent of the macro. Disable compiler warnings around use of
that macro.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com

Fix: bitfield: shift undefined/implementation defined behaviors

bitfield.h uses the left shift operator with a left operand which
may be negative. The C99 standard states that shifting a negative
value is undefined.

When building with -Wshift-negative-value, we get this gcc warning:

In file included from /home/smarchi/src/babeltrace/include/babeltrace/ctfser-internal.h:44:0,
                 from /home/smarchi/src/babeltrace/ctfser/ctfser.c:42:
/home/smarchi/src/babeltrace/include/babeltrace/ctfser-internal.h: In function ‘bt_ctfser_write_unsigned_int’:
/home/smarchi/src/babeltrace/include/babeltrace/bitfield-internal.h:116:24: error: left shift of negative value [-Werror=shift-negative-value]
   mask = ~((~(type) 0) << (__start % ts));  \
                        ^
/home/smarchi/src/babeltrace/include/babeltrace/bitfield-internal.h:222:2: note: in expansion of macro ‘_bt_bitfield_write_le’
  _bt_bitfield_write_le(ptr, type, _start, _length, _v)
  ^~~~~~~~~~~~~~~~~~~~~
/home/smarchi/src/babeltrace/include/babeltrace/ctfser-internal.h:418:3: note: in expansion of macro ‘bt_bitfield_write_le’
   bt_bitfield_write_le(mmap_align_addr(ctfser->base_mma) +
   ^~~~~~~~~~~~~~~~~~~~

This boils down to the fact that the expression ~((uint8_t)0) has type
"signed int", which is used as an operand of the left shift.  This is due
to the integer promotion rules of C99 (6.3.3.1):

    If an int can represent all values of the original type, the value is
    converted to an int; otherwise, it is converted to an unsigned int.
    These are called the integer promotions. All other types are unchanged
    by the integer promotions.

We also need to cast the result explicitly into the left hand
side type to deal with:

warning: large integer implicitly truncated to unsigned type [-Woverflow]

The C99 standard states that a right shift has implementation-defined
behavior when shifting a signed negative value. Add a preprocessor check
that the compiler provides the expected behavior, else provide an
alternative implementation which guarantees the intended behavior.

A preprocessor check is also added to ensure that the compiler
representation for signed values is two's complement, which is expected
by this header.

Document that this header strictly respects the C99 standard, with
the exception of its use of __typeof__.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Cleanup: bitfield.h: move to kernel style SPDX license identifiers

The SPDX identifier is a legally binding shorthand, which can be used
instead of the full boiler plate text. According to kernel documentation
it has to be inserted on the first or second line of a file.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: timestamp_end field should include all events within sub-buffer

Fix for timestamp_end not including all events within sub-buffer. This
happens if a thread is preempted/interrupted for a long time between
reserve and commit (e.g. in the middle of a packet), which causes the
timestamp used for timestamp_end field of the packet header to be lower
than the timestamp of the last events in the buffer (those following the
event that was preempted/interrupted between reserve and commit).

The fix involves sampling the timestamp when doing the last space
reservation in a sub-buffer (which necessarily happens before doing the
delivery after its last commit). Save this timestamp temporarily in a
per-sub-buffer control area (we have exclusive access to that area until
we increment the commit counter).

Then, that timestamp value will be read when delivering the sub-buffer,
whichever event or switch happens to be the last to increment the commit
counter to perform delivery. The timestamp value can be read without
worrying about concurrent access, because at that point sub-buffer
delivery has exclusive access to the sub-buffer.

This ensures the timestamp_end value is always larger or equal to the
timestamp of the last event, always below or equal the timestamp_begin
of the following packet, and always below or equal the timestamp of the
first event in the following packet.

Fixes: #1183
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: Remove start and number from syscall_get_arguments() args (v5.1)

  commit b35f549df1d7520d37ba1e6d4a8d4df6bd52d136
  Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
  Date:   Mon Nov 7 16:26:37 2016 -0500

    syscalls: Remove start and number from syscall_get_arguments() args

    At Linux Plumbers, Andy Lutomirski approached me and pointed out that the
    function call syscall_get_arguments() implemented in x86 was horribly
    written and not optimized for the standard case of passing in 0 and 6 for
    the starting index and the number of system calls to get. When looking at
    all the users of this function, I discovered that all instances pass in only
    0 and 6 for these arguments. Instead of having this function handle
    different cases that are never used, simply rewrite it to return the first 6
    arguments of a system call.

    This should help out the performance of tracing system calls by ptrace,
    ftrace and perf.

Link: http://lkml.kernel.org/r/20161107213233.754809394@goodmis.org
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

lttng abi documentation: clarify getter usage requirements

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: don't access packet header for stream_id and stream_instance_id getters

The stream ID and stream instance ID are invariant for a stream, so
there is no point reading them from the packet header currently owned by
the consumer (between get/put subbuf).

Actually, the consumer try to access the stream_id from the live timer
when sending a live beacon without getting the reader subbuffer first.
Doing so is racy against producers. In typical live scenarios
(non-overwrite channels), the producers will always write the same
stream id and stream instance id values at the same header offsets,
which will "work", except for the initial state of an empty buffer:
the value "0" will be returned (erroneously).

For the less frequently used scenario of a live session with "overwrite"
channels, this will trigger WARN_ON safety nets in libringbuffer. This
safety net triggers a kernel OOPS report and disables tracing for that
channel.

In the case where a ring buffer does not have any data ready, it makes
no sense to try to get a subbuffer for reading anyway, so the approach
was broken.

So return the stream id and stream instance id from the internal
data structures rather than reading it from the ring buffer.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: atomic_long_add_unless() returns a boolean

Because of a documentation error in older kernels, it was assumed that
atomic_long_add_unless would return the old value, but the
implementation actually returns a boolean.

Also add missing error code int 'ret' and compare against the right type
max value.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: Revert "KVM: MMU: show mmu_valid_gen..." (v5.1)

See upstream commit :

  commit b59c4830ca185ba0e9f9e046fb1cd10a4a92627a
  Author: Sean Christopherson <sean.j.christopherson@intel.com>
  Date:   Tue Feb 5 13:01:30 2019 -0800

    Revert "KVM: MMU: show mmu_valid_gen in shadow page related tracepoints"

    ...as part of removing x86 KVM's fast invalidate mechanism, i.e. this
    is one part of a revert all patches from the series that introduced the
    mechanism[1].

    This reverts commit 2248b023219251908aedda0621251cffc548f258.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: pipe: stop using ->can_merge (v5.1)

See upstream commit:

  commit 01e7187b41191376cee8bea8de9f907b001e87b4
  Author: Jann Horn <jannh@google.com>
  Date:   Wed Jan 23 15:19:18 2019 +0100

    pipe: stop using ->can_merge

    Al Viro pointed out that since there is only one pipe buffer type to which
    new data can be appended, it isn't necessary to have a ->can_merge field in
    struct pipe_buf_operations, we can just check for a magic type.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: rcu: Remove wrapper definitions for obsolete RCU... (v5.1)

See upstream commit :

commit 6ba7d681aca22e53385bdb35b1d7662e61905760
Author: Paul E. McKenney <paulmck@linux.ibm.com>
Date:   Wed Jan 9 15:22:03 2019 -0800

    rcu: Remove wrapper definitions for obsolete RCU update functions

    None of synchronize_rcu_bh, synchronize_rcu_bh_expedited, call_rcu_bh,
    rcu_barrier_bh, synchronize_sched, synchronize_sched_expedited,
    call_rcu_sched, rcu_barrier_sched, get_state_synchronize_sched, and
    cond_synchronize_sched are actually used.  This commit therefore removes
    their trivial wrapper-function definitions.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: mm: create the new vm_fault_t type (v5.1)

See upstream commit:

  commit 3d3539018d2cbd12e5af4a132636ee7fd8d43ef0
  Author: Souptick Joarder <jrdr.linux@gmail.com>
  Date:   Thu Mar 7 16:31:14 2019 -0800

    mm: create the new vm_fault_t type

    Page fault handlers are supposed to return VM_FAULT codes, but some
    drivers/file systems mistakenly return error numbers.  Now that all
    drivers/file systems have been converted to use the vm_fault_t return
    type, change the type definition to no longer be compatible with 'int'.
    By making it an unsigned int, the function prototype becomes
    incompatible with a function which returns int.  Sparse will detect any
    attempts to return a value which is not a VM_FAULT code.

    VM_FAULT_SET_HINDEX and VM_FAULT_GET_HINDEX values are changed to avoid
    conflict with other VM_FAULT codes.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: extra-version-git.sh redirect stderr to /dev/null

Running make in a git repo that does not contain any tag prints:

fatal: No names found, cannot describe anything.

in the make and make clean outputs.

It's fine to have no tag name available (extra-version-git.sh will
return the value 0), but we should not print an error in the make
output. Redirect this error to /dev/null.

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Suggested-by: Michael Jeanson <mjeanson@efficios.com>

Version 2.10.9

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Blacklist: kprobe for arm

This upstream kernel commit broke optimized kprobe.

commit e46daee53bb50bde38805f1823a182979724c229
Author: Kees Cook <keescook@chromium.org>
Date:   Tue Oct 30 22:12:56 2018 +0100

    ARM: 8806/1: kprobes: Fix false positive with FORTIFY_SOURCE

    The arm compiler internally interprets an inline assembly label
    as an unsigned long value, not a pointer. As a result, under
    CONFIG_FORTIFY_SOURCE, the address of a label has a size of 4 bytes,
    which was tripping the runtime checks. Instead, we can just cast the label
    (as done with the size calculations earlier).

    Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1639397

Reported-by: William Cohen <wcohen@redhat.com>
Fixes: 6974f0c4555e ("include/linux/string.h: add the option of fortified string.h functions")
Cc: stable@vger.kernel.org
Acked-by: Laura Abbott <labbott@redhat.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: William Cohen <wcohen@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
It was introduced in the 4.20 cycle.
It was also backported to the 4.19 and 4.14 branch.

This issue is fixed upstream by [1] and is present in the 5.0 kernel
release.

[1] 0ac569bf6a7983c0c5747d6df8db9dc05bc92b6c

The fix was backported to 4.20, 4.19 and 4.14 branch.
It is included starting at:
    v5.0.0
    v4.20.13
    v4.19.26
    v4.14.104

Fixes #1174

Signed-off-by: Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Cleanup: tp mempool: Remove logically dead code

Found by Coverity:
CID 1391045 (#1 of 1): Logically dead code (DEADCODE)

Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: btrfs: Remove fsid/metadata_fsid fields from btrfs_info

Introduced in v5.0.

See upstream commit :

  commit de37aa513105f864d3c21105bf5542d498f21ca2
  Author: Nikolay Borisov <nborisov@suse.com>
  Date:   Tue Oct 30 16:43:24 2018 +0200

    btrfs: Remove fsid/metadata_fsid fields from btrfs_info

    Currently btrfs_fs_info structure contains a copy of the
    fsid/metadata_uuid fields. Same values are also contained in the
    btrfs_fs_devices structure which fs_info has a reference to. Let's
    reduce duplication by removing the fields from fs_info and always refer
    to the ones in fs_devices. No functional changes.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: SUNRPC: Simplify defining common RPC trace events (v5.0)

See upstream commit :

  commit dc5820bd21d84ee34770b0a1e2fca9378f8f7456
  Author: Chuck Lever <chuck.lever@oracle.com>
  Date:   Wed Dec 19 11:00:16 2018 -0500

    SUNRPC: Simplify defining common RPC trace events

    Clean up, no functional change is expected.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: Replace pointer values with task->tk_pid and rpc_clnt->cl_clid

Introduced in v3.12.

See upstream commit :

  commit 92cb6c5be8134db6f7c38f25f6afd13e444cebaf
  Author: Trond Myklebust <Trond.Myklebust@netapp.com>
  Date:   Wed Sep 4 22:09:50 2013 -0400

    SUNRPC: Replace pointer values with task->tk_pid and rpc_clnt->cl_clid

    Instead of the pointer values, use the task and client identifier values
    for tracing purposes.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: Remove 'type' argument from access_ok() function (v5.0)

See upstream commit :

  commit 96d4f267e40f9509e8a66e2b39e8b95655617693
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Thu Jan 3 18:57:57 2019 -0800

    Remove 'type' argument from access_ok() function

    Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
    of the user address range verification function since we got rid of the
    old racy i386-only code to walk page tables by hand.

    It existed because the original 80386 would not honor the write protect
    bit when in kernel mode, so you had to do COW by hand before doing any
    user access.  But we haven't supported that in a long time, and these
    days the 'type' argument is a purely historical artifact.

    A discussion about extending 'user_access_begin()' to do the range
    checking resulted this patch, because there is no way we're going to
    move the old VERIFY_xyz interface to that model.  And it's best done at
    the end of the merge window when I've done most of my merges, so let's
    just get this done once and for all.

    This patch was mostly done with a sed-script, with manual fix-ups for
    the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.

    There were a couple of notable cases:

     - csky still had the old "verify_area()" name as an alias.

     - the iter_iov code had magical hardcoded knowledge of the actual
       values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
       really used it)

     - microblaze used the type argument for a debug printout

    but other than those oddities this should be a total no-op patch.

    I tried to fix up all architectures, did fairly extensive grepping for
    access_ok() uses, and the changes are trivial, but I may have missed
    something.  Any missed conversion should be trivially fixable, though.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: timer instrumentation for RHEL 7.6

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: ext4: adjust reserved cluster count when removing extents (v4.20)

See upstream commit :

  commit 9fe671496b6c286f9033aedfc1718d67721da0ae
  Author: Eric Whitney <enwlinux@gmail.com>
  Date:   Mon Oct 1 14:25:08 2018 -0400

    ext4: adjust reserved cluster count when removing extents

    Modify ext4_ext_remove_space() and the code it calls to correct the
    reserved cluster count for pending reservations (delayed allocated
    clusters shared with allocated blocks) when a block range is removed
    from the extent tree.  Pending reservations may be found for the clusters
    at the ends of written or unwritten extents when a block range is removed.
    If a physical cluster at the end of an extent is freed, it's necessary
    to increment the reserved cluster count to maintain correct accounting
    if the corresponding logical cluster is shared with at least one
    delayed and unwritten extent as found in the extents status tree.

    Add a new function, ext4_rereserve_cluster(), to reapply a reservation
    on a delayed allocated cluster sharing blocks with a freed allocated
    cluster.  To avoid ENOSPC on reservation, a flag is applied to
    ext4_free_blocks() to briefly defer updating the freeclusters counter
    when an allocated cluster is freed.  This prevents another thread
    from allocating the freed block before the reservation can be reapplied.

    Redefine the partial cluster object as a struct to carry more state
    information and to clarify the code using it.

    Adjust the conditional code structure in ext4_ext_remove_space to
    reduce the indentation level in the main body of the code to improve
    readability.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: signal: Remove SEND_SIG_FORCED (v4.20)

See upstream commit :

  commit 4ff4c31a6e85f4c49fbeebeaa28018d002884b5a
  Author: Eric W. Biederman <ebiederm@xmission.com>
  Date:   Mon Sep 3 10:39:04 2018 +0200

    signal: Remove SEND_SIG_FORCED

    There are no more users of SEND_SIG_FORCED so it may be safely removed.

    Remove the definition of SEND_SIG_FORCED, it's use in is_si_special,
    it's use in TP_STORE_SIGINFO, and it's use in __send_signal as without
    any users the uses of SEND_SIG_FORCED are now unncessary.

    This makes the code simpler, easier to understand and use.  Users of
    signal sending functions now no longer need to ask themselves do I
    need to use SEND_SIG_FORCED.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Fix: signal: Distinguish between kernel_siginfo and siginfo (v4.20)

See upstream commit :

  commit ae7795bc6187a15ec51cf258abae656a625f9980
  Author: Eric W. Biederman <ebiederm@xmission.com>
  Date:   Tue Sep 25 11:27:20 2018 +0200

    signal: Distinguish between kernel_siginfo and siginfo

    Linus recently observed that if we did not worry about the padding
    member in struct siginfo it is only about 48 bytes, and 48 bytes is
    much nicer than 128 bytes for allocating on the stack and copying
    around in the kernel.

    The obvious thing of only adding the padding when userspace is
    including siginfo.h won't work as there are sigframe definitions in
    the kernel that embed struct siginfo.

    So split siginfo in two; kernel_siginfo and siginfo.  Keeping the
    traditional name for the userspace definition.  While the version that
    is used internally to the kernel and ultimately will not be padded to
    128 bytes is called kernel_siginfo.

    The definition of struct kernel_siginfo I have put in include/signal_types.h

    A set of buildtime checks has been added to verify the two structures have
    the same field offsets.

    To make it easy to verify the change kernel_siginfo retains the same
    size as siginfo.  The reduction in size comes in a following change.

Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>