From Liam.Howlett at Oracle.com  Fri Apr  5 12:40:39 2024
From: Liam.Howlett at Oracle.com (Liam R. Howlett)
Date: Fri, 5 Apr 2024 15:40:39 -0400
Subject: fwd: Re: Performance loss with word count benchmark
Message-ID: <20240405194039.5aqhgkhiqhw6hvx5@revolver>

For some reason this email from Julia is missing from the October 2023
archive of the mailing list even though it was sent around the middle of
the month.  I'm forwarding it back to the list so the results won't be
lost.

Thanks again Julia for running the benchmarks and following up with us.
Liam

----- Forwarded message from Julia Lawall <julia.lawall at inria.fr> -----

...
Subject: Re: Performance loss with word count benchmark
Date: Fri, 13 Oct 2023 23:40:41 +0200 (CEST)



On Mon, 2 Oct 2023, Jirka Hladky wrote:

> Thank you, Julia!
>
> The results are interesting:
>
> $tail -v -n+1 * | grep -P "==>|system"
> ==> wordcount_yeti-4_5.17.0_powersave-active.json <==
>      "system": 21.587097254999996,
> ==> wordcount_yeti-4_5.18.0_powersave-active.json <==
>      "system": 21.593763075000005,
> ==> wordcount_yeti-4_5.19.0_powersave-active.json <==
>      "system": 22.53202131,
> ==> wordcount_yeti-4_6.0.0_powersave-active.json <==
>      "system": 27.673837299999995,
> ==> wordcount_yeti-4_6.1.0_powersave-active.json <==
>      "system": 24.58705548,
> ==> wordcount_yeti-4_6.2.0_powersave-active.json <==
>      "system": 24.951412994999995,
>
> System time went up significantly between 5.19 and 6.0. Starting from
> 6.1, it has improved a little. I was searching to link the results to
> the lower performance of the "mprotect" system call (beginning in
> 6.1), but this data does not align with this. Something else is
> happening here...

I tried some more recent versions, with interesting results.  This is on a
four-socket Intel 6130.

wordcount_yeti-4_5.19.0_performance.json:      "mean": 3.12326750034,
wordcount_yeti-4_6.0.0_performance.json:      "mean": 3.08271866984,
wordcount_yeti-4_6.1.0_performance.json:      "mean": 3.9168611305299996,
wordcount_yeti-4_6.2.0_performance.json:      "mean": 3.9323236962599992,
wordcount_yeti-4_6.3.0_performance.json:      "mean": 3.9299195262349995,
wordcount_yeti-4_6.4.0_performance.json:      "mean": 1.6312004133800002,
wordcount_yeti-4_6.5.0_performance.json:      "mean": 1.6477082927600002,
wordcount_yeti-4_6.6.0rc1_performance.json:      "mean": 0.9028324600200002,
wordcount_yeti-4_6.6.0rc3_performance.json:      "mean": 0.8936725624550004,

Bisecting between 6.3 nd 6.4 gives the following list of commits:

c7f8f31c00d1 mm: separate vma->lock from vm_area_struct =========> 1.6 seconds
0d2ebf9c3f78 mm/mmap: free vm_area_struct without call_rcu in exit_mmap
70d4cbc80c88 (HEAD) powerc/mm: try VMA lock-based page fault handling first
cd7f176aea5f arm64/mm: try VMA lock-based page fault handling first
0bff0aaea03e x86/mm: try VMA lock-based page fault handling first
52f238653e45 mm: introduce per-VMA lock statistics ==============> 3.9 seconds

The versions in the middle don't compile.  The commit c7f8f31c00d1 is
performance related:

commit c7f8f31c00d187a2c71a241c7f2bd6aa102a4e6f
Author: Suren Baghdasaryan <surenb at google.com>
Date:   Mon Feb 27 09:36:32 2023 -0800

    mm: separate vma->lock from vm_area_struct

I don't know if this commit undoes something that was aggravated by the
introduction of maple trees.  Or if the performance improvement is just so
great that it hides the previous performance degradation.

There is another big performance improvement in 6.6-rc1.  After
c7f8f31c00d187a2c71a241c7f2bd6aa102a4e6f, the graphe still has the towers
of mprotects, as shown in the attached graph.  In 6.6.0-rc3, the towers
are gone, and the mprotects come at different times on different cores.
This surely reduces contention and improves performance.  But I haven't
bisected that case to see what causes the changed behavior.

julia



