On Sun, Feb 07, 2021 at 10:20:15AM +0100, Pavel Machek wrote:
> Hi!
>
> > commit db2805150a0f27c00ad286a29109397a7723adad upstream.
> >
> > The octeontx2 hardware needs the buffer to be 128 byte aligned.
> > But in the current implementation of napi_alloc_frag(), it can't
> > guarantee the return
ned-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
We have set 'current_mask' to '&save_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_hw
__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
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
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 I
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)) {
> > > fpstate_init_soft(
Commit-ID: 4c833368f0bf748d4147bf301b1f95bc8eccb3c0
Gitweb: http://git.kernel.org/tip/4c833368f0bf748d4147bf301b1f95bc8eccb3c0
Author: Kevin Hao
AuthorDate: Sun, 22 Jan 2017 16:50:23 +0800
Committer: Thomas Gleixner
CommitDate: Mon, 23 Jan 2017 10:40:18 +0100
x86/fpu: Set the xcomp_bv
Commit-ID: 5fa356458b5c918bdf8307b070a3d74bc015d910
Gitweb: http://git.kernel.org/tip/5fa356458b5c918bdf8307b070a3d74bc015d910
Author: Kevin Hao
AuthorDate: Sun, 22 Jan 2017 16:50:23 +0800
Committer: Ingo Molnar
CommitDate: Mon, 23 Jan 2017 09:03:03 +0100
x86/fpu: Set the xcomp_bv
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, 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()
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
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
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
/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
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
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
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
pg
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 c
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'
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
(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
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
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
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
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
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
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
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 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
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
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 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 af
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 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 sho
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_FR
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, 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 8a2
type
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 does
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
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 th
type
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 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
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, 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
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
---
include/linux
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:
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
> 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 mod
56 matches
Mail list logo
