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-next>] [day] [month] [year] [list]
Message-ID: <CAKXUXMxs3waRA8pveFQ2LRMF5imoHxjQ0zfLS_4vpfr2YSLYPw@mail.gmail.com>
Date:   Tue, 14 Jun 2022 13:33:38 +0200
From:   Lukas Bulwahn <lukas.bulwahn@...il.com>
To:     "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        "maple-tree@...ts.infradead.org" <maple-tree@...ts.infradead.org>
Cc:     Linux-MM <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        kernel-janitors <kernel-janitors@...r.kernel.org>
Subject: Issue in count_mm_mlocked_page_nr() with commit afcf76df48f9
 ("mm/mlock: use vma iterator and maple state instead of vma linked list")

Dear Matthew, dear Liam,

The commit afcf76df48f9 ("mm/mlock: use vma iterator and maple state instead
of vma linked list") refactors the function count_mm_mlocked_page_nr() in
mm/mlock.c, such that the special case:

        if (mm == NULL)
                mm = current->mm;

is now dead code. Before the refactoring, after this if statement, the variable
mm was used further in vma = find_vma(mm, start) in the following line, but now,
with the introduction of VMA_ITERATOR(vmi, mm, start) before the if statement,
the assignment within the if statement is simply ignored.

I assume that:
- If the semantics of this function shall be preserved, the VMA_ITERATOR macro
needs to move after the if statement.

- or, if the consideration of the special case on mm == NULL is actually
obsolete with this refactoring, it could be simply deleted.

I will keep it up to you how this issue is correctly resolved.

This was discovered due to tracking all dead stores that clang-analyzer reports
on an x86 defconfig. The underlying issue here is more severe than "just a dead
store in the kernel code base", but it is probably easy for you to resolve.

Best regards,

Lukas

P.S.: Sorry, if you get this mail twice, the first time my email
client tricked me into unintentionally sending a HTML email rather
than a text email.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