From: Bagas Sanjaya <bagasdotme@gmail.com>
To: Linux regressions mailing list <regressions@lists.linux.dev>,
Alistair Popple <apopple@nvidia.com>,
Felix Kuehling <Felix.Kuehling@amd.com>,
Andrew Morton <akpm@linux-foundation.org>,
Marco <rodomar705@protonmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: Fwd: Kernel memory management bug at mm/migrate.c:662 when flushing caches
Date: Wed, 2 Aug 2023 18:47:07 +0700 [thread overview]
Message-ID: <307e4377-f52f-40dc-23ec-90a75668cb99@gmail.com> (raw)
In-Reply-To: <32c3d93c-c320-0f88-87db-003f51bfc039@leemhuis.info>
On 02/08/2023 18:25, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 02.08.23 13:08, Bagas Sanjaya wrote:
>>
>> I notice a regression report on Bugzilla [1]. Quoting from it:
>>
>>> I hit this kernel bug on the latest 6.3.9 kernel after executing this script to cleanup hugepages from the kernel before booting up a Windows 11 VM with QEMU (otherwise I don't have enough contiguous memory to allocate the pages to the VM)
>>>
>>> snip
>>> if [[ $VM_ACTION == 'prepare' ]];
>>> then
>>> sync
>>> echo 3 > /proc/sys/vm/drop_caches
>>> echo 1 > /proc/sys/vm/compact_memory
>>> endsnip
>>>
>>> Attached is the full QEMU script that I used. I do use ZFS as a root filesystem, as you can see from the loaded modules.
>
> Bagas, FWIW, I'd totally understand if developers will ignore this
> (remains to be seen if that is the case, maybe we are lucky and somebody
> will take a look), as I think you for now shouldn't have forwarded this
> for two reasons:
>
> * 6.3.y is old and EOL; testing mainline or at least a fresh 6.4.y
> kernel) would have been a must here.
> * with out-of-tree modules like ZFS anything can happen, the user is own
> its own.
>
I have already asked the reporter to try reproducing this with
"officially-supported" other filesystems (e.g. ext4, xfs, or btrfs).
The reporter also stated that he was now trying the mainline (but not
rc release, just latest stable).
> As I can see from the bug both things will likely clear up soon, hence
> waiting would have been wise here.
>
> Please in the future do not forward such bugs, as developers might
> otherwise start to ignore mails wrt to regression tracking -- which we
> really need to avoid, as that will make things a lot harder.
>
Thanks for another tip!
--
An old man doll... just what I always wanted! - Clara
next prev parent reply other threads:[~2023-08-02 11:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 11:08 Bagas Sanjaya
2023-08-02 11:25 ` Linux regression tracking (Thorsten Leemhuis)
2023-08-02 11:47 ` Bagas Sanjaya [this message]
2023-08-02 12:38 ` Bagas Sanjaya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=307e4377-f52f-40dc-23ec-90a75668cb99@gmail.com \
--to=bagasdotme@gmail.com \
--cc=Felix.Kuehling@amd.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=regressions@lists.linux.dev \
--cc=rodomar705@protonmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox