hi,
When we press ctrl-alt-del,kernel_restart_prepare will revoke
cfi_intelext_reboot which
will set flash to read array mode,but later when device_shutdown is
invoked which may
put current work queue to sleep and other process may be sheduled to
running and programming flash in not FL_READY
I am curious how Linux convert an fd to the pathname? Does it
recursively walk back from current dentry to the root?
Using d_path.
Can someone point me to the right place in the kernel where this
functionality is implemented?
do_proc_readlink may be the function you want.
-
To unsubscribe
the defconfig of ppc.
There does have some broken for some configs. But they are not related to this
change. This also passed allyesconfig for x86. Boot test on p2020rdb and
p5020ds boards.
Kevin Hao (5):
jump_label: factor out the base part of jump_label.h to a separate
file
jump_label
/workqueue.h and this will cause recursive
inclusion. In order to fix this, we choose to factor out the base
part of jump_label.h to a separate header file and we can include
that file instead of jump_label.h to avoid the recursive inclusion.
No functional change.
Signed-off-by: Kevin Hao haoke
The struct static_key will have a atomic_t type member no matter
whether jump label is enabled or not. We would include linux/atomic.h
when jump label is not enabled. But it also does make sense to include
this header file when jump label is enabled.
Signed-off-by: Kevin Hao haoke...@gmail.com
On Wed, Mar 12, 2014 at 12:43:05PM -0500, Scott Wood wrote:
Shouldn't we use readback, sync here? The following is quoted form
t4240RM:
To guarantee that the results of any sequence of writes to configuration
registers are in effect, the final configuration register write should be
On Fri, Mar 14, 2014 at 05:26:27PM -0500, Scott Wood wrote:
On Thu, 2014-03-13 at 15:46 +0800, Kevin Hao wrote:
On Wed, Mar 12, 2014 at 12:43:05PM -0500, Scott Wood wrote:
Shouldn't we use readback, sync here? The following is quoted form
t4240RM:
To guarantee that the results
On Tue, Mar 11, 2014 at 08:10:24PM -0500, Scott Wood wrote:
+ FSL_DIS_ALL_IRQ
+
+ /*
+* Place DDR controller in self refresh mode.
+* From here on, DDR can't be access any more.
+*/
+ lwz r10, 0(r13)
+ orisr10, r10, CCSR_DDR_SDRAM_CFG_2_FRC_SR@h
+
-by: Kevin Hao haoke...@gmail.com
[grant.likely: Changed multiplier to 4 which makes more sense]
Signed-off-by: Grant Likely grant.lik...@linaro.org
---
v2: Fix the bug such as we get the same score for the following two match
entries:
name2 { }
struct of_device_id matches
On Tue, Feb 18, 2014 at 10:31:20PM +, Grant Likely wrote:
Adds a selftest function for the of_match_node function. of_match_node
is supposed to handle precedence for the compatible property as well as
the name and device_type values. This patch adds some test case data and
a function that
On Wed, Feb 19, 2014 at 02:21:02PM +0800, Kevin Hao wrote:
+ /*
+ * Matching compatible is better than matching type and name,
+ * and the specific compatible is better than the general.
+ */
+ if (matches-compatible[0
-by: Kevin Hao haoke...@gmail.com
[grant.likely: Changed multiplier to 4 which makes more sense]
Signed-off-by: Grant Likely grant.lik...@linaro.org
---
v3: Also need to bail out when there does have a compatible member in match
entry, but it doesn't match with the device node's compatible.
v2: Fix
On Thu, Feb 20, 2014 at 02:09:08PM +0530, Sachin Kamat wrote:
Hi Grant,
I observe the following boot failure with today's (next-20140220) linux-next
tree on Exynos based boards with the default exynos_defconfig.
Does this help?
diff --git a/drivers/of/base.c b/drivers/of/base.c
index
On Thu, Feb 20, 2014 at 03:57:07PM +0530, Sachin Kamat wrote:
Hi Kevin,
On 20 February 2014 15:42, Kevin Hao haoke...@gmail.com wrote:
On Thu, Feb 20, 2014 at 02:09:08PM +0530, Sachin Kamat wrote:
Hi Grant,
I observe the following boot failure with today's (next-20140220)
linux-next
On Tue, Mar 18, 2014 at 06:18:54PM -0500, Scott Wood wrote:
The sequence write, readback, sync will guarantee this according to the
manual.
If you're referring to the section you quoted above, the manual does not
say that. It only talks about when accesses to memory regions affected
This line was introduced by commit fcb11918 (resources: add arch hook
for preventing allocation in reserved areas). But the struct tmp was
already assigned to *new in the above line, so this seems superfluous.
Just remove it.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
kernel/resource.c | 1
On Fri, Aug 30, 2013 at 06:37:33PM +0200, Radim Krčmář wrote:
2013-08-25 15:15+0800, Kevin Hao:
We plan to use the jump label in the cpu/mmu feature check on ppc.
This will need to include the jump_label.h in several very basic header
files of ppc which seems to be included by most
On Thu, Jan 16, 2014 at 10:05:32AM -0800, Guenter Roeck wrote:
Hi all,
I am getting kernel stack overflows with v3.13-rc8 on a system with P2020 CPU.
The kernel is patched for the target, but I don't think that is related.
Stack overflows are in different areas, but always in calls from
On Fri, Jan 17, 2014 at 01:58:10PM +1100, Benjamin Herrenschmidt wrote:
On Fri, 2014-01-17 at 10:20 +0800, Kevin Hao wrote:
On Thu, Jan 16, 2014 at 10:05:32AM -0800, Guenter Roeck wrote:
Hi all,
I am getting kernel stack overflows with v3.13-rc8 on a system with P2020
CPU
Author: Kevin Hao haoke...@gmail.com
Date: Fri Jan 17 12:25:28 2014 +0800
powerpc: Set the correct ksp_limit on ppc32 when switching to irq stack
Guenter Roeck has got the following call trace on a p2020 board:
Kernel stack overflow in process eb3e5a00, r1=eb79df90
CPU: 0 PID
On Fri, Mar 28, 2014 at 09:00:13AM +, dongsheng.w...@freescale.com wrote:
Thanks Kevin. Your patch works normal. :)
I still have some confused. I think when __do_softirq always get a interrupt,
the hard stack will be run out, isn't it?
No, it won't. Please see the explanation in the
On Sat, Mar 29, 2014 at 08:27:07AM +1100, Benjamin Herrenschmidt wrote:
On Fri, 2014-03-28 at 16:18 +0800, Kevin Hao wrote:
powerpc: Set the correct ksp_limit on ppc32 when switching to irq stack
Kevin. It looks like it was applied to 3.14 and sent to 3.12 stable but
not 3.13
to reminder Michael of this when the pulling request is sent to Linus.
Thanks,
Kevin
Fixes: 52d996270032 (powerpc: kill PPC_OF)
Cc: Kevin Hao haoke...@gmail.com
Cc: Michael Ellerman m...@ellerman.id.au
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
drivers/tty/serial/Kconfig | 4 ++--
1 file
On Fri, Apr 17, 2015 at 07:58:10AM +0100, Grant Likely wrote:
On Fri, Apr 17, 2015 at 7:01 AM, Kevin Hao haoke...@gmail.com wrote:
On Thu, Apr 16, 2015 at 10:20:59PM -0700, Guenter Roeck wrote:
powerpc qemu runs fail with the current upstream kernel.
Bisect points to commit 52d996270032
On Fri, Aug 21, 2015 at 08:28:26AM +0200, Ingo Molnar wrote:
* Kevin Hao haoke...@gmail.com wrote:
These are used to define a static_key_{true,false} array.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
include/linux/jump_label.h | 6 ++
1 file changed, 6 insertions
On Fri, Aug 21, 2015 at 08:40:59AM +0200, Ingo Molnar wrote:
Please also Cc: peterz and me to the next submission of the series - static
key
(and jump label) changes go through the locking tree normally, and there's a
number of changes pending already for v4.3:
Sure.
Thanks,
Kevin
is enabled
b xxx if MMU_FTR_XXX is not enabled
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/include/asm/mmu.h | 29 +
arch/powerpc/kernel/cputable.c | 15 +++
arch/powerpc/kernel/setup_32.c | 1 +
arch/powerpc/kernel/setup_64.c | 1 +
4
is enabled
b xxx if CPU_FTR_XXX is not enabled
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/include/asm/cpufeatures.h | 20
arch/powerpc/include/asm/cputable.h| 8
arch/powerpc/kernel/cputable.c | 18 ++
arch/powerpc
of jump label for cpu_has_feature().
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/include/asm/reg.h | 9 -
arch/powerpc/include/asm/time.h | 2 +-
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
These are used to define a static_key_{true,false} array.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
include/linux/jump_label.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 7f653e8f6690..5c1d6a49dd6b 100644
will introduces various recursive inclusion.
And it is very hard to fix that. So we choose to move the function
cpu_has_feature to a separate header file before using the jump label
for it. No functional change.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/include/asm/cacheflush.h
So we can use static_key for cpu_has_feature() and mmu_has_feature().
Signed-off-by: Kevin Hao haoke...@gmail.com
---
arch/powerpc/kernel/setup_32.c | 2 ++
arch/powerpc/kernel/setup_64.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel
The jump_label_init() run in a very early stage, even before the
sched_init(). So there is no chance for concurrent access of the
jump label table.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
kernel/jump_label.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/jump_label.c b
For some archs (such as powerpc) would want to invoke jump_label_init()
in a much earlier stage. So check static_key_initialized in order to
make sure this function run only once.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
kernel/jump_label.c | 3 +++
1 file changed, 3 insertions(+)
diff
(qemu). This patch series
is against linux-next.
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-September/111026.html
Kevin Hao (8):
jump_label: no need to acquire the jump_label_mutex in
jump_lable_init()
jump_label: make it possible for the archs to invoke jump_label_init
On Thu, Aug 20, 2015 at 08:29:03PM +0200, Peter Zijlstra wrote:
On Thu, Aug 20, 2015 at 08:14:29PM +0800, Kevin Hao wrote:
The jump_label_init() run in a very early stage, even before the
sched_init(). So there is no chance for concurrent access of the
jump label table.
It also doesn't
On Thu, Aug 20, 2015 at 08:31:58PM +0200, Peter Zijlstra wrote:
On Thu, Aug 20, 2015 at 08:14:31PM +0800, Kevin Hao wrote:
These are used to define a static_key_{true,false} array.
Yes but why...
there might have been some clue in the patches you didn't send me, but
since you didn't send
will introduces various recursive inclusion.
And it is very hard to fix that. So we choose to move the function
cpu_has_feature to a separate header file before using the jump label
for it. No functional change.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: No change.
arch/powerpc/include
of jump label for cpu_has_feature().
Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: No change.
arch/powerpc/include/asm/reg.h | 9 -
arch/powerpc/include/asm/time.h | 2 +-
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc
/pipermail/linuxppc-dev/2013-September/111026.html
Kevin Hao (6):
jump_label: make it possible for the archs to invoke jump_label_init()
much earlier
powerpc: invoke jump_label_init() in a much earlier stage
powerpc: kill mfvtb()
powerpc: move the cpu_has_feature to a separate file
powerpc
is enabled
b xxx if CPU_FTR_XXX is not enabled
Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: Use the open-coded definition and initialization for cpu_feat_keys[].
arch/powerpc/include/asm/cpufeatures.h | 20
arch/powerpc/include/asm/cputable.h| 8
So we can use static_key for cpu_has_feature() and mmu_has_feature().
Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: No change.
arch/powerpc/kernel/setup_32.c | 2 ++
arch/powerpc/kernel/setup_64.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch
is enabled
b xxx if MMU_FTR_XXX is not enabled
Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: Use the open-coded definition and initialization for mmu_feat_keys[].
arch/powerpc/include/asm/mmu.h | 29 +
arch/powerpc/kernel/cputable.c | 17
For some archs (such as powerpc) would want to invoke jump_label_init()
in a much earlier stage. So check static_key_initialized in order to
make sure this function run only once.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
v2: No change.
kernel/jump_label.c | 3 +++
1 file changed, 3
On Mon, Sep 07, 2015 at 07:29:42PM +1000, Michael Ellerman wrote:
> On Mon, 2015-24-08 at 11:20:25 UTC, Kevin Hao wrote:
> > This function is only used by get_vtb(). They are almost the same
> > except the reading from the real register. Move the mfspr() to
> > get_vtb()
On Mon, Jan 23, 2017 at 01:16:40PM -0800, Yu-cheng Yu wrote:
> On Mon, Jan 23, 2017 at 01:10:20PM -0800, Dave Hansen wrote:
> > The code is:
> >
> > > void fpstate_init(union fpregs_state *state)
> > > {
> > > if (!static_cpu_has(X86_FEATURE_FPU)) {
> > >
On Mon, Jan 23, 2017 at 06:01:10PM -0800, Dave Hansen wrote:
> On 01/23/2017 05:50 PM, Kevin Hao wrote:
> > According to the ISA manual, XSAVES also set the XCOMP_BV[62:0]. My code
> > only
> > try to be compatible with what the cpu does when excuting XSAVES. The
> > f
On Mon, Jan 23, 2017 at 04:53:25PM -0800, Dave Hansen wrote:
> >> The fix I am proposing is...
> >>
> >>state->xsave.header.xcomp_bv = XCOMP_BV_COMPACTED_FORMAT |
> >> xfeatures_mask;
> >
> > Actually I thought about this change before I made this patch, but
On Mon, Jan 23, 2017 at 06:38:42PM -0800, Dave Hansen wrote:
> On 01/23/2017 06:09 PM, Kevin Hao wrote:
> > On Mon, Jan 23, 2017 at 06:01:10PM -0800, Dave Hansen wrote:
> >> On 01/23/2017 05:50 PM, Kevin Hao wrote:
> >>> According to the ISA manual, XSAVES also s
GS: 0033 SS: 007b
The reason is that a #GP occurs when executing XRSTORS. The root cause
is that we forget to set the xcomp_bv when we fake up the XSAVES area
in function copyin_to_xsaves().
Signed-off-by: Kevin Hao <haoke...@gmail.com>
---
arch/x86/kernel/fpu/xstate.c | 2 ++
1 file chan
> I am curious how Linux convert an fd to the pathname? Does it
> recursively walk back from current dentry to the root?
Using d_path.
> Can someone point me to the right place in the kernel where this
> functionality is implemented?
do_proc_readlink may be the function you want.
-
To unsubscribe
hi,
When we press ctrl-alt-del,kernel_restart_prepare will revoke
cfi_intelext_reboot which
will set flash to read array mode,but later when device_shutdown is
invoked which may
put current work queue to sleep and other process may be sheduled to
running and programming flash in not FL_READY
On Fri, Aug 30, 2013 at 06:37:33PM +0200, Radim Krčmář wrote:
> 2013-08-25 15:15+0800, Kevin Hao:
> > We plan to use the jump label in the cpu/mmu feature check on ppc.
> > This will need to include the jump_label.h in several very basic header
> > files of ppc which seems t
This line was introduced by commit fcb11918 (resources: add arch hook
for preventing allocation in reserved areas). But the struct tmp was
already assigned to *new in the above line, so this seems superfluous.
Just remove it.
Signed-off-by: Kevin Hao
---
kernel/resource.c | 1 -
1 file changed
11. name
This is based on some pseudo-codes provided by Grant Likely.
Signed-off-by: Kevin Hao
[grant.likely: Changed multiplier to 4 which makes more sense]
Signed-off-by: Grant Likely
---
v2: Fix the bug such as we get the same score for the following two match
entries:
name2 { }
On Tue, Feb 18, 2014 at 10:31:20PM +, Grant Likely wrote:
> Adds a selftest function for the of_match_node function. of_match_node
> is supposed to handle precedence for the compatible property as well as
> the name and device_type values. This patch adds some test case data and
> a function
On Wed, Feb 19, 2014 at 02:21:02PM +0800, Kevin Hao wrote:
> + /*
> + * Matching compatible is better than matching type and name,
> + * and the specific compatible is better than the general.
> + */
> + if (matche
11. name
This is based on some pseudo-codes provided by Grant Likely.
Signed-off-by: Kevin Hao
[grant.likely: Changed multiplier to 4 which makes more sense]
Signed-off-by: Grant Likely
---
v3: Also need to bail out when there does have a compatible member in match
entry, but it doesn't m
On Fri, Mar 14, 2014 at 05:26:27PM -0500, Scott Wood wrote:
> On Thu, 2014-03-13 at 15:46 +0800, Kevin Hao wrote:
> > On Wed, Mar 12, 2014 at 12:43:05PM -0500, Scott Wood wrote:
> > > > Shouldn't we use "readback, sync" here? The following is quoted form
> >
On Tue, Mar 18, 2014 at 06:18:54PM -0500, Scott Wood wrote:
> > The sequence "write, readback, sync" will guarantee this according to the
> > manual.
>
> If you're referring to the section you quoted above, the manual does not
> say that. It only talks about when accesses "to memory regions
On Thu, Feb 20, 2014 at 02:09:08PM +0530, Sachin Kamat wrote:
> Hi Grant,
>
> I observe the following boot failure with today's (next-20140220) linux-next
> tree on Exynos based boards with the default exynos_defconfig.
Does this help?
diff --git a/drivers/of/base.c b/drivers/of/base.c
index
On Thu, Feb 20, 2014 at 03:57:07PM +0530, Sachin Kamat wrote:
> Hi Kevin,
>
> On 20 February 2014 15:42, Kevin Hao wrote:
> > On Thu, Feb 20, 2014 at 02:09:08PM +0530, Sachin Kamat wrote:
> >> Hi Grant,
> >>
> >> I observe the following boot failure wit
On Thu, Jan 16, 2014 at 10:05:32AM -0800, Guenter Roeck wrote:
> Hi all,
>
> I am getting kernel stack overflows with v3.13-rc8 on a system with P2020 CPU.
> The kernel is patched for the target, but I don't think that is related.
> Stack overflows are in different areas, but always in calls from
On Fri, Jan 17, 2014 at 01:58:10PM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2014-01-17 at 10:20 +0800, Kevin Hao wrote:
> > On Thu, Jan 16, 2014 at 10:05:32AM -0800, Guenter Roeck wrote:
> > > Hi all,
> > >
> > > I am getting kernel stack overflows w
AP: 0901 Not tainted (3.13.0-rc3-03475-g2e3f85b)
Could you double check if you got the following patch applied?
commit 1a18a66446f3f289b05b634f18012424d82aa63a
Author: Kevin Hao
Date: Fri Jan 17 12:25:28 2014 +0800
powerpc: Set the correct ksp_limit on ppc32 when switching to irq stack
Guenter Roeck has g
On Fri, Mar 28, 2014 at 09:00:13AM +, dongsheng.w...@freescale.com wrote:
> Thanks Kevin. Your patch works normal. :)
>
> I still have some confused. I think when __do_softirq always get a interrupt,
> the hard stack will be run out, isn't it?
No, it won't. Please see the explanation in the
On Sat, Mar 29, 2014 at 08:27:07AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2014-03-28 at 16:18 +0800, Kevin Hao wrote:
>
> > powerpc: Set the correct ksp_limit on ppc32 when switching to irq stack
> >
>
> Kevin. It looks like it was applied to 3.14
__slab_alloc()
free_delayed()
__free_slab()
reference to released kmem_cache
Fixes: f0b231101c94 ("mm/SLUB: delay giving back empty slubs to IRQ enabled
regions&q
We have set 'current_mask' to '_cpumask' in its declaration,
so there is no need to assign again.
Signed-off-by: Kevin Hao
---
kernel/trace/trace_hwlat.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/kernel/trace/trace_hwlat.c b/kernel/trace/trace_hwlat.c
index e2be7bb7ef7e..ddb528a6cd51
Signed-off-by: Kevin Hao
---
kernel/trace/trace_hwlat.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_hwlat.c b/kernel/trace/trace_hwlat.c
index ddb528a6cd51..17873e5d0353 100644
--- a/kernel/trace/trace_hwlat.c
+++ b/kernel/trace/trace_hwlat.c
@@ -28
propagate to upstream yet. I failed
to reminder Michael of this when the pulling request is sent to Linus.
Thanks,
Kevin
>
> Fixes: 52d996270032 ("powerpc: kill PPC_OF")
> Cc: Kevin Hao
> Cc: Michael Ellerman
> Signed-off-by: Guenter Roeck
> ---
> drivers/tty/seria
On Fri, Apr 17, 2015 at 07:58:10AM +0100, Grant Likely wrote:
> On Fri, Apr 17, 2015 at 7:01 AM, Kevin Hao wrote:
> > On Thu, Apr 16, 2015 at 10:20:59PM -0700, Guenter Roeck wrote:
> >> powerpc qemu runs fail with the current upstream kernel.
> >> Bisect points to co
On Mon, Sep 07, 2015 at 07:29:42PM +1000, Michael Ellerman wrote:
> On Mon, 2015-24-08 at 11:20:25 UTC, Kevin Hao wrote:
> > This function is only used by get_vtb(). They are almost the same
> > except the reading from the real register. Move the mfspr() to
> > get_vtb()
will introduces various recursive inclusion.
And it is very hard to fix that. So we choose to move the function
cpu_has_feature to a separate header file before using the jump label
for it. No functional change.
Signed-off-by: Kevin Hao
---
v2: No change.
arch/powerpc/include/asm/cacheflush.h
of jump label for cpu_has_feature().
Signed-off-by: Kevin Hao
---
v2: No change.
arch/powerpc/include/asm/reg.h | 9 -
arch/powerpc/include/asm/time.h | 2 +-
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
/pipermail/linuxppc-dev/2013-September/111026.html
Kevin Hao (6):
jump_label: make it possible for the archs to invoke jump_label_init()
much earlier
powerpc: invoke jump_label_init() in a much earlier stage
powerpc: kill mfvtb()
powerpc: move the cpu_has_feature to a separate file
powerpc
is enabled
b xxx if CPU_FTR_XXX is not enabled
Signed-off-by: Kevin Hao
---
v2: Use the open-coded definition and initialization for cpu_feat_keys[].
arch/powerpc/include/asm/cpufeatures.h | 20
arch/powerpc/include/asm/cputable.h| 8
arch/powerpc/kernel
So we can use static_key for cpu_has_feature() and mmu_has_feature().
Signed-off-by: Kevin Hao
---
v2: No change.
arch/powerpc/kernel/setup_32.c | 2 ++
arch/powerpc/kernel/setup_64.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel
is enabled
b xxx if MMU_FTR_XXX is not enabled
Signed-off-by: Kevin Hao
---
v2: Use the open-coded definition and initialization for mmu_feat_keys[].
arch/powerpc/include/asm/mmu.h | 29 +
arch/powerpc/kernel/cputable.c | 17 +
arch/powerpc/kernel
For some archs (such as powerpc) would want to invoke jump_label_init()
in a much earlier stage. So check static_key_initialized in order to
make sure this function run only once.
Signed-off-by: Kevin Hao
---
v2: No change.
kernel/jump_label.c | 3 +++
1 file changed, 3 insertions(+)
diff
These are used to define a static_key_{true,false} array.
Signed-off-by: Kevin Hao
---
include/linux/jump_label.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 7f653e8f6690..5c1d6a49dd6b 100644
--- a/include/linux
is enabled
b xxx if CPU_FTR_XXX is not enabled
Signed-off-by: Kevin Hao
---
arch/powerpc/include/asm/cpufeatures.h | 20
arch/powerpc/include/asm/cputable.h| 8
arch/powerpc/kernel/cputable.c | 18 ++
arch/powerpc/kernel/setup_32.c
of jump label for cpu_has_feature().
Signed-off-by: Kevin Hao
---
arch/powerpc/include/asm/reg.h | 9 -
arch/powerpc/include/asm/time.h | 2 +-
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index
is enabled
b xxx if MMU_FTR_XXX is not enabled
Signed-off-by: Kevin Hao
---
arch/powerpc/include/asm/mmu.h | 29 +
arch/powerpc/kernel/cputable.c | 15 +++
arch/powerpc/kernel/setup_32.c | 1 +
arch/powerpc/kernel/setup_64.c | 1 +
4 files changed, 46
For some archs (such as powerpc) would want to invoke jump_label_init()
in a much earlier stage. So check static_key_initialized in order to
make sure this function run only once.
Signed-off-by: Kevin Hao
---
kernel/jump_label.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/kernel
will introduces various recursive inclusion.
And it is very hard to fix that. So we choose to move the function
cpu_has_feature to a separate header file before using the jump label
for it. No functional change.
Signed-off-by: Kevin Hao
---
arch/powerpc/include/asm/cacheflush.h | 1 +
arch
So we can use static_key for cpu_has_feature() and mmu_has_feature().
Signed-off-by: Kevin Hao
---
arch/powerpc/kernel/setup_32.c | 2 ++
arch/powerpc/kernel/setup_64.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index
The jump_label_init() run in a very early stage, even before the
sched_init(). So there is no chance for concurrent access of the
jump label table.
Signed-off-by: Kevin Hao
---
kernel/jump_label.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/jump_label.c b/kernel/jump_label.c
(qemu). This patch series
is against linux-next.
[1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-September/111026.html
Kevin Hao (8):
jump_label: no need to acquire the jump_label_mutex in
jump_lable_init()
jump_label: make it possible for the archs to invoke jump_label_init
On Thu, Aug 20, 2015 at 08:29:03PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 20, 2015 at 08:14:29PM +0800, Kevin Hao wrote:
> > The jump_label_init() run in a very early stage, even before the
> > sched_init(). So there is no chance for concurrent access of the
> > jump labe
On Thu, Aug 20, 2015 at 08:31:58PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 20, 2015 at 08:14:31PM +0800, Kevin Hao wrote:
> > These are used to define a static_key_{true,false} array.
>
> Yes but why...
>
> there might have been some clue in the patches you didn't sen
On Fri, Aug 21, 2015 at 08:28:26AM +0200, Ingo Molnar wrote:
>
> * Kevin Hao wrote:
>
> > These are used to define a static_key_{true,false} array.
> >
> > Signed-off-by: Kevin Hao
> > ---
> > include/linux/jump_label.h | 6 ++
> > 1 file
On Fri, Aug 21, 2015 at 08:40:59AM +0200, Ingo Molnar wrote:
> Please also Cc: peterz and me to the next submission of the series - static
> key
> (and jump label) changes go through the locking tree normally, and there's a
> number of changes pending already for v4.3:
Sure.
Thanks,
Kevin
GS: 0033 SS: 007b
The reason is that a #GP occurs when executing XRSTORS. The root cause
is that we forget to set the xcomp_bv when we fake up the XSAVES area
in function copyin_to_xsaves().
Signed-off-by: Kevin Hao
---
arch/x86/kernel/fpu/xstate.c | 2 ++
1 file changed, 2 insertions(+)
diff
On Mon, Jan 23, 2017 at 01:16:40PM -0800, Yu-cheng Yu wrote:
> On Mon, Jan 23, 2017 at 01:10:20PM -0800, Dave Hansen wrote:
> > The code is:
> >
> > > void fpstate_init(union fpregs_state *state)
> > > {
> > > if (!static_cpu_has(X86_FEATURE_FPU)) {
> > >
On Mon, Jan 23, 2017 at 04:53:25PM -0800, Dave Hansen wrote:
> >> The fix I am proposing is...
> >>
> >>state->xsave.header.xcomp_bv = XCOMP_BV_COMPACTED_FORMAT |
> >> xfeatures_mask;
> >
> > Actually I thought about this change before I made this patch, but
On Mon, Jan 23, 2017 at 06:01:10PM -0800, Dave Hansen wrote:
> On 01/23/2017 05:50 PM, Kevin Hao wrote:
> > According to the ISA manual, XSAVES also set the XCOMP_BV[62:0]. My code
> > only
> > try to be compatible with what the cpu does when excuting XSAVES. The
> > f
On Mon, Jan 23, 2017 at 06:38:42PM -0800, Dave Hansen wrote:
> On 01/23/2017 06:09 PM, Kevin Hao wrote:
> > On Mon, Jan 23, 2017 at 06:01:10PM -0800, Dave Hansen wrote:
> >> On 01/23/2017 05:50 PM, Kevin Hao wrote:
> >>> According to the ISA manual, XSAVES also s
the defconfig of ppc.
There does have some broken for some configs. But they are not related to this
change. This also passed allyesconfig for x86. Boot test on p2020rdb and
p5020ds boards.
Kevin Hao (5):
jump_label: factor out the base part of jump_label.h to a separate
file
jump_label
linux/workqueue.h" and this will cause recursive
inclusion. In order to fix this, we choose to factor out the base
part of jump_label.h to a separate header file and we can include
that file instead of jump_label.h to avoid the recursive inclusion.
No functional change.
Signed-off-by:
1 - 100 of 108 matches
Mail list logo
