[syzbot] [mm?] WARNING in copy_huge_pmd

[syzbot] [mm?] WARNING in copy_huge_pmd

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    88264981f208 Merge tag 'sched_ext-for-6.12' of git://git.k..
git tree:       upstream
console+strace: https://syzkaller.appspot.com/x/log.txt?x=16c36c27980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=e851828834875d6f
dashboard link: https://syzkaller.appspot.com/bug?extid=bf2c35fa302ebe3c7471
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12773080580000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16ed5e9f980000

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/0e011ac37c93/disk-88264981.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f5c65577e19e/vmlinux-88264981.xz
kernel image: https://storage.googleapis.com/syzbot-assets/984d963c8ea1/bzImage-88264981.xz

The issue was bisected to:

commit 75182022a0439788415b2dd1db3086e07aa506f7
Author: Peter Xu <peterx@redhat.com>
Date:   Mon Aug 26 20:43:51 2024 +0000

    mm/x86: support large pfn mappings

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17df9c27980000
final oops:     https://syzkaller.appspot.com/x/report.txt?x=143f9c27980000
console output: https://syzkaller.appspot.com/x/log.txt?x=103f9c27980000

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+bf2c35fa302ebe3c7471@syzkaller.appspotmail.com
Fixes: 75182022a043 ("mm/x86: support large pfn mappings")

------------[ cut here ]------------
WARNING: CPU: 1 PID: 5508 at mm/huge_memory.c:1602 copy_huge_pmd+0x102c/0x1c60 mm/huge_memory.c:1602
Modules linked in:
CPU: 1 UID: 0 PID: 5508 Comm: syz-executor274 Not tainted 6.11.0-syzkaller-08481-g88264981f208 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
RIP: 0010:copy_huge_pmd+0x102c/0x1c60 mm/huge_memory.c:1602
Code: ff 90 0f 0b 90 e9 2e f5 ff ff e8 8f fc 92 ff 48 ff cb e9 0f f7 ff ff e8 82 fc 92 ff 48 ff cb e9 8a f7 ff ff e8 75 fc 92 ff 90 <0f> 0b 90 e9 11 fd ff ff 4c 8d ac 24 00 01 00 00 48 b8 06 fe ff ff
RSP: 0018:ffffc90003cdf0c0 EFLAGS: 00010293
RAX: ffffffff8201bd3b RBX: ffff88803090c118 RCX: ffff8880317a9e00
RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
RBP: ffffc90003cdf248 R08: ffffffff8201bc06 R09: 1ffffffff2038ef5
R10: dffffc0000000000 R11: fffffbfff2038ef6 R12: ffff88802fab89c0
R13: d7ffe7fff1cbfe02 R14: 0000000000000020 R15: ffff888031e5b780
FS:  00007f38182a06c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f381831d9f0 CR3: 000000007b18c000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <TASK>
 copy_pmd_range+0x425/0x85f0 mm/memory.c:1245
 copy_pud_range mm/memory.c:1292 [inline]
 copy_p4d_range mm/memory.c:1316 [inline]
 copy_page_range+0x99f/0xe90 mm/memory.c:1414
 dup_mmap kernel/fork.c:750 [inline]
 dup_mm kernel/fork.c:1674 [inline]
 copy_mm+0x11fb/0x1f40 kernel/fork.c:1723
 copy_process+0x1845/0x3d50 kernel/fork.c:2375
 kernel_clone+0x226/0x8f0 kernel/fork.c:2787
 __do_sys_clone3 kernel/fork.c:3091 [inline]
 __se_sys_clone3+0x2cb/0x350 kernel/fork.c:3070
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f3818306429
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f38182a0118 EFLAGS: 00000202 ORIG_RAX: 00000000000001b3
RAX: ffffffffffffffda RBX: 00007f3818390318 RCX: 00007f3818306429
RDX: 00007f38182e2ab6 RSI: 0000000000000058 RDI: 00007f38182a0120
RBP: 00007f3818390310 R08: 00007fffb191b837 R09: 0000000000000080
R10: 0000000000000000 R11: 0000000000000202 R12: 00007f381835d074
R13: 00007f381839031c R14: 00007f38182a0120 R15: 000000080000000e
 </TASK>


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Re: [syzbot] [mm?] WARNING in copy_huge_pmd

