oe-lkp.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Oliver Sang <oliver.sang@intel.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: <oe-lkp@lists.linux.dev>, <lkp@intel.com>,
	<linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Waiman Long <longman@redhat.com>, <linux-mm@kvack.org>,
	<oliver.sang@intel.com>
Subject: Re: [linus:master] [kmemleak]  39042079a0: kernel-selftests.kvm.memslot_perf_test.fail
Date: Fri, 26 Jan 2024 14:35:44 +0800	[thread overview]
Message-ID: <ZbNSwITESw+/SfNy@xsang-OptiPlex-9020> (raw)
In-Reply-To: <ZbJNtFO_N4pVuEUK@arm.com>

hi, Catalin,

On Thu, Jan 25, 2024 at 12:01:56PM +0000, Catalin Marinas wrote:
> On Thu, Jan 25, 2024 at 03:34:37PM +0800, kernel test robot wrote:
> > kernel test robot noticed "kernel-selftests.kvm.memslot_perf_test.fail" on:
> > 
> > commit: 39042079a0c241d09fa6fc3bb67c2ddf60011d0f ("kmemleak: avoid RCU stalls when freeing metadata for per-CPU pointers")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> [...]
> > The kernel config and materials to reproduce are available at:
> > https://download.01.org/0day-ci/archive/20240125/202401251429.d3dea02b-oliver.sang@intel.com
> [...]
> > # Testing RW performance with 1 runs, 5 seconds each
> > #
> > not ok 71 selftests: kvm: memslot_perf_test # TIMEOUT 120 seconds
> 
> I'm not sure how this relates to kmemleak, especially the commit above.
> It might as well be that the above kmemleak commit increases the system
> load and you trip over the timeout above. Is it still reproducible with
> a larger timeout (unfortunately I don't have the hardware to try to
> reproduce the problem)?
> 
> I can see a lockdep warning in the dmesg but that doesn't look related
> to kmemleak.

below things FYI.

(1) we set same timeout for 39042079a0 and its parent, test always can pass
on parent (by 20 runs), but almost always fail on 39042079a0 (18 out of 20
runs fail).

(2) while running tests, we use a kmemleak monitor.
for parent runs, seems no problem, but for 39042079a0 runs, it will capture
below log:

$ cat kmemleak
unreferenced object 0xff110001198a1720 (size 16):
  comm "swapper/0", pid 1, jiffies 4294783051
  hex dump (first 16 bytes):
    41 43 50 49 20 48 4d 41 54 00 6b 6b 6b 6b 6b a5  ACPI HMAT.kkkkk.
  backtrace (crc 45396b86):
    [<ffffffff81a97e28>] __kmem_cache_alloc_node+0x228/0x310
    [<ffffffff81936de5>] __kmalloc_node_track_caller+0x55/0xf0
    [<ffffffff819160b4>] kstrdup+0x34/0x60
    [<ffffffff81aada3b>] mt_set_default_dram_perf+0x3cb/0x460
    [<ffffffff8658a9a6>] hmat_init+0x2b6/0x3a0
    [<ffffffff81002c58>] do_one_initcall+0xd8/0x410
    [<ffffffff864aaa4a>] do_initcalls+0x1ca/0x390
    [<ffffffff864ab53e>] kernel_init_freeable+0x8ce/0xc80
    [<ffffffff83beed8f>] kernel_init+0x1f/0x1d0
    [<ffffffff810a07c1>] ret_from_fork+0x31/0x70
    [<ffffffff81006341>] ret_from_fork_asm+0x11/0x20

(3) we tried to disable the kmemleak monitor for 39042079a0, then
memslot_perf_test can pass now. there is no kmemleak dump.

(4) we also noticed a test can pass on 39042079a0 now, but always fail on
parent, no matter kmemleak monitor enable or disable.
(normally we won't report a commit if it makes some test start to pass, so this
information is not in original report)

f67f8d4a8c1e1ebc 39042079a0c241d09fa6fc3bb67
---------------- ---------------------------
       fail:runs  %reproduction    fail:runs
           |             |             |
           :20         150%          30:30    kernel-selftests.kvm.rseq_test.pass

> 
> -- 
> Catalin

      reply	other threads:[~2024-01-26  6:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-25  7:34 [linus:master] [kmemleak] 39042079a0: kernel-selftests.kvm.memslot_perf_test.fail kernel test robot
2024-01-25 12:01 ` Catalin Marinas
2024-01-26  6:35   ` Oliver Sang [this message]

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=ZbNSwITESw+/SfNy@xsang-OptiPlex-9020 \
    --to=oliver.sang@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lkp@intel.com \
    --cc=longman@redhat.com \
    --cc=oe-lkp@lists.linux.dev \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).