>
> On Mon, Oct 2, 2023 at 11:31?AM Julia Lawall <julia.lawall at inria.fr> wrote:
> >
> >
> >
> > On Mon, 2 Oct 2023, Jirka Hladky wrote:
> >
> > > Thanks for sharing, Julia!
> > >
> > > > Something else seems to happen for 6.1, though.
> > >
> > > Could you please share the user and system times as well? I'm using
> > > the tool "hyperfine" to measure it, including statistics:
> > >
> > > cargo install hyperfine || cargo install --version 8.4.0 hyperfine
> > >
> > > See
> > > https://crates.io/crates/hyperfine
> > >
> > > hyperfine --warmup 1 'phoenix-2.0/tests/word_count/word_count
> > > word_count_datafiles/word_100MB.txt'
> >
> > The hyperfine files for 5.17-6.2 are attached.
> >
> > julia
> >
> > >
> > > Merci!
> > > Jirka
> > >
> > > On Sat, Sep 30, 2023 at 8:03?AM Julia Lawall <julia.lawall at inria.fr> wrote:
> > > >
> > > >
> > > >
> > > > On Sat, 30 Sep 2023, Jirka Hladky wrote:
> > > >
> > > > > Hi Matt and Julia,
> > > > > thanks a lot for adding me to this thread. The performance issues with the word_count test might be connected to a performance drop in the mprotect system call. Libmicro [1] shows performance drops for various mprotect tests up to a factor of 1.5x.
> > > > >
> > > > > ==> 6.0.0-54.eln121.x86_64_mmap_mprotect.log <==
> > > > > TSC for 32768 mprotect calls with len of 128kiB: 202866 K-cycles.  Avg: 6.191 K-cycles/call
> > > > >
> > > > > ==> 6.5.0-57.eln130.x86_64_mmap_mprotect.log <==
> > > > > TSC for 32768 mprotect calls with len of 128kiB: 302327 K-cycles.  Avg: 9.22631 K-cycles/call
> > > > >
> > > > > ==> 6.6.0-0.rc2.20.eln130.x86_64_mmap_mprotect.log <==
> > > > > TSC for 32768 mprotect calls with len of 128kiB: 269886 K-cycles.  Avg: 8.2363 K-cycles/call
> > > > >
> > > > > Matt, Liam: could you please comment if this is expected?
> > > > >
> > > > > I'm attaching a simple .c reproducer. It times the mprotect syscall for a large mmaped region where we alternate NO_PROT and PROT_READ | PROT_WRITE 128kiB large areas. You can run it like this:gcc -Wall -Wextra -O1 mmap_mprotect.c -o mmap_mprotect
> > > > > ./mmap_mprotect 128 32768
> > > > >
> > > > > It will allocate 128kiB * 32768 = 4 GiB of memory
> > > > >
> > > > > Here is the main part where we measure the performance:
> > > > >
> > > > >      // Time the mprotect calls -alternate protection between PROT_NONE and PROT_READ | PROT_WRITE
> > > > >      //
> > > > >      u_int64_t start_rdtsc = start_clock();
> > > > >
> > > > >      for (i = 0; i < iterations; i++) {
> > > > >        if (i % 2 == 0 ) {
> > > > >          prot = PROT_NONE;
> > > > >        } else {
> > > > >          prot = PROT_READ | PROT_WRITE;
> > > > >        }
> > > > >        ret =mprotect((void *)ts_map + i*mmap_len, mmap_len, prot);
> > > > >        if (ret != 0) {
> > > > >          perror("mprotect");
> > > > >          printf(" mmap error at iteration %d from %ld\n", i, iterations);
> > > > >        }
> > > > >      }
> > > > >
> > > > >      u_int64_t stop_rdtsc = stop_clock();
> > > > >
> > > > >
> > > > >
> > > > > BTW, I have noticed that the word_count test shows the most significant performance degradation with Maple Tree compared to RB when run with many threads. Below are the results from Intel Icelake server with 36-core Platinum 8351N CPU :
> > > >
> > > > I also observed this.  I tried the same experiment on a 2-socket Intel
> > > > 6130 (same as the previous machine, but with 2 sockets instead of 4), and
> > > > I don't have any performance degradation for 6.0:
> > > >
> > > > wordcount_dahu-28_5.19.0_performance.json:      "mean": 1.1824737362849995,
> > > > wordcount_dahu-28_6.0.0_performance.json:      "mean": 1.142431961085,
> > > > wordcount_dahu-28_6.1.0_performance.json:      "mean": 1.346207455575,
> > > > wordcount_dahu-28_6.2.0_performance.json:      "mean": 1.3775329248449997,
> > > >
> > > > The calls to mprotect seem to be less aligned than for the larger machine.
> > > >
> > > > Something else seems to happen for 6.1, though.
> > > >
> > > > julia
> > > >
> > > >
> > > >
> > > >
> > > > > 72 threads:
> > > > > ==> 6.0.0-54.eln121.x86_64_allthreads.statistics.txt <==
> > > > > Benchmark 1: phoenix-2.0/tests/word_count/word_count word_count_datafiles/word_100MB.txt
> > > > >  Time (mean ? ?):     797.4 ms ?  47.0 ms    [User: 4868.8 ms, System: 10793.5 ms]
> > > > >  Range (min ? max):   707.0 ms ? 849.8 ms    10 runs
> > > > >
> > > > >
> > > > > ==> 6.5.0-57.eln130.x86_64_allthreads.statistics.txt <==
> > > > > Benchmark 1: phoenix-2.0/tests/word_count/word_count word_count_datafiles/word_100MB.txt
> > > > >  Time (mean ? ?):      1.673 s ?  0.265 s    [User: 9.574 s, System: 54.777 s]
> > > > >  Range (min ? max):    1.282 s ?  2.240 s    10 runs
> > > > >
> > > > >
> > > > > ==> 6.6.0-0.rc2.20.eln130.x86_64_allthreads.statistics.txt <==
> > > > > Benchmark 1: phoenix-2.0/tests/word_count/word_count word_count_datafiles/word_100MB.txt
> > > > >  Time (mean ? ?):      1.223 s ?  0.038 s    [User: 13.107 s, System: 20.346 s]
> > > > >  Range (min ? max):    1.153 s ?  1.273 s    10 runs
> > > > >
> > > > > System time is 5x longer with 6.5 kernel compared to 6.0. In 6.6, there is a significant improvement.
> > > > > When I repeat the test on the same server but just with four threads, I'm getting much better results:
> > > > >
> > > > > ==> 6.0.0-54.eln121.x86_64_4threads.statistics.txt <==
> > > > > Benchmark 1: phoenix-2.0/tests/word_count/word_count word_count_datafiles/word_100MB.txt
> > > > >  Time (mean ? ?):     689.4 ms ?   3.3 ms    [User: 2350.9 ms, System: 191.9 ms]
> > > > >  Range (min ? max):   684.5 ms ? 693.8 ms    10 runs
> > > > >
> > > > >
> > > > > ==> 6.5.0-57.eln130.x86_64_4threads.statistics.txt <==
> > > > > Benchmark 1: phoenix-2.0/tests/word_count/word_count word_count_datafiles/word_100MB.txt
> > > > >  Time (mean ? ?):     699.3 ms ?   2.4 ms    [User: 2371.8 ms, System: 205.8 ms]
> > > > >  Range (min ? max):   695.4 ms ? 702.6 ms    10 runs
> > > > >
> > > > >
> > > > > ==> 6.6.0-0.rc2.20.eln130.x86_64_4threads.statistics.txt <==
> > > > > Benchmark 1: phoenix-2.0/tests/word_count/word_count word_count_datafiles/word_100MB.txt
> > > > >  Time (mean ? ?):     696.5 ms ?   3.0 ms    [User: 2370.1 ms, System: 194.3 ms]
> > > > >  Range (min ? max):   691.2 ms ? 700.2 ms    10 runs
> > > > >
> > > > > In this scenario, there is barely any difference between kernel 6.0, 6.5, and 6.6.
> > > > >
> > > > > It seems like the test is not ready to use so many threads. Actual runtime with four threads is SHORTER than with 72 threads.
> > > > >
> > > > > Thanks
> > > > > Jirka
> > > > >
> > > > > [1] https://github.com/redhat-performance/libMicro/tree/master
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Sep 29, 2023 at 10:09?PM Julia Lawall <julia.lawall at inria.fr> wrote:
> > > > >       Attached are graphs from a small extract of the run of wordcount on the
> > > > >       4-socket Intel 6130 before and after the introduction of maple trees.
> > > > >
> > > > >       The kernel called beforemaple is 6.0.0-rc3-00220-g000a449345bb
> > > > >       The kernel called aftermaple is 6.0.0-rc3-00286-gc154124fe925
> > > > >
> > > > >       trace-cmd is given the argument -e syscalls, so all system calls are
> > > > >       traced.  The only ones that happen in this region are mprotects.
> > > > >
> > > > >       My interpretation is that there are the towers of enter mprotects that
> > > > >       subsequently block on a rwsem, and then wake up later to do an exit.
> > > > >       Other mprotects manage to sneak in along the way, because rwsems are
> > > > >       not fair.  This is probably orthogonal to maple trees, though.
> > > > >
> > > > >       julia
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -Jirka
> > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > -Jirka
> > >
> > >
>
>
>
> --
> -Jirka
>
>