[David Hildenbrand]

On 23.09.24 14:18, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    88264981f208 Merge tag 'sched_ext-for-6.12' of git://git.k..
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=16c36c27980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=e851828834875d6f
> dashboard link: https://syzkaller.appspot.com/bug?extid=bf2c35fa302ebe3c7471
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12773080580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16ed5e9f980000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/0e011ac37c93/disk-88264981.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/f5c65577e19e/vmlinux-88264981.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/984d963c8ea1/bzImage-88264981.xz
> 
> The issue was bisected to:
> 
> commit 75182022a0439788415b2dd1db3086e07aa506f7
> Author: Peter Xu <peterx@redhat.com>
> Date:   Mon Aug 26 20:43:51 2024 +0000
> 
>      mm/x86: support large pfn mappings
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17df9c27980000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=143f9c27980000
> console output: https://syzkaller.appspot.com/x/log.txt?x=103f9c27980000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+bf2c35fa302ebe3c7471@syzkaller.appspotmail.com
> Fixes: 75182022a043 ("mm/x86: support large pfn mappings")
> 
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 5508 at mm/huge_memory.c:1602 copy_huge_pmd+0x102c/0x1c60 mm/huge_memory.c:1602

This is the

VM_WARN_ON_ONCE(is_cow_mapping(src_vma->vm_flags) && pmd_write(pmd))

So we have a special-marked PMD in a COW mapping.

The reproducer seems to involve fuse, but not sure if that makes a 
difference here.

-- 
Cheers,

David / dhildenb

Re: [syzbot] [mm?] WARNING in copy_huge_pmd

[Peter Xu]

On Tue, Sep 24, 2024 at 04:45:00PM +0200, David Hildenbrand wrote:
> On 23.09.24 14:18, syzbot wrote:
> > Hello,
> > 
> > syzbot found the following issue on:
> > 
> > HEAD commit:    88264981f208 Merge tag 'sched_ext-for-6.12' of git://git.k..
> > git tree:       upstream
> > console+strace: https://syzkaller.appspot.com/x/log.txt?x=16c36c27980000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=e851828834875d6f
> > dashboard link: https://syzkaller.appspot.com/bug?extid=bf2c35fa302ebe3c7471
> > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12773080580000
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16ed5e9f980000
> > 
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/0e011ac37c93/disk-88264981.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/f5c65577e19e/vmlinux-88264981.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/984d963c8ea1/bzImage-88264981.xz
> > 
> > The issue was bisected to:
> > 
> > commit 75182022a0439788415b2dd1db3086e07aa506f7
> > Author: Peter Xu <peterx@redhat.com>
> > Date:   Mon Aug 26 20:43:51 2024 +0000
> > 
> >      mm/x86: support large pfn mappings
> > 
> > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17df9c27980000
> > final oops:     https://syzkaller.appspot.com/x/report.txt?x=143f9c27980000
> > console output: https://syzkaller.appspot.com/x/log.txt?x=103f9c27980000
> > 
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+bf2c35fa302ebe3c7471@syzkaller.appspotmail.com
> > Fixes: 75182022a043 ("mm/x86: support large pfn mappings")
> > 
> > ------------[ cut here ]------------
> > WARNING: CPU: 1 PID: 5508 at mm/huge_memory.c:1602 copy_huge_pmd+0x102c/0x1c60 mm/huge_memory.c:1602
> 
> This is the
> 
> VM_WARN_ON_ONCE(is_cow_mapping(src_vma->vm_flags) && pmd_write(pmd))
> 
> So we have a special-marked PMD in a COW mapping.
> 
> The reproducer seems to involve fuse, but not sure if that makes a
> difference here.

That chunk of code seems to be there only making sure the test won't get
blocked due to any fused based fs being stuck, via writting to the "abort"
file:

      snprintf(abort, sizeof(abort), "/sys/fs/fuse/connections/%s/abort",
               ent->d_name);
      int fd = open(abort, O_WRONLY);
      if (fd == -1) {
        continue;
      }
      if (write(fd, abort, 1) < 0) {
      }
      close(fd);

So far looks not relevant to this issue indeed.

Unfortunately I cannot reproduce it even with the reproducer.  So this one
is a bit tricky..

