linux-kernel - Re: linux-5.13.2: warning from kernel/rcu/tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5812280.fcLxn8YiTP@natalenko.name>
Date:   Mon, 19 Jul 2021 14:12:15 +0200
From:   Oleksandr Natalenko <oleksandr@...alenko.name>
To:     Matthew Wilcox <willy@...radead.org>,
        Miaohe Lin <linmiaohe@...wei.com>
Cc:     Boqun Feng <boqun.feng@...il.com>,
        Zhouyi Zhou <zhouzhouyi@...il.com>, paulmck@...nel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        stable@...r.kernel.org, Chris Clayton <chris2553@...glemail.com>,
        Chris Rankin <rankincj@...il.com>,
        Josh Triplett <josh@...htriplett.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Joel Fernandes <joel@...lfernandes.org>,
        rcu <rcu@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux-MM <linux-mm@...ck.org>,
        "Huang, Ying" <ying.huang@...el.com>, gregkh@...uxfoundation.org
Subject: Re: linux-5.13.2: warning from kernel/rcu/tree_plugin.h:359

On pondělí 19. července 2021 14:08:37 CEST Miaohe Lin wrote:
> On 2021/7/19 19:59, Oleksandr Natalenko wrote:
> > On pondělí 19. července 2021 13:50:07 CEST Miaohe Lin wrote:
> >> On 2021/7/19 19:22, Matthew Wilcox wrote:
> >>> On Mon, Jul 19, 2021 at 07:12:58PM +0800, Miaohe Lin wrote:
> >>>> When in the commit 2799e77529c2a, we're using the percpu_ref to
> >>>> serialize
> >>>> against concurrent swapoff, i.e. there's percpu_ref inside
> >>>> get_swap_device() instead of rcu_read_lock(). Please see commit
> >>>> 63d8620ecf93 ("mm/swapfile: use percpu_ref to serialize against
> >>>> concurrent swapoff") for detail.
> >>> 
> >>> Oh, so this is a backport problem.  2799e77529c2 was backported without
> >>> its prerequisite 63d8620ecf93.  Greg, probably best to just drop
> >> 
> >> Yes, they're posted as a patch set:
> >> 
> >> https://lkml.kernel.org/r/20210426123316.806267-1-linmiaohe@huawei.com
> >> 
> >>> 2799e77529c2 from all stable trees; the race described is not very
> >>> important (swapoff vs reading a page back from that swap device).
> >>> .
> >> 
> >> The swapoff races with reading a page back from that swap device should
> >> be
> >> really uncommon as most users only do swapoff when the system is going to
> >> shutdown.
> >> 
> >> Sorry for the trouble!
> > 
> > git log --oneline v5.13..v5.13.3 --author="Miaohe Lin"
> > 11ebc09e50dc mm/zswap.c: fix two bugs in zswap_writeback_entry()
> > 95d192da198d mm/z3fold: use release_z3fold_page_locked() to release locked
> > z3fold page
> > ccb7848e2344 mm/z3fold: fix potential memory leak in z3fold_destroy_pool()
> > 9f7229c901c1 mm/huge_memory.c: don't discard hugepage if other processes
> > are mapping it
> > f13259175e4f mm/huge_memory.c: add missing read-only THP checking in
> > transparent_hugepage_enabled()
> > afafd371e7de mm/huge_memory.c: remove dedicated macro
> > HPAGE_CACHE_INDEX_MASK a533a21b692f mm/shmem: fix shmem_swapin() race
> > with swapoff
> > c3b39134bbd0 swap: fix do_swap_page() race with swapoff
> > 
> > Do you suggest reverting "mm/shmem: fix shmem_swapin() race with swapoff"
> > as well?
> 
> This patch also rely on its prerequisite 63d8620ecf93. I think we should
> either revert any commit in this series or just backport the entire series.

Then why not just pick up 2 more patches instead of dropping 2 patches. Greg, 
could you please make sure the whole series from [1] gets pulled?

Thanks.

[1] https://lkml.kernel.org/r/20210426123316.806267-1-linmiaohe@huawei.com

-- 
Oleksandr Natalenko (post-factum)