----- End forwarded message -----


From paulenes252 at gmail.com  Tue Apr 16 14:55:36 2024
From: paulenes252 at gmail.com (Dip Paul Enes)
Date: Tue, 16 Apr 2024 22:55:36 +0100
Subject: Very Urgent Reply!!!!
Message-ID: <661ef3f4.050a0220.32cd.0b61@mx.google.com>

Attention Sir/Madam,

I hope this message finds you well. I am writing to inform you of some exciting news regarding the delivery of your consignment. Diplomat James Morgan, who has been mandated by our company to ensure the safe and prompt delivery of your consignment, has just arrived in your city.

I am delighted to inform you that Diplomat James Morgan has successfully completed all the necessary procedures and documentation for the swift release and delivery of your consignment. He brings with him years of experience and expertise in handling diplomatic deliveries, and we are confident that he will ensure the successful completion of this important transaction.

Given the significance of the consignment to you, we have arranged for Diplomat James Morgan to personally oversee its delivery to your designated location. His professionalism, attention to detail, and commitment to providing excellent customer service make him the ideal choice for this crucial task.

We understand that you have eagerly been awaiting the arrival of your consignment, and we apologize for any delays or inconveniences you may have experienced during this process. Rest assured that we are doing everything in our power to make sure your consignment arrives in perfect condition and within the shortest possible time frame.