What confuses me yet is how that special bit is set, if it's only used so
far with vfio-pci, and this test doesn't seem to have it involved.

The test keeps invoking processes, then threads, doing concurrent accesses
over a few stuff (madvise, mremap, migrate_pages, munmap, etc.) on the
pre-mapped areas, but none of them seem to create new memory that can
provide hint on how special bit can start to occur.

I wonder if some of these operations can race in a way that mm can wrongly
create the special bit (alone with it being writable).. and then it could
be a historical bug, only captured by this patchset due to the newly added
WARN_ON_ONCE somehow, then it could mean that it's not the WRITE bit that
is not intended, but the SPECIAL bit altogether.

Thanks,

-- 
Peter Xu

Re: [syzbot] [mm?] WARNING in copy_huge_pmd

[David Hildenbrand]

On 25.09.24 18:59, Peter Xu wrote:
> On Tue, Sep 24, 2024 at 04:45:00PM +0200, David Hildenbrand wrote:
>> On 23.09.24 14:18, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit:    88264981f208 Merge tag 'sched_ext-for-6.12' of git://git.k..
>>> git tree:       upstream
>>> console+strace: https://syzkaller.appspot.com/x/log.txt?x=16c36c27980000
>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=e851828834875d6f
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bf2c35fa302ebe3c7471
>>> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12773080580000
>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16ed5e9f980000
>>>
>>> Downloadable assets:
>>> disk image: https://storage.googleapis.com/syzbot-assets/0e011ac37c93/disk-88264981.raw.xz
>>> vmlinux: https://storage.googleapis.com/syzbot-assets/f5c65577e19e/vmlinux-88264981.xz
>>> kernel image: https://storage.googleapis.com/syzbot-assets/984d963c8ea1/bzImage-88264981.xz
>>>
>>> The issue was bisected to:
>>>
>>> commit 75182022a0439788415b2dd1db3086e07aa506f7
>>> Author: Peter Xu <peterx@redhat.com>
>>> Date:   Mon Aug 26 20:43:51 2024 +0000
>>>
>>>       mm/x86: support large pfn mappings
>>>
>>> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17df9c27980000
>>> final oops:     https://syzkaller.appspot.com/x/report.txt?x=143f9c27980000
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=103f9c27980000
>>>
>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>> Reported-by: syzbot+bf2c35fa302ebe3c7471@syzkaller.appspotmail.com
>>> Fixes: 75182022a043 ("mm/x86: support large pfn mappings")
>>>
>>> ------------[ cut here ]------------
>>> WARNING: CPU: 1 PID: 5508 at mm/huge_memory.c:1602 copy_huge_pmd+0x102c/0x1c60 mm/huge_memory.c:1602
>>
>> This is the
>>
>> VM_WARN_ON_ONCE(is_cow_mapping(src_vma->vm_flags) && pmd_write(pmd))
>>
>> So we have a special-marked PMD in a COW mapping.
>>
>> The reproducer seems to involve fuse, but not sure if that makes a
>> difference here.
> 
> That chunk of code seems to be there only making sure the test won't get
> blocked due to any fused based fs being stuck, via writting to the "abort"
> file:
> 
>        snprintf(abort, sizeof(abort), "/sys/fs/fuse/connections/%s/abort",
>                 ent->d_name);
>        int fd = open(abort, O_WRONLY);
>        if (fd == -1) {
>          continue;
>        }
>        if (write(fd, abort, 1) < 0) {
>        }
>        close(fd);
> 
> So far looks not relevant to this issue indeed.
> 
> Unfortunately I cannot reproduce it even with the reproducer.  So this one
> is a bit tricky..
> 
> What confuses me yet is how that special bit is set, if it's only used so
> far with vfio-pci, and this test doesn't seem to have it involved.
> 
> The test keeps invoking processes, then threads, doing concurrent accesses
> over a few stuff (madvise, mremap, migrate_pages, munmap, etc.) on the
> pre-mapped areas, but none of them seem to create new memory that can
> provide hint on how special bit can start to occur.
> 
> I wonder if some of these operations can race in a way that mm can wrongly
> create the special bit (alone with it being writable).. and then it could
> be a historical bug, only captured by this patchset due to the newly added
> WARN_ON_ONCE somehow, then it could mean that it's not the WRITE bit that
> is not intended, but the SPECIAL bit altogether.

