[PATCH v3 2/4] powerpc/spinlock: support vcpu preempted check

->yield_count keeps zero on powerNV. So we can just skip the machine type check. Suggested-by: Boqun Feng Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/spinlock.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/arch/powerpc/incl

[PATCH v3 0/4] implement vcpu preempted check

nterface bool vcpu_is_preempted(int cpu) and use it in some spin loops of osq_lock, rwsem_spin_on_owner and mutex_spin_on_owner. These spin_on_onwer variant also cause rcu stall before we apply this patch set Pan Xinhui (4): kernel/sched: introduce vcpu preempted check interface powerpc/spinlock: support v

[PATCH v3 3/4] locking/osq: Drop the overhead of osq_lock()

call_common 2.83% sched-messaging [kernel.vmlinux] [k] copypage_power7 2.64% sched-messaging [kernel.vmlinux] [k] rwsem_spin_on_owner 2.00% sched-messaging [kernel.vmlinux] [k] osq_lock Suggested-by: Boqun Feng Signed-off-by: Pan Xinhui --- kernel/locking/osq_lock.c | 10 +- 1 f

[PATCH v3 1/4] kernel/sched: introduce vcpu preempted check interface

check. Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Pan Xinhui --- include/linux/sched.h | 12 1 file changed, 12 insertions(+) diff --git a/include/linux/sched.h b/include/linux/sched.h index 6e42ada..cbe0574 100644 --- a/include/linux/sched.h +++ b/include/linux/sched.h

[PATCH v3 4/4] kernel/locking: Drop the overhead of {mutex,rwsem}_spin_on_owner

essaging [kernel.vmlinux] [k] system_call 2.69% sched-messaging [kernel.vmlinux] [k] wait_consider_task Signed-off-by: Pan Xinhui --- kernel/locking/mutex.c | 15 +-- kernel/locking/rwsem-xadd.c | 16 +--- 2 files changed, 26 insertions(+), 5 deletions(-) diff --git

[PATCH v3] locking/qrwlock: Let qrwlock has same layout regardless of the endian

ut, IOW we can remove the #if __little_endian in struct __qrwlock. With such modification, we only need define some _QW* and _QR* with corresponding values in different endian systems. Suggested-by: Will Deacon Signed-off-by: Pan Xinhui Acked-by: Waiman Long --- change from v2: change ma

[PATCH] gfp: GFP_RECLAIM_MASK should include __GFP_NO_KSWAPD

From: Pan Xinhui 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 slub pass this new gfp

Re: [PATCH] gfp: GFP_RECLAIM_MASK should include __GFP_NO_KSWAPD

as many available flags as possible. :) thanks xinhui On 2015年10月14日 13:36, Pan Xinhui wrote: > From: Pan Xinhui > > GFP_RECLAIM_MASK was introduced in commit 6cb062296f73 ("Categorize GFP > flags"). In slub subsystem, this macro controls slub's allocation > behavior. In

Re: [PATCH] gfp: GFP_RECLAIM_MASK should include __GFP_NO_KSWAPD

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 >> >> GFP_RECLAIM_MASK was introduced in commit 6cb062296f73 ("Categorize GFP >> flags"). In slub

Re: [PATCH] gfp: GFP_RECLAIM_MASK should include __GFP_NO_KSWAPD

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*. > >

Re: [PATCH] gfp: GFP_RECLAIM_MASK should include __GFP_NO_KSWAPD

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_REC

[PATCH] mm/util.c: add a none zero check of "len"

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 --- mm/util.c | 5 + 1 file changed, 5 insertions(+) diff --git a/mm/util.c b/mm/util.c index fec39d4..3dc287

[PATCH] tty/n_gsm.c: fix a memory leak when gsmtty is removed

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. Signed

[PATCH] tty/n_gsm.c: fix a memory leak when gsmtty is removed

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. Signed

[PATCH] touchscreen:atmel_mxt_ts: suspend/resume cause panic if input_dev fails to init

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 --- drivers/input/touchscreen/atmel_mxt_ts.c | 6 ++ 1 file changed, 6 ins

[PATCH] atmel: fix an error handle in mxt_probe

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 l

[PATCH] ACPI / osl: add acpi_os_down_wait to avoid a schedule BUG

67, 1] [] ? kthread_create_on_node+0x190/0x190 Signed-off-by: Pan Xinhui --- drivers/acpi/osl.c | 28 +++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c index 7ccba39..57a1812 100644 --- a/drivers/acpi/osl.c +++ b/drivers/acpi/