Diplomat James Morgan will contact you directly to arrange a convenient delivery date and time. Please ensure that you are available to receive the consignment or designate a trusted representative who can accept it on your behalf. You may be required to provide valid identification upon delivery, as per standard protocol.

Should you have any questions or concerns, please do not hesitate to reach out to me directly at dipmorgan7 at gmail.com. Your satisfaction is our top priority, and we are committed to resolving any issues you may have promptly and effectively.

Thank you for choosing our services for the delivery of your consignment. We appreciate your trust in our company and assure you that we will continue to strive for excellence throughout this process.

Wishing you a seamless delivery experience and a pleasant day ahead.

Warm regards,

Dip James Morgan


From Liam.Howlett at oracle.com  Mon Apr 22 07:13:17 2024
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Mon, 22 Apr 2024 10:13:17 -0400
Subject: general protection fault in mas_empty_area_rev
In-Reply-To: <CAJg=8jyuSxDL6XvqEXY_66M20psRK2J53oBTP+fjV5xpW2-R6w@mail.gmail.com>
References: <CAJg=8jyuSxDL6XvqEXY_66M20psRK2J53oBTP+fjV5xpW2-R6w@mail.gmail.com>
Message-ID: <uekqafv4wx5axijnnfybnxixui3ruzy3mkxirflv7tb3ovrtbk@ounqurycykuv>

* Marius Fleischer <fleischermarius at gmail.com> [240420 16:08]:
> Hi,
> 
> 
> We would like to report the following bug which has been found by our
> modified version of syzkaller.
> 
> ======================================================
> 
> description: general protection fault in mas_empty_area_rev
> 
> affected file: lib/maple_tree.c
> 
> kernel version: 6.9-rc4
> 
> kernel commit: 0bbac3facb5d6cc0171c45c9873a2dc96bea9680
> 
> git tree: upstream
> 
> kernel config: attached
> 
> crash reproducer: attached
> 
> ======================================================


Thank you for reporting this issue.  I'm currently looking at what went
wrong.

It does not occur with my configuration against the reported kernel
version.  I'll attempt to recreate it with your kernel config next -
with whatever modifications I need to get it to boot in my test
environment.

> 
> Crash log:
> 
> general protection fault, probably for non-canonical address
> 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
> 
> KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> 
> CPU: 0 PID: 79545 Comm: syz-executor.0 Not tainted 6.9.0-rc4-dirty #3

This indicates that you built with your own patches.  Could you test an
unmodified 6.9.0-rc4 with your setup?

Thanks,
Liam

> 
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1
> 04/01/2014
> 
> RIP: 0010:ma_dead_node lib/maple_tree.c:560 [inline]
> 
> RIP: 0010:mas_data_end lib/maple_tree.c:1450 [inline]
> 
> RIP: 0010:mas_empty_area_rev+0x15ad/0x2320 lib/maple_tree.c:5114
> 
...

> Call Trace:
> 
>  <TASK>
> 
>  unmapped_area_topdown mm/mmap.c:1643 [inline]
> 
>  vm_unmapped_area+0x2db/0xb30 mm/mmap.c:1682
> 
>  arch_get_unmapped_area_topdown+0x384/0x750 arch/x86/kernel/sys_x86_64.c:212
> 
>  thp_get_unmapped_area mm/huge_memory.c:864 [inline]
> 
>  thp_get_unmapped_area+0x361/0x430 mm/huge_memory.c:854
> 
>  get_unmapped_area+0x1db/0x3e0 mm/mmap.c:1845
> 
>  do_mmap+0x282/0xef0 mm/mmap.c:1261
> 
>  vm_mmap_pgoff+0x1a7/0x3b0 mm/util.c:573
...



From fleischermarius at gmail.com  Mon Apr 22 08:11:32 2024
From: fleischermarius at gmail.com (Marius Fleischer)
Date: Mon, 22 Apr 2024 08:11:32 -0700
Subject: general protection fault in mas_empty_area_rev
In-Reply-To: <uekqafv4wx5axijnnfybnxixui3ruzy3mkxirflv7tb3ovrtbk@ounqurycykuv>
References: <CAJg=8jyuSxDL6XvqEXY_66M20psRK2J53oBTP+fjV5xpW2-R6w@mail.gmail.com>
 <uekqafv4wx5axijnnfybnxixui3ruzy3mkxirflv7tb3ovrtbk@ounqurycykuv>