I assume you are missing a check for present/non-swap pmds. Assume you 
have a migration entry and end up using the special bit -- which is 
perfectly fine -- your code would assume it's a present PMD with the 
special bit set.

Maybe for the time being something like:

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 0580ac9e47b9..e55efcad1e6c 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1586,7 +1586,7 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct 
mm_struct *src_mm,
         int ret = -ENOMEM;

         pmd = pmdp_get_lockless(src_pmd);
-       if (unlikely(pmd_special(pmd))) {
+       if (unlikely(pmd_present(pmd) && pmd_special(pmd))) {
                 dst_ptl = pmd_lock(dst_mm, dst_pmd);
                 src_ptl = pmd_lockptr(src_mm, src_pmd);
                 spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);


-- 
Cheers,

David / dhildenb

Re: [syzbot] [mm?] WARNING in copy_huge_pmd

[Peter Xu]

On Thu, Sep 26, 2024 at 12:48:19PM +0200, David Hildenbrand wrote:
> On 25.09.24 18:59, Peter Xu wrote:
> > On Tue, Sep 24, 2024 at 04:45:00PM +0200, David Hildenbrand wrote:
> > > On 23.09.24 14:18, syzbot wrote:
> > > > Hello,
> > > > 
> > > > syzbot found the following issue on:
> > > > 
> > > > HEAD commit:    88264981f208 Merge tag 'sched_ext-for-6.12' of git://git.k..
> > > > git tree:       upstream
> > > > console+strace: https://syzkaller.appspot.com/x/log.txt?x=16c36c27980000
> > > > kernel config:  https://syzkaller.appspot.com/x/.config?x=e851828834875d6f
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=bf2c35fa302ebe3c7471
> > > > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > > > syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12773080580000
> > > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16ed5e9f980000
> > > > 
> > > > Downloadable assets:
> > > > disk image: https://storage.googleapis.com/syzbot-assets/0e011ac37c93/disk-88264981.raw.xz
> > > > vmlinux: https://storage.googleapis.com/syzbot-assets/f5c65577e19e/vmlinux-88264981.xz
> > > > kernel image: https://storage.googleapis.com/syzbot-assets/984d963c8ea1/bzImage-88264981.xz
> > > > 
> > > > The issue was bisected to:
> > > > 
> > > > commit 75182022a0439788415b2dd1db3086e07aa506f7
> > > > Author: Peter Xu <peterx@redhat.com>
> > > > Date:   Mon Aug 26 20:43:51 2024 +0000
> > > > 
> > > >       mm/x86: support large pfn mappings
> > > > 
> > > > bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17df9c27980000
> > > > final oops:     https://syzkaller.appspot.com/x/report.txt?x=143f9c27980000
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=103f9c27980000
> > > > 
> > > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > > Reported-by: syzbot+bf2c35fa302ebe3c7471@syzkaller.appspotmail.com
> > > > Fixes: 75182022a043 ("mm/x86: support large pfn mappings")
> > > > 
> > > > ------------[ cut here ]------------
> > > > WARNING: CPU: 1 PID: 5508 at mm/huge_memory.c:1602 copy_huge_pmd+0x102c/0x1c60 mm/huge_memory.c:1602
> > > 
> > > This is the
> > > 
> > > VM_WARN_ON_ONCE(is_cow_mapping(src_vma->vm_flags) && pmd_write(pmd))
> > > 
> > > So we have a special-marked PMD in a COW mapping.
> > > 
> > > The reproducer seems to involve fuse, but not sure if that makes a
> > > difference here.
> > 
> > That chunk of code seems to be there only making sure the test won't get
> > blocked due to any fused based fs being stuck, via writting to the "abort"
> > file:
> > 
> >        snprintf(abort, sizeof(abort), "/sys/fs/fuse/connections/%s/abort",
> >                 ent->d_name);
> >        int fd = open(abort, O_WRONLY);
> >        if (fd == -1) {
> >          continue;
> >        }
> >        if (write(fd, abort, 1) < 0) {
> >        }
> >        close(fd);
> > 
> > So far looks not relevant to this issue indeed.
> > 
> > Unfortunately I cannot reproduce it even with the reproducer.  So this one
> > is a bit tricky..
> > 
> > What confuses me yet is how that special bit is set, if it's only used so
> > far with vfio-pci, and this test doesn't seem to have it involved.
> > 
> > The test keeps invoking processes, then threads, doing concurrent accesses
> > over a few stuff (madvise, mremap, migrate_pages, munmap, etc.) on the
> > pre-mapped areas, but none of them seem to create new memory that can
> > provide hint on how special bit can start to occur.
> > 
> > I wonder if some of these operations can race in a way that mm can wrongly
> > create the special bit (alone with it being writable).. and then it could
> > be a historical bug, only captured by this patchset due to the newly added
> > WARN_ON_ONCE somehow, then it could mean that it's not the WRITE bit that
> > is not intended, but the SPECIAL bit altogether.
> 
> I assume you are missing a check for present/non-swap pmds. Assume you have
> a migration entry and end up using the special bit -- which is perfectly
> fine -- your code would assume it's a present PMD with the special bit set.
> 
> Maybe for the time being something like:
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 0580ac9e47b9..e55efcad1e6c 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -1586,7 +1586,7 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct
> mm_struct *src_mm,
>         int ret = -ENOMEM;
> 
>         pmd = pmdp_get_lockless(src_pmd);
> -       if (unlikely(pmd_special(pmd))) {
> +       if (unlikely(pmd_present(pmd) && pmd_special(pmd))) {
>                 dst_ptl = pmd_lock(dst_mm, dst_pmd);
>                 src_ptl = pmd_lockptr(src_mm, src_pmd);
>                 spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);

Good catch!

I definitely overlooked it, and I did check the config has THP_MIGRATION
set indeed.  So it's very possible relevant.

Do you want to send a formal patch?  You can also push a branch with "#syz
test", looks like syzbot can constantly reproduce.

Thanks!

-- 
Peter Xu

Re: [syzbot] [mm?] WARNING in copy_huge_pmd

[David Hildenbrand]

On 26.09.24 15:39, Peter Xu wrote:
> On Thu, Sep 26, 2024 at 12:48:19PM +0200, David Hildenbrand wrote:
>> On 25.09.24 18:59, Peter Xu wrote:
>>> On Tue, Sep 24, 2024 at 04:45:00PM +0200, David Hildenbrand wrote:
>>>> On 23.09.24 14:18, syzbot wrote:
>>>>> Hello,
>>>>>
>>>>> syzbot found the following issue on:
>>>>>
>>>>> HEAD commit:    88264981f208 Merge tag 'sched_ext-for-6.12' of git://git.k..
>>>>> git tree:       upstream
>>>>> console+strace: https://syzkaller.appspot.com/x/log.txt?x=16c36c27980000
>>>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=e851828834875d6f
>>>>> dashboard link: https://syzkaller.appspot.com/bug?extid=bf2c35fa302ebe3c7471
>>>>> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
>>>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12773080580000
>>>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16ed5e9f980000
>>>>>
>>>>> Downloadable assets:
>>>>> disk image: https://storage.googleapis.com/syzbot-assets/0e011ac37c93/disk-88264981.raw.xz
>>>>> vmlinux: https://storage.googleapis.com/syzbot-assets/f5c65577e19e/vmlinux-88264981.xz
>>>>> kernel image: https://storage.googleapis.com/syzbot-assets/984d963c8ea1/bzImage-88264981.xz
>>>>>
>>>>> The issue was bisected to:
>>>>>
>>>>> commit 75182022a0439788415b2dd1db3086e07aa506f7
>>>>> Author: Peter Xu <peterx@redhat.com>
>>>>> Date:   Mon Aug 26 20:43:51 2024 +0000
>>>>>
>>>>>        mm/x86: support large pfn mappings
>>>>>
>>>>> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17df9c27980000
>>>>> final oops:     https://syzkaller.appspot.com/x/report.txt?x=143f9c27980000
>>>>> console output: https://syzkaller.appspot.com/x/log.txt?x=103f9c27980000
>>>>>
>>>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>>>> Reported-by: syzbot+bf2c35fa302ebe3c7471@syzkaller.appspotmail.com
>>>>> Fixes: 75182022a043 ("mm/x86: support large pfn mappings")
>>>>>
>>>>> ------------[ cut here ]------------
>>>>> WARNING: CPU: 1 PID: 5508 at mm/huge_memory.c:1602 copy_huge_pmd+0x102c/0x1c60 mm/huge_memory.c:1602
>>>>
>>>> This is the
>>>>
>>>> VM_WARN_ON_ONCE(is_cow_mapping(src_vma->vm_flags) && pmd_write(pmd))
>>>>
>>>> So we have a special-marked PMD in a COW mapping.
>>>>
>>>> The reproducer seems to involve fuse, but not sure if that makes a
>>>> difference here.
>>>
>>> That chunk of code seems to be there only making sure the test won't get
>>> blocked due to any fused based fs being stuck, via writting to the "abort"
>>> file:
>>>
>>>         snprintf(abort, sizeof(abort), "/sys/fs/fuse/connections/%s/abort",
>>>                  ent->d_name);
>>>         int fd = open(abort, O_WRONLY);
>>>         if (fd == -1) {
>>>           continue;
>>>         }
>>>         if (write(fd, abort, 1) < 0) {
>>>         }
>>>         close(fd);
>>>
>>> So far looks not relevant to this issue indeed.
>>>
>>> Unfortunately I cannot reproduce it even with the reproducer.  So this one
>>> is a bit tricky..
>>>
>>> What confuses me yet is how that special bit is set, if it's only used so
>>> far with vfio-pci, and this test doesn't seem to have it involved.
>>>
>>> The test keeps invoking processes, then threads, doing concurrent accesses
>>> over a few stuff (madvise, mremap, migrate_pages, munmap, etc.) on the
>>> pre-mapped areas, but none of them seem to create new memory that can
>>> provide hint on how special bit can start to occur.
>>>
>>> I wonder if some of these operations can race in a way that mm can wrongly
>>> create the special bit (alone with it being writable).. and then it could
>>> be a historical bug, only captured by this patchset due to the newly added
>>> WARN_ON_ONCE somehow, then it could mean that it's not the WRITE bit that
>>> is not intended, but the SPECIAL bit altogether.
>>
>> I assume you are missing a check for present/non-swap pmds. Assume you have
>> a migration entry and end up using the special bit -- which is perfectly
>> fine -- your code would assume it's a present PMD with the special bit set.
>>
>> Maybe for the time being something like:
>>
>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>> index 0580ac9e47b9..e55efcad1e6c 100644
>> --- a/mm/huge_memory.c
>> +++ b/mm/huge_memory.c
>> @@ -1586,7 +1586,7 @@ int copy_huge_pmd(struct mm_struct *dst_mm, struct
>> mm_struct *src_mm,
>>          int ret = -ENOMEM;
>>
>>          pmd = pmdp_get_lockless(src_pmd);
>> -       if (unlikely(pmd_special(pmd))) {
>> +       if (unlikely(pmd_present(pmd) && pmd_special(pmd))) {
>>                  dst_ptl = pmd_lock(dst_mm, dst_pmd);
>>                  src_ptl = pmd_lockptr(src_mm, src_pmd);
>>                  spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING);
> 
> Good catch!
> 
> I definitely overlooked it, and I did check the config has THP_MIGRATION
> set indeed.  So it's very possible relevant.
> 
> Do you want to send a formal patch?  You can also push a branch with "#syz
> test", looks like syzbot can constantly reproduce.

Yes, let me send out a patch real quick.

-- 
Cheers,

David / dhildenb

Re: [syzbot] [mm?] WARNING in copy_huge_pmd

[David Hildenbrand]

On 23.09.24 14:18, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    88264981f208 Merge tag 'sched_ext-for-6.12' of git://git.k..
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=16c36c27980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=e851828834875d6f
> dashboard link: https://syzkaller.appspot.com/bug?extid=bf2c35fa302ebe3c7471
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=12773080580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16ed5e9f980000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/0e011ac37c93/disk-88264981.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/f5c65577e19e/vmlinux-88264981.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/984d963c8ea1/bzImage-88264981.xz
> 
> The issue was bisected to:
> 
> commit 75182022a0439788415b2dd1db3086e07aa506f7
> Author: Peter Xu <peterx@redhat.com>
> Date:   Mon Aug 26 20:43:51 2024 +0000
> 
>      mm/x86: support large pfn mappings
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=17df9c27980000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=143f9c27980000
> console output: https://syzkaller.appspot.com/x/log.txt?x=103f9c27980000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+bf2c35fa302ebe3c7471@syzkaller.appspotmail.com
> Fixes: 75182022a043 ("mm/x86: support large pfn mappings")
> 
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 5508 at mm/huge_memory.c:1602 copy_huge_pmd+0x102c/0x1c60 mm/huge_memory.c:1602
> Modules linked in:
> CPU: 1 UID: 0 PID: 5508 Comm: syz-executor274 Not tainted 6.11.0-syzkaller-08481-g88264981f208 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
> RIP: 0010:copy_huge_pmd+0x102c/0x1c60 mm/huge_memory.c:1602
> Code: ff 90 0f 0b 90 e9 2e f5 ff ff e8 8f fc 92 ff 48 ff cb e9 0f f7 ff ff e8 82 fc 92 ff 48 ff cb e9 8a f7 ff ff e8 75 fc 92 ff 90 <0f> 0b 90 e9 11 fd ff ff 4c 8d ac 24 00 01 00 00 48 b8 06 fe ff ff
> RSP: 0018:ffffc90003cdf0c0 EFLAGS: 00010293
> RAX: ffffffff8201bd3b RBX: ffff88803090c118 RCX: ffff8880317a9e00
> RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000
> RBP: ffffc90003cdf248 R08: ffffffff8201bc06 R09: 1ffffffff2038ef5
> R10: dffffc0000000000 R11: fffffbfff2038ef6 R12: ffff88802fab89c0
> R13: d7ffe7fff1cbfe02 R14: 0000000000000020 R15: ffff888031e5b780
> FS:  00007f38182a06c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f381831d9f0 CR3: 000000007b18c000 CR4: 00000000003506f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>   <TASK>
>   copy_pmd_range+0x425/0x85f0 mm/memory.c:1245
>   copy_pud_range mm/memory.c:1292 [inline]
>   copy_p4d_range mm/memory.c:1316 [inline]
>   copy_page_range+0x99f/0xe90 mm/memory.c:1414
>   dup_mmap kernel/fork.c:750 [inline]
>   dup_mm kernel/fork.c:1674 [inline]
>   copy_mm+0x11fb/0x1f40 kernel/fork.c:1723
>   copy_process+0x1845/0x3d50 kernel/fork.c:2375
>   kernel_clone+0x226/0x8f0 kernel/fork.c:2787
>   __do_sys_clone3 kernel/fork.c:3091 [inline]
>   __se_sys_clone3+0x2cb/0x350 kernel/fork.c:3070
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f3818306429
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f38182a0118 EFLAGS: 00000202 ORIG_RAX: 00000000000001b3
> RAX: ffffffffffffffda RBX: 00007f3818390318 RCX: 00007f3818306429
> RDX: 00007f38182e2ab6 RSI: 0000000000000058 RDI: 00007f38182a0120
> RBP: 00007f3818390310 R08: 00007fffb191b837 R09: 0000000000000080
> R10: 0000000000000000 R11: 0000000000000202 R12: 00007f381835d074
> R13: 00007f381839031c R14: 00007f38182a0120 R15: 000000080000000e
>   </TASK>
> 
> 
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> 
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
> 
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
> 
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
> 
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
> 
> If you want to undo deduplication, reply with:
> #syz undup
> 

#syz test: https://github.com/davidhildenbrand/linux.git copy_huge_pmd_pfn

-- 
Cheers,

David / dhildenb

Re: [syzbot] [mm?] WARNING in copy_huge_pmd

[syzbot]

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger any issue:

Reported-by: syzbot+bf2c35fa302ebe3c7471@syzkaller.appspotmail.com
Tested-by: syzbot+bf2c35fa302ebe3c7471@syzkaller.appspotmail.com

Tested on:

commit:         08768b86 mm/huge_memory: check pmd_special() only afte..
git tree:       https://github.com/davidhildenbrand/linux.git copy_huge_pmd_pfn
console output: https://syzkaller.appspot.com/x/log.txt?x=1087aaa9980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=bc30a30374b0753
dashboard link: https://syzkaller.appspot.com/bug?extid=bf2c35fa302ebe3c7471
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

Note: no patches were applied.
Note: testing is done by a robot and is best-effort only.