fix: kvm-x86 requires CONFIG_KALLSYMS_ALL

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

Version 2.12.11

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

Fix: bytecode validator: reject specialized load field/context ref instructions

Reject specialized load field/context ref instructions so a bytecode
crafted with nefarious intent cannot:

- Read user-space memory without proper get_user accessors,
- Read a memory area larger than the memory targeted by the instrumentation.

This prevents bytecode received from a tracing group user from oopsing
the kernel or disclosing the content of kernel memory to the tracing
group

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

Fix: bytecode validator: reject specialized load instructions

Reject specialized load instructions so a bytecode crafted with
nefarious intent cannot:

- Read user-space memory without proper get_user accessors,
- Read a memory area larger than the memory targeted by the instrumentation.

This prevents bytecode received from a tracing group user from oopsing
the kernel or disclosing the content of kernel memory to the tracing
group.

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

Fix: bytecode interpreter: LOAD_FIELD: handle user fields

The instructions for recursive traversal through composed types
are used by the filter expressions which access fields nested within
composed types.

Instructions BYTECODE_OP_LOAD_FIELD_STRING and
BYTECODE_OP_LOAD_FIELD_SEQUENCE were leaving the "user" attribute
uninitialized. Initialize those to 0.

The handling of userspace strings and integers is missing in LOAD_FIELD
instructions. Therefore, ensure that the specialization leaves the
generic LOAD_FIELD instruction in place for userspace input.

Add a "user" attribute to:
- struct bytecode_get_index_data elem field (produced by the
  specialization),
- struct vstack_load used by the specialization,
- struct load_ptr used by the interpreter.

Use this "user" attribute in dynamic_load_field() for integer, string
and string_sequence object types to ensure that the proper
userspace-aware accesses are performed when loading those fields.

This prevents events with userspace input arguments (e.g. pipe2 system
call fildes field) from oopsing the kernel or reading arbitrary kernel
memory when used by the filter bytecode.

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

bytecode: propagate `rev_bo` of element

When specializing and executing bytecode.

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

Fix: bytecode interpreter context_get_index() leaves byte order uninitialized

Within the bytecode interpreter, context_get_index() leaves the "rev_bo"
field uninitialized in the top of stack.

Initialize the rev_bo field based on the context field type
reserve_byte_order field.

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

Fix: move "user" attribute from field to type

The "user" field attribute (copy from userspace) is not taken into
account in the bytecode specialization and interpreter recursive
traversal through composed types (LOAD_FIELD bytecode instructions).

Those are currently used by the filter expressions which access fields
nested within composed types.

Move the "user" attribute from the event fields to the integer and
string types. This will allow ensuring that the bytecode specialization
and interpreter have access to this user attribute even in nested types
(e.g. arrays, sequences) in a subsequent change.

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

Introduce lttng_copy_from_user_check_nofault

This code will be re-used by the bytecode interpreter, so move it out of
the ring buffer.

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

wrapper: powerpc64: fix kernel crash caused by do_get_kallsyms

Kernel crashes on powerpc64 ABIv2 as follow when lttng_tracer initializes,
since do_get_kallsyms in lttng_wrapper fails to return a proper address of
kallsyms_lookup_name.

