kpatch load crashes - kernel 3.10.19

[sububack]

I have tried loading 'memtest-patch' it worked fine. However when trying to patch the fix below, it crashed.

[host:~]$ modprobe kpatch [host:~]$ cat /proc/meminfo | grep Chunk VmallocChunk: 34359439720 kB [host:~]$ [host:~]$ insmod kpatch-patch.ko [host:~]$ [host:~]$ cat /proc/meminfo | grep Chunk TestMallocChunk: 34359439720 kB [host:~] https://git.kernel.org/cgit/linux/kernel/git/gregkh/tty.git/diff/?h=tty-linus&id=4291086b1f081b869c6d79e5b7441633dc3ace00 ## LOG:

[host:~]$ modprobe kpatch
[host:~]$ insmod kpatch-tty-fix.ko
[  148.134083] BUG: unable to handle kernel paging request at ffffffffa02bce00
[  148.135021] IP:
[  148.135021]  [<ffffffff810a0d06>] load_module+0x1ab6/0x2430
[  148.135021] PGD 1a0d067 PUD 1a0e063 PMD 33c807067 PTE 33ba4d161
[  148.135021] Oops: 0003 [#1] SMP
[  148.135021] Modules linked in: kpatch_tty_fix(+) kpatch uio_pci_proxy iptable_filter ip_tables tun bridge lowmemorykiller(C) usb_storage 8021q mrp garp stp llc ixgbevf mdio kvm_intel e1000 kvm ext4 jbd2 sg sr_mod cdrom virtio_blk virtio_pci virtio_ring virtio i2c_piix4 i2c_core ata_piix dm_mod
[  148.135021] CPU: 3 PID: 3272 Comm: insmod Tainted: G     U   C   3.10.19 #1
[  148.135021] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[  148.135021] task: ffff88033b832940 ti: ffff88033b498000 task.ti: ffff88033b498000
[  148.135021] RIP: 0010:[<ffffffff810a0d06>]
[  148.135021]  [<ffffffff810a0d06>] load_module+0x1ab6/0x2430
[  148.135021] RSP: 0018:ffff88033b499dd0  EFLAGS: 00010246
[  148.135021] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[  148.135021] RDX: ffff88033b5a7c00 RSI: 0000000000000000 RDI: ffffffff81a87ee0
[  148.135021] RBP: ffff88033b499ee0 R08: 0000000000000000 R09: 0000000000000000
[  148.135021] R10: 0000000000002b2e R11: ffff88033b499a4e R12: ffffffffa02bce18
[  148.135021] R13: ffffffffa02bce50 R14: 0000000000000001 R15: ffffffffa02bce00
[  148.135021] FS:  00007f31bae0d700(0000) GS:ffff88034c580000(0000) knlGS:0000000000000000
[  148.135021] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[  148.135021] CR2: ffffffffa02bce00 CR3: 000000033b51f000 CR4: 00000000000006e0
[  148.135021] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  148.135021] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[  148.135021] Stack:
[  148.135021]  ffffffff81274fe0 ffff88033b832940 ffff88033b499e50 ffff88033b832940
[  148.135021]  ffffffffa02bf3e8 ffffffffa02bd030 ffffffffa02bce18 0000000000000b28
[  148.135021]  ffffffffa02bf3e8 ffff880300000001 ffff880300000001 ffff88033b56ee40
[  148.135021] Call Trace:
[  148.135021]  [<ffffffff81274fe0>] ? ddebug_proc_write+0xf0/0xf0
[  148.135021]  [<ffffffff8113d96e>] ? map_vm_area+0x2e/0x40
[  148.135021]  [<ffffffff810a1741>] SyS_init_module+0xc1/0x110
[  148.135021]  [<ffffffff8152b8d9>] system_call_fastpath+0x16/0x1b
[  148.135021] Code: 00 0f 1f 40 00 74 22 49 c7 c0 32 25 61 81 89 c1 4c 89 e2 4c 89 c6 48 c7 c7 a8 c1 79 81 31 c0 e8 fd b1 47 00 e8 bb d0 47 00 31 f6 <41> c7 07 00 00 00 00 4c 89 fa 48 c7 c7 a0 53 a4 81 e8 84 d9 fc
[  148.135021] RIP
[  148.135021]  [<ffffffff810a0d06>] load_module+0x1ab6/0x2430
[  148.135021]  RSP <ffff88033b499dd0>
[  148.135021] CR2: ffffffffa02bce00

---

However, this patch worked fine on a Fedora-20, which is running - 3.11.10-301 Kernel.
Let me know if you need some other data, this issue is happening consistently.

Thanks.

[jpoimboe]

I think the panic happens in do_init_module() on the mod->state = MODULE_STATE_LIVE line. After calling the patch module's init function, the struct module mod pointer no longer points to valid memory. It's almost as if the patch module's memory was freed somehow during the initcall.

Were there any kpatch-related printk's before the "BUG"?

Are you sure that the kernel source used to build kpatch.ko, the kernel source provided to kpatch-build to build kpatch-tty-fix.ko, and the runtime kernel are all identical, including .config files?

Are you running with the stock 3.10.19 upstream kernel? If you can provide instructions on how to recreate it, that would help a lot.

[sububack]

Hi,

Yes, it's a stock 3.10.19 kernel (Didn't have any changes to it, only few
patches related to bugs are added to this). And it's running on a
simulator. And the source/config are same as the vmlinux.
And before BUG there was not any printk messages.

This kpatch source was a little old (I guess i pulled it in late
September), shall try once with the latest code and get back if there is
any change.

Regards,
Subramanain. K

On Tue, Nov 4, 2014 at 8:24 PM, Josh Poimboeuf notifications@github.com
wrote:

I think the panic happens in do_init_module() on the mod->state =
MODULE_STATE_LIVE line. After calling the patch module's init function,
the struct module mod pointer no longer points to valid memory. It's
almost as if the patch module's memory was freed somehow during the
initcall.

Were there any kpatch-related printk's before the "BUG"?

Are you sure that the kernel source used to build kpatch.ko, the kernel
source provided to kpatch-build to build kpatch-tty-fix.ko, and the runtime
kernel are all identical, including .config files?

Are you running with the stock 3.10.19 upstream kernel? If you can provide
instructions on how to recreate it, that would help a lot.

—
Reply to this email directly or view it on GitHub
#465 (comment).

[jpoimboe]

This kpatch source was a little old (I guess i pulled it in late September), shall try once with the latest code and get back if there is any change.

Thanks, let me go how it goes.

[sububack]

It seems to work now, Thanks