Re: [PATCH] ACPI / osl: add acpi_os_down_wait to avoid a schedule BUG

+0xe/0x10 [ 722.027821, 2] [] cpu_notify+0x23/0x50 [ 722.033757, 2] [] notify_cpu_starting+0x28/0x30 [ 722.040569, 2] [] 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

Re: [PATCH] ACPI / osl: add acpi_os_down_wait to avoid a schedule BUG

1148.586991, 1] [] smpboot_thread_fn+0x17d/0x2b0 [ 1148.593819, 1] [] ? SyS_setgroups+0x160/0x160 [ 1148.600455, 1] [] kthread+0xe4/0x100 [ 1148.606208, 1] [] ? kthread_create_on_node+0x190/0x190 [ 1148.613721, 1] [] ret_from_fork+0x58/0x90 [ 1148.619967, 1] [] ? kthread_create_on_node+0x190/0x190 Signed-off

[PATCH V4] x86/mm/pat: Do a small optimization and fix in reserve_memtype

From: Pan Xinhui 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 a little ahead. If

[PATCH V5] x86/mm/pat: Do a small optimization and fix in reserve_memtype

From: Pan Xinhui 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 a little ahead. If

Re: [PATCH V4] x86/mm/pat: Do a small optimization and fix in reserve_memtype

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...@

Re: [PATCH V4] x86/mm/pat: Do a small optimization and fix in reserve_memtype

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 f

[PATCH] x86/mm/pat: Do a small optimization when dump PAT memtype list

From: Pan Xinhui 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(). These two

Re: [PATCH] x86/mm/pat: Do a small optimization when dump PAT memtype list

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: Thursda

[PATCH] x86/mm/pat: Do a small optimization when dump PAT memtype list

From: Pan Xinhui 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. *entry* is stored as

Re: [PATCH V2] acpi-cpufreq: replace per_cpu with driver_data of policy

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 unsig

Re: [PATCH V2] acpi-cpufreq: replace per_cpu with driver_data of policy

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 &g

Re: [PATCH] cpufreq: Add scaling frequency range support

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, Pa

Re: [PATCH] cpufreq: Add scaling frequency range support

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 2

[PATCH V2] cpufreq: Correct a freq check in cpufreq_set_policy

From: Pan Xinhui 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 &

[PATCH] cpufreq: Add scaling frequency range support

From: Pan Xinhui 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/scaling_ma

[PATCH] cpufreq: Correct a freq check in cpufreq_set_policy

From: Pan Xinhui 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 &

Re: [PATCH] cpufreq: Add scaling frequency range support

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 >> >> Userspace at most time do cpufreq tests very much inconveniently. >> Currently they have to echo min and max cpu