root@qemuppc64:~# lttng create trace_session --live -U net://127.0.0.1
Spawning a session daemon
lttng_kretprobes: loading out-of-tree module taints kernel.
BUG: Unable to handle kernel data access on read at 0xfffffffffffffff8
Faulting instruction address: 0xc0000000001f6fd0
Oops: Kernel access of bad area, sig: 11 [#1]
<snip>
NIP [c0000000001f6fd0] module_kallsyms_lookup_name+0xf0/0x180
LR [c0000000001f6f28] module_kallsyms_lookup_name+0x48/0x180
Call Trace:
module_kallsyms_lookup_name+0x34/0x180 (unreliable)
kallsyms_lookup_name+0x258/0x2b0
wrapper_kallsyms_lookup_name+0x4c/0xd0 [lttng_wrapper]
wrapper_get_pfnblock_flags_mask_init+0x28/0x60 [lttng_wrapper]
lttng_events_init+0x40/0x344 [lttng_tracer]
do_one_initcall+0x78/0x340
do_init_module+0x6c/0x2f0
__do_sys_finit_module+0xd0/0x120
system_call_exception+0x194/0x2f0
system_call_vectored_common+0xe8/0x278
<snip>

do_get_kallsyms makes use of kprobe_register and in turn kprobe_lookup_name
to get the address of the kernel function kallsyms_lookup_name. In case of
PPC64_ELF_ABI_v2, when kprobes are placed at function entry,
kprobe_lookup_name adjusts the global entry point of the function returned
by kallsyms_lookup_name to the local entry point(at some fixed offset of
global one). This adjustment is all for kprobes to be able to work properly.
Global and local entry point are defined in powerpc64 ABIv2.

When the local entry point is given, some instructions at the beginning of
the function are skipped and thus causes the above kernel crash. We just
want to make a simple function call which needs global entry point.

This patch adds 4 bytes which is the length of one instruction to
kallsyms_lookup_name so that it will not trigger the global to local
adjustment, and then substracts 4 bytes from the returned address. See the
following kernel change for more details.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290e3070762ac80e5fc4087d8c4de7e3f1d90aca

Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I34e68e886b97e3976d0b5e25be295a8bb866c1a4

fix: adjust range v5.10.137 in block probe

See upstream commit, backported in v5.10.137 :

commit 1cb3032406423b25aa984854b4d78e0100d292dd
Author: Christoph Hellwig <hch@lst.de>
Date:   Thu Dec 3 17:21:39 2020 +0100

    block: remove the request_queue to argument request based tracepoints

    [ Upstream commit a54895fa057c67700270777f7661d8d3c7fda88a ]

    The request_queue can trivially be derived from the request.

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

Version 2.12.10

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

Fix: stub prototypes with extra semicolons when CONFIG_HAVE_SYSCALL_TRACEPOINTS=n

The stub prototypes have extra erroneous semicolons. This has been fixed
by a refactoring in the master branch:

commit f2db8be348380b48e3795d14e49cc585b3c357fd
Author: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date:   Mon Nov 1 15:14:44 2021 -0400

    Cleanup: syscall filter enable/disable event

Fixes: #1357
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I23fa8fea006b49ae47a9a6c30c6ca5ff330d5734

fix: tie compaction probe build to CONFIG_COMPACTION

The definition of 'struct compact_control' in 'mm/internal.h' depends on
CONFIG_COMPACTION being defined. Only build the compaction probe when
this configuration option is enabled.

Thanks to Bruce Ashfield <bruce.ashfield@gmail.com> for reporting this
issue.

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

fix: net: skb: introduce kfree_skb_reason() (v5.15.58..v5.16)

See upstream commit :

  commit c504e5c2f9648a1e5c2be01e8c3f59d394192bd3
  Author: Menglong Dong <imagedong@tencent.com>
  Date:   Sun Jan 9 14:36:26 2022 +0800

    net: skb: introduce kfree_skb_reason()

    Introduce the interface kfree_skb_reason(), which is able to pass
    the reason why the skb is dropped to 'kfree_skb' tracepoint.

    Add the 'reason' field to 'trace_kfree_skb', therefor user can get
    more detail information about abnormal skb with 'drop_monitor' or
    eBPF.

    All drop reasons are defined in the enum 'skb_drop_reason', and
    they will be print as string in 'kfree_skb' tracepoint in format
    of 'reason: XXX'.

    ( Maybe the reasons should be defined in a uapi header file, so that
    user space can use them? )

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

Version 2.12.9

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

fix: 'random' tracepoints removed in stable kernels

The upstream commit 14c174633f349cb41ea90c2c0aaddac157012f74 removing
the 'random' tracepoints is being backported to multiple stable kernel
branches, I don't see how that qualifies as a fix but here we are.

Use the presence of 'include/trace/events/random.h' in the kernel source
tree instead of the rather tortuous version check to determine if we
need to build 'lttng-probe-random.ko'.

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

fix: random: remove unused tracepoints (v5.10, v5.15)

The following kernel commit has been back ported to v5.10.119 and v5.15.44.

commit 14c174633f349cb41ea90c2c0aaddac157012f74
Author: Jason A. Donenfeld <Jason@zx2c4.com>
Date:   Thu Feb 10 16:40:44 2022 +0100

  random: remove unused tracepoints

  These explicit tracepoints aren't really used and show sign of aging.
  It's work to keep these up to date, and before I attempted to keep them
  up to date, they weren't up to date, which indicates that they're not
  really used. These days there are better ways of introspecting anyway.

Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I0b7eb8aa78b5bd2039e20ae3e1da4c5eb9018789

fix: random: remove unused tracepoints (v5.18)

See upstream commit :

  commit 14c174633f349cb41ea90c2c0aaddac157012f74
  Author: Jason A. Donenfeld <Jason@zx2c4.com>
  Date:   Thu Feb 10 16:40:44 2022 +0100

    random: remove unused tracepoints

    These explicit tracepoints aren't really used and show sign of aging.
    It's work to keep these up to date, and before I attempted to keep them
    up to date, they weren't up to date, which indicates that they're not
    really used. These days there are better ways of introspecting anyway.

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

Document supported kernel versions for stable-2.12 branch

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

Fix: include erroneously removed by backport

commit ad5e2bb2 ("Fix: tracepoint event: allow same provider and event name")
erroneously removes an include from the tracepoint event header. This
issue crept into the cherry-pick of the patch into the stable-2.12
branch.

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

Fix: tracepoint event: allow same provider and event name

Using the same name for the provider (TRACE_SYSTEM) and event name
causes a compilation error because the same identifiers are emitted
twice.

Fix this by prefixing the provider identifier with
"__provider_event_desc___".

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

Fix: compaction migratepages event name

The commit "fix: mm: compaction: fix the migration stats in trace_mm_compaction_migratepages() (v5.17)"

Triggers this warning:

    LTTng: event provider mismatch: The event name needs to start with provider name + _ + one or more letter, provider: compaction, event name: mm_compaction_migratepages

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

Version 2.12.8

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

Document expected ISO8601 time formats in ABI header

Document the expected ISO8601 time formats in the ABI header to justify
the choice of string maximum length.

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

fix: net: socket: rename SKB_DROP_REASON_SOCKET_FILTER (v5.17)

No version check needed since this change is between two RCs, see
upstream commit :

  commit 364df53c081d93fcfd6b91085ff2650c7f17b3c7
  Author: Menglong Dong <imagedong@tencent.com>
  Date:   Thu Jan 27 17:13:01 2022 +0800

    net: socket: rename SKB_DROP_REASON_SOCKET_FILTER

    Rename SKB_DROP_REASON_SOCKET_FILTER, which is used
    as the reason of skb drop out of socket filter before
    it's part of a released kernel. It will be used for
    more protocols than just TCP in future series.

Link: https://lore.kernel.org/all/20220127091308.91401-2-imagedong@tencent.com/
Change-Id: I666461a5b541fe9e0bf53ad996ce33237af4bfbb
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

fix: net: skb: introduce kfree_skb_reason() (v5.17)

See upstream commit :

  commit c504e5c2f9648a1e5c2be01e8c3f59d394192bd3
  Author: Menglong Dong <imagedong@tencent.com>
  Date:   Sun Jan 9 14:36:26 2022 +0800

    net: skb: introduce kfree_skb_reason()

    Introduce the interface kfree_skb_reason(), which is able to pass
    the reason why the skb is dropped to 'kfree_skb' tracepoint.

    Add the 'reason' field to 'trace_kfree_skb', therefor user can get
    more detail information about abnormal skb with 'drop_monitor' or
    eBPF.

    All drop reasons are defined in the enum 'skb_drop_reason', and
    they will be print as string in 'kfree_skb' tracepoint in format
    of 'reason: XXX'.

    ( Maybe the reasons should be defined in a uapi header file, so that
    user space can use them? )

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

fix: random: rather than entropy_store abstraction, use global (v5.17)

See upstream commit :

  commit 90ed1e67e896cc8040a523f8428fc02f9b164394
  Author: Jason A. Donenfeld <Jason@zx2c4.com>
  Date:   Wed Jan 12 17:18:08 2022 +0100

    random: rather than entropy_store abstraction, use global

    Originally, the RNG used several pools, so having things abstracted out
    over a generic entropy_store object made sense. These days, there's only
    one input pool, and then an uneven mix of usage via the abstraction and
    usage via &input_pool. Rather than this uneasy mixture, just get rid of
    the abstraction entirely and have things always use the global. This
    simplifies the code and makes reading it a bit easier.

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

fix: btrfs: pass fs_info to trace_btrfs_transaction_commit (v5.17)

See upstream commit :

  commit 2e4e97abac4c95f8b87b2912ea013f7836a6f10b
  Author: Josef Bacik <josef@toxicpanda.com>
  Date:   Fri Nov 5 16:45:29 2021 -0400

    btrfs: pass fs_info to trace_btrfs_transaction_commit

    The root on the trans->root can be anything, and generally we're
    committing from the transaction kthread so it's usually the tree_root.
    Change this to just take an fs_info, and to maintain compatibility
    simply put the ROOT_TREE_OBJECTID as the root objectid for the
    tracepoint.  This will allow use to remove trans->root.

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

fix: mm: compaction: fix the migration stats in trace_mm_compaction_migratepages() (v5.17)

See upstream commit :

  commit 84b328aa81216e08804d8875d63f26bda1298788
  Author: Baolin Wang <baolin.wang@linux.alibaba.com>
  Date:   Fri Jan 14 14:08:40 2022 -0800

    mm: compaction: fix the migration stats in trace_mm_compaction_migratepages()

    Now the migrate_pages() has changed to return the number of {normal
    page, THP, hugetlb} instead, thus we should not use the return value to
    calculate the number of pages migrated successfully.  Instead we can
    just use the 'nr_succeeded' which indicates the number of normal pages
    migrated successfully to calculate the non-migrated pages in
    trace_mm_compaction_migratepages().

Link: https://lkml.kernel.org/r/b4225251c4bec068dcd90d275ab7de88a39e2bd7.1636275127.git.baolin.wang@linux.alibaba.com
Change-Id: Ib8e8f2a16a273f16cd73fe63afbbfc25c0a2540c
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

fix: block: remove the ->rq_disk field in struct request (v5.17)

See upstream commit :

  commit f3fa33acca9f0058157214800f68b10d8e71ab7a
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Fri Nov 26 13:18:00 2021 +0100

    block: remove the ->rq_disk field in struct request

    Just use the disk attached to the request_queue instead.

Link: https://lore.kernel.org/r/20211126121802.2090656-4-hch@lst.de
Change-Id: I24263be519d1b51f4b00bd95f14a9aeb8457889a
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

fix: block: remove GENHD_FL_SUPPRESS_PARTITION_INFO (v5.17)

See upstream commit :

  commit 3b5149ac50970669ee0ddb9629ec77ffd5c0622d
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Mon Nov 22 14:06:21 2021 +0100

    block: remove GENHD_FL_SUPPRESS_PARTITION_INFO

    This flag is not set directly anywhere and only inherited from
    GENHD_FL_HIDDEN.  Just check for GENHD_FL_HIDDEN instead.

Link: https://lore.kernel.org/r/20211122130625.1136848-11-hch@lst.de
Change-Id: Ide92bdaaff7d16e96be23aaf00cebeaa601235b7
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

Copyright ownership transfer

Apply copyright ownership transfer from Julien Desfossez to EfficiOS Inc.

Link: https://lists.lttng.org/pipermail/lttng-dev/2022-January/030092.html
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Julien Desfossez <ju@klipix.org>
Signed-off-by: Julien Desfossez <ju@klipix.org>
Change-Id: Ida168b1fbe6589cb371a549ef14d9b4b28b221b3

Version 2.12.7

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

fix: mm: move kvmalloc-related functions to slab.h (v5.16)

See upstream commit :

  commit 8587ca6f34152ea650bad4b2db68456601159024
  Author: Matthew Wilcox (Oracle) <willy@infradead.org>
  Date:   Fri Nov 5 13:35:07 2021 -0700

    mm: move kvmalloc-related functions to slab.h

    Not all files in the kernel should include mm.h.  Migrating callers from
    kmalloc to kvmalloc is easier if the kvmalloc functions are in slab.h.

    [akpm@linux-foundation.org: move the new kvrealloc() also]
    [akpm@linux-foundation.org: drivers/hwmon/occ/p9_sbe.c needs slab.h]

Link: https://lkml.kernel.org/r/20210622215757.3525604-1-willy@infradead.org
Change-Id: I84e885ffbd1e2ff551a4738950e0c9462551b853
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

fix: block: don't call blk_status_to_errno in blk_update_request (v5.16)

See upstream commit :

  commit 8a7d267b4a2c71a5ff5dd9046abea7117c7d0ac2
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Mon Oct 18 10:45:18 2021 +0200

    block: don't call blk_status_to_errno in blk_update_request

    We only need to call it to resolve the blk_status_t -> errno mapping for
    tracing, so move the conversion into the tracepoints that are not called
    at all when tracing isn't enabled.

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

fix: KVM: MMU: change tracepoints arguments to kvm_page_fault (v5.16)

See upstream commit :

  commit f0066d94c92dc5cf7f1a272a1bd324b0fc575292
  Author: Paolo Bonzini <pbonzini@redhat.com>
  Date:   Fri Aug 6 04:35:50 2021 -0400

    KVM: MMU: change tracepoints arguments to kvm_page_fault

    Pass struct kvm_page_fault to tracepoints instead of extracting the
    arguments from the struct.  This also lets the kvm_mmu_spte_requested
    tracepoint pick the gfn directly from fault->gfn, instead of using
    the address.

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

fix: KVM: x86: Get exit_reason as part of kvm_x86_ops.get_exit_info (v5.16)

See upstream commit :

  commit 0a62a0319abb92c89a4f91c2dbfcaee4e47f37ca
  Author: David Edmondson <david.edmondson@oracle.com>
  Date:   Mon Sep 20 11:37:35 2021 +0100

    KVM: x86: Get exit_reason as part of kvm_x86_ops.get_exit_info

    Extend the get_exit_info static call to provide the reason for the VM
    exit. Modify relevant trace points to use this rather than extracting
    the reason in the caller.

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

fix: isystem: delete global -isystem compile option (v5.16)

See upstream commit :

  commit 04e85bbf71c9072dcf0ad9a7150495d72461105c
  Author: Alexey Dobriyan <adobriyan@gmail.com>
  Date:   Mon Aug 2 23:43:15 2021 +0300

    isystem: delete global -isystem compile option

    Further isolate kernel from userspace, prevent accidental inclusion of
    undesireable headers, mainly float.h and stdatomic.h.

    nds32 keeps -isystem globally due to intrinsics used in entrenched header.

    -isystem is selectively reenabled for some files, again, for intrinsics.

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

fix: block: move block-related definitions out of fs.h (v5.16)

See upstream commit :

  commit 3f1266f1f82d7b8c72472a8921e80aa3e611fb62
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Sat Jun 20 09:16:41 2020 +0200

    block: move block-related definitions out of fs.h

    Move most of the block related definition out of fs.h into more suitable
    headers.

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

fix: implicit-int error in EXPORT_SYMBOL_GPL

Add module header to fix error:
error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
[-Werror=implicit-int]

Log:
/workdir/build/workspace/sources/lttng-modules/src/wrapper/random.c:54:1:
warning: data definition has no type or storage class
   54 EXPORT_SYMBOL_GPL(wrapper_get_bootid);
      ^~~~~~~~~~~~~~~~~
/workdir/build/workspace/sources/lttng-modules/src/wrapper/random.c:54:1:
error: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL'
[-Werror=implicit-int]
/workdir/build/workspace/sources/lttng-modules/src/wrapper/random.c:54:1:
warning: parameter names (without types) in function declaration
cc1: some warnings being treated as errors
make[3]: ***
[/workdir/build/tmp/work-shared/qt5222/kernel-source/scripts/Makefile.build:271:
/workdir/build/workspace/sources/lttng-modules/src/wrapper/random.o]

Signed-off-by: Daniel Gomez <daniel@qtec.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: If1b96f6fcc19988b94dc09b12d071f2c61491b83

fix: Revert "Makefile: Enable -Wimplicit-fallthrough for Clang" (v5.15)

Starting with v5.15, "-Wimplicit-fallthrough=5" was added to the build
flags which requires the use of "__attribute__((__fallthrough__))" to
annotate fallthrough case statements.

See upstream commit by the man himself:

  commit d936eb23874433caa3e3d841cfa16f5434b85dcf
  Author: Linus Torvalds <torvalds@linux-foundation.org>
  Date:   Thu Jul 15 18:05:31 2021 -0700

    Revert "Makefile: Enable -Wimplicit-fallthrough for Clang"

    This reverts commit b7eb335e26a9c7f258c96b3962c283c379d3ede0.

    It turns out that the problem with the clang -Wimplicit-fallthrough
    warning is not about the kernel source code, but about clang itself, and
    that the warning is unusable until clang fixes its broken ways.

    In particular, when you enable this warning for clang, you not only get
    warnings about implicit fallthroughs.  You also get this:

       warning: fallthrough annotation in unreachable code [-Wimplicit-fallthrough]

    which is completely broken becasue it

     (a) doesn't even tell you where the problem is (seriously: no line
         numbers, no filename, no nothing).

     (b) is fundamentally broken anyway, because there are perfectly valid
         reasons to have a fallthrough statement even if it turns out that
         it can perhaps not be reached.

    In the kernel, an example of that second case is code in the scheduler:

                    switch (state) {
                    case cpuset:
                            if (IS_ENABLED(CONFIG_CPUSETS)) {
                                    cpuset_cpus_allowed_fallback(p);
                                    state = possible;
                                    break;
                            }
                            fallthrough;
                    case possible:

    where if CONFIG_CPUSETS is enabled you actually never hit the
    fallthrough case at all.  But that in no way makes the fallthrough
    wrong.

    So the warning is completely broken, and enabling it for clang is a very
    bad idea.

    In the meantime, we can keep the gcc option enabled, and make the gcc
    build use

        -Wimplicit-fallthrough=5

    which means that we will at least continue to require a proper
    fallthrough statement, and that gcc won't silently accept the magic
    comment versions. Because gcc does this all correctly, and while the odd
    "=5" part is kind of obscure, it's documented in [1]:

      "-Wimplicit-fallthrough=5 doesn’t recognize any comments as
       fallthrough comments, only attributes disable the warning"

    so if clang ever fixes its bad behavior we can try enabling it there again.

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

fix: cpu/hotplug: Remove deprecated CPU-hotplug functions. (v5.15)

The CPU-hotplug functions get|put_online_cpus() were deprecated in v4.13
and removed in v5.15.

See upstream commits :

commit 8c854303ce0e38e5bbedd725ff39da7e235865d8
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date:   Tue Aug 3 16:16:21 2021 +0200

    cpu/hotplug: Remove deprecated CPU-hotplug functions.

    No users in tree use the deprecated CPU-hotplug functions anymore.

    Remove them.

Introduced in v4.13 :

  commit 8f553c498e1772cccb39a114da4a498d22992758
  Author: Thomas Gleixner <tglx@linutronix.de>
  Date:   Wed May 24 10:15:12 2017 +0200

    cpu/hotplug: Provide cpus_read|write_[un]lock()

    The counting 'rwsem' hackery of get|put_online_cpus() is going to be
    replaced by percpu rwsem.

    Rename the functions to make it clear that it's locking and not some
    refcount style interface. These new functions will be used for the
    preparatory patches which make the code ready for the percpu rwsem
    conversion.

    Rename all instances in the cpu hotplug code while at it.

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

fix: sched: Change task_struct::state (v5.14)

See upstream commit:

  commit 2f064a59a11ff9bc22e52e9678bc601404c7cb34
  Author: Peter Zijlstra <peterz@infradead.org>
  Date:   Fri Jun 11 10:28:17 2021 +0200

    sched: Change task_struct::state

    Change the type and name of task_struct::state. Drop the volatile and
    shrink it to an 'unsigned int'. Rename it in order to find all uses
    such that we can use READ_ONCE/WRITE_ONCE as appropriate.

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

fix: btrfs: pass btrfs_inode to btrfs_writepage_endio_finish_ordered() (v5.14)

See upstream commit:

  commit 38a39ac77e089515acbe85c6c70c3df1e728357d
  Author: Qu Wenruo <wqu@suse.com>
  Date:   Thu Apr 8 20:32:27 2021 +0800

    btrfs: pass btrfs_inode to btrfs_writepage_endio_finish_ordered()

    There is a pretty bad abuse of btrfs_writepage_endio_finish_ordered() in
    end_compressed_bio_write().

    It passes compressed pages to btrfs_writepage_endio_finish_ordered(),
    which is only supposed to accept inode pages.

    Thankfully the important info here is the inode, so let's pass
    btrfs_inode directly into btrfs_writepage_endio_finish_ordered(), and
    make @page parameter optional.

    By this, end_compressed_bio_write() can happily pass page=NULL while
    still getting everything done properly.

    Also, to cooperate with such modification, replace @page parameter for
    trace_btrfs_writepage_end_io_hook() with btrfs_inode.
    Although this removes page_index info, the existing start/len should be
    enough for most usage.

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

fix: adjust ranges for RHEL 8.4

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

Version 2.12.6

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

fix: adjust ranges for RHEL 8.2 and 8.3

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

Disable block rwbs bitwise enum in default build

Only generate the bitwise enumerations when
CONFIG_LTTNG_EXPERIMENTAL_BITWISE_ENUM is enabled, so the default build
does not generate traces which lead to warnings when viewed with
babeltrace 1.x and babeltrace 2 with default options.

Original commit:

  commit 23634515e7271c8c8594ad87a6685232d4eff297
  Author: Geneviève Bastien <gbastien@versatic.net>
  Date:   Tue Feb 11 11:20:27 2020 -0500

    block: Make the rwbs field as a bit field enum

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

Disable sched_switch bitwise enum in default build

Only generate the bitwise enumerations when
CONFIG_LTTNG_EXPERIMENTAL_BITWISE_ENUM is enabled, so the default build
does not generate traces which lead to warnings when viewed with
babeltrace 1.x and babeltrace 2 with default options.

Original commit:

  commit 721caea47b6506f7ad9086c3e9801dc9dfe06b6a
  Author: Geneviève Bastien <gbastien@versatic.net>
  Date:   Wed Feb 12 16:58:25 2020 -0500

    sched: Make the sched_switch task state an enum

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

Add experimental bitwise enum config option

Only generate the bitwise enumerations when
CONFIG_LTTNG_EXPERIMENTAL_BITWISE_ENUM is enabled, so the default build
does not generate traces which lead to warnings when viewed with
babeltrace 1.x and babeltrace 2 with default options.

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

Add defaults to Kconfig options

Add defaults to the Kconfig options used when building in-tree that
match the default configuration when built out-of-tree.

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

Sync `show_inode_state()` macro with upstream stable kernels

The following commit was backported to multiple stable branches:

  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.

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

fix: block: remove disk_part_iter (v5.12)

In v5.12 a refactoring of the genhd code was started and the symbols
related to 'disk_part_iter' were unexported. In v5.13 they were
completely removed.

This patch replaces the short lived compat code that is specific to
v5.12 and replaces it with a generic internal implementation that
iterates directly on the 'disk->part_tbl' xarray which will be used
on v5.12 and up.

This seems like a better option than keeping the compat code that will
only work on v5.12 and make maintenance more complicated. The compat was
backported to the stable branches but isn't yet part of a point release
so can be safely replaced.

See the upstream commits:

  commit 3212135a718b06be38811f2d9a320ae842e76409
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Tue Apr 6 08:23:02 2021 +0200

    block: remove disk_part_iter

    Just open code the xa_for_each in the remaining user.

  commit a33df75c6328bf40078b35f2040d8e54d574c357
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Sun Jan 24 11:02:41 2021 +0100

    block: use an xarray for disk->part_tbl

    Now that no fast path lookups in the partition table are left, there is
    no point in micro-optimizing the data structure for it.  Just use a bog
    standard xarray.

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

Fix: Backport of "Fix: increment buffer offset when failing to copy from user-space"

Private field was introduced in 2.13 only.

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

Fix: increment buffer offset when failing to copy from user-space

Upon failure to copy from user-space due to failing access ok check, the
ring buffer offset is not incremented, which could generate unreadable
traces because we don't account for the padding we write into the ring
buffer.

Note that this typically won't affect a common use-case of copying
strings from user-space, because unless mprotect is invoked within a
narrow race window (between user strlen and user strcpy), the strlen
will fail on access ok when calculating the space to reserve, which will
match what happens on strcpy.

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

Sync `show_inode_state()` macro with Ubuntu 4.15 kernel

The following commit changed the `show_inode_state()` macro which
triggered a warning on our CI build:
  commit 63388062bea96e5cd8b8d7abf7b7142f8666ca1f
  Author: Jan Kara <jack@suse.cz>
  Date:   Mon Jan 25 12:37:43 2021 -0800

      writeback: Drop I_DIRTY_TIME_EXPIRE

Also, this commit adds a comment to clarify why we keep these
`#if/#elif` even though we don't use it the macro.

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I2dd53a1a286ab8a431977bda6cde01f700f0c7d9

fix: mm, tracing: kfree event name mismatching with provider kmem (v5.12)

a8bc8ae5c932 ("fix: mm, tracing: record slab name for kmem_cache_free() (v5.12)")
introduces the following call trace for kfree. This is caused by mismatch
between kfree event and its provider kmem.

This patch maps kfree to kmem_kfree.

WARNING: CPU: 2 PID: 42294 at src/lttng-probes.c:81 fixup_lazy_probes+0xb0/0x1b0 [lttng_tracer]
CPU: 2 PID: 42294 Comm: modprobe Tainted: G           O      5.12.0-rc6-yoctodev-standard #1
Hardware name: Intel Corporation JACOBSVILLE/JACOBSVILLE, BIOS JBVLCRB2.86B.0014.P20.2004020248 04/02/2020
RIP: 0010:fixup_lazy_probes+0xb0/0x1b0 [lttng_tracer]
Code: 75 28 83 c3 01 3b 5d c4 74 22 48 8b 4d d0 48 63
      c3 4c 89 e2 4c 89 f6 48 8b 04 c1 4c 8b 38 4c 89
      ff e8 64 9f 4b de 85 c0 74 c3 <0f> 0b 48 8b 05 bf
      f2 1e 00 48 8d 50 e8 48 3d f0 a0 98 c0 75 18 eb
RSP: 0018:ffffb976807bfbe0 EFLAGS: 00010286
RAX: 00000000ffffffff RBX: 0000000000000004 RCX: 0000000000000004
RDX: 0000000000000066 RSI: ffffffffc03c10a7 RDI: ffffffffc03c11a1
RBP: ffffb976807bfc28 R08: 0000000000000000 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000004
R13: ffffffffc03c2000 R14: ffffffffc03c10a7 R15: ffffffffc03c11a1
FS:  00007f0ef9533740(0000) GS:ffffa100faa00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000561e8f0aa000 CR3: 000000015b318000 CR4: 0000000000350ee0
Call Trace:
 lttng_probe_register+0x38/0xe0 [lttng_tracer]
 ? __event_probe__module_load+0x520/0x520 [lttng_probe_module]
 __lttng_events_init__module+0x15/0x20 [lttng_probe_module]
 do_one_initcall+0x68/0x310
 ? kmem_cache_alloc_trace+0x2ad/0x4c0
 ? do_init_module+0x28/0x280
 do_init_module+0x62/0x280
 load_module+0x26e4/0x2920
 ? kernel_read_file+0x22e/0x290
 __do_sys_finit_module+0xb1/0xf0
 __x64_sys_finit_module+0x1a/0x20
 do_syscall_64+0x38/0x50
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I00e8ee2b8c35f6f8602c88295f5113fbbd139709

Set 'stable-2.12' branch in git review config

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

fix backport: block: add a disk_uevent helper (v5.12)

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

fix: Adjust ranges for Ubuntu 5.4.0-67 kernel

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

fix: block: add a disk_uevent helper (v5.12)

See upstream commit:

  commit bc359d03c7ec1bf3b86d03bafaf6bbb21e6414fd
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Sun Jan 24 11:02:39 2021 +0100

    block: add a disk_uevent helper

    Add a helper to call kobject_uevent for the disk and all partitions, and
    unexport the disk_part_iter_* helpers that are now only used in the core
    block code.

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

Fix: properly compare type enumeration

Fixes: fead3a9cead4 ("Fix: bytecode linker: validate event and field array/sequence encoding")
Fixes: #1304
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I9b5e3df5415d56420365997ce289be7e02a0140e

compiler warning cleanup: is_signed_type: compare -1 to 1

Comparing -1 to 0 triggers compiler warnings (gcc -Wtype-limits and
-Wbool-compare) and Coverity warning "Macro compares unsigned to 0".

Comparing -1 to 1 instead takes care of silencing those warnings while
keeping the same behavior.

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

Fix: bytecode linker: validate event and field array/sequence encoding

The bytecode linker should only allow linking filter expressions loading
fields which are string-encoded arrays and sequence for comparison
against a string, and reject arrays and sequences without encoding, so
the filter interpreter does not attempt to load non-NULL terminated
arrays/sequences as if they were strings.

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

Fix: kretprobe: null ptr deref on session destroy

The `filter_bytecode_runtime_head` list is currently not initialized for
the return event of the kretprobe. This caused a kernel null ptr
dereference when destroying a session. It can reproduced with the
following commands:

  lttng create
  lttng enable-event -k --function=lttng_test_filter_event_write my_event
  lttng start
  lttng stop
  lttng destroy

Signed-off-by: Francis Deslauriers <francis.deslauriers@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I1162ce8b10dd7237a26331531f048346b984eee7

fix: mm, tracing: record slab name for kmem_cache_free() (v5.12)

See upstream commit:

  commit 3544de8ee6e4817278b15fe08658de49abf58954
  Author: Jacob Wen <jian.w.wen@oracle.com>
  Date:   Wed Feb 24 12:00:55 2021 -0800

    mm, tracing: record slab name for kmem_cache_free()

    Currently, a trace record generated by the RCU core is as below.

    ... kmem_cache_free: call_site=rcu_core+0x1fd/0x610 ptr=00000000f3b49a66

    It doesn't tell us what the RCU core has freed.

    This patch adds the slab name to trace_kmem_cache_free().
    The new format is as follows.

    ... kmem_cache_free: call_site=rcu_core+0x1fd/0x610 ptr=0000000037f79c8d name=dentry
    ... kmem_cache_free: call_site=rcu_core+0x1fd/0x610 ptr=00000000f78cb7b5 name=sock_inode_cache
    ... kmem_cache_free: call_site=rcu_core+0x1fd/0x610 ptr=0000000018768985 name=pool_workqueue
    ... kmem_cache_free: call_site=rcu_core+0x1fd/0x610 ptr=000000006a6cb484 name=radix_tree_node

    We can use it to understand what the RCU core is going to free. For
    example, some users maybe interested in when the RCU core starts
    freeing reclaimable slabs like dentry to reduce memory pressure.

Link: https://lkml.kernel.org/r/20201216072804.8838-1-jian.w.wen@oracle.com
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I1ee2fc476614cadcc8d3ac5d8feddc7910e1aa3a

Fix: filter interpreter early-exits on uninitialized value

I observed that syscall filtering on string arguments wouldn't work on
my development machines, both running 5.11.2-arch1-1 (Arch Linux).

For instance, enabling the tracing of the `openat()` syscall with the
'filename == "/proc/cpuinfo"' filter would not produce events even
though matching events were present in another session that had no
filtering active. The same problem occurred with `execve()`.

I tried a couple of kernel versions before (5.11.1 and 5.10.13, if
memory serves me well) and I had the same problem. Meanwhile, I couldn't
reproduce the problem on various Debian machines (the LTTng CI) nor on a
fresh Ubuntu 20.04 with both the stock kernel and with an updated 5.11.2
kernel.

I built the lttng-modules with the interpreter debugging printout and
saw the following warning:
  LTTng: [debug bytecode in /home/jgalar/EfficiOS/src/lttng-modules/src/lttng-bytecode-interpreter.c:bytecode_interpret@1508] Bytecode warning: loading a NULL string.

After a shedload (yes, a _shed_load) of digging, I figured that the
problem was hidden in plain sight near that logging statement.

In the `BYTECODE_OP_LOAD_FIELD_REF_USER_STRING` operation, the 'ax'
register's 'user_str' is initialized with the stack value (the user
space string's address in our case). However, a NULL check is performed
against the register's 'str' member.

I initialy suspected that both members would be part of the same union
and alias each-other, but they are actually contiguous in a structure.

On the unaffected machines, I could confirm that the `str` member was
uninitialized to a non-zero value causing the condition to evaluate to
false.

Francis Deslauriers reproduced the problem by initializing the
interpreter stack to zero.

I am unsure of the exact kernel configuration option that reveals this
issue on Arch Linux, but my kernel has the following option enabled:

CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL:
   Zero-initialize any stack variables that may be passed by reference
   and had not already been explicitly initialized. This is intended to
   eliminate all classes of uninitialized stack variable exploits and
   information exposures.

I have not tried to build without this enabled as, anyhow, this seems
to be a legitimate issue.

I have spotted what appears to be an identical problem in
`BYTECODE_OP_LOAD_FIELD_REF_USER_SEQUENCE` and corrected it. However,
I have not exercised that code path.

The commit that introduced this problem is 5b4ad89.

The debug print-out of the `BYTECODE_OP_LOAD_FIELD_REF_USER_STRING`
operation is modified to print the user string (truncated to 31 chars).

Signed-off-by: Jérémie Galarneau <jeremie.galarneau@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I2da3c31b9e3ce0e1b164cf3d2711c0893cbec273

Fix: memory leaks on event destroy

Both filter runtime and event enabler ref objects are owned by the
event, but are not freed upon destruction of the event object, thus
leaking memory.

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

Version 2.12.5

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

fix: Adjust ranges for Ubuntu 5.8.0-44 kernel

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

fix: missing include for 'task_struct' in fdtable.h

In some kernel versions, linux/fdtable.h dereferences a pointer in a
forward declared 'struct task_struct' without an include of 'linux/sched.h'.

Add this missing include to the wrapper.

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

fix: file: Rename fcheck lookup_fd_rcu (v5.11)

See upstream commit:

  commit 460b4f812a9d473d4b39d87d37844f9fc30a9eb3
  Author: Eric W. Biederman <ebiederm@xmission.com>
  Date:   Fri Nov 20 17:14:27 2020 -0600

    file: Rename fcheck lookup_fd_rcu

    Also remove the confusing comment about checking if a fd exists.  I
    could not find one instance in the entire kernel that still matches
    the description or the reason for the name fcheck.

    The need for better names became apparent in the last round of
    discussion of this set of changes[1].

    [1] https://lkml.kernel.org/r/CAHk-=wj8BQbgJFLa+J0e=iT-1qpmCRTbPAJ8gd6MJQ=kbRPqyQ@mail.gmail.com

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

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: Iac1572bde82541f4eeb18004534e750a53e90da8

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: I5d5811c06c45ee0877bdd47967453f467a09a3f6

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: If791cecf3ac8ceb2a4d0c2879410ae6b4199117d

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: I5af74cffe57cfe44c6e4a951c7a1270028650aa5

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: Id6046ac402b33c8aff577d66a7d68397a1f08d5c

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: Ie12dec7d2f28fc83343262f42680d42a2f40b59e

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: I2f6c13372e83564bd517c81ed7e2a696da8ee8ec

aarch64: blacklist gcc prior to 5.1

Linux aarch64 requires GCC 5.1 or better because prior versions perform
unsafe access to deallocated stack.

Some Linux distributions may have backported the fix, but it was never
released into earlier upstream gcc versions.

Link: https://lwn.net/Articles/842122/
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63293
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I72993e446f7f54f39d0f360273b68f194be8c13a

fix: genirq: Restrict export of irq_to_desc() (v5.11)

See upstream commit:

  commit 64a1b95bb9fe3ec76e1a2cd803eff06389341ae4
  Author: Thomas Gleixner <tglx@linutronix.de>
  Date:   Thu Dec 10 20:26:06 2020 +0100

    genirq: Restrict export of irq_to_desc()

    No more (ab)use in drivers finally. There is still the modular build of
    PPC/KVM which needs it, so restrict it to this case which still makes it
    unavailable for most drivers.

Link: https://lore.kernel.org/r/20201210194045.551428291@linutronix.de
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: Ie5a2af2f02ade07c73e1c7a8aa0fb155280b3d8b

fix: block: merge struct block_device and struct hd_struct (v5.11)

See upstream commit :

  commit 0d02129e76edf91cf04fabf1efbc3a9a1f1d729a
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Fri Nov 27 16:43:51 2020 +0100

    block: merge struct block_device and struct hd_struct

    Instead of having two structures that represent each block device with
    different life time rules, merge them into a single one.  This also
    greatly simplifies the reference counting rules, as we can use the inode
    reference count as the main reference count for the new struct
    block_device, with the device model reference front ending it for device
    model interaction.

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

fix: kprobes: Remove kretprobe hash (v5.11)

See upstream commit:

  commit d741bf41d7c7db4898bacfcb020353cddc032fd8
  Author: Peter Zijlstra <peterz@infradead.org>
  Date:   Sat Aug 29 22:03:24 2020 +0900

    kprobes: Remove kretprobe hash

    The kretprobe hash is mostly superfluous, replace it with a per-task
    variable.

    This gets rid of the task hash and it's related locking.

    Note that this may change the kprobes module-exported API for kretprobe
    handlers. If any out-of-tree kretprobe user uses ri->rp, use
    get_kretprobe(ri) instead.

Link: https://lore.kernel.org/r/159870620431.1229682.16325792502413731312.stgit@devnote2
Signed-off-by: Michael Jeanson <mjeanson@efficios.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Change-Id: I855765f390ad7caf481ef5fea334645e852f5b0f

fix: block: remove the request_queue argument to the block_bio_remap tracepoint (v5.11)

See upstream commit:

  commit 1c02fca620f7273b597591065d366e2cca948d8f
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Thu Dec 3 17:21:38 2020 +0100

    block: remove the request_queue argument to the block_bio_remap tracepoint

    The request_queue can trivially be derived from the bio.

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

fix: block: remove the request_queue argument to the block_split tracepoint (v5.11)

See upstream commit:

  commit eb6f7f7cd3af0f67ce57b21fab1bc64beb643581
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Thu Dec 3 17:21:37 2020 +0100

    block: remove the request_queue argument to the block_split tracepoint

    The request_queue can trivially be derived from the bio.

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

fix: block: simplify and extend the block_bio_merge tracepoint class (v5.11)

See upstream commit:

  commit e8a676d61c07eccfcd9d6fddfe4dcb630651c29a
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Thu Dec 3 17:21:36 2020 +0100

    block: simplify and extend the block_bio_merge tracepoint class

    The block_bio_merge tracepoint class can be reused for most bio-based
    tracepoints.  For that it just needs to lose the superfluous q and rq
    parameters.

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

fix: block: remove the request_queue to argument request based tracepoints (v5.11)

See upstream commit :

  commit a54895fa057c67700270777f7661d8d3c7fda88a
  Author: Christoph Hellwig <hch@lst.de>
  Date:   Thu Dec 3 17:21:39 2020 +0100

    block: remove the request_queue to argument request based tracepoints

    The request_queue can trivially be derived from the request.

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

Version 2.12.4

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

fix: adjust version range for trace_find_free_extent()

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

Improve the release script

  * Use git-archive, this removes all custom code to cleanup the repo, it
    can now be used in an unclean repo as the code will be exported from
    a specific tag.
  * Add parameters, this will allow using the script on any machine
    while keeping the default behavior for the maintainer.

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

Add release maintainer script

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

fix: statedump: undefined symbols caused by incorrect patch backport

bb346792c2cb ("fix: tracepoint: Optimize using static_call() (v5.10)")
misses three definitions and causes the following build failures.

ERROR: "__tracepoint_lttng_statedump_process_net_ns" [lttng-statedump.ko] undefined!
ERROR: "__tracepoint_lttng_statedump_process_user_ns" [lttng-statedump.ko] undefined!
ERROR: "__tracepoint_lttng_statedump_process_uts_ns" [lttng-statedump.ko] undefined!

Fixes: #1290
Signed-off-by: He Zhe <zhe.he@windriver.com>
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>

fix: include order for older kernels

Fixes a build failure on v3.0 and v3.1.

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

fix: tracepoint: Optimize using static_call() (v5.10)

See upstream commit :

  commit d25e37d89dd2f41d7acae0429039d2f0ae8b4a07
  Author: Steven Rostedt (VMware) <rostedt@goodmis.org>
  Date:   Tue Aug 18 15:57:52 2020 +0200

    tracepoint: Optimize using static_call()

    Currently the tracepoint site will iterate a vector and issue indirect
    calls to however many handlers are registered (ie. the vector is
    long).

    Using static_call() it is possible to optimize this for the common
    case of only having a single handler registered. In this case the
    static_call() can directly call this handler. Otherwise, if the vector
    is longer than 1, call a function that iterates the whole vector like
    the current code.

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

fix: KVM: x86/mmu: Return unique RET_PF_* values if the fault was fixed (v5.10)

See upstream commit :

  commit c4371c2a682e0da1ed2cd7e3c5496f055d873554
  Author: Sean Christopherson <sean.j.christopherson@intel.com>
  Date:   Wed Sep 23 15:04:24 2020 -0700

    KVM: x86/mmu: Return unique RET_PF_* values if the fault was fixed

    Introduce RET_PF_FIXED and RET_PF_SPURIOUS to provide unique return
    values instead of overloading RET_PF_RETRY.  In the short term, the
    unique values add clarity to the code and RET_PF_SPURIOUS will be used
    by set_spte() to avoid unnecessary work for spurious faults.

    In the long term, TDX will use RET_PF_FIXED to deterministically map
    memory during pre-boot.  The page fault flow may bail early for benign
    reasons, e.g. if the mmu_notifier fires for an unrelated address.  With
    only RET_PF_RETRY, it's impossible for the caller to distinguish between
    "cool, page is mapped" and "darn, need to try again", and thus cannot
    handle benign cases like the mmu_notifier retry.

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

fix: kvm: x86/mmu: Add TDP MMU PF handler (v5.10)

See upstream commit :

  commit bb18842e21111a979e2e0e1c5d85c09646f18d51
  Author: Ben Gardon <bgardon@google.com>
  Date:   Wed Oct 14 11:26:50 2020 -0700

    kvm: x86/mmu: Add TDP MMU PF handler

    Add functions to handle page faults in the TDP MMU. These page faults
    are currently handled in much the same way as the x86 shadow paging
    based MMU, however the ordering of some operations is slightly
    different. Future patches will add eager NX splitting, a fast page fault
    handler, and parallel page faults.

    Tested by running kvm-unit-tests and KVM selftests on an Intel Haswell
    machine. This series introduced no new failures.

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