lttng-modules:stable-2.11

Last commit made on 2021-07-13
Get this branch:
git clone -b stable-2.11 https://git.launchpad.net/lttng-modules

Branch merges

Branch information

Name:
stable-2.11
Repository:
lp:lttng-modules

Recent commits

9a8d7db... by Mathieu Desnoyers

Fix: Include correct header in backport of "fix: sched: Change task_struct::state (v5.14)"

Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: I1dad8c9f057886ef8b18c0a6b3407e2fd595473c

62c3d34... by Michael Jeanson <email address hidden>

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

See upstream commit:

  commit 2f064a59a11ff9bc22e52e9678bc601404c7cb34
  Author: Peter Zijlstra <email address hidden>
  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 <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

2d0b0a6... by Michael Jeanson <email address hidden>

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

See upstream commit:

  commit 38a39ac77e089515acbe85c6c70c3df1e728357d
  Author: Qu Wenruo <email address hidden>
  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 <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

0cc3c73... by Michael Jeanson <email address hidden>

fix: adjust ranges for RHEL 8.4

Change-Id: I9ac44467cca4850fb4051252937542d5a054ccc4
Signed-off-by: Michael Jeanson <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

eec5342... by Mathieu Desnoyers

Version 2.11.9

Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: I144be01dd9770e7aab485a84219c685da6cb2e67

46e6a93... by Michael Jeanson <email address hidden>

fix: adjust ranges for RHEL 8.2 and 8.3

Signed-off-by: Michael Jeanson <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: I0863ac030f9fdfeb0173b843e75396acda21f3b6

e71c0a4... by Michael Jeanson <email address hidden>

Sync `show_inode_state()` macro with upstream stable kernels

The following commit was backported to multiple stable branches:

  commit 5fcd57505c002efc5823a7355e21f48dd02d5a51
  Author: Jan Kara <email address hidden>
  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 <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>

7c05bae... by Michael Jeanson <email address hidden>

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 <email address hidden>
  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 <email address hidden>
  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 <email address hidden>
Signed-off-by: Mathieu Desnoyers <email address hidden>
Change-Id: I43d8ef8463cb7a83dc8859a32dc29502cd897ddf

7eb89c4... by Mathieu Desnoyers

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 <email address hidden>
Change-Id: I7af440269feda5500651d6ecdc1f63007910cf3d

72b1318... by Mathieu Desnoyers

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 <email address hidden>
Change-Id: Ic4d9487dd8870a526bae3023bb80f5e6301cec50