HI,
The patch is the same as in the README, i.e:
--- src.orig/fs/proc/meminfo.c
+++ src/fs/proc/meminfo.c
@@ -95,7 +95,7 @@ static int meminfo_proc_show(struct seq_
"Committed_AS: %8lu kB\n"
"VmallocTotal: %8lu kB\n"
"VmallocUsed: %8lu kB\n"
- "VmallocChunk: %8lu kB\n"
+ "VMALLOCCHUNK: %8lu kB\n"
#ifdef CONFIG_MEMORY_FAILURE
"HardwareCorrupted: %5lu kB\n"
#endif
and, yes, I see it every time.
The patch/module is loaded via;
kpatch load kpatch_0001_Test_kpatch.ko
and unloaded via kpatch unload
Regards
/Ravineet
On 13 May 2016 at 21:26, Jessica Yu <[email protected]> wrote:
> +++ Ravineet Singh [13/05/16 16:15 +0200]:
>
>> Thanks for the reply,
>>
>> I indeed had CONFIG_LIVEPATCH configured, after removing it, it is
>> possible
>> to unload the kpatch module
>> via kpatch unload .
>> Also install/uninstall seems to work fine. Also an installed kpatch module
>> is auto loaded upon boot.
>>
>> The only issue I see is; while unloading a kpatch module, a dump from the
>> kernel is generated (se below).
>> Any ideas?
>>
>> regards
>> /Ravineet
>>
>> [ 29.144476] kpatch: loaded patch module 'kpatch_0001_Test_kpatch'
>> [ 37.464348] kpatch: unloaded patch module 'kpatch_0001_Test_kpatch'
>> [ 37.466345] ------------[ cut here ]------------
>>
>
> [ 37.466742] WARNING: CPU: 4 PID: 1878 at kernel/module.c:1107
>> module_put+0x95/0xa0
>>
>
> Hm, that looks like some sort of module refcount issue (it's WARNing
> in module_put). I am however unable to reproduce the problem with the
> kpatch.ko core module under 4.6.0-rc4..
>
> Quick questions: What are you patching in kpatch_0001_Test_kpatch, and
> how are you loading/unloading the module? Are you able reproduce the
> problem consistently (i.e. it happens every time you unload)? Trying
> to figure out if this is just a kernel fluke or if the problem is on
> our side.
>
> Thanks,
> Jessica
>
>
> [ 37.467373] Modules linked in: kpatch(O) [last unloaded:
>> kpatch_0001_Test_kpatch]
>> [ 37.468034] CPU: 4 PID: 1878 Comm: rmmod Tainted: G W O K
>> 4.6-rc4+ #3
>> [ 37.468625] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>> Bochs 01/01/2011
>> [ 37.469024] 0000000000000000 ffff88007ba03e10 ffffffff81336508
>> 0000000000000000
>> [ 37.469024] 0000000000000000 ffff88007ba03e50 ffffffff8105ab51
>> 000004537ba03e30
>> [ 37.469024] ffff88007b7b7f80 ffffffffa0002640 ffffffffa0017420
>> ffffffffa0017190
>> [ 37.469024] Call Trace:
>> [ 37.469024] [<ffffffff81336508>] dump_stack+0x4d/0x65
>> [ 37.469024] [<ffffffff8105ab51>] __warn+0xd1/0xf0
>> [ 37.469024] [<ffffffff8105ac3d>] warn_slowpath_null+0x1d/0x20
>> [ 37.469024] [<ffffffff810cc345>] module_put+0x95/0xa0
>> [ 37.469024] [<ffffffff810cc3b1>] module_unload_free+0x41/0xc0
>> [ 37.469024] [<ffffffff810cdeff>] free_module+0x19f/0x2b0
>> [ 37.469024] [<ffffffff810ce1bc>] SyS_delete_module+0x1ac/0x230
>> [ 37.469024] [<ffffffff81002af2>] ? syscall_return_slowpath+0x92/0x100
>> [ 37.469024] [<ffffffff818d649b>] entry_SYSCALL_64_fastpath+0x13/0x8f
>> [ 37.475283] ---[ end trace 3b7c7357c1bf21ff ]---
>>
>>
>>
>> On 25 April 2016 at 19:58, Josh Poimboeuf <[email protected]> wrote:
>>
>> On Fri, Apr 22, 2016 at 04:00:15PM +0200, Ravineet Singh wrote:
>>> > Hi,
>>> > Not sure if this is the correct forum but I'll try anyway.
>>> > I am looking at the possibility to build kpatch-patches on x86 machines
>>> to
>>> > be deployed in a arm v8 environment.
>>> >
>>> > The first step is to verify kpatch on x86_64 and initially I have a
>>> > couple a hinder.
>>> > I might have missed one or several steps but, it seems like the kpatch
>>> > sysfs entry is not created and hence
>>> > listing nor unloading is possible...
>>> >
>>> > I basically follwed the guide on: https://github.com/dynup/kpatch for
>>> > debian 8.
>>> >
>>> > I guess it is obvious to you guys but:
>>> > root@debian64:~/kpatch (master) # strace kpatch list 2>&1 | grep
>>> "/sys"
>>> > stat("/sys/kernel/kpatch/patches/*", 0x7ffcb713dff0) = -1 ENOENT (No
>>> such
>>> > file or directory)
>>> >
>>> > Could someone point me in the right direction please :)
>>>
>>> Hi Ravineet,
>>>
>>> Any chance your kernel was compiled with CONFIG_LIVEPATCH? If so, you
>>> built a livepatch module and you'll need to manage the patch using the
>>> /sys/kernel/livepatch directory because the kpatch command-line utility
>>> doesn't know how to interact with livepatch yet.
>>>
>>> --
>>> Josh
>>>
>>>
>>
>>
>> --
>> Regards
>> Ravineet
>>
>
> _______________________________________________
>> kpatch mailing list
>> [email protected]
>> https://www.redhat.com/mailman/listinfo/kpatch
>>
>
>
--
Regards
Ravineet
_______________________________________________
kpatch mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/kpatch
