linux-kernel - Re: Abnormal values show up in /proc/allocinfo

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]

Message-ID: <CAJuCfpEP-xMzHonsE3uV1uYahXehR007B5QX9KjdZdHBWyrXwQ@mail.gmail.com>
Date: Mon, 25 Nov 2024 12:31:39 -0800
From: Suren Baghdasaryan <surenb@...gle.com>
To: David Wang <00107082@....com>
Cc: kent.overstreet@...ux.dev, linux-kernel@...r.kernel.org
Subject: Re: Abnormal values show up in /proc/allocinfo

On Mon, Nov 25, 2024 at 9:31 AM Suren Baghdasaryan <surenb@...gle.com> wrote:
>
> On Mon, Nov 25, 2024 at 2:10 AM David Wang <00107082@....com> wrote:
> >
> >
> > Hi,
> >
> > Some update
> >
> > I reproduce the abnormal values of "func:compaction_alloc" today, just once. But I have not found a deterministic procedure yet.
> > Seems to me, it happens when kcompactd starts to work
> >
> >     ret_from_fork(100.000% 57/57)
> >         kthread(100.000% 57/57)
> >             kcompactd(100.000% 57/57)
> >                 compact_node(100.000% 57/57)
> >                     compact_zone(100.000% 57/57)
> >                         migrate_pages(100.000% 57/57)
> >                             migrate_pages_batch(100.000% 57/57)
> >                                 compaction_alloc(100.000% 57/57)
> >
> >
> > Maybe, kcompactd mess up information needed by memory tracking? Just a wild guess.
> > And those negative signed values, and underflowed unsigned values could also be the side-effect of memory compaction.
> > A wilder guess....
>
> Ok, thanks! I think that's enough for me to start digging. Will post
> an update once I find something.
> Thanks,
> Suren.
>
> >
> >
> >
> > FYI
> > David
> >
> >
> >
> >
> > At 2024-11-25 08:35:54, "Suren Baghdasaryan" <surenb@...gle.com> wrote:
> > >On Sat, Nov 23, 2024 at 11:43 PM David Wang <00107082@....com> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I am running 6.12.0 for a week, and today I notice several strange
> > >> items in /proc/allocinfo:
> > >>
> > >>        -4096 18446744073709551615 mm/filemap.c:3787 func:do_read_cache_folio
> > >>  -1946730496 18446744073709076340 mm/filemap.c:1952 func:__filemap_get_folio
> > >>   -903294976 18446744073709331085 mm/readahead.c:263 func:page_cache_ra_unbounded
> > >>   -353054720 18446744073709465421 mm/shmem.c:1769 func:shmem_alloc_folio
> > >>  10547565210        0 mm/compaction.c:1880 func:compaction_alloc
> > >>   -156487680 18446744073709513411 mm/memory.c:1064 func:folio_prealloc
> > >>  -2422685696 18446744073708960140 mm/memory.c:1062 func:folio_prealloc
> > >>  -2332479488 18446744073708982163 fs/btrfs/extent_io.c:635 [btrfs] func:btrfs_alloc_page_array
> > >>
> > >> some values are way too large, seems like corrupted/uninitialized, and values for compaction_alloc
> > >> are inconsistent: non-zero size with zero count.
> > >>
> > >> I do not know when those data became this strange, and I have not reboot my system yet.
> > >> Do you guys need extra information before I reboot my system and started to try reproducing?
> > >
> > >Hi David,
> > >Thanks for reporting. Can you share your .config file? Also, do you
> > >see these abnormal values shortly after boot or does it take time for
> > >them to get into abnormal state?
> > >I'll take a look on Monday and see if there is an obvious issue and if
> > >I can reproduce this.

Hi David,
Could you please check if you have this fix:

ed265529d39a "mm/codetag: fix arg in pgalloc_tag_copy alloc_tag_sub"

It was merged after v6.12-rc6 and it fixes an accounting bug inside
pgalloc_tag_copy(), which is used during compaction.
Thanks,
Suren.


https://lore.kernel.org/all/20240906042108.1150526-3-yuzhao@google.com/
https://lore.kernel.org/all/20241022232440.334820-1-souravpanda@google.com/

> > >Thanks,
> > >Suren.
> > >
> > >>
> > >>
> > >> Thanks
> > >> David
> > >>
> > >>
> > >>
> > >>