Although this check should have been done by caller. But as it's exported to
others,
It's better to add a none zero check of len like other functions.
Signed-off-by: xinhuix.pan xinhuix@intel.com
---
mm/util.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/mm/util.c b/mm/util.c
On 2015年01月22日 07:09, David Rientjes wrote:
On Tue, 20 Jan 2015, Pan Xinhui wrote:
Although this check should have been done by caller. But as it's exported to
others,
It's better to add a none zero check of len like other functions.
Signed-off-by: xinhuix.pan xinhuix@intel.com
---
mm
;
|
tty_kref_put --- release_one_tty - gsmtty_cleanup (added by
our patch)
So our patch fix the memory leak by doing the cleanup work after tty core did.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
Changes in v2:
Don't use schedule_work to put dlci. Replace
In gsmtty_remove, we will put dlci. when dlci's ref-count is zero,
tty_port_destructor will be called, and it will check if port-itty is NULL.
However port-itty will be set to NULL in release_tty after gsmtty_remove.
that may cause memory leak. so we use queue_work to put the dlci later.
when gsmtty_remove put dlci, it will cause memory leak if
dlci-port's refcount is zero.
So we do the cleanup work in .cleanup callback instead.
dlci will be last put in two call chains.
1) gsmld_close - gsm_cleanup_mux - gsm_dlci_release - dlci_put
2) gsmld_remove - dlci_put
so there is a race.
In gsmtty_remove, we will put dlci. when dlci's ref-count is zero,
tty_port_destructor will be called, and it will check if port-itty is NULL.
However port-itty will be set to NULL in release_tty after gsmtty_remove.
that may cause memory leak. so we use queue_work to put the dlci later.
hi, Jiri
thanks for your kind reply, and the nice advices. :)
On 2015年03月23日 23:23, Jiri Slaby wrote:
On 03/24/2015, 08:22 AM, Pan Xinhui wrote:
In gsmtty_remove, we will put dlci. when dlci's ref-count is zero,
tty_port_destructor will be called, and it will check if port-itty is
NULL
input_dev may be NULL if mxt_initialize_input_device fails. But pm ops is still
available and suspend/resume assume
input_dev is not NULL. To fix this issue, we add a check if (!input_dev).
Signed-off-by: xinhui.pan xinhuix@intel.com
---
drivers/input/touchscreen/atmel_mxt_ts.c | 6 ++
mxt_probe() may fail at last step, and the queue_work scheduled by
request_firmware_nowait
may run later and then access some data which is freed.
To handle this error, add one mutex_lock to cover such case. It may cause
module load delay only when the probe fails.
here is the detail.
module
hi,
yes, we can't guarantee MXT_FW_RESET_TIME is enough. patch v3 is sent
out :)
thanks
xinhui
On 2015年05月14日 19:31, Nick Dyer wrote:
Hi-
This looks like a good tidy up, one minor comment:
On 15/05/15 12:19, Pan Xinhui wrote:
+mxt_wait_for_completion(data, data
mxt_probe() may fail at last step, or we jsut unload mxt module soon.
the queue_work scheduled by request_firmware_nowait may run later,
and then access some data which is freed.
To handle this issue, add fw_load_completion field in mxt_data.
then we wait for it complete both in probe error path
mxt_probe() may fail at last step, or we jsut unload mxt module soon.
the queue_work scheduled by request_firmware_nowait may run later,
and then access some data which is freed.
To handle this issue, add fw_load_completion field in mxt_data.
then we wait for it complete both in probe error path
HI, Dmitry
thanks for your reply :)
On 2015年05月14日 01:41, Dmitry Torokhov wrote:
Hi,
On Wed, Apr 22, 2015 at 06:46:58PM +0800, Pan Xinhui wrote:
mxt_probe() may fail at last step, and the queue_work scheduled by
request_firmware_nowait
may run later and then access some data which
.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
lib/bitmap.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/bitmap.c b/lib/bitmap.c
index 64c0926..3c489c1 100644
--- a/lib/bitmap.c
+++ b/lib/bitmap.c
@@ -561,6 +561,8 @@ static int __bitmap_parselist(const char *buf, unsigned int
[ 1148.606208, 1] [810ab8d0] ? kthread_create_on_node+0x190/0x190
[ 1148.613721, 1] [81a044c8] ret_from_fork+0x58/0x90
[ 1148.619967, 1] [810ab8d0] ? kthread_create_on_node+0x190/0x190
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
drivers/acpi/osl.c | 28
[ 1148.600455, 1] [810ab9b4] kthread+0xe4/0x100
[ 1148.606208, 1] [810ab8d0] ? kthread_create_on_node+0x190/0x190
[ 1148.613721, 1] [81a044c8] ret_from_fork+0x58/0x90
[ 1148.619967, 1] [810ab8d0] ? kthread_create_on_node+0x190/0x190
Signed-off-by: Pan Xinhui xinhuix
] cpu_notify+0x23/0x50
[ 722.033757, 2] [81089068] notify_cpu_starting+0x28/0x30
[ 722.040569, 2] [8102fcff] start_secondary+0x15f/0x2d0
[ 722.047185, 2]bad: scheduling from the idle thread!
any comments are welcome. :)
thanks,
xinhui
On 2015年05月28日 14:33, Pan Xinhui wrote
We can avoid in-loop incrementation of ndigits.
Save current totaldigits to ndigits before loop,
and check ndigits against totaldigits after the loop.
Signed-off-by: Pan Xinhui xinhuix@intel.com
Cc: Yury Norov yury.no...@gmail.com
---
lib/bitmap.c | 7 ---
1 file changed, 4 insertions
If string end with '-', for exapmle, bitmap_parselist(1,0-,mask, nmaskbits),
It is not in a valid pattern, so add a check after loop.
Return -EINVAL on such condition.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
lib/bitmap.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib
and reasonable to accept such string as long as
the parsing result is correct.
Signed-off-by: Pan Xinhui xinhuix@intel.com
Cc: Yury Norov yury.no...@gmail.com
---
lib/bitmap.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/lib/bitmap.c b/lib
-by: Pan Xinhui xinhuix@intel.com
---
lib/bitmap.c | 238
+--
1 file changed, 134 insertions(+), 104 deletions(-)
---
change log
v3:
__bitmap_parselist now allow some extra input, like ,2, 3 5-8, at
least one digit inside
add __bitmap_parse_common to match any contents and return expected reslut.
as __bitmap_parse_common need NULL-terminated string, we alloc a new buf.
this patch also fix some parse issues in __bitmap_parselist.
now it can handle grouping errors with input like , ,, etc.
Signed-off-by: Pan
hi, Yury
On 2015年06月30日 16:32, Yury Norov wrote:
2015-07-01 4:37 GMT+03:00 Pan Xinhui xinhuix@intel.com:
hi, Yury
thanks for your nice reply.
On 2015年06月29日 21:39, Yury Norov wrote:
Sometimes the input from user may cause an unexpected result.
Could you please provide
add __bitmap_parse_common to match any contents and return expected result.
as __bitmap_parse_common need NULL-terminated string, we alloc a new buf.
this patch also fix some parse issues in __bitmap_parselist.
now it can handle grouping errors with input like , ,, etc.
Signed-off-by:
) if input has '0-', bit 0 might be set unexpectedly,
now we return -EINVAL as this kind of input is definitely wrong.
3) minor code style fix in __bitmap_parse.
and avoid in-loop incrementation of ndigits.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
lib/bitmap.c | 34
hi, all
after a deep think, allocing a new buf is ugly.
new patch lib/bitmap.c: fix some parsing issues and code style is sent out.
any comments is welcome. :)
thanks
xinhui
On 2015年06月30日 18:02, Pan Xinhui wrote:
add __bitmap_parse_common to match any contents and return expected
We can avoid in-loop incrementation of ndigits.
Save current totaldigits to ndigits before loop,
and check ndigits against totaldigits after the loop.
Signed-off-by: Pan Xinhui xinhuix@intel.com
Cc: Yury Norov yury.no...@gmail.com
---
lib/bitmap.c | 7 ---
1 file changed, 4 insertions
and reasonable to accept such string as long as
the parsing result is correct.
Signed-off-by: Pan Xinhui xinhuix@intel.com
Cc: Yury Norov yury.no...@gmail.com
---
lib/bitmap.c | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/lib/bitmap.c b/lib
If string end with '-', for exapmle, bitmap_parselist(1,0-,mask, nmaskbits),
It is not in a valid pattern, so add a check after loop.
Return -EINVAL on such condition.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
lib/bitmap.c | 4
1 file changed, 4 insertions(+)
diff --git a/lib
cpufreq core will mark all cpus in policy-cpus as initialized
by setting percpu cpufreq_cpu_data = policy.
However in acpi-cpufreq, we did not set percpu acpi_cpufreq_data for
all cpus in policy-cpus.
That will cause a issue that when we call get_cur_freq_on_cpu for a
cpu, it returns zero instead
add __bitmap_parse_common to match any contents and return expected reslut.
as __bitmap_parse_common need NULL-terminated string, we alloc a new buf.
this patch also fix an unexpected parse result issue in __bitmap_parselist.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
lib/bitmap.c
1 above.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
lib/bitmap.c | 43 ++-
1 file changed, 26 insertions(+), 17 deletions(-)
---
change log
V2 from v1: solve the codes conflicts
---
diff --git a/lib/bitmap.c b/lib/bitmap.c
index a578a01..b0e3afc
hello, Frans
thanks for your reply :)
On 2015年07月01日 14:17, Frans Klaver wrote:
On Wed, Jul 1, 2015 at 6:15 AM, Pan Xinhui xinhuix@intel.com wrote:
In __bitmap_parselist we can accept whitespaces on head or tail
during every parsing procedure.
If input has valid ranges
of acpi_cpufreq_data.
Add field *cpu* in acpi_cpufreq_data to do some proper cleanup work.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
drivers/cpufreq/acpi-cpufreq.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi
hi, Viresh
thanks for your reply.
On 2015年07月07日 14:54, Viresh Kumar wrote:
On 06-07-15, 14:30, Pan Xinhui wrote:
policy-cpu in acpi_cpufreq_cpu_init/exit is the same cpu in most cases.
However during cpu hotplug,
cpufreq core might nominate a new cpu for policy-cpu.
Why aren't
Hi, Greg
thanks for your reply!
On 2015年08月12日 02:16, Greg Kroah-Hartman wrote:
On Tue, Aug 11, 2015 at 07:23:01PM +0800, Pan Xinhui wrote:
From: Pan Xinhui xinhuix@intel.com
printk can be called in any context, It's very useful to output debug
info.
But it might cause very bad
On 2015年08月12日 10:04, Greg Kroah-Hartman wrote:
On Wed, Aug 12, 2015 at 09:53:58AM +0800, Pan Xinhui wrote:
Hi, Greg
thanks for your reply!
On 2015年08月12日 02:16, Greg Kroah-Hartman wrote:
On Tue, Aug 11, 2015 at 07:23:01PM +0800, Pan Xinhui wrote:
From: Pan Xinhui xinhuix
On 2015年08月12日 20:31, Peter Hurley wrote:
On 08/11/2015 02:16 PM, Greg Kroah-Hartman wrote:
On Tue, Aug 11, 2015 at 07:23:01PM +0800, Pan Xinhui wrote:
From: Pan Xinhui xinhuix@intel.com
printk can be called in any context, It's very useful to output debug
info.
But it might cause
Sometimes the input from user may cause an unexpected result.
just like __bitmap_parse, we return -EINVAL if there is no avaiable digit in
each
parsing procedures.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
lib/bitmap.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions
this command ends with ',' by mistake.
actually __bitmap_parselist() will report 0-3 for the final result which is
wrong.
just like __bitmap_parse, we return -EINVAL if there is no avaiable digit in
each
parsing procedures.
Signed-off-by: Pan Xinhui xinhuix@intel.com
Hello, Pan.
(Adding Alexey
From: Pan Xinhui xinhuix@intel.com
Userspace at most time do cpufreq tests very much inconveniently.
Currently they have to echo min and max cpu freq separately like below:
echo 48 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 224 /sys/devices/system/cpu/cpu0/cpufreq
hi, Rafael
thanks for you reply.
On 2015年07月29日 08:18, Rafael J. Wysocki wrote:
On Tuesday, July 28, 2015 12:53:33 PM Pan Xinhui wrote:
hi, Viresh
thanks for your reply :)
On 2015年07月28日 12:29, Viresh Kumar wrote:
On 28-07-15, 11:32, Pan Xinhui wrote:
From: Pan Xinhui xinhuix
On 2015年07月29日 17:59, Pan Xinhui wrote:
hi, Rafael
thanks for you reply.
On 2015年07月29日 08:18, Rafael J. Wysocki wrote:
On Tuesday, July 28, 2015 12:53:33 PM Pan Xinhui wrote:
hi, Viresh
thanks for your reply :)
On 2015年07月28日 12:29, Viresh Kumar wrote:
On 28-07-15, 11:32, Pan
From: Pan Xinhui xinhuix@intel.com
This check was originally added by commit 9c9a43ed2734 ([CPUFREQ]
return error when failing to set minfreq).It attempt to return an error
on obviously incorrect limits when we echo xxx .../scaling_max,min_freq
Actually we just need check if new_policy-min
From: Pan Xinhui xinhuix@intel.com
printk can be called in any context, It's very useful to output debug
info.
But it might cause very bad issues on some special cases. For example,
some driver hit errors, and it dumps many messages like reg values, etc.
Sometimes, printk is called when
, 0664);
+
thanks
xinhui
On 2015年08月11日 19:23, Pan Xinhui wrote:
From: Pan Xinhui xinhuix@intel.com
printk can be called in any context, It's very useful to output debug
info.
But it might cause very bad issues on some special cases. For example,
some driver hit errors, and it dumps
hi, Peter
thanks for your reply!
On 2015年08月11日 20:00, Peter Hurley wrote:
On 08/11/2015 07:23 AM, Pan Xinhui wrote:
From: Pan Xinhui xinhuix@intel.com
printk can be called in any context, It's very useful to output debug
info.
But it might cause very bad issues on some special
From: Pan Xinhui xinhuix@intel.com
printk can be called in any context, It's very useful to output debug
info.
But it might cause very bad issues on some special cases. For example,
some driver hit errors, and it dumps many messages like reg values, etc.
Sometimes, printk is called when
From: Pan Xinhui xinhuix@intel.com
printk can be called in any context, It's very useful to output debug
info.
But it might cause very bad issues on some special cases. For example,
some driver hit errors, and it dumps many messages like reg values, etc.
Sometimes, printk is called when
(auto_printk, 0, XH_T0);
+}
+module_param_call(th, NULL, xh_th, NULL, 0664);
+
thanks
xinhui
On 2015年08月12日 17:37, Pan Xinhui wrote:
From: Pan Xinhui xinhuix@intel.com
printk can be called in any context, It's very useful to output debug
info.
But it might cause very bad issues on some
hi, Viresh
thanks for your reply :)
On 2015年07月28日 12:29, Viresh Kumar wrote:
On 28-07-15, 11:32, Pan Xinhui wrote:
From: Pan Xinhui xinhuix@intel.com
Userspace at most time do cpufreq tests very much inconveniently.
Currently they have to echo min and max cpu freq separately like
hi, Viresh
thanks for your quick reply! :)
On 2015年07月28日 12:41, Viresh Kumar wrote:
On 28-07-15, 11:34, Pan Xinhui wrote:
From: Pan Xinhui xinhuix@intel.com
This check was originally added by commit 9c9a43ed2734 ([CPUFREQ]
return error when failing to set minfreq).It attempt
From: Pan Xinhui xinhuix@intel.com
This check was originally added by commit 9c9a43ed2734 ([CPUFREQ]
return error when failing to set minfreq).It attempt to return an error
on obviously incorrect limits when we echo xxx .../scaling_max,min_freq
Actually we just need check if new_policy-min
From: Pan Xinhui xinhuix@intel.com
Userspace at most time do cpufreq tests very much inconveniently.
Currently they have to echo min and max cpu freq separately like below:
echo 48 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 224 /sys/devices/system/cpu/cpu0/cpufreq
hi, Elliott
thanks for your reply. :)
On 2015年07月23日 22:53, Elliott, Robert (Server Storage) wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Pan Xinhui
Sent: Thursday, July 23, 2015 4:54 AM
To: linux
From: Pan Xinhui xinhuix@intel.com
There are many nodes in the PAT memtype rb-tree. When we dump this tree
we call kzalloc every time to copy nodes. Actually these kzalloc are not
necessary. Lets do a optimization now.
Let seq_file core create an *entry* when open and free it when release
hi, Borislav
thanks for your kind reply. :)
On 2015年07月22日 15:46, Borislav Petkov wrote:
On Wed, Jul 22, 2015 at 01:38:48PM +0800, Pan Xinhui wrote:
From: Pan Xinhui xinhuix@intel.com
It's more reasonable to unlock memtype_lock right after
rbt_memtype_check_insert. memtype_lock
From: Pan Xinhui xinhuix@intel.com
It's more reasonable to unlock memtype_lock right after
rbt_memtype_check_insert. memtype_lock protects all data stored in
rb-tree from multiple access. It's not cool to call kfree, pr_info, etc
with this lock held. So move spin_unlock a little ahead
From: Pan Xinhui xinhuix@intel.com
It's more reasonable to unlock memtype_lock right after
rbt_memtype_check_insert. All pat_rbtree operations need to be performed
while holding the memtype_lock. But codes like kfree, pr_info, etc have
nothing to do with this lock. So move spin_unlock
hi, Borislav
thanks for your reply. :)
On 2015年07月22日 18:46, Borislav Petkov wrote:
On Wed, Jul 22, 2015 at 05:06:04PM +0800, Pan Xinhui wrote:
how about:
memtype_lock protects the rb-tree root and the rb-nodes which is a field of
memtype from delete/add/lookup in a race.
Use
From: Pan Xinhui xinhuix@intel.com
It's more reasonable to unlock memtype_lock right after
rbt_memtype_check_insert. All pat_rbtree operations need to be performed
while holding the memtype_lock. But codes like kfree, pr_info, etc have
nothing to do with this lock. So move spin_unlock
hi, Borislav
very kind of you. :)
On 2015年07月22日 22:45, Borislav Petkov wrote:
On Wed, Jul 22, 2015 at 02:38:28PM +, Elliott, Robert (Server Storage)
wrote:
With each branch now just one line, the {} can be removed.
... and I had suggested it without the {}.
hmm, sorry for my
hi, Elliot
thanks for your reply.
On 2015年07月22日 22:38, Elliott, Robert (Server Storage) wrote:
---
Robert Elliott, HP Server Storage
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Pan Xinhui
Sent
From: Pan Xinhui xinhuix@intel.com
There are many nodes in the PAT memtype rb-tree. When we dump this tree
we call kzalloc every time to copy nodes. Actually these kzalloc are not
necessary. Lets do a optimization now.
Create an *entry* in memtype_seq_start(), and free it in
memtype_seq_stop
hi, Rafael,
let me do more explanation :)
On 2015年07月14日 10:09, Pan Xinhui wrote:
hi, Rafael,
thanks for you reply :)
On 2015年07月14日 07:26, Rafael J. Wysocki wrote:
On Monday, July 13, 2015 02:33:08 PM Pan Xinhui wrote:
hi, Rafeal
thanks for your reply. :)
On 2015年07月11日
behavior because level is set to PG_LEVEL_4K even when pte
is NULL.
So let *level* meaningful even lookup_address_in_pgd return NULL by
moving the assignment before pud/pmd_offset.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
arch/x86/mm/pageattr.c | 4 ++--
1 file changed, 2 insertions
hi, Rafael,
thanks for you reply :)
On 2015年07月14日 07:26, Rafael J. Wysocki wrote:
On Monday, July 13, 2015 02:33:08 PM Pan Xinhui wrote:
hi, Rafeal
thanks for your reply. :)
On 2015年07月11日 04:44, Rafael J. Wysocki wrote:
Hi,
On Fri, Jul 10, 2015 at 7:50 AM, Pan Xinhui xinhuix
hi, Rafael
thanks for your nice work :)
On 2015年07月18日 09:14, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki rafael.j.wyso...@intel.com
acpi_processor_unregister_performance() actually doesn't use its
first argument, so drop it and update the callers accordingly.
Signed-off-by:
From: Pan Xinhui xinhuix@intel.com
freq_table is now stored as policy-freq_table, so drop the redundant
freq_table from struct cpufreq_acpi_io.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
drivers/cpufreq/ia64-acpi-cpufreq.c | 15 ---
1 file changed, 8 insertions(+), 7
On 2015年07月20日 14:24, Pan Xinhui wrote:
From: Pan Xinhui xinhuix@intel.com
freq_table should be alloced in -init and freed in -exit. However it
does not be freed. Fix this memory leak in acpi_cpufreq_cpu_exit.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
drivers/cpufreq/ia64
hi, tglx
thanks for your reply.
On 2015年07月17日 22:50, Thomas Gleixner wrote:
On Tue, 14 Jul 2015, Pan Xinhui wrote:
If pmd or pud is not set, we may set a wrong page mapping level.
No. The behaviour is simply undefined, if the return value of the
function is NULL.
So what you
From: Pan Xinhui xinhuix@intel.com
freq_table should be alloced in -init and freed in -exit. However it
does not be freed. Fix this memory leak in acpi_cpufreq_cpu_exit.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
drivers/cpufreq/ia64-acpi-cpufreq.c | 1 +
1 file changed, 1
hi, Rafael
thanks for your reply :)
On 2015年07月18日 08:34, Rafael J. Wysocki wrote:
On Tuesday, July 14, 2015 10:52:35 AM Pan Xinhui wrote:
hi, Rafael,
let me do more explanation :)
On 2015年07月14日 10:09, Pan Xinhui wrote:
hi, Rafael,
thanks for you reply :)
On 2015年07月14日
hi, Rafeal
thanks for your reply. :)
On 2015年07月11日 04:44, Rafael J. Wysocki wrote:
Hi,
On Fri, Jul 10, 2015 at 7:50 AM, Pan Xinhui xinhuix@intel.com wrote:
If CONFIG_X86_ACPI_CPUFREQ_CPB has not been defined, the placeholder for
cpb is not needed. Add ifdef around it.
Signed
hi, tglx
thanks for your reply :)
On 2015年07月21日 16:10, Thomas Gleixner wrote:
On Tue, 21 Jul 2015, Pan Xinhui wrote:
diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c
index 188e3e0..f3c49fa 100644
--- a/arch/x86/mm/pat.c
+++ b/arch/x86/mm/pat.c
@@ -538,22 +538,20 @@ int
From: Pan Xinhui xinhuix@intel.com
It's safe and more reasonable to unlock memtype_lock right after
rbt_memtype_check_insert. It's not cool to call kfree, pr_info, etc with
this lock held. So move spin_unlock a little ahead.
memory_lock protects data stored in rb-tree, if *new* succeed
From: Pan Xinhui xinhuix@intel.com
It's safe and more reasonable to unlock memtype_lock right after
rbt_memtype_check_insert.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
arch/x86/mm/pat.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/x86/mm/pat.c b
hi, Borislav
thanks for your reply :)
On 2015年07月21日 14:55, Borislav Petkov wrote:
On Tue, Jul 21, 2015 at 02:29:35PM +0800, Pan Xinhui wrote:
From: Pan Xinhui xinhuix@intel.com
It's safe and more reasonable to unlock memtype_lock right after
rbt_memtype_check_insert.
Signed
s many available flags as possible. :)
thanks
xinhui
On 2015年10月14日 13:36, Pan Xinhui wrote:
> From: Pan Xinhui <xinhuix@intel.com>
>
> GFP_RECLAIM_MASK was introduced in commit 6cb062296f73 ("Categorize GFP
> flags"). In slub subsystem, this macro controls slub's allo
From: Pan Xinhui <xinhuix@intel.com>
GFP_RECLAIM_MASK was introduced in commit 6cb062296f73 ("Categorize GFP
flags"). In slub subsystem, this macro controls slub's allocation
behavior. In particular, some flags which are not in GFP_RECLAIM_MASK
will be cleared. So when sl
hello, Michal
thanks for your kind reply!
On 2015年10月14日 15:41, Michal Hocko wrote:
> On Wed 14-10-15 13:58:05, Pan Xinhui wrote:
>> Hi, all
>> I am working on some debug features' development.
>> I use kmalloc in some places of *scheduler*.
>
> This
hi, Michal
thanks for your reply :)
On 2015年10月14日 15:34, Michal Hocko wrote:
> On Wed 14-10-15 13:36:51, Pan Xinhui wrote:
>> From: Pan Xinhui <xinhuix@intel.com>
>>
>> GFP_RECLAIM_MASK was introduced in commit 6cb062296f73 ("Categorize GFP
>>
On 2015年10月14日 16:38, Michal Hocko wrote:
> On Wed 14-10-15 16:17:31, Pan Xinhui wrote:
> [...]
>> I have a look at Mel's patchset. yes, it can help fix my kswapd issue.
>> :) So I just need change my kmalloc's gfp_flag to GFP_ATOMIC &~
>> __GFP_KSWAPD_RECLAIM, then
hi, Dmitry
thanks for your reply
On 2015年07月08日 01:11, Dmitry Torokhov wrote:
Hi Pan,
On Tue, Jul 07, 2015 at 08:43:26PM +0800, Pan Xinhui wrote:
@@ -364,19 +363,24 @@ static u32 get_cur_val(const struct cpumask *mask)
static unsigned int get_cur_freq_on_cpu(unsigned int
acpi_processor_register_performance call, it
may also fail thanks to the internal check of pr-performace.
So we add a field *perf_cpu* to fix this issue.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
drivers/cpufreq/acpi-cpufreq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion
If CONFIG_X86_ACPI_CPUFREQ_CPB has not been defined, the placeholder for
cpb is not needed. Add ifdef around it.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
drivers/cpufreq/acpi-cpufreq.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers
hi, Andrew
thanks for you kind reply :)
On 2015年07月10日 06:57, Andrew Morton wrote:
On Sat, 27 Jun 2015 14:36:18 +0800 Pan Xinhui xinhuix@intel.com wrote:
Sometimes the input from user may cause an unexpected result.
for example, echo 1-3, /proc/irq/xxx/smp_affinity_list
acpi_processor_register_performance call, it
may also fail thanks to the internal check of pr-performace.
So we add a field *acpi_perf_cpu* to fix this issue.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
Change from V1:
comments update
---
drivers/cpufreq/acpi-cpufreq.c | 4 +++-
1
hi, Viresh
thanks for your reply. :)
On 2015年07月07日 18:45, Viresh Kumar wrote:
On 07-07-15, 18:29, Pan Xinhui wrote:
Now policy has field of driver_data, we can use it to get rid of per_cpu
acpi_cpufreq_data.
Instead:
Drivers can store their internal per-policy information
hi, all
thanks for reviewing.
any comments or advices are welcome :)
I am OOO tomorrow, so response may arrive later.
thanks
xinhui
On 2015年07月07日 20:43, Pan Xinhui wrote:
Drivers can store their internal per-policy information in
policy-driver_data, lets use it.
we have benefits
*driver_data* to fix it.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
Changes from V1:
codes style fix, comments update
move cpufreq_cpu_put(policy) after we get *driver_data*
---
drivers/cpufreq/acpi-cpufreq.c | 40 ++--
1 file changed, 22
hi, Viresh
thanks for your quick reply :)
On 2015年07月07日 16:53, Viresh Kumar wrote:
On 07-07-15, 15:52, Pan Xinhui wrote:
I have latest codes.
codes in cpufreq.c are below.
1436 down_write(policy-rwsem);
1437 cpumask_clear_cpu(cpu, policy-cpus);
1438
1439
*driver_data* to fix it.
Signed-off-by: Pan Xinhui xinhuix@intel.com
---
drivers/cpufreq/acpi-cpufreq.c | 38 +++---
1 file changed, 23 insertions(+), 15 deletions(-)
diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
index 0136dfc
hi, Rafael
thanks for your kind reply. :)
On 2015年07月09日 08:20, Rafael J. Wysocki wrote:
On Tuesday, July 07, 2015 08:04:43 PM Viresh Kumar wrote:
On 07-07-15, 20:43, Pan Xinhui wrote:
Drivers can store their internal per-policy information in
policy-driver_data, lets use it.
we
oop
traverse.
Reported-by: Dmitry Vyukov <dvyu...@google.com>
Fixes: 5a64096700dc ("tty/n_gsm.c: fix a memory leak in gsmld_open")
Signed-off-by: Pan Xinhui <xinhui@linux.vnet.ibm.com>
the signed-off-by name has to match your from: name :(
--
To unsubscribe from this list
From: Pan Xinhui <xinhui@linux.vnet.ibm.com>
There is one filed gsm->num to store mux's index of gsm_mux[]. So use
gsm->num to remove itself from gsm_mux[] instead of the for-loop
traverse in gsm_cleanup_mux().
Signed-off-by: Pan Xinhui <xinhui@linux.vnet.ibm.com>
you are right.
i still have many confusion. but tears came out several times:( when i am back,
i will reply you again.
thx
xinhui
On 2015-12-14 23:40 , One Thousand Gnomes Wrote:
On Mon, 14 Dec 2015 15:08:03 +0800
Pan Xinhui <xinhui@linux.vnet.ibm.com> wrote:
From: Pan Xinhu
From: Pan Xinhui <xinhui@linux.vnet.ibm.com>
There is one filed gsm->num to store mux's index of gsm_mux[]. So use
gsm->num to remove itself from gsm_mux[] instead of the for-loop
traverse in gsm_cleanup_mux().
Signed-off-by: Pan Xinhui <xinhui@linux.vnet.ibm.com>
The existing version uses a heavy barrier while only release semantics
is required. So use atomic_sub_return_release instead.
Suggested-by: Peter Zijlstra (Intel) <pet...@infradead.org>
Signed-off-by: Pan Xinhui <xinhui@linux.vnet.ibm.com>
---
include/asm-generic/qspinlock.h |
queued_spin_lock_slowpath should not worry about interrupt change
node->count by accident because ->count is inc and dec when we
enter/leave queued_spin_lock_slowpath.
So this_cpu_dec() does some no point things here, lets use this_cpu_ptr
for a small optimization.
Signed-off-by: Pan
1 - 100 of 645 matches
Mail list logo
