linux-kernel - Re: Possible 6.5 regression: Huge values for "commited memory"

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 for Android: free password hash cracker in your pocket

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

Date:   Sun, 17 Sep 2023 07:02:50 +0200
From:   Helge Deller <deller@....de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        stable <stable@...r.kernel.org>, Sasha Levin <sashal@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Linux PARISC <linux-parisc@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Regressions <regressions@...ts.linux.dev>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        Bagas Sanjaya <bagasdotme@...il.com>,
        Michael Labiuk <michael.labiuk@...tuozzo.com>,
        Christoph Biedl <linux-kernel.bfrz@...chmal.in-ulm.de>
Subject: Re: Possible 6.5 regression: Huge values for "commited memory"

Greg & Sasha,

can you please queue-up this upstream patch for kernel v6.5-stable ?

commit 3cec50490969afd4a76ccee441f747d869ccff77
Author: Linus Torvalds <torvalds@...ux-foundation.org>
Date:   Sat Sep 16 12:31:42 2023 -0700

     vm: fix move_vma() memory accounting being off

Thanks,
Helge


On 9/16/23 23:17, Linus Torvalds wrote:
> On Sat, 16 Sept 2023 at 12:31, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
>>
>> Does the attached patch fix the problem?
>
> So while I didn't confirm the fix myself, I'm pretty sure that was it.
> Getting the return value wrong would cause an incorrect extra
> vm_acct_memory() call in the non-error case when VM_ACCOUNT is set
> (and mean the loss of one in the error case, but the error case never
> happens in practice).
>
> Which then causes 'vm_committed_as' to grow when it shouldn't, and
> causes exactly that "Committed_AS" in /proc/meminfo to be off.
>
> So here's the same patch, but now with a proper commit message etc.
>
> I haven't pushed it out (because it would be lovely to get a
> "Tested-by" for it, and that will make the commit ID change), but I'll
> probably do so later today, with or without confirmation, because it
> does seem to be the problem.
>
>                Linus