Prediction: How many reverts will 5.15.4 contain?

drumz · 11-18-2021, 01:12 PM

We need a distraction!

Here's a fun guessing game. How many reverts (including partial reverts) will Linux kernel 5.15.4 contain? 5.15.3 contains 920 patches.

The revert doesn't specifically have to be a patch in 5.15.3 (that will be too hard for me to count).

By my count 5.15.3 itself contains 9 reverts (selected by searching for "revert" in the Changelog and subjectively deciding if the commit message indicates whether or not the patch is a full or partial revert):

Code:

commit 3e1e7e4a6b54b9ed9a633a9faeb8f0dafd6dd7fb
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Jul 12 09:52:59 2021 -0400

    SUNRPC: Partial revert of commit 6f9f17287e78
    
    commit ea7a1019d8baf8503ecd6e3ec8436dec283569e6 upstream.
    
    The premise of commit 6f9f17287e78 ("SUNRPC: Mitigate cond_resched() in
    xprt_transmit()") was that cond_resched() is expensive and unnecessary
    when there has been just a single send.
    The point of cond_resched() is to ensure that tasks that should pre-empt
    this one get a chance to do so when it is safe to do so. The code prior
    to commit 6f9f17287e78 failed to take into account that it was keeping a
    rpc_task pinned for longer than it needed to, and so rather than doing a
    full revert, let's just move the cond_resched.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code:

commit ac8ffb5d9dfbdb965f72732a0e214cfcdc8eb44c
Author: Coly Li <colyli@suse.de>
Date:   Wed Nov 3 23:10:41 2021 +0800

    bcache: Revert "bcache: use bvec_virt"
    
    commit 2878feaed543c35f9dbbe6d8ce36fb67ac803eef upstream.
    
    This reverts commit 2fd3e5efe791946be0957c8e1eed9560b541fe46.
    
    The above commit replaces page_address(bv->bv_page) by bvec_virt(bv) to
    avoid directly access to bv->bv_page, but in situation bv->bv_offset is
    not zero and page_address(bv->bv_page) is not equal to bvec_virt(bv). In
    such case a memory corruption may happen because memory in next page is
    tainted by following line in do_btree_node_write(),
            memcpy(bvec_virt(bv), addr, PAGE_SIZE);
    
    This patch reverts the mentioned commit to avoid the memory corruption.
    
    Fixes: 2fd3e5efe791 ("bcache: use bvec_virt")
    Signed-off-by: Coly Li <colyli@suse.de>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: stable@vger.kernel.org # 5.15
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Link: https://lore.kernel.org/r/20211103151041.70516-1-colyli@suse.de
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code:

commit 97308cd5ce8edc466a2eed1bb31fd81a088ed54d
Author: Fabio Estevam <festevam@gmail.com>
Date:   Wed Nov 3 21:11:12 2021 -0300

    Revert "drm/imx: Annotate dma-fence critical section in commit path"
    
    [ Upstream commit 14d9a37c952588930d7226953359fea3ab956d39 ]
    
    This reverts commit f4b34faa08428d813fc3629f882c503487f94a12.
    
    Since commit f4b34faa0842 ("drm/imx: Annotate dma-fence critical section in
    commit path") the following possible circular dependency is detected:
    
    [    5.001811] ======================================================
    [    5.001817] WARNING: possible circular locking dependency detected
    [    5.001824] 5.14.9-01225-g45da36cc6fcc-dirty #1 Tainted: G        W
    [    5.001833] ------------------------------------------------------
    [    5.001838] kworker/u8:0/7 is trying to acquire lock:
    [    5.001848] c1752080 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x40/0x294
    [    5.001903]
    [    5.001903] but task is already holding lock:
    [    5.001909] c176df78 (dma_fence_map){++++}-{0:0}, at: imx_drm_atomic_commit_tail+0x10/0x160
    [    5.001957]
    [    5.001957] which lock already depends on the new lock.
    ...
    
    Revert it for now.
    
    Tested on a imx6q-sabresd.
    
    Fixes: f4b34faa0842 ("drm/imx: Annotate dma-fence critical section in commit path")
    Signed-off-by: Fabio Estevam <festevam@gmail.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/20211104001112.4035691-1-festevam@gmail.com
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Code:

commit cab693c0fe29a714e69afb8b472619d951941fc8
Author: Trond Myklebust <trond.myklebust@hammerspace.com>
Date:   Mon Oct 4 15:44:16 2021 -0400

    NFS: Fix deadlocks in nfs_scan_commit_list()
    
    [ Upstream commit 64a93dbf25d3a1368bb58ddf0f61d0a92d7479e3 ]
    
    Partially revert commit 2ce209c42c01 ("NFS: Wait for requests that are
    locked on the commit list"), since it can lead to deadlocks between
    commit requests and nfs_join_page_group().
    For now we should assume that any locked requests on the commit list are
    either about to be removed and committed by another task, or the writes
    they describe are about to be retransmitted. In either case, we should
    not need to worry.
    
    Fixes: 2ce209c42c01 ("NFS: Wait for requests that are locked on the commit list")
    Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Code:

commit bf736690bcbe39c328eef22e00314e38b3fa4475
Author: Hao Wu <hao.wu@rubrik.com>
Date:   Wed Sep 8 02:26:06 2021 -0700

    tpm: fix Atmel TPM crash caused by too frequent queries
    
    [ Upstream commit 79ca6f74dae067681a779fd573c2eb59649989bc ]
    
    The Atmel TPM 1.2 chips crash with error
    `tpm_try_transmit: send(): error -62` since kernel 4.14.
    It is observed from the kernel log after running `tpm_sealdata -z`.
    The error thrown from the command is as follows
    ```
    $ tpm_sealdata -z
    Tspi_Key_LoadKey failed: 0x00001087 - layer=tddl,
    code=0087 (135), I/O error
    ```
    
    The issue was reproduced with the following Atmel TPM chip:
    ```
    $ tpm_version
    T0  TPM 1.2 Version Info:
      Chip Version:        1.2.66.1
      Spec Level:          2
      Errata Revision:     3
      TPM Vendor ID:       ATML
      TPM Version:         01010000
      Manufacturer Info:   41544d4c
    ```
    
    The root cause of the issue is due to the TPM calls to msleep()
    were replaced with usleep_range() [1], which reduces
    the actual timeout. Via experiments, it is observed that
    the original msleep(5) actually sleeps for 15ms.
    Because of a known timeout issue in Atmel TPM 1.2 chip,
    the shorter timeout than 15ms can cause the error described above.
    
    A few further changes in kernel 4.16 [2] and 4.18 [3, 4] further
    reduced the timeout to less than 1ms. With experiments,
    the problematic timeout in the latest kernel is the one
    for `wait_for_tpm_stat`.
    
    To fix it, the patch reverts the timeout of `wait_for_tpm_stat`
    to 15ms for all Atmel TPM 1.2 chips, but leave it untouched
    for Ateml TPM 2.0 chip, and chips from other vendors.
    As explained above, the chosen 15ms timeout is
    the actual timeout before this issue introduced,
    thus the old value is used here.
    Particularly, TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 14700us,
    TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 15000us according to
    the existing TPM_TIMEOUT_RANGE_US (300us).
    The fixed has been tested in the system with the affected Atmel chip
    with no issues observed after boot up.
    
    References:
    [1] 9f3fc7bcddcb tpm: replace msleep() with usleep_range() in TPM
    1.2/2.0 generic drivers
    [2] cf151a9a44d5 tpm: reduce tpm polling delay in tpm_tis_core
    [3] 59f5a6b07f64 tpm: reduce poll sleep time in tpm_transmit()
    [4] 424eaf910c32 tpm: reduce polling time to usecs for even finer
    granularity
    
    Fixes: 9f3fc7bcddcb ("tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers")
    Link: https://patchwork.kernel.org/project/linux-integrity/patch/20200926223150.109645-1-hao.wu@rubrik.com/
    Signed-off-by: Hao Wu <hao.wu@rubrik.com>
    Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Code:

commit b2cf0bed6817e283ec1708bc2ca3bb5d8b9f0f4f
Author: Ye Bin <yebin10@huawei.com>
Date:   Wed Oct 20 15:39:59 2021 +0800

    nbd: Fix use-after-free in pid_show
    
    [ Upstream commit 0c98057be9efa32de78dbc4685fc73da9d71faa1 ]
    
    I got issue as follows:
    [  263.886511] BUG: KASAN: use-after-free in pid_show+0x11f/0x13f
    [  263.888359] Read of size 4 at addr ffff8880bf0648c0 by task cat/746
    [  263.890479] CPU: 0 PID: 746 Comm: cat Not tainted 4.19.90-dirty #140
    [  263.893162] Call Trace:
    [  263.893509]  dump_stack+0x108/0x15f
    [  263.893999]  print_address_description+0xa5/0x372
    [  263.894641]  kasan_report.cold+0x236/0x2a8
    [  263.895696]  __asan_report_load4_noabort+0x25/0x30
    [  263.896365]  pid_show+0x11f/0x13f
    [  263.897422]  dev_attr_show+0x48/0x90
    [  263.898361]  sysfs_kf_seq_show+0x24d/0x4b0
    [  263.899479]  kernfs_seq_show+0x14e/0x1b0
    [  263.900029]  seq_read+0x43f/0x1150
    [  263.900499]  kernfs_fop_read+0xc7/0x5a0
    [  263.903764]  vfs_read+0x113/0x350
    [  263.904231]  ksys_read+0x103/0x270
    [  263.905230]  __x64_sys_read+0x77/0xc0
    [  263.906284]  do_syscall_64+0x106/0x360
    [  263.906797]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
    
    Reproduce this issue as follows:
    1. nbd-server 8000 /tmp/disk
    2. nbd-client localhost 8000 /dev/nbd1
    3. cat /sys/block/nbd1/pid
    Then trigger use-after-free in pid_show.
    
    Reason is after do step '2', nbd-client progress is already exit. So
    it's task_struct already freed.
    To solve this issue, revert part of 6521d39a64b3's modify and remove
    useless 'recv_task' member of nbd_device.
    
    Fixes: 6521d39a64b3 ("nbd: Remove variable 'pid'")
    Signed-off-by: Ye Bin <yebin10@huawei.com>
    Reviewed-by: Josef Bacik <josef@toxicpanda.com>
    Link: https://lore.kernel.org/r/20211020073959.2679255-1-yebin10@huawei.com
    Signed-off-by: Jens Axboe <axboe@kernel.dk>
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Code:

commit e24f9679c3c039cc8ec80beff2239a3240176e37
Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Date:   Mon Oct 25 10:30:37 2021 +0100

    Revert "wcn36xx: Enable firmware link monitoring"
    
    [ Upstream commit 43ea9bd84f27d06482cc823d9749cc9dd2993bc8 ]
    
    Firmware link offload monitoring can be made to work in 3/4 cases by
    switching on firmware feature bit WLANACTIVE_OFFLOAD
    
    - Secure power-save on
    - Secure power-save off
    - Open power-save on
    
    However, with an open AP if we switch off power-saving - thus never
    entering Beacon Mode Power Save - BMPS, firmware never forwards loss
    of beacon upwards.
    
    We had hoped that WLANACTIVE_OFFLOAD and some fixes for sequence numbers
    would unblock this but, it hasn't and further investigation is required.
    
    Its possible to have a complete set of Secure power-save on/off and Open
    power-save on/off provided we use Linux' link monitoring mechanism.
    
    While we debug the Open AP failure we need to fix upstream.
    
    This reverts commit c973fdad79f6eaf247d48b5fc77733e989eb01e1.
    
    Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
    Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
    Link: https://lore.kernel.org/r/20211025093037.3966022-2-bryan.odonoghue@linaro.org
    Signed-off-by: Sasha Levin <sashal@kernel.org>

Code:

commit 8b09d36daf476ad2a03d691a6336d0d1c515e04c
Author: Johan Hovold <johan@kernel.org>
Date:   Thu Oct 7 15:31:46 2021 +0200

    Revert "serial: 8250: Fix reporting real baudrate value in c_ospeed field"
    
    commit d02b006b29de14968ba4afa998bede0d55469e29 upstream.
    
    This reverts commit 32262e2e429cdb31f9e957e997d53458762931b7.
    
    The commit in question claims to determine the inverse of
    serial8250_get_divisor() but failed to notice that some drivers override
    the default implementation using a get_divisor() callback.
    
    This means that the computed line-speed values can be completely wrong
    and results in regular TCSETS requests failing (the incorrect values
    would also be passed to any overridden set_divisor() callback).
    
    Similarly, it also failed to honour the old (deprecated) ASYNC_SPD_FLAGS
    and would break applications relying on those when re-encoding the
    actual line speed.
    
    There are also at least two quirks, UART_BUG_QUOT and an OMAP1510
    workaround, which were happily ignored and that are now broken.
    
    Finally, even if the offending commit were to be implemented correctly,
    this is a new feature and not something which should be backported to
    stable.
    
    Cc: Pali Rohár <pali@kernel.org>
    Fixes: 32262e2e429c ("serial: 8250: Fix reporting real baudrate value in c_ospeed field")
    Cc: stable <stable@vger.kernel.org>
    Signed-off-by: Johan Hovold <johan@kernel.org>
    Link: https://lore.kernel.org/r/20211007133146.28949-1-johan@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Code:

commit 46fd62b26822e1a33cffd8c22340e829b00c9d4c
Author: Eric Whitney <enwlinux@gmail.com>
Date:   Tue Oct 12 13:19:01 2021 -0400

    Revert "ext4: enforce buffer head state assertion in ext4_da_map_blocks"
    
    commit 3eda41df05d6ad5c825cbc7fef03d563597b1afa upstream.
    
    This reverts commit 948ca5f30e1df0c11eb5b0f410b9ceb97fa77ad9.
    
    Two crash reports from users running variations on 5.15-rc4 kernels
    suggest that it is premature to enforce the state assertion in the
    original commit.  Both crashes were triggered by BUG calls in that
    code, indicating that under some rare circumstance the buffer head
    state did not match a delayed allocated block at the time the
    block was written out.  No reproducer is available.  Resolving this
    problem will require more time than remains in the current release
    cycle, so reverting the original patch for the time being is necessary
    to avoid any instability it may cause.
    
    Signed-off-by: Eric Whitney <enwlinux@gmail.com>
    Link: https://lore.kernel.org/r/20211012171901.5352-1-enwlinux@gmail.com
    Fixes: 948ca5f30e1d ("ext4: enforce buffer head state assertion in ext4_da_map_blocks")
    Signed-off-by: Theodore Ts'o <tytso@mit.edu>
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

drumz · 11-18-2021, 01:15 PM

My guess is 13!

pghvlaans · 11-18-2021, 01:18 PM

I figure it'll be a fair number, and my favorite football player wore number 28, so 28.

kgha · 11-18-2021, 02:46 PM

The answer, as always, is 42.

hitest · 11-18-2021, 02:53 PM

An interesting linux discussion! As we're on RC2 now which has a hard freeze we may not be getting new kernels prior to the release of Slackware 15.0. I don't of course know if that's the case. For me a hard freeze means no new additions?! Interesting days ahead.

TheRealGrogan · 11-18-2021, 03:21 PM

He said "a much harder freeze", not a hard freeze

Wiggle room :-)

Funny poll though, I too have scoffed at seeing so many reverts in recent times. I'm going to say 3, with the mindset of at least 3.

marav · 11-18-2021, 03:25 PM

my vote: 10

Ser Olmy · 11-18-2021, 04:40 PM

I'd go with 6-10.

Incidentally, I'm doing my best to possibly get the count up by one: there seems to be a NAT bug in 5.15.x that absolutely needs to be addressed, but whether it'll be a revert or just a patch remains to be seen.

Also, I'm hoping to have the bisect done before 5.15.4, but progress is a bit slow.

LuckyCyborg · 11-18-2021, 04:47 PM

It's one of those LTS kernels, where they dump all half tested code on them, supposedly to fix the things later.

What you expect?

I for one I believe that we are quite lucky with 5.15.x which proved to be a quite behaved series.

Honestly, I expected crashes. Many crashes. Crashing this and that even this. Crashes everywhere!

SCerovec · 11-19-2021, 11:21 AM

i say 14

drumz · 11-19-2021, 03:51 PM

5.15.4-rc1 has been announced, and from a quick check of the patch subject lines it looks like 3 out of the 20 patches are reverts. It looks like most of us have overestimated.

avian · 11-20-2021, 03:10 AM

Quote:

Originally Posted by drumz

5.15.4-rc1 has been announced, and from a quick check of the patch subject lines it looks like 3 out of the 20 patches are reverts. It looks like most of us have overestimated.

I chose 4. Im still holding hope for an extra revert.. Come on devs, I know you want to.

brianL · 11-20-2021, 06:13 AM

I'm feeling generous (?). 51 or more.

ctrlaltca · 11-21-2021, 08:51 AM

So, the final result seems to be 4: https://cdn.kernel.org/pub/linux/ker...angeLog-5.15.4
12% of the answers were correct, 17% underestimated the number of reverts, about 70% overestimated the number of reverts (me too).
Seems like we don't trust our kernel developers enough

ardya · 11-21-2021, 12:14 PM

Cowboy Neal option.