Re: [PATCH] cpufreq: Correct a freq check in cpufreq_set_policy

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 >> >> This check was originally added by commit 9c9a43ed2734 ("[CPUFREQ] >> return error when failing to set m

[PATCH V2] cpufreq: Add scaling frequency range support

From: Pan Xinhui 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/scaling_ma

Re: [PATCH] printk: rebalance printk

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 >>> >>> printk can be called in any context, It's very useful to output d

Re: [PATCH] powerpc: introduce {cmp}xchg for u8 and u16

Hello, Waiman On 2016年04月13日 23:53, Waiman Long wrote: > On 04/13/2016 07:15 AM, Pan Xinhui wrote: >> Hello Peter, >> >> On 2016年04月12日 22:30, Peter Zijlstra wrote: >> >>>> I am working on the qspinlock implementation on PPC. >>>> Your and Waiman

Re: [PATCH] locking/pvqspinlock: Add lock holder CPU argument to pv_wait()

On 2016年04月14日 08:21, Peter Zijlstra wrote: > On Wed, Apr 13, 2016 at 04:59:20PM -0400, Waiman Long wrote: >> Pan Xinhui was asking for a lock holder cpu argument in pv_wait() >> to help the porting of pvqspinlock to PPC. The new argument will can >> potentially help hyp

Re: [PATCH] locking/pvqspinlock: Add lock holder CPU argument to pv_wait()

On 2016年04月14日 04:59, Waiman Long wrote: > Pan Xinhui was asking for a lock holder cpu argument in pv_wait() > to help the porting of pvqspinlock to PPC. The new argument will can > potentially help hypervisor expediate the execution of the critical > section so that the lock hol

Re: [PATCH] locking/pvqspinlock: Add lock holder CPU argument to pv_wait()

>state, vcpu_halted, ph->prev_cpu); } /* any comments are welcome. I put my patch here just for simplicity, or need I send it out in a new thread? thanks xinhui On 2016年04月14日 17:36, Pan Xinhui wrote: > > > On 2016年04月14日 04:59, Waiman Long wrote: >> P

Re: [PATCH resend] powerpc: enable qspinlock and its virtualization support

On 2016年04月29日 05:07, Waiman Long wrote: > On 04/28/2016 06:55 AM, Pan Xinhui wrote: >> From: Pan Xinhui >> >> This patch aims to enable qspinlock on PPC. And on pseries platform, it also >> support >> paravirt qspinlock. >> >> Signed-off-by: Pa

[PATCH] pv-qspinlock: Try to re-hash the lock after spurious_wakeup

urn directly, that is not paravirt-friendly because pv_wait_head_or_lock will just spin on the lock then. Signed-off-by: Pan Xinhui --- kernel/locking/qspinlock_paravirt.h | 39 + 1 file changed, 31 insertions(+), 8 deletions(-) diff --git a/kernel/lock

[PATCH v2 5/6] pv-qspinlock: use cmpxchg_release in __pv_queued_spin_unlock

cmpxchg_release is lighter, we can gain a better performace then. Suggested-by: Boqun Feng Signed-off-by: Pan Xinhui --- kernel/locking/qspinlock_paravirt.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/locking/qspinlock_paravirt.h b/kernel/locking

[PATCH v2 6/6] powerpc: pseries: pv-qspinlock build config/make

pseries can use pv-qspinlock. Signed-off-by: Pan Xinhui --- arch/powerpc/kernel/Makefile | 1 + arch/powerpc/platforms/pseries/Kconfig | 8 2 files changed, 9 insertions(+) diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index 2da380f..ae7c2f1 100644

[PATCH v2 2/6] powerpc: pseries/Kconfig: qspinlock build config

pseries will use qspinlock by default. Signed-off-by: Pan Xinhui --- arch/powerpc/platforms/pseries/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index bec90fb..f669323 100644 --- a/arch/powerpc

[PATCH v2 3/6] powerpc: lib/locks.c: cpu yield/wake helper function

pv-qspinlock core has pv_wait/pv_kick which will give a better performace by yielding and kicking cpu at some cases. lets support them by adding two corresponding helper functions. Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/spinlock.h | 4 arch/powerpc/lib/locks.c

[PATCH v2 4/6] pv-qspinlock: powerpc support pv-qspinlock

callbacks to pv version. Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/qspinlock.h | 17 + arch/powerpc/include/asm/qspinlock_paravirt.h | 38 +++ .../powerpc/include/asm/qspinlock_paravirt_types.h | 13 +++ arch/powerpc/kernel/paravirt.c

[PATCH v2 1/6] qspinlock: powerpc support qspinlock

Base code to enable qspinlock on powerpc. this patch add some #ifdef here and there. Although there is no paravirt related code, we can successfully build a qspinlock kernel after apply this patch. Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/qspinlock.h | 22

[PATCH v3 0/6] powerpc use pv-qpsinlock instead of spinlock

x][k] __pv_queued_spin_lock_slowpath 3.66% sched-messaging [kernel.vmlinux][k] __pv_queued_spin_unlock 3.37% sched-messaging [kernel.vmlinux][k] __slab_free 3.06% sched-messaging [kernel.vmlinux][k] unix_stream_read_gen

[PATCH v3 2/6] powerpc: pseries/Kconfig: Add qspinlock build config

pseries will use qspinlock by default. Signed-off-by: Pan Xinhui --- arch/powerpc/platforms/pseries/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/pseries/Kconfig b/arch/powerpc/platforms/pseries/Kconfig index bec90fb..f669323 100644 --- a/arch/powerpc

[PATCH v3 5/6] pv-qspinlock: use cmpxchg_release in __pv_queued_spin_unlock

cmpxchg_release is light-wight than cmpxchg, we can gain a better performace then. On some arch like ppc, barrier impact the performace too much. Suggested-by: Boqun Feng Signed-off-by: Pan Xinhui --- kernel/locking/qspinlock_paravirt.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion

[PATCH v3 0/6] powerpc use pv-qpsinlock as the default spinlock implemention

| 311449290 | kernel compiling test: build a linux kernel image to see how long it took _testspinlcok__pv-qspinlcok_ | compiling takes| 22m | 22m | Pan Xinhui (6): qspinlock: powerpc support qspinlock powerpc

[PATCH v3 6/6] powerpc: pseries: Add pv-qspinlock build config/make

pseries has PowerVM support, the default option is Y. Signed-off-by: Pan Xinhui --- arch/powerpc/kernel/Makefile | 1 + arch/powerpc/platforms/pseries/Kconfig | 8 2 files changed, 9 insertions(+) diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile index

[PATCH v3 3/6] powerpc: lib/locks.c: Add cpu yield/wake helper function

pv-qspinlock core has pv_wait/pv_kick which will give a better performace by yielding and kicking cpu at some cases. lets support them by adding two corresponding helper functions. Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/spinlock.h | 4 arch/powerpc/lib/locks.c

[PATCH v3 4/6] pv-qspinlock: powerpc support pv-qspinlock

pv_lock_ops callbacks to pv version. Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/qspinlock.h | 17 arch/powerpc/include/asm/qspinlock_paravirt.h | 38 ++ .../powerpc/include/asm/qspinlock_paravirt_types.h | 13 +++ arch/powerpc/kernel/paravirt.c

[PATCH v3 1/6] qspinlock: powerpc support qspinlock

Base code to enable qspinlock on powerpc. this patch add some #ifdef here and there. Although there is no paravirt related code, we can successfully build a qspinlock kernel after apply this patch. Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/qspinlock.h | 22

[PATCH V4] powerpc: Implement {cmp}xchg for u8 and u16

From: Pan Xinhui Implement xchg{u8,u16}{local,relaxed}, and cmpxchg{u8,u16}{,local,acquire,relaxed}. It works on all ppc. remove volatile of first parameter in __cmpxchg_local and __cmpxchg Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Pan Xinhui --- change from v3: rewrite in

Re: [PATCH V4] powerpc: Implement {cmp}xchg for u8 and u16

On 2016年04月27日 22:59, Boqun Feng wrote: > On Wed, Apr 27, 2016 at 10:50:34PM +0800, Boqun Feng wrote: >> >> Sorry, my bad, we can't implement cmpxchg like this.. please ignore >> this, I should really go to bed soon... >> >> But still, we can save the "tmp" for xchg() I think. >> > > No.. we can

Re: [PATCH V4] powerpc: Implement {cmp}xchg for u8 and u16

On 2016年04月28日 15:59, Peter Zijlstra wrote: > On Wed, Apr 27, 2016 at 05:16:45PM +0800, Pan Xinhui wrote: >> From: Pan Xinhui >> >> Implement xchg{u8,u16}{local,relaxed}, and >> cmpxchg{u8,u16}{,local,acquire,relaxed}. >> >> It works on all ppc. >

[PATCH] powerpc: enable qspinlock and its virtualization support

From: Pan Xinhui This path aims to enable qspinlock on PPC. And on pseries platform, it also support paravirt qspinlock. Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/qspinlock.h | 37 +++ arch/powerpc/include/asm/qspinlock_paravirt.h | 36

[PATCH resend] powerpc: enable qspinlock and its virtualization support

From: Pan Xinhui This patch aims to enable qspinlock on PPC. And on pseries platform, it also support paravirt qspinlock. Signed-off-by: Pan Xinhui --- arch/powerpc/include/asm/qspinlock.h | 37 +++ arch/powerpc/include/asm/qspinlock_paravirt.h | 36

[PATCH resend ] tty/n_gsm.c: use gsm->num to remove mux itself from gsm_mux[]

From: Pan Xinhui 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 --- drivers/tty/n_gsm.c | 14 +- 1 files changed, 5 inser

Re: [PATCH] tty/n_gsm.c: fix false positive WARN_ON and do some codes improvement

ukov Fixes: 5a64096700dc ("tty/n_gsm.c: fix a memory leak in gsmld_open") Signed-off-by: Pan Xinhui the signed-off-by name has to match your from: name :( -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger

Re: [PATCH 1/2] ACPI / processor: Drop an unused argument of a cleanup routine

hi, Rafael thanks for your nice work :) On 2015年07月18日 09:14, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > acpi_processor_unregister_performance() actually doesn't use its > first argument, so drop it and update the callers accordingly. > > Signed-off-by: Rafael J. Wysocki > -

Re: [PATCH] x86/mm/pat: let level meaningful even NULL return in, lookup_address_in_pgd

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

Re: [PATCH] acpi-cpufreq: Add a miss ifdef CONFIG_X86_ACPI_CPUFREQ_CPB

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,

[PATCH] cpufreq: ia64: remove redundant freq_table of acpi_cpufreq_data

From: Pan Xinhui 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 --- drivers/cpufreq/ia64-acpi-cpufreq.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/cpuf

[PATCH] cpufreq: ia64: Fix a memory leak in acpi_cpufreq_cpu_exit

From: Pan Xinhui 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 --- drivers/cpufreq/ia64-acpi-cpufreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufre

Re: [PATCH] cpufreq: ia64: Fix a memory leak in acpi_cpufreq_cpu_exit

hui On 2015年07月20日 14:24, Pan Xinhui wrote: > From: Pan Xinhui > > 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 > --- > drivers/cpufreq/ia

[PATCH] x86/mm/pat: Do a small optimization in reserve_memtype

From: Pan Xinhui It's safe and more reasonable to unlock memtype_lock right after rbt_memtype_check_insert. Signed-off-by: Pan Xinhui --- arch/x86/mm/pat.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/x86/mm/pat.c b/arch/x86/mm/pat.c index 188e3e0..cb

Re: [PATCH] x86/mm/pat: Do a small optimization in reserve_memtype

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 >> >> It's safe and more reasonable to unlock memtype_lock right after >> rbt_memtype_c

[PATCH V2] x86/mm/pat: Do a small optimization and fix in reserve_memtype

From: Pan Xinhui 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 to be stored i

Re: [PATCH V2] x86/mm/pat: Do a small optimization and fix in reserve_memtype

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 &

[PATCH V3] x86/mm/pat: Do a small optimization and fix in reserve_memtype

From: Pan Xinhui 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. If *new* suc

Re: [PATCH V3] x86/mm/pat: Do a small optimization and fix in reserve_memtype

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 >> >> It's more reasonable to unlock memtype_lock right after >> rbt_memtype_check_i

Re: [PATCH V3] x86/mm/pat: Do a small optimization and fix in reserve_memtype

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

Re: [PATCH resend ] tty/n_gsm.c: use gsm->num to remove mux itself from gsm_mux[]

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 wrote: From: Pan Xinhui There is one filed gsm->num to store mux&#

[PATCH V2] tty/n_gsm.c: use gsm->num to remove mux itself from gsm_mux[]

From: Pan Xinhui 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 --- change from V1: lock is also held for the if() --- drivers/

[PATCH] asm-generic/cmpxchg: use BUILD_BUG() when detect unfit, {cmp}xchg size

From: pan xinhui __xchg_called_with_bad_pointer/wrong_size_cmpxchg can't tell us what codes use {cmp}xchg in incorrect way. And no error will be reported until the link stage. To fix such kinds of issues in a easy way, We use BUILD_BUG(). Signed-off-by: pan xinhui --- include/asm-ge

[PATCH] arch/powerpc: use BUILD_BUG() when detect unfit {cmp}xchg, size

From: pan xinhui __xchg_called_with_bad_pointer() can't tell us what codes use {cmp}xchg in incorrect way. And no error will be reported until the link stage. To fix such kinds of issues in a easy way, we use BUILD_BUG() here. Signed-off-by: pan xinhui --- arch/powerpc/include/asm/cmpx

[PATCH V2] arch/powerpc: use BUILD_BUG_ON_MSG() when detect unfit {cmp}xchg size

From: pan xinhui __xchg_called_with_bad_pointer() can't tell us what codes use {cmp}xchg in incorrect way. And no error will be reported until the link stage. To fix such a kind of issues easily, we use BUILD_BUG_ON_MSG() here. Signed-off-by: pan xinhui --- change from V1:

[PATCH V2] arch/powerpc: use BUILD_BUG_ON_MSG() when detect unfit {cmp}xchg size

From: pan xinhui __xchg_called_with_bad_pointer() can't tell us what codes use {cmp}xchg in incorrect way. And no error will be reported until the link stage. To fix such a kind of issues easily, we use BUILD_BUG_ON_MSG() here. Signed-off-by: pan xinhui --- change from V1:

Re: [PATCH] atmel: fix an error handle in mxt_probe

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 is

[PATCH V2] atmel: fix a race between fw_load and data free

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

[PATCH V3] atmel: fix a race between fw_load and data free

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

Re: [PATCH V2] atmel: fix a race between fw_load and data free

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,

[PATCH v2 RESEND] tty/n_gsm.c: fix a memory leak when gsmtty is removed

| tty->port->itty = NULL; | 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 --- Changes in v2: Don&#

Re: [PATCH] tty/n_gsm.c: fix a memory leak when gsmtty is removed

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->

[PATCH v2] tty/n_gsm.c: fix a memory leak when gsmtty is removed

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 ra

Re: [PATCH] mm/util.c: add a none zero check of "len"

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 --- mm/

Re: [PATCH V2] powerpc: Implement {cmp}xchg for u8 and u16

Hello, boqun On 2016年04月19日 17:18, Boqun Feng wrote: > Hi Xinhui, > > On Tue, Apr 19, 2016 at 02:29:34PM +0800, Pan Xinhui wrote: >> From: Pan Xinhui >> >> Implement xchg{u8,u16}{local,relaxed}, and >> cmpxchg{u8,u16}{,local,acquire,relaxed}. >> &g

[PATCH V2]sh: cmpxchg: fix a bit shift bug in big_endian os

From: Pan Xinhui Correct bitoff in big endian OS. Current code works correctly for 1 byte but not for 2 bytes. Fixes: 3226aad81aa6 ("sh: support 1 and 2 byte xchg") Signed-off-by: Pan Xinhui Acked-by: Michael S. Tsirkin --- changes from V1: just add some patch comment

[PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

From: Pan Xinhui Implement xchg{u8,u16}{local,relaxed}, and cmpxchg{u8,u16}{,local,acquire,relaxed}. It works on all ppc. The basic idea is from commit 3226aad81aa6 ("sh: support 1 and 2 byte xchg") Suggested-by: Peter Zijlstra (Intel) Signed-off-by: Pan Xinhui --- change from v2:

Re: [PATCH v2] locking/pvqspinlock: Add lock holder CPU argument to pv_wait()

Hello Peter On 2016年04月20日 20:08, Peter Zijlstra wrote: > On Thu, Apr 14, 2016 at 02:41:58PM -0400, Waiman Long wrote: >> Pan Xinhui was asking for a lock holder cpu argument in pv_wait() >> to help the porting of pvqspinlock to PPC. The new argument will can >> potent

Re: [PATCH v2] locking/pvqspinlock: Add lock holder CPU argument to pv_wait()

On 2016年04月20日 22:19, Peter Zijlstra wrote: > On Wed, Apr 20, 2016 at 10:15:09PM +0800, Pan Xinhui wrote: >> So there is such case that we search the whole hashtable and the lock is not >> found. :( >> Waiman assume that if l = null, the lock is not stored. however the lo

Re: [PATCH v2] locking/pvqspinlock: Add lock holder CPU argument to pv_wait()

On 2016年04月20日 22:18, Peter Zijlstra wrote: > On Wed, Apr 20, 2016 at 10:15:09PM +0800, Pan Xinhui wrote: >>>> +static struct pv_node *pv_lookup_hash(struct qspinlock *lock) >>>> +{ >>>> + unsigned long offset, hash = hash_ptr(lock, pv_lock_hash_

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

On 2016年04月20日 22:24, Peter Zijlstra wrote: > On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote: > >> +#define __XCHG_GEN(cmp, type, sfx, skip, v) \ >> +static __always_inline unsigned long >> \

Re: [PATCH V3] powerpc: Implement {cmp}xchg for u8 and u16

On 2016年04月21日 23:52, Boqun Feng wrote: > On Thu, Apr 21, 2016 at 11:35:07PM +0800, Pan Xinhui wrote: >> On 2016年04月20日 22:24, Peter Zijlstra wrote: >>> On Wed, Apr 20, 2016 at 09:24:00PM +0800, Pan Xinhui wrote: >>> >>>> +#de

Re: [PATCH v11 3/3] printk: make printk.synchronous param rw

On 2016年04月08日 01:31, Sergey Senozhatsky wrote: > Change `synchronous' printk param to be RW, so user space > can change printk mode back and forth to/from sync mode > (which is considered to be more reliable). > > Signed-off-by: Sergey Senozhatsky > --- > kernel/printk/printk.c | 63 > ++

  1   2   3   4   >