Message-ID: <CAJg=8jzRT=oA9g6AGd1KmAY3GBkKkczj1rCqQ+pik5LmUQYd_A@mail.gmail.com>

Hi Liam,

Thank you so much for the response!

> >
> > Crash log:
> >
> > general protection fault, probably for non-canonical address
> > 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
> >
> > KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> >
> > CPU: 0 PID: 79545 Comm: syz-executor.0 Not tainted 6.9.0-rc4-dirty #3
>
> This indicates that you built with your own patches.  Could you test an
> unmodified 6.9.0-rc4 with your setup?
>

I'm very sorry for this oversight. I had applied the patches for another bug
from this conversation
(https://lore.kernel.org/all/20240404070702.2744-3-osalvador at suse.de/T/#m480f21ab850996395082d0faab7f624f45b83781)
I will test the reproducer without these patches and get back to you!

If there is any other information I can provide to help you, please let me know!

Wishing you a lovely start to the week!

Best,
Marius


From Liam.Howlett at oracle.com  Mon Apr 22 08:24:39 2024
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Mon, 22 Apr 2024 11:24:39 -0400
Subject: general protection fault in mas_empty_area_rev
In-Reply-To: <CAJg=8jzRT=oA9g6AGd1KmAY3GBkKkczj1rCqQ+pik5LmUQYd_A@mail.gmail.com>
References: <CAJg=8jyuSxDL6XvqEXY_66M20psRK2J53oBTP+fjV5xpW2-R6w@mail.gmail.com>
 <uekqafv4wx5axijnnfybnxixui3ruzy3mkxirflv7tb3ovrtbk@ounqurycykuv>
 <CAJg=8jzRT=oA9g6AGd1KmAY3GBkKkczj1rCqQ+pik5LmUQYd_A@mail.gmail.com>
Message-ID: <7jhx44ynje54wfcq3bkaui5w6oox7ypd7cgg4u5zhue6rf5tok@nj6jaxppzq2b>

* Marius Fleischer <fleischermarius at gmail.com> [240422 11:11]:
> Hi Liam,
> 
> Thank you so much for the response!
> 
> > >
> > > Crash log:
> > >
> > > general protection fault, probably for non-canonical address
> > > 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
> > >
> > > KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> > >
> > > CPU: 0 PID: 79545 Comm: syz-executor.0 Not tainted 6.9.0-rc4-dirty #3
> >
> > This indicates that you built with your own patches.  Could you test an
> > unmodified 6.9.0-rc4 with your setup?
> >
> 
> I'm very sorry for this oversight. I had applied the patches for another bug
> from this conversation
> (https://lore.kernel.org/all/20240404070702.2744-3-osalvador at suse.de/T/#m480f21ab850996395082d0faab7f624f45b83781)
> I will test the reproducer without these patches and get back to you!

After testing with your config, I can see that those fixes are needed to
boot.

I am going to try 6.9-rc5 with your configuration and see if I can
trigger the issue there.

> 
> If there is any other information I can provide to help you, please let me know!
> 
> Wishing you a lovely start to the week!

Thanks for the prompt response and information.

Regards,
Liam


From Liam.Howlett at oracle.com  Mon Apr 22 10:05:15 2024
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Mon, 22 Apr 2024 13:05:15 -0400
Subject: general protection fault in mas_empty_area_rev
In-Reply-To: <7jhx44ynje54wfcq3bkaui5w6oox7ypd7cgg4u5zhue6rf5tok@nj6jaxppzq2b>
References: <CAJg=8jyuSxDL6XvqEXY_66M20psRK2J53oBTP+fjV5xpW2-R6w@mail.gmail.com>
 <uekqafv4wx5axijnnfybnxixui3ruzy3mkxirflv7tb3ovrtbk@ounqurycykuv>
 <CAJg=8jzRT=oA9g6AGd1KmAY3GBkKkczj1rCqQ+pik5LmUQYd_A@mail.gmail.com>
 <7jhx44ynje54wfcq3bkaui5w6oox7ypd7cgg4u5zhue6rf5tok@nj6jaxppzq2b>
Message-ID: <usubtr2bibcnwca3rk3ytbd2jbpvshgu44faujrrrcnidnrr25@ttdhvhrz34vs>

* Liam R. Howlett <Liam.Howlett at oracle.com> [240422 11:25]:
> * Marius Fleischer <fleischermarius at gmail.com> [240422 11:11]:
> > Hi Liam,
> > 
> > Thank you so much for the response!
> > 
> > > >
> > > > Crash log:
> > > >
> > > > general protection fault, probably for non-canonical address
> > > > 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
> > > >
> > > > KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> > > >
> > > > CPU: 0 PID: 79545 Comm: syz-executor.0 Not tainted 6.9.0-rc4-dirty #3
> > >
> > > This indicates that you built with your own patches.  Could you test an
> > > unmodified 6.9.0-rc4 with your setup?
> > >
> > 
> > I'm very sorry for this oversight. I had applied the patches for another bug
> > from this conversation
> > (https://lore.kernel.org/all/20240404070702.2744-3-osalvador at suse.de/T/#m480f21ab850996395082d0faab7f624f45b83781)
> > I will test the reproducer without these patches and get back to you!
> 
> After testing with your config, I can see that those fixes are needed to
> boot.
> 
> I am going to try 6.9-rc5 with your configuration and see if I can
> trigger the issue there.
> 

The reproducer does not trigger for me with your configuration and
reproducer.

Does it still happen for you in 6.9-rc5?

Thanks,
Liam


From fleischermarius at gmail.com  Mon Apr 22 11:07:20 2024
From: fleischermarius at gmail.com (Marius Fleischer)
Date: Mon, 22 Apr 2024 11:07:20 -0700
Subject: general protection fault in mas_empty_area_rev
In-Reply-To: <usubtr2bibcnwca3rk3ytbd2jbpvshgu44faujrrrcnidnrr25@ttdhvhrz34vs>
References: <CAJg=8jyuSxDL6XvqEXY_66M20psRK2J53oBTP+fjV5xpW2-R6w@mail.gmail.com>
 <uekqafv4wx5axijnnfybnxixui3ruzy3mkxirflv7tb3ovrtbk@ounqurycykuv>
 <CAJg=8jzRT=oA9g6AGd1KmAY3GBkKkczj1rCqQ+pik5LmUQYd_A@mail.gmail.com>
 <7jhx44ynje54wfcq3bkaui5w6oox7ypd7cgg4u5zhue6rf5tok@nj6jaxppzq2b> <usubtr2bibcnwca3rk3ytbd2jbpvshgu44faujrrrcnidnrr25@ttdhvhrz34vs>
Message-ID: <CAJg=8jyaV20PannVxVQrqasmo3RCTAjOWfmkdm3ehviMoc=V-w@mail.gmail.com>

Hi Liam,

On Mon, 22 Apr 2024 at 10:05, Liam R. Howlett <Liam.Howlett at oracle.com> wrote:
> * Liam R. Howlett <Liam.Howlett at oracle.com> [240422 11:25]:
> > * Marius Fleischer <fleischermarius at gmail.com> [240422 11:11]:
> > > Hi Liam,
> > >
> > > Thank you so much for the response!
> > >
> > > > >
> > > > > Crash log:
> > > > >
> > > > > general protection fault, probably for non-canonical address
> > > > > 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
> > > > >
> > > > > KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> > > > >
> > > > > CPU: 0 PID: 79545 Comm: syz-executor.0 Not tainted 6.9.0-rc4-dirty #3
> > > >
> > > > This indicates that you built with your own patches.  Could you test an
> > > > unmodified 6.9.0-rc4 with your setup?
> > > >
> > >
> > > I'm very sorry for this oversight. I had applied the patches for another bug
> > > from this conversation
> > > (https://lore.kernel.org/all/20240404070702.2744-3-osalvador at suse.de/T/#m480f21ab850996395082d0faab7f624f45b83781)
> > > I will test the reproducer without these patches and get back to you!
> >
> > After testing with your config, I can see that those fixes are needed to
> > boot.
> >
> > I am going to try 6.9-rc5 with your configuration and see if I can
> > trigger the issue there.
> >
>
> The reproducer does not trigger for me with your configuration and
> reproducer.
>
> Does it still happen for you in 6.9-rc5?
>
You are right, indeed, I was not able to boot v6.9-rc4 without the fixes.

I tested the reproducer on 6.9-rc5 (ed30a4a51bb196781c8058073ea720133a65596f)
and it still triggers the crash in my setup. How can I help you
further troubleshoot
this issue?

Thanks,
Marius


From Liam.Howlett at oracle.com  Mon Apr 22 11:53:17 2024
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Mon, 22 Apr 2024 14:53:17 -0400
Subject: general protection fault in mas_empty_area_rev
In-Reply-To: <CAJg=8jyaV20PannVxVQrqasmo3RCTAjOWfmkdm3ehviMoc=V-w@mail.gmail.com>
References: <CAJg=8jyuSxDL6XvqEXY_66M20psRK2J53oBTP+fjV5xpW2-R6w@mail.gmail.com>
 <uekqafv4wx5axijnnfybnxixui3ruzy3mkxirflv7tb3ovrtbk@ounqurycykuv>
 <CAJg=8jzRT=oA9g6AGd1KmAY3GBkKkczj1rCqQ+pik5LmUQYd_A@mail.gmail.com>
 <7jhx44ynje54wfcq3bkaui5w6oox7ypd7cgg4u5zhue6rf5tok@nj6jaxppzq2b>
 <usubtr2bibcnwca3rk3ytbd2jbpvshgu44faujrrrcnidnrr25@ttdhvhrz34vs>
 <CAJg=8jyaV20PannVxVQrqasmo3RCTAjOWfmkdm3ehviMoc=V-w@mail.gmail.com>
Message-ID: <4vyuejd7gikyjlbmcpmdcemplminhy27ltbodmq7nkjsozzod7@ttzgzxrjp63y>

* Marius Fleischer <fleischermarius at gmail.com> [240422 14:07]:
> Hi Liam,
> 
> On Mon, 22 Apr 2024 at 10:05, Liam R. Howlett <Liam.Howlett at oracle.com> wrote:
> > * Liam R. Howlett <Liam.Howlett at oracle.com> [240422 11:25]:
> > > * Marius Fleischer <fleischermarius at gmail.com> [240422 11:11]:
> > > > Hi Liam,
> > > >
> > > > Thank you so much for the response!
> > > >
> > > > > >
> > > > > > Crash log:
> > > > > >
> > > > > > general protection fault, probably for non-canonical address
> > > > > > 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
> > > > > >
> > > > > > KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> > > > > >
> > > > > > CPU: 0 PID: 79545 Comm: syz-executor.0 Not tainted 6.9.0-rc4-dirty #3
> > > > >
> > > > > This indicates that you built with your own patches.  Could you test an
> > > > > unmodified 6.9.0-rc4 with your setup?
> > > > >
> > > >
> > > > I'm very sorry for this oversight. I had applied the patches for another bug
> > > > from this conversation
> > > > (https://lore.kernel.org/all/20240404070702.2744-3-osalvador at suse.de/T/#m480f21ab850996395082d0faab7f624f45b83781)
> > > > I will test the reproducer without these patches and get back to you!
> > >
> > > After testing with your config, I can see that those fixes are needed to
> > > boot.
> > >
> > > I am going to try 6.9-rc5 with your configuration and see if I can
> > > trigger the issue there.
> > >
> >
> > The reproducer does not trigger for me with your configuration and
> > reproducer.
> >
> > Does it still happen for you in 6.9-rc5?
> >
> You are right, indeed, I was not able to boot v6.9-rc4 without the fixes.
> 
> I tested the reproducer on 6.9-rc5 (ed30a4a51bb196781c8058073ea720133a65596f)
> and it still triggers the crash in my setup. How can I help you
> further troubleshoot
> this issue?

Can you try the attached patch and see if that stops the crash?

Thanks,
Liam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_20240422.patch
Type: text/x-diff
Size: 918 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/maple-tree/attachments/20240422/707bdc10/attachment-0001.bin>

From fleischermarius at gmail.com  Mon Apr 22 12:34:16 2024
From: fleischermarius at gmail.com (Marius Fleischer)
Date: Mon, 22 Apr 2024 12:34:16 -0700
Subject: general protection fault in mas_empty_area_rev
In-Reply-To: <4vyuejd7gikyjlbmcpmdcemplminhy27ltbodmq7nkjsozzod7@ttzgzxrjp63y>
References: <CAJg=8jyuSxDL6XvqEXY_66M20psRK2J53oBTP+fjV5xpW2-R6w@mail.gmail.com>
 <uekqafv4wx5axijnnfybnxixui3ruzy3mkxirflv7tb3ovrtbk@ounqurycykuv>
 <CAJg=8jzRT=oA9g6AGd1KmAY3GBkKkczj1rCqQ+pik5LmUQYd_A@mail.gmail.com>
 <7jhx44ynje54wfcq3bkaui5w6oox7ypd7cgg4u5zhue6rf5tok@nj6jaxppzq2b>
 <usubtr2bibcnwca3rk3ytbd2jbpvshgu44faujrrrcnidnrr25@ttdhvhrz34vs>
 <CAJg=8jyaV20PannVxVQrqasmo3RCTAjOWfmkdm3ehviMoc=V-w@mail.gmail.com> <4vyuejd7gikyjlbmcpmdcemplminhy27ltbodmq7nkjsozzod7@ttzgzxrjp63y>
Message-ID: <CAJg=8jx3jVc-Z-z7=WJFhv1TjH8MW6oTQo69xCDhxc5aX6H_=g@mail.gmail.com>

Hi Liam,

On Mon, 22 Apr 2024 at 11:53, Liam R. Howlett <Liam.Howlett at oracle.com> wrote:
> * Marius Fleischer <fleischermarius at gmail.com> [240422 14:07]:
> > Hi Liam,
> >
> > On Mon, 22 Apr 2024 at 10:05, Liam R. Howlett <Liam.Howlett at oracle.com> wrote:
> > > * Liam R. Howlett <Liam.Howlett at oracle.com> [240422 11:25]:
> > > > * Marius Fleischer <fleischermarius at gmail.com> [240422 11:11]:
> > > > > Hi Liam,
> > > > >
> > > > > Thank you so much for the response!
> > > > >
> > > > > > >
> > > > > > > Crash log:
> > > > > > >
> > > > > > > general protection fault, probably for non-canonical address
> > > > > > > 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
> > > > > > >
> > > > > > > KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
> > > > > > >
> > > > > > > CPU: 0 PID: 79545 Comm: syz-executor.0 Not tainted 6.9.0-rc4-dirty #3
> > > > > >
> > > > > > This indicates that you built with your own patches.  Could you test an
> > > > > > unmodified 6.9.0-rc4 with your setup?
> > > > > >
> > > > >
> > > > > I'm very sorry for this oversight. I had applied the patches for another bug
> > > > > from this conversation
> > > > > (https://lore.kernel.org/all/20240404070702.2744-3-osalvador at suse.de/T/#m480f21ab850996395082d0faab7f624f45b83781)
> > > > > I will test the reproducer without these patches and get back to you!
> > > >
> > > > After testing with your config, I can see that those fixes are needed to
> > > > boot.
> > > >
> > > > I am going to try 6.9-rc5 with your configuration and see if I can
> > > > trigger the issue there.
> > > >
> > >
> > > The reproducer does not trigger for me with your configuration and
> > > reproducer.
> > >
> > > Does it still happen for you in 6.9-rc5?
> > >
> > You are right, indeed, I was not able to boot v6.9-rc4 without the fixes.
> >
> > I tested the reproducer on 6.9-rc5 (ed30a4a51bb196781c8058073ea720133a65596f)
> > and it still triggers the crash in my setup. How can I help you
> > further troubleshoot
> > this issue?
>
> Can you try the attached patch and see if that stops the crash?
>

I tested your patch against 6.9-rc5. It stops the crash.

Best,
Marius


From Liam.Howlett at oracle.com  Mon Apr 22 13:33:49 2024
From: Liam.Howlett at oracle.com (Liam R. Howlett)
Date: Mon, 22 Apr 2024 16:33:49 -0400
Subject: [PATCH] maple_tree: Fix mas_empty_area_rev() null pointer dereference
Message-ID: <20240422203349.2418465-1-Liam.Howlett@oracle.com>

Currently the code calls mas_start() followed by mas_data_end() if the
maple state is MA_START, but mas_start() may return with the maple state
node == NULL.  This will lead to a null pointer dereference when
checking information in the NULL node, which is done in mas_data_end().

Avoid setting the offset if there is no node by waiting until after the
maple state is checked for an empty or single entry state.

A user could trigger the events to cause a kernel oops by unmapping all
vmas to produce an empty maple tree, then mapping a vma that would cause
the scenario described above.

Reported-by: Marius Fleischer <fleischermarius at gmail.com>
Closes: https://lore.kernel.org/lkml/CAJg=8jyuSxDL6XvqEXY_66M20psRK2J53oBTP+fjV5xpW2-R6w at mail.gmail.com/
Link: https://lore.kernel.org/lkml/CAJg=8jyuSxDL6XvqEXY_66M20psRK2J53oBTP+fjV5xpW2-R6w at mail.gmail.com/
Fixes: 54a611b60590 ("Maple Tree: add new data structure")
Tested-by: Marius Fleischer <fleischermarius at gmail.com>
Tested-by: Sidhartha Kumar <sidhartha.kumar at oracle.com>
Cc: maple-tree at lists.infradead.org
Cc: linux-mm at kvack.org
Cc: stable at vger.kernel.org
Signed-off-by: Liam R. Howlett <Liam.Howlett at oracle.com>
---
 lib/maple_tree.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/lib/maple_tree.c b/lib/maple_tree.c
index 55e1b35bf877..2d7d27e6ae3c 100644
--- a/lib/maple_tree.c
+++ b/lib/maple_tree.c
@@ -5109,18 +5109,18 @@ int mas_empty_area_rev(struct ma_state *mas, unsigned long min,
 	if (size == 0 || max - min < size - 1)
 		return -EINVAL;
 
-	if (mas_is_start(mas)) {
+	if (mas_is_start(mas))
 		mas_start(mas);
-		mas->offset = mas_data_end(mas);
-	} else if (mas->offset >= 2) {
-		mas->offset -= 2;
-	} else if (!mas_rewind_node(mas)) {
+	else if ((mas->offset < 2) && (!mas_rewind_node(mas)))
 		return -EBUSY;
-	}
 
-	/* Empty set. */
-	if (mas_is_none(mas) || mas_is_ptr(mas))
+	if (unlikely(mas_is_none(mas) || mas_is_ptr(mas)))
 		return mas_sparse_area(mas, min, max, size, false);
+	else if (mas->offset >= 2)
+		mas->offset -= 2;
+	else
+		mas->offset = mas_data_end(mas);
+
 
 	/* The start of the window can only be within these values. */
 	mas->index = min;
-- 
2.43.0



