Re: [PATCH] mm/damon/tests/vaddr-kunit: don't use mas_lock for MM_MT_FLAGS-initialized maple tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/3/24 18:18, SeongJae Park wrote:
On Tue,  3 Sep 2024 17:58:15 -0700 SeongJae Park <sj@xxxxxxxxxx> wrote:

On Tue, 3 Sep 2024 20:48:53 -0400 "Liam R. Howlett" <Liam.Howlett@xxxxxxxxxx> wrote:

* SeongJae Park <sj@xxxxxxxxxx> [240903 20:45]:
damon_test_three_regions_in_vmas() initializes a maple tree with
MM_MT_FLAGS.  The flags contains MT_FLAGS_LOCK_EXTERN, which means
mt_lock of the maple tree will not be used.  And therefore the maple
tree initialization code skips initialization of the mt_lock.  However,
__link_vmas(), which adds vmas for test to the maple tree, uses the
mt_lock.  In other words, the uninitialized spinlock is used.  The
problem becomes celar when spinlock debugging is turned on, since it
reports spinlock bad magic bug.  Fix the issue by not using the mt_lock
as promised.

You can't do this, lockdep will tell you this is wrong.

Hmm, but lockdep was silence on my setup?

We need a lock and to use the lock for writes.

This code is executed by a single-thread test code.  Do we still need the lock?


I'd suggest using different flags so the spinlock is used.

The reporter mentioned simply dropping MT_FLAGS_LOCK_EXTERN from the flags
causes suspicious RCU usage message.  May I ask if you have a suggestion of
better flags?

I was actually thinking replacing the mt_init_flags() with mt_init(), which
same to mt_init_flags() with zero flag, like below.

```
--- a/mm/damon/tests/vaddr-kunit.h
+++ b/mm/damon/tests/vaddr-kunit.h
@@ -77,7 +77,7 @@ static void damon_test_three_regions_in_vmas(struct kunit *test)
                 (struct vm_area_struct) {.vm_start = 307, .vm_end = 330},
         };

-       mt_init_flags(&mm.mm_mt, MM_MT_FLAGS);
+       mt_init(&mm.mm_mt);
         if (__link_vmas(&mm.mm_mt, vmas, ARRAY_SIZE(vmas)))
                 kunit_skip(test, "Failed to create VMA tree");
```

And just confirmed it also convinces the reproducer.  But because I'm obviously
not familiar with maple tree, would like to hear some comments from Liam or
others first.

Same here. That is why I gave up after trying MT_FLAGS_ALLOC_RANGE and
"MT_FLAGS_ALLOC_RANGE | MT_FLAGS_USE_RCU". After all, I really don't know what
I am doing and was just playing around ... and there isn't really a good
explanation why initializing the maple tree with MT_FLAGS_ALLOC_RANGE (but not
MT_FLAGS_USE_RCU) would trigger rcu warnings.

Guenter





[Index of Archives]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux