Re: Boot regression in Linux v6.4-rc3
Linus Torvalds <[email protected]> Sat, 27 May 2023 12:34:10 -0700
| Newsgroups | gmane.linux.ports.ia64,gmane.linux.debian.ports.ia64 |
|---|---|
| Message-ID | <CAHk-=wjDQZ8snU__Y8qJ8M5H--1FtAwNq-oHKmY4CJuomWPvDw@mail.gmail.com> |
On Sat, May 27, 2023 at 11:41 AM Frank Scheiner <[email protected]> wrote: > > Ok, I put the decoded console messages on [2]. > > [2]: https://pastebin.com/dLYMijfS Ugh. Apparently ia64 decoding isn't great. But at least it gives multiple line numbers: load_module (kernel/module/main.c:2291 kernel/module/main.c:2412 kernel/module/main.c:2868) except your kernel obviously has those test-patches, so I still don't know exactly where they are. But it looks like it is in move_module(). Strange. I don't know how it gets to "__copy_user" from there... [ Looks at the ia64 code ] Oh. It turns out that it *says* __copy_user(), but the code is actually shared with the regular memcpy() function, which does GLOBAL_ENTRY(memcpy) and r28=0x7,in0 and r29=0x7,in1 mov f6=f0 mov retval=in0 br.cond.sptk .common_code ;; where that ".common_code" label is - surprise surprise - the common copy code, and so when the oops reports that the problem happened in __copy_user(), it actually is in this case just a normal memcpy. Ok, so it's probably the memcpy(dest, (void *)shdr->sh_addr, shdr->sh_size); in move_module() that takes a fault. And looking at the registers, the destination is in r17/r18, and your dump has unable to handle kernel paging request at virtual address 1000000000000000 ... r17 : 0fffffffffffffff r18 : 1000000000000000 so it's almost certainly that 'dest' that is bad. Which I guess shouldn't surprise anybody. But that's where my knowledge of ia64 and the new module loader layout ends. Linus