] ? trace_hardirqs_on_thunk+0x3a/0x3f
[815b3652] system_call_fastpath+0x16/0x1b
The cause is that it doesn't release the last btree node,
when height = 1 and fill = 1.
Signed-off-by: Minfei Huang huangmin...@ucloud.cn
CC: Joern Engel jo...@logfs.org
CC: Johannes Berg johan...@sipsolutions.net
---
lib/btree.c
] ? trace_hardirqs_on_thunk+0x3a/0x3f
[815b3652] system_call_fastpath+0x16/0x1b
The cause is that it doesn't release the last btree node,
when height = 1 and fill = 1.
Signed-off-by: Minfei Huang huangmin...@ucloud.cn
CC: Joern Engel jo...@logfs.org
CC: Johannes Berg johan...@sipsolutions.net
---
lib/btree.c
,
...
}
It shows value exactly when use the value of io address.
The io address in callback function will become the danging point,
cause by the thread of sync io wakes up by other threads
and return to relieve the io address,
Signed-off-by: Minfei Huang huangmin...@ucloud.cn
---
drivers/md/dm-io.c | 19
and allocate it from the pool the
same as async_io.
- Use a completion object rather than an explicit io_schedule()
loop. The callback triggers the completion.
Signed-off-by: Minfei Huang huangmin...@ucloud.cn
---
drivers/md/dm-io.c | 22 +-
1 files changed, 9 insertions
From: Minfei Huang mnfhu...@gmail.com
It is a problem when configuring high memory off where the vmalloc
reserve area could end up overlapping the early_ioremap fixmap
area on i386.
The ordering of the VMALLOC_RESERVE space is:
FIXADDR_TOP
fixed_addresses
FIXADDR_START
On 10/28/14 at 08:14pm, H. Peter Anvin wrote:
On 10/28/2014 10:29 AM, Thomas Gleixner wrote:
On Tue, 28 Oct 2014, H. Peter Anvin wrote:
On 10/28/2014 04:06 AM, Thomas Gleixner wrote:
The available address we can use is lower than FIXADDR_BOOT_START. So
We will set the kmap boundary
. So we can reuse the virtual address whichever we can.
The macros of FIXADDR_BOOT_START and FIXADDR_BOOT_SIZE donot use any
more.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
arch/x86/include/asm/fixmap.h | 2 --
arch/x86/include/asm/highmem.h | 4 +---
arch/x86/include
memory. So we can re-use the virtual address whichever we can.
The macros of FIXADDR_BOOT_START and FIXADDR_BOOT_SIZE donot use any
more.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
arch/x86/include/asm/fixmap.h | 2 --
arch/x86/include/asm/highmem.h | 25
Could someone who help me review my patch?
Thanks
Minfei
On 11/06/14 at 01:41pm, Minfei Huang wrote:
The variable value is undefined from the stack eara. So it makes sense to
init the variable to run process correctly.
If the variable pmd_idx inits the value more than PTRS_PER_PMD
The kdump starts 2nd kernel without any error message when I use
3.18.0-rc4 merged last 6 patchs. The following is the message which 2nd
kernel prints during booting.
Patchset:
0001-iommu-vt-d-Update-iommu_attach_domain-and-its-caller.patch
.
The kernel may panic cause by the undefine variable which is allocated
from stack.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
arch/x86/mm/init_32.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index c8140e1..c23ab1e 100644
--- a/arch/x86/mm
On 03/15/15 at 12:49am, Yinghai Lu wrote:
While trying to optimize setup_data handling code, found commit f47233c2d34f
(x86/mm/ASLR: Propagate base load address calculation), uses a physical
address as the value.
It leads to wrong kaslr status. That kaslr status is passed for controlling
On 03/15/15 at 10:02am, Yinghai Lu wrote:
On Sun, Mar 15, 2015 at 5:18 AM, Minfei Huang mhu...@redhat.com wrote:
On 03/15/15 at 12:49am, Yinghai Lu wrote:
It confuses me with the virtual address in function parse_kaslr_setup.
When we are in here(parse_kaslr_setup), we already use
2015-04-01 21:35 GMT+08:00 Jiri Kosina jkos...@suse.cz:
On Wed, 1 Apr 2015, Minfei Huang wrote:
Sorry, Use the gmail account to resend this patch, because the yahoo
account cannt receive the maillist.
As mentioned in the annotation, the patch module would not permit
2015-04-01 22:13 GMT+08:00 Jiri Kosina jkos...@suse.cz:
On Wed, 1 Apr 2015, Minfei Huang wrote:
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 3f9f1d6..0266950 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -502,6 +502,17 @@ static int
On 04/13/15 at 05:58P, Josh Poimboeuf wrote:
On Mon, Apr 13, 2015 at 06:37:10PM +0800, Minfei Huang wrote:
For my patches, I think it is used by the persion which will compose the
patch individually, not for the manufactor.
Yes, Verifying extra function address is more useless
On 04/13/15 at 06:13P, Josh Poimboeuf wrote:
On Sun, Apr 12, 2015 at 09:15:54PM +0800, Minfei Huang wrote:
For now, the kallsyms will only store the first (KSYM_NAME_LEN-1). The
kallsyms name is same for the function which first (KSYM_NAME_LEN-1) is
same, but the rest
On 04/14/15 at 08:17P, Minfei Huang wrote:
On 04/13/15 at 05:58P, Josh Poimboeuf wrote:
On Mon, Apr 13, 2015 at 06:37:10PM +0800, Minfei Huang wrote:
For my patches, I think it is used by the persion which will compose the
patch individually, not for the manufactor.
Yes, Verifying
On 04/13/15 at 11:05P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 08:48:11AM +0800, Minfei Huang wrote:
On 04/14/15 at 08:17P, Minfei Huang wrote:
On 04/13/15 at 05:58P, Josh Poimboeuf wrote:
On Mon, Apr 13, 2015 at 06:37:10PM +0800, Minfei Huang wrote:
For my patches, I think
On 04/14/15 at 12:11P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 01:03:48PM +0800, Minfei Huang wrote:
On 04/13/15 at 11:57P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 08:26:29AM +0800, Minfei Huang wrote:
On 04/13/15 at 06:13P, Josh Poimboeuf wrote:
On Sun, Apr 12, 2015
On 04/13/15 at 11:57P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 08:26:29AM +0800, Minfei Huang wrote:
On 04/13/15 at 06:13P, Josh Poimboeuf wrote:
On Sun, Apr 12, 2015 at 09:15:54PM +0800, Minfei Huang wrote:
For now, the kallsyms will only store the first (KSYM_NAME_LEN-1
On 04/14/15 at 12:32P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 01:29:50PM +0800, Minfei Huang wrote:
On 04/14/15 at 12:11P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 01:03:48PM +0800, Minfei Huang wrote:
On 04/13/15 at 11:57P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015
On 04/15/15 at 01:58P, Miroslav Benes wrote:
On Wed, 15 Apr 2015, Minfei Huang wrote:
On 04/15/15 at 10:30P, Miroslav Benes wrote:
On Wed, 15 Apr 2015, Minfei Huang wrote:
Yes, the function name can be changed, before the extra module is
installed to the production system
On 04/24/15 at 09:59P, Jiri Kosina wrote:
We give up old_addr hint from the coming patch module in cases when kernel
load
base has been randomized (as in such case, the coming module has no idea about
the exact randomization offset).
We are currently too pessimistic, and give up
On 04/27/15 at 04:28P, Jiri Kosina wrote:
We give up old_addr hint from the coming patch module in cases when kernel
load base has been randomized (as in such case, the coming module has no
idea about the exact randomization offset).
We are currently too pessimistic, and give up
On 04/28/15 at 01:29P, Jiri Kosina wrote:
On Mon, 27 Apr 2015, Minfei Huang wrote:
Found that kaslr_enabled is only exist for x86. Maybe you can define a
weak function klp_adjustment_function_addr in general. Then each arch
can overwrite the function to implemente it specially
From: Minfei Huang minfei.hu...@hotmail.com
The previous patches can be applied, while the corresponding module is
loaded. Now the code cannot handle correct behavior to deal with the
case that the patch fail to be initialized when the module is being
loaded.
In general, the patch will do
On 05/11/15 at 02:02P, Miroslav Benes wrote:
On Mon, 11 May 2015, Minfei Huang wrote:
From: Minfei Huang minfei.hu...@hotmail.com
The previous patches can be applied, while the corresponding module is
loaded. Now the code cannot handle correct behavior to deal with the
case
On 05/12/15 at 12:49P, Jiri Kosina wrote:
On Mon, 11 May 2015, Minfei Huang wrote:
1) Patched a patch to fix the issue for module A.
2) livepatch will try to enable the patch, while the corresponding
module is loaded ( call klp_module_notify_coming )
3) Firstly, livepatch will do
fails
to call the klp_module_notify_coming.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
v1:
- modify the commit log, describe the issue more details
---
kernel/livepatch/core.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/kernel/livepatch
: prevent patch inconsistencies if the coming module notifier fails
(or bugs, corruptions, whatever).
Will do.
On Thu, 14 May 2015, Minfei Huang wrote:
The previous patches can be applied, once the corresponding module is
loaded. In general, the patch will do relocation (if necessary
From: Minfei Huang mnfhu...@gmail.com
The previous patches can be applied, once the corresponding module is
loaded. In general, the patch will do relocation (if necessary) and
obtain/verify function address before we start to enable patch.
There are three different situations in which the coming
On 05/14/15 at 09:30am, Josh Poimboeuf wrote:
On Thu, May 14, 2015 at 09:51:07AM +0800, Minfei Huang wrote:
@@ -891,22 +891,24 @@ static void klp_module_notify_coming(struct klp_patch
*patch,
int ret;
ret = klp_init_object_loaded(patch, obj);
- if (ret)
- goto
On 05/18/15 at 02:08pm, Petr Mladek wrote:
On Wed 2015-05-13 09:14:15, Josh Poimboeuf wrote:
On Tue, May 12, 2015 at 10:04:44PM +0800, Minfei Huang wrote:
@@ -883,7 +883,7 @@ int klp_register_patch(struct klp_patch *patch)
}
EXPORT_SYMBOL_GPL(klp_register_patch);
-static void
On 05/12/15 at 01:41P, Miroslav Benes wrote:
On Tue, 12 May 2015, Minfei Huang wrote:
The previous patches can be applied, once the corresponding module is
loaded. In general, the patch will do relocation (if necessary) and
obtain/verify function address before we start to enable patch
, we would get those errors
everytime the patch is enabled.
In order to fix above situations, we can make obj-mod to NULL, if the
coming modified notifier fails.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
v3:
- modify the code style
v2:
- add the error message to make it more friendly
On 05/13/15 at 09:14P, Josh Poimboeuf wrote:
On Tue, May 12, 2015 at 10:04:44PM +0800, Minfei Huang wrote:
@@ -883,7 +883,7 @@ int klp_register_patch(struct klp_patch *patch)
}
EXPORT_SYMBOL_GPL(klp_register_patch);
-static void klp_module_notify_coming(struct klp_patch *patch
On 05/18/15 at 05:35pm, Petr Mladek wrote:
On Mon 2015-05-18 21:00:57, Minfei Huang wrote:
On 05/18/15 at 02:08pm, Petr Mladek wrote:
On Wed 2015-05-13 09:14:15, Josh Poimboeuf wrote:
...[snip]...
The patch isn't necessarily dead, since it might also include previously
enabled
, we would get those errors
everytime the patch is enabled.
In order to fix above situations, we can make obj-mod to NULL, if the
coming modified notifier fails.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
v2:
- add the error message to make it more friendly
- modify the commit log, base
On 04/14/15 at 06:27pm, Petr Mladek wrote:
On Tue 2015-04-14 23:55:36, Minfei Huang wrote:
On 04/14/15 at 10:11P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 01:45:49PM +0800, Minfei Huang wrote:
On 04/14/15 at 12:32P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 01:29:50PM +0800
On 04/14/15 at 10:11P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 01:45:49PM +0800, Minfei Huang wrote:
On 04/14/15 at 12:32P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 01:29:50PM +0800, Minfei Huang wrote:
For end user, they may know litter about restriction of kallsyms
, Minfei Huang wrote:
On 04/15/15 at 10:30P, Miroslav Benes wrote:
On Wed, 15 Apr 2015, Minfei Huang wrote:
Yes, the function name can be changed, before the extra module is
installed to the production system.
We discuss around and around, there are still some confusion
On 04/13/15 at 10:37P, Petr Mladek wrote:
On Sun 2015-04-12 21:15:53, Minfei Huang wrote:
In order to restrict the patch, we can verify the provided function
address and name match. Now we have can only verify the vmlinux function
name and address.
Add a new function to verify extra
On 04/13/15 at 10:44P, Petr Mladek wrote:
On Sun 2015-04-12 21:15:54, Minfei Huang wrote:
For now, the kallsyms will only store the first (KSYM_NAME_LEN-1). The
kallsyms name is same for the function which first (KSYM_NAME_LEN-1) is
same, but the rest is not.
Then function will never
On 04/13/15 at 11:41P, Petr Mladek wrote:
On Mon 2015-04-13 17:11:19, Minfei Huang wrote:
On 04/13/15 at 10:37P, Petr Mladek wrote:
On Sun 2015-04-12 21:15:53, Minfei Huang wrote:
In order to restrict the patch, we can verify the provided function
address and name match. Now we have
On 04/13/15 at 12:22P, Petr Mladek wrote:
On Mon 2015-04-13 17:50:23, Minfei Huang wrote:
On 04/13/15 at 11:41P, Petr Mladek wrote:
On Mon 2015-04-13 17:11:19, Minfei Huang wrote:
On 04/13/15 at 10:37P, Petr Mladek wrote:
On Sun 2015-04-12 21:15:53, Minfei Huang wrote
function is found.
Minfei Huang (2):
livepatch: Add a new function to verify the address and name match for
patched module
livepatch: Fix the bug if the function name is larger than
KSYM_NAME_LEN-1
kernel/livepatch/core.c | 55 ++---
1
are not
matched.
Signed-off-by: Minfei Huang minfei.hu...@hotmail.com
---
kernel/livepatch/core.c | 54 ++---
1 file changed, 38 insertions(+), 16 deletions(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 3f9f1d6..ff42c29 100644
is livepatch cannt
recognize the function name.
Now, livepatch will verify the function name with first (KSYM_NAME_LEN-1)
and address, if provided. Once they are matched, we can confirm that the
patched function is found.
Signed-off-by: Minfei Huang minfei.hu...@hotmail.com
---
kernel/livepatch/core.c | 4
On 04/14/15 at 08:41pm, Petr Mladek wrote:
On Wed 2015-04-15 01:01:39, Minfei Huang wrote:
On 04/14/15 at 06:27pm, Petr Mladek wrote:
On Tue 2015-04-14 23:55:36, Minfei Huang wrote:
On 04/14/15 at 10:11P, Josh Poimboeuf wrote:
On Tue, Apr 14, 2015 at 01:45:49PM +0800, Minfei Huang
On 04/15/15 at 10:30P, Miroslav Benes wrote:
On Wed, 15 Apr 2015, Minfei Huang wrote:
Yes, the function name can be changed, before the extra module is
installed to the production system.
We discuss around and around, there are still some confusion with it.
1) How does end user
On 04/15/15 at 10:30P, Miroslav Benes wrote:
On Wed, 15 Apr 2015, Minfei Huang wrote:
Yes, the function name can be changed, before the extra module is
installed to the production system.
We discuss around and around, there are still some confusion with it.
1) How does end user
On 05/19/15 at 11:58P, Jiri Kosina wrote:
On Tue, 19 May 2015, Minfei Huang wrote:
klp_for_each_object and klp_for_each_func are now used all over the
code. One need not think what is the proper condition to check in the
for loop now.
Signed-off-by: Jiri Slaby jsl...@suse.cz
On 05/19/15 at 12:01P, Jiri Slaby wrote:
klp_for_each_object and klp_for_each_func are now used all over the
code. One need not think what is the proper condition to check in the
for loop now.
Signed-off-by: Jiri Slaby jsl...@suse.cz
---
include/linux/livepatch.h | 6 ++
From: Minfei Huang mnfhu...@gmail.com
Transforming PFN(Page Frame Number) to struct page is never failure, so
we can simplify the code logic to do the image-control_page assignment
directly in the loop, and remove the unnecessary conditional judgement.
Signed-off-by: Minfei Huang mnfhu
From: Minfei Huang mnfhu...@gmail.com
For some arch, kexec shall map the reserved pages, then use them, when
we try to start the kdump service.
Now kexec will never unmap the reserved pages, once it fails to continue
starting the kdump service.
Make a pair of reserved pages in kdump starting
On 06/02/15 at 11:15am, Miroslav Benes wrote:
On Tue, 2 Jun 2015, Minfei Huang wrote:
- if (kallsyms_on_each_symbol(klp_verify_callback, args))
- return 0;
+ mutex_lock(module_mutex);
+ ret = kallsyms_on_each_symbol(klp_verify_callback, args
On Mon, Jun 1, 2015 at 11:48 PM, Miroslav Benes mbe...@suse.cz wrote:
The list of loaded modules is walked through in
module_kallsyms_on_each_symbol (called by kallsyms_on_each_symbol). The
module_mutex lock should be acquired to prevent potential corruptions
in the list.
This was uncovered
2015 13:44:46 +0800
Minfei Huang mnfhu...@gmail.com wrote:
For some arch, kexec shall map the reserved pages, then use them, when
we try to start the kdump service.
Now kexec will never unmap the reserved pages, once it fails to continue
starting the kdump service.
Make a pair
or not.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
v2:
- replace the failure label with fail_unmap_pages
v1:
- reconstruct the patch code
---
kernel/kexec.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 4589899
From: Minfei Huang mnfhu...@gmail.com
Usually we prefer to let compiler put the module initialized function to
section .init.text. Thus this text in memory will be freed in future.
Once we add the __init preceding function name, we can use following
command to find it in specfied section
On Tue, May 26, 2015 at 10:44 AM, Li Bin huawei.li...@huawei.com wrote:
The klp_is_module return type should be boolean.
Signed-off-by: Li Bin huawei.li...@huawei.com
---
kernel/livepatch/core.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
On 05/20/15 at 09:11am, Jiri Slaby wrote:
On 05/20/2015, 03:51 AM, Minfei Huang wrote:
Sure. Sorry for confuse you with my comment.
Oh, I see now, but:
list_for_each_entry(patch, klp_patches, list) {
for (obj = patch-objs; obj-funcs; obj
On 05/22/15 at 08:25P, Josh Poimboeuf wrote:
On Fri, May 22, 2015 at 02:10:32PM +0800, Minfei Huang wrote:
From: Minfei Huang mnfhu...@gmail.com
Usually we prefer to let compiler put the module initialized function to
section .init.text. Thus this text in memory will be freed in future
built-in.o: file format elf64-x86-64
SYMBOL TABLE:
ld .init.text .init.text
l F .init.text 004e klp_init
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
v1:
- modify the subject to make it more concise
or not.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
kernel/kexec.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 4589899..68f6dfb 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1291,35 +1291,37
it.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
arch/x86/platform/uv/uv_time.c | 2 +-
include/linux/ftrace.h | 2 +-
include/linux/workqueue.h | 2 +-
kernel/trace/ftrace.c | 5 +++--
kernel/trace/trace_events.c| 2 +-
kernel/workqueue.c | 11
On 08/03/15 at 10:04am, Steven Rostedt wrote:
On Mon, 3 Aug 2015 17:15:53 +0800
yalin wang yalin.wang2...@gmail.com wrote:
better to also provide a wrapper function with name schedule_on_each_cpu(),
as this function is used frequently .
#define schedule_on_each_cpu(f)
On 07/30/15 at 11:07am, Baoquan He wrote:
People reported that crash_notes in /proc/vmcore were corrupted and
this cause crash kdump failure. With code debugging and log we got
the root cause. This is because percpu variable crash_notes are
allocated in 2 vmalloc pages. As you know percpu is
On 08/11/15 at 02:33pm, Baoquan He wrote:
Hi Andrew,
On 08/03/15 at 03:04pm, Andrew Morton wrote:
On Mon, 3 Aug 2015 20:50:43 +0800 Baoquan He b...@redhat.com wrote:
And I think the WARN_ON can be replaced with a
BUILD_BUG_ON(sizeofPAGE_SIZE)? That would avoid adding runtime
Ping.
Could someone help to review this patch?
Thanks
Minfei
On 07/22/15 at 11:13am, Minfei Huang wrote:
From: Minfei Huang mnfhu...@gmail.com
Now, ftrace only calculate the dyn_ftrace number in the adding
breakpoint loop, not in adding update and finish update loop.
Calculate
From: Minfei Huang mnfhu...@gmail.com
Since the patch ftrace: remove daemon(cb7be3b) remove the function
ftraced, the variant ftrace_update_time never be used any more.
Remove the unused variant ftrace_update_time.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
kernel/trace/ftrace.c | 6
On 07/28/15 at 01:30pm, Simon Horman wrote:
On Mon, Jul 27, 2015 at 09:44:53AM -0400, Vivek Goyal wrote:
On Sat, Jun 06, 2015 at 02:14:12PM +0800, Minfei Huang wrote:
From: Minfei Huang mnfhu...@gmail.com
Transforming PFN(Page Frame Number) to struct page is never failure, so
we
Transforming PFN(Page Frame Number) to struct page is never failure, so
we can simplify the code logic to do the image-control_page assignment
directly in the loop, and remove the unnecessary conditional judgement.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
Acked-by: Dave Young dyo
On 07/23/15 at 01:07pm, Josh Poimboeuf wrote:
On Thu, Jul 23, 2015 at 12:02:06PM +0800, Minfei Huang wrote:
On 07/22/15 at 09:40am, Josh Poimboeuf wrote:
Is it really safe to assume that there are no dependencies between
patches which patch different objects?
I think so.
What
The if condition will be always true, since the operator has the high
priority than operator ||.
Use () to quote them to make the if condition correctly.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
kernel/trace/ftrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Since the patch ftrace: remove daemon(cb7be3b) remove the function
ftraced, the variant ftrace_update_time never be used any more.
Remove the unused variant ftrace_update_time.
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
kernel/trace/ftrace.c | 6 --
1 file changed, 6 deletions
On 07/27/15 at 10:20am, yalin wang wrote:
On Jul 26, 2015, at 23:55, Minfei Huang mnfhu...@gmail.com wrote:
The if condition will be always true, since the operator has the high
priority than operator ||.
Use () to quote them to make the if condition correctly.
Signed-off
From: Minfei Huang mnfhu...@gmail.com
Now, ftrace only calculate the dyn_ftrace number in the adding
breakpoint loop, not in adding update and finish update loop.
Calculate the correct dyn_ftrace, once ftrace reports the failure message
to the userspace.
Signed-off-by: Minfei Huang mnfhu
On 07/21/15 at 12:22pm, Yinghai Lu wrote:
On Tue, Jul 21, 2015 at 1:58 AM, Baoquan He b...@redhat.com wrote:
Maybe system which don't need low memory is rare, only for testing?
No, it is not rare.
All recent intel based systems with iommu support does not need low.
And those systems
Could someone help to review this patch?
Thanks
Minfei
On 07/15/15 at 04:55pm, Minfei Huang wrote:
From: Minfei Huang mnfhu...@gmail.com
Livepatch will obey the stacking rule to enable/disable the patch. It
only allows to enable the patch, when it is the fist disabled patch,
disable
Hi, Vivek.
Since Dave acked this patch, Could you help to merge it?
Thanks
Minfei
On 06/15/15 at 05:28pm, Dave Young wrote:
On 06/06/15 at 02:14pm, Minfei Huang wrote:
From: Minfei Huang mnfhu...@gmail.com
Transforming PFN(Page Frame Number) to struct page is never failure, so
we can
On 07/22/15 at 09:40am, Josh Poimboeuf wrote:
On Wed, Jul 15, 2015 at 04:55:06PM +0800, Minfei Huang wrote:
From: Minfei Huang mnfhu...@gmail.com
Livepatch will obey the stacking rule to enable/disable the patch. It
only allows to enable the patch, when it is the fist disabled patch
From: Minfei Huang mnfhu...@gmail.com
It is not elegance, if we use function directly as the argument, like
following:
int module_kallsyms_on_each_symbol(int (*fn)(void *, const char *,
struct module *, unsigned long),
void
From: Minfei Huang mnfhu...@gmail.com
It is not elegance, if we use function directly as the argument, like
following:
bool each_symbol_section(bool (*fn)(const struct symsearch *arr,
struct module *owner,
void *data), void
From: Minfei Huang mnfhu...@gmail.com
This patchset do the cleanup. For now, we can use function type
as the parament to simplify the code.
Previously, we will declare the function as following:
bool each_symbol_section(bool (*fn)(const struct symsearch *arr
Lost the character 'n' in the Namhyung Kim namhy...@kernel.org.
Resent it.
On 07/14/15 at 02:59P, Minfei Huang wrote:
From: Minfei Huang mnfhu...@gmail.com
This patchset do the cleanup. For now, we can use function type
as the parament to simplify the code.
Previously, we will declare
Lost the character 'n' in the Namhyung Kim namhy...@kernel.org.
Resent it.
On 07/14/15 at 02:59P, Minfei Huang wrote:
From: Minfei Huang mnfhu...@gmail.com
It is not elegance, if we use function directly as the argument, like
following:
int module_kallsyms_on_each_symbol(int (*fn)(void
Lost the character 'n' in the Namhyung Kim namhy...@kernel.org.
Resend it.
On 07/14/15 at 02:59P, Minfei Huang wrote:
From: Minfei Huang mnfhu...@gmail.com
It is not elegance, if we use function directly as the argument, like
following:
bool each_symbol_section(bool (*fn)(const struct
From: Minfei Huang mnfhu...@gmail.com
It is more better that klp_disable_func returnes immediately, if
func-state and func-old_addr do not satisfy the condition.
We should robust the livepatch code, although the above situation never
happen in current code path.
Signed-off-by: Minfei Huang
From: Minfei Huang mnfhu...@gmail.com
Livepatch will obey the stacking rule to enable/disable the patch. It
only allows to enable the patch, when it is the fist disabled patch,
disable the patch, when it is the last enabled patch.
In the livepatch code, it uses list to gather the all
On 07/15/15 at 07:22am, Rusty Russell wrote:
Minfei Huang mhu...@redhat.com writes:
From: Minfei Huang mnfhu...@gmail.com
It is not elegance, if we use function directly as the argument, like
following:
bool each_symbol_section(bool (*fn)(const struct symsearch *arr
:0: note: this is the location of the previous
definition
# define finish_arch_post_lock_switch() do { } while (0)
^
Signed-off-by: Minfei Huang mnfhu...@gmail.com
---
include/linux/kallsyms.h | 4 +++-
include/linux/module.h | 4 +---
2 files changed, 4 insertions(+), 4 deletions
ping.
Can someone help review this patch?
Thanks
Minfei
On 07/12/15 at 08:18P, Minfei Huang wrote:
From: Minfei Huang mnfhu...@gmail.com
The variable pmd_idx is undefined, when we try to start the loop to
calculate the page.
Assign the proper value which indexes the start address
On 10/15/15 at 10:25pm, Steven Rostedt wrote:
> On Thu, 17 Sep 2015 00:19:42 +0800
> Minfei Huang <mnfhu...@gmail.com> wrote:
>
> > Now, ftrace only calculate the dyn_ftrace number in the adding
> > breakpoint loop, not in adding update and finish update loop.
>
On 11/10/15 at 08:07am, Josh Poimboeuf wrote:
> On Fri, Nov 06, 2015 at 02:25:00PM +0800, Zhou Chengming wrote:
> > When enable KASLR, livepatch will adjust old_addr of changed
> > function accordingly. So do the same thing for reloc.
> >
> > +
> > +#if defined(CONFIG_RANDOMIZE_BASE)
> > +
On 11/09/15 at 11:45pm, Jessica Yu wrote:
> In livepatch modules, preserve section, symbol, string information from
> the load_info struct in the module loader. This information is used to
> patch modules that are not loaded in memory yet; specifically it is used
> to resolve remaining symbols and
From: Minfei Huang <mnfhu...@gmail.com>
Previously, UV NMI used 'in_crash_kexec' flag to be sure that we are in
kdump kernel or not in commit 5edd19af18a36a4e22c570b1b969179e0ca1fe4c
("x86, UV: Make kdump avoid stack dumps"). But this flags is r
gt; - if (evictee)
> - __brelse(evictee);
> + if (old)
> + __brelse(old);
> }
>
> /*
>
>
> more simple to understand and have better performance .
> am i understanding correctly ?
>
> > On Sep 28, 2015, at 13:36,
On 07/08/15 at 08:06P, Minfei Huang wrote:
On 07/07/15 at 05:18P, Vivek Goyal wrote:
On Thu, Jul 02, 2015 at 09:45:52AM +0800, Minfei Huang wrote:
For some arch, kexec shall map the reserved pages, then use them, when
we try to start the kdump service.
Now kexec will never unmap
1 - 100 of 456 matches
Mail list logo
