<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/csky, branch v5.4.64</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>csky: Fixup abiv2 syscall_trace break a4 &amp; a5</title>
<updated>2020-06-17T14:40:21+00:00</updated>
<author>
<name>Guo Ren</name>
<email>guoren@linux.alibaba.com</email>
</author>
<published>2020-05-24T10:44:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=108681048cf728a8570e036c34ebd7daa43133b4'/>
<id>108681048cf728a8570e036c34ebd7daa43133b4</id>
<content type='text'>
[ Upstream commit e0bbb53843b5fdfe464b099217e3b9d97e8a75d7 ]

Current implementation could destory a4 &amp; a5 when strace, so we need to get them
from pt_regs by SAVE_ALL.

Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit e0bbb53843b5fdfe464b099217e3b9d97e8a75d7 ]

Current implementation could destory a4 &amp; a5 when strace, so we need to get them
from pt_regs by SAVE_ALL.

Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>csky: Fixup raw_copy_from_user()</title>
<updated>2020-06-03T06:21:15+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2020-04-07T01:40:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=70bf0fd60f2ff6c34bfa664a206643608c645894'/>
<id>70bf0fd60f2ff6c34bfa664a206643608c645894</id>
<content type='text'>
[ Upstream commit 51bb38cb78363fdad1f89e87357b7bc73e39ba88 ]

If raw_copy_from_user(to, from, N) returns K, callers expect
the first N - K bytes starting at to to have been replaced with
the contents of corresponding area starting at from and the last
K bytes of destination *left* *unmodified*.

What arch/sky/lib/usercopy.c is doing is broken - it can lead to e.g.
data corruption on write(2).

raw_copy_to_user() is inaccurate about return value, which is a bug,
but consequences are less drastic than for raw_copy_from_user().
And just what are those access_ok() doing in there?  I mean, look into
linux/uaccess.h; that's where we do that check (as well as zero tail
on failure in the callers that need zeroing).

AFAICS, all of that shouldn't be hard to fix; something like a patch
below might make a useful starting point.

I would suggest moving these macros into usercopy.c (they are never
used anywhere else) and possibly expanding them there; if you leave
them alive, please at least rename __copy_user_zeroing(). Again,
it must not zero anything on failed read.

Said that, I'm not sure we won't be better off simply turning
usercopy.c into usercopy.S - all that is left there is a couple of
functions, each consisting only of inline asm.

Guo Ren reply:

Yes, raw_copy_from_user is wrong, it's no need zeroing code.

unsigned long _copy_from_user(void *to, const void __user *from,
unsigned long n)
{
        unsigned long res = n;
        might_fault();
        if (likely(access_ok(from, n))) {
                kasan_check_write(to, n);
                res = raw_copy_from_user(to, from, n);
        }
        if (unlikely(res))
                memset(to + (n - res), 0, res);
        return res;
}
EXPORT_SYMBOL(_copy_from_user);

You are right and access_ok() should be removed.

but, how about:
do {
...
        "2:     stw     %3, (%1, 0)     \n"             \
+       "       subi    %0, 4          \n"               \
        "9:     stw     %4, (%1, 4)     \n"             \
+       "       subi    %0, 4          \n"               \
        "10:    stw     %5, (%1, 8)     \n"             \
+       "       subi    %0, 4          \n"               \
        "11:    stw     %6, (%1, 12)    \n"             \
+       "       subi    %0, 4          \n"               \
        "       addi    %2, 16          \n"             \
        "       addi    %1, 16          \n"             \

Don't expand __ex_table

AI Viro reply:

Hey, I've no idea about the instruction scheduling on csky -
if that doesn't slow the things down, all the better.  It's just
that copy_to_user() and friends are on fairly hot codepaths,
and in quite a few situations they will dominate the speed of
e.g. read(2).  So I tried to keep the fast path unchanged.
Up to the architecture maintainers, obviously.  Which would be
you...

As for the fixups size increase (__ex_table size is unchanged)...
You have each of those macros expanded exactly once.
So the size is not a serious argument, IMO - useless complexity
would be, if it is, in fact, useless; the size... not really,
especially since those extra subi will at least offset it.

Again, up to you - asm optimizations of (essentially)
memcpy()-style loops are tricky and can depend upon the
fairly subtle details of architecture.  So even on something
I know reasonably well I would resort to direct experiments
if I can't pass the buck to architecture maintainers.

It *is* worth optimizing - this is where read() from a file
that is already in page cache spends most of the time, etc.

Guo Ren reply:

Thx, after fixup some typo “sub %0, 4”, apply the patch.

TODO:
 - user copy/from codes are still need optimizing.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 51bb38cb78363fdad1f89e87357b7bc73e39ba88 ]

If raw_copy_from_user(to, from, N) returns K, callers expect
the first N - K bytes starting at to to have been replaced with
the contents of corresponding area starting at from and the last
K bytes of destination *left* *unmodified*.

What arch/sky/lib/usercopy.c is doing is broken - it can lead to e.g.
data corruption on write(2).

raw_copy_to_user() is inaccurate about return value, which is a bug,
but consequences are less drastic than for raw_copy_from_user().
And just what are those access_ok() doing in there?  I mean, look into
linux/uaccess.h; that's where we do that check (as well as zero tail
on failure in the callers that need zeroing).

AFAICS, all of that shouldn't be hard to fix; something like a patch
below might make a useful starting point.

I would suggest moving these macros into usercopy.c (they are never
used anywhere else) and possibly expanding them there; if you leave
them alive, please at least rename __copy_user_zeroing(). Again,
it must not zero anything on failed read.

Said that, I'm not sure we won't be better off simply turning
usercopy.c into usercopy.S - all that is left there is a couple of
functions, each consisting only of inline asm.

Guo Ren reply:

Yes, raw_copy_from_user is wrong, it's no need zeroing code.

unsigned long _copy_from_user(void *to, const void __user *from,
unsigned long n)
{
        unsigned long res = n;
        might_fault();
        if (likely(access_ok(from, n))) {
                kasan_check_write(to, n);
                res = raw_copy_from_user(to, from, n);
        }
        if (unlikely(res))
                memset(to + (n - res), 0, res);
        return res;
}
EXPORT_SYMBOL(_copy_from_user);

You are right and access_ok() should be removed.

but, how about:
do {
...
        "2:     stw     %3, (%1, 0)     \n"             \
+       "       subi    %0, 4          \n"               \
        "9:     stw     %4, (%1, 4)     \n"             \
+       "       subi    %0, 4          \n"               \
        "10:    stw     %5, (%1, 8)     \n"             \
+       "       subi    %0, 4          \n"               \
        "11:    stw     %6, (%1, 12)    \n"             \
+       "       subi    %0, 4          \n"               \
        "       addi    %2, 16          \n"             \
        "       addi    %1, 16          \n"             \

Don't expand __ex_table

AI Viro reply:

Hey, I've no idea about the instruction scheduling on csky -
if that doesn't slow the things down, all the better.  It's just
that copy_to_user() and friends are on fairly hot codepaths,
and in quite a few situations they will dominate the speed of
e.g. read(2).  So I tried to keep the fast path unchanged.
Up to the architecture maintainers, obviously.  Which would be
you...

As for the fixups size increase (__ex_table size is unchanged)...
You have each of those macros expanded exactly once.
So the size is not a serious argument, IMO - useless complexity
would be, if it is, in fact, useless; the size... not really,
especially since those extra subi will at least offset it.

Again, up to you - asm optimizations of (essentially)
memcpy()-style loops are tricky and can depend upon the
fairly subtle details of architecture.  So even on something
I know reasonably well I would resort to direct experiments
if I can't pass the buck to architecture maintainers.

It *is* worth optimizing - this is where read() from a file
that is already in page cache spends most of the time, etc.

Guo Ren reply:

Thx, after fixup some typo “sub %0, 4”, apply the patch.

TODO:
 - user copy/from codes are still need optimizing.

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>csky: Fixup remove duplicate irq_disable</title>
<updated>2020-06-03T06:21:14+00:00</updated>
<author>
<name>Liu Yibin</name>
<email>jiulong@linux.alibaba.com</email>
</author>
<published>2020-05-13T07:54:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=68d72327999af2c7d9955ded4c0e9033fd3f477f'/>
<id>68d72327999af2c7d9955ded4c0e9033fd3f477f</id>
<content type='text'>
[ Upstream commit 6633a5aa8eb6bda70eb3a9837efd28a67ccc6e0a ]

Interrupt has been disabled in __schedule() with local_irq_disable()
and enabled in finish_task_switch-&gt;finish_lock_switch() with
local_irq_enabled(), So needn't to disable irq here.

Signed-off-by: Liu Yibin &lt;jiulong@linux.alibaba.com&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 6633a5aa8eb6bda70eb3a9837efd28a67ccc6e0a ]

Interrupt has been disabled in __schedule() with local_irq_disable()
and enabled in finish_task_switch-&gt;finish_lock_switch() with
local_irq_enabled(), So needn't to disable irq here.

Signed-off-by: Liu Yibin &lt;jiulong@linux.alibaba.com&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>csky: Fixup perf callchain unwind</title>
<updated>2020-06-03T06:21:14+00:00</updated>
<author>
<name>Mao Han</name>
<email>han_mao@linux.alibaba.com</email>
</author>
<published>2020-04-20T04:55:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=99bd434f88930e8212b61827f8b591017835d94b'/>
<id>99bd434f88930e8212b61827f8b591017835d94b</id>
<content type='text'>
[ Upstream commit 229a0ddee1108a3f82a873e6cbbe35c92c540444 ]

 [ 5221.974084] Unable to handle kernel paging request at virtual address 0xfffff000, pc: 0x8002c18e
 [ 5221.985929] Oops: 00000000
 [ 5221.989488]
 [ 5221.989488] CURRENT PROCESS:
 [ 5221.989488]
 [ 5221.992877] COMM=callchain_test PID=11962
 [ 5221.995213] TEXT=00008000-000087e0 DATA=00009f1c-0000a018 BSS=0000a018-0000b000
 [ 5221.999037] USER-STACK=7fc18e20  KERNEL-STACK=be204680
 [ 5221.999037]
 [ 5222.003292] PC: 0x8002c18e (perf_callchain_kernel+0x3e/0xd4)
 [ 5222.007957] LR: 0x8002c198 (perf_callchain_kernel+0x48/0xd4)
 [ 5222.074873] Call Trace:
 [ 5222.074873] [&lt;800a248e&gt;] get_perf_callchain+0x20a/0x29c
 [ 5222.074873] [&lt;8009d964&gt;] perf_callchain+0x64/0x80
 [ 5222.074873] [&lt;8009dc1c&gt;] perf_prepare_sample+0x29c/0x4b8
 [ 5222.074873] [&lt;8009de6e&gt;] perf_event_output_forward+0x36/0x98
 [ 5222.074873] [&lt;800497e0&gt;] search_exception_tables+0x20/0x44
 [ 5222.074873] [&lt;8002cbb6&gt;] do_page_fault+0x92/0x378
 [ 5222.074873] [&lt;80098608&gt;] __perf_event_overflow+0x54/0xdc
 [ 5222.074873] [&lt;80098778&gt;] perf_swevent_hrtimer+0xe8/0x164
 [ 5222.074873] [&lt;8002ddd0&gt;] update_mmu_cache+0x0/0xd8
 [ 5222.074873] [&lt;8002c014&gt;] user_backtrace+0x58/0xc4
 [ 5222.074873] [&lt;8002c0b4&gt;] perf_callchain_user+0x34/0xd0
 [ 5222.074873] [&lt;800a2442&gt;] get_perf_callchain+0x1be/0x29c
 [ 5222.074873] [&lt;8009d964&gt;] perf_callchain+0x64/0x80
 [ 5222.074873] [&lt;8009d834&gt;] perf_output_sample+0x78c/0x858
 [ 5222.074873] [&lt;8009dc1c&gt;] perf_prepare_sample+0x29c/0x4b8
 [ 5222.074873] [&lt;8009de94&gt;] perf_event_output_forward+0x5c/0x98
 [ 5222.097846]
 [ 5222.097846] [&lt;800a0300&gt;] perf_event_exit_task+0x58/0x43c
 [ 5222.097846] [&lt;8006c874&gt;] hrtimer_interrupt+0x104/0x2ec
 [ 5222.097846] [&lt;800a0300&gt;] perf_event_exit_task+0x58/0x43c
 [ 5222.097846] [&lt;80437bb6&gt;] dw_apb_clockevent_irq+0x2a/0x4c
 [ 5222.097846] [&lt;8006c770&gt;] hrtimer_interrupt+0x0/0x2ec
 [ 5222.097846] [&lt;8005f2e4&gt;] __handle_irq_event_percpu+0xac/0x19c
 [ 5222.097846] [&lt;80437bb6&gt;] dw_apb_clockevent_irq+0x2a/0x4c
 [ 5222.097846] [&lt;8005f408&gt;] handle_irq_event_percpu+0x34/0x88
 [ 5222.097846] [&lt;8005f480&gt;] handle_irq_event+0x24/0x64
 [ 5222.097846] [&lt;8006218c&gt;] handle_level_irq+0x68/0xdc
 [ 5222.097846] [&lt;8005ec76&gt;] __handle_domain_irq+0x56/0xa8
 [ 5222.097846] [&lt;80450e90&gt;] ck_irq_handler+0xac/0xe4
 [ 5222.097846] [&lt;80029012&gt;] csky_do_IRQ+0x12/0x24
 [ 5222.097846] [&lt;8002a3a0&gt;] csky_irq+0x70/0x80
 [ 5222.097846] [&lt;800ca612&gt;] alloc_set_pte+0xd2/0x238
 [ 5222.097846] [&lt;8002ddd0&gt;] update_mmu_cache+0x0/0xd8
 [ 5222.097846] [&lt;800a0340&gt;] perf_event_exit_task+0x98/0x43c

The original fp check doesn't base on the real kernal stack region.
Invalid fp address may cause kernel panic.

Signed-off-by: Mao Han &lt;han_mao@linux.alibaba.com&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 229a0ddee1108a3f82a873e6cbbe35c92c540444 ]

 [ 5221.974084] Unable to handle kernel paging request at virtual address 0xfffff000, pc: 0x8002c18e
 [ 5221.985929] Oops: 00000000
 [ 5221.989488]
 [ 5221.989488] CURRENT PROCESS:
 [ 5221.989488]
 [ 5221.992877] COMM=callchain_test PID=11962
 [ 5221.995213] TEXT=00008000-000087e0 DATA=00009f1c-0000a018 BSS=0000a018-0000b000
 [ 5221.999037] USER-STACK=7fc18e20  KERNEL-STACK=be204680
 [ 5221.999037]
 [ 5222.003292] PC: 0x8002c18e (perf_callchain_kernel+0x3e/0xd4)
 [ 5222.007957] LR: 0x8002c198 (perf_callchain_kernel+0x48/0xd4)
 [ 5222.074873] Call Trace:
 [ 5222.074873] [&lt;800a248e&gt;] get_perf_callchain+0x20a/0x29c
 [ 5222.074873] [&lt;8009d964&gt;] perf_callchain+0x64/0x80
 [ 5222.074873] [&lt;8009dc1c&gt;] perf_prepare_sample+0x29c/0x4b8
 [ 5222.074873] [&lt;8009de6e&gt;] perf_event_output_forward+0x36/0x98
 [ 5222.074873] [&lt;800497e0&gt;] search_exception_tables+0x20/0x44
 [ 5222.074873] [&lt;8002cbb6&gt;] do_page_fault+0x92/0x378
 [ 5222.074873] [&lt;80098608&gt;] __perf_event_overflow+0x54/0xdc
 [ 5222.074873] [&lt;80098778&gt;] perf_swevent_hrtimer+0xe8/0x164
 [ 5222.074873] [&lt;8002ddd0&gt;] update_mmu_cache+0x0/0xd8
 [ 5222.074873] [&lt;8002c014&gt;] user_backtrace+0x58/0xc4
 [ 5222.074873] [&lt;8002c0b4&gt;] perf_callchain_user+0x34/0xd0
 [ 5222.074873] [&lt;800a2442&gt;] get_perf_callchain+0x1be/0x29c
 [ 5222.074873] [&lt;8009d964&gt;] perf_callchain+0x64/0x80
 [ 5222.074873] [&lt;8009d834&gt;] perf_output_sample+0x78c/0x858
 [ 5222.074873] [&lt;8009dc1c&gt;] perf_prepare_sample+0x29c/0x4b8
 [ 5222.074873] [&lt;8009de94&gt;] perf_event_output_forward+0x5c/0x98
 [ 5222.097846]
 [ 5222.097846] [&lt;800a0300&gt;] perf_event_exit_task+0x58/0x43c
 [ 5222.097846] [&lt;8006c874&gt;] hrtimer_interrupt+0x104/0x2ec
 [ 5222.097846] [&lt;800a0300&gt;] perf_event_exit_task+0x58/0x43c
 [ 5222.097846] [&lt;80437bb6&gt;] dw_apb_clockevent_irq+0x2a/0x4c
 [ 5222.097846] [&lt;8006c770&gt;] hrtimer_interrupt+0x0/0x2ec
 [ 5222.097846] [&lt;8005f2e4&gt;] __handle_irq_event_percpu+0xac/0x19c
 [ 5222.097846] [&lt;80437bb6&gt;] dw_apb_clockevent_irq+0x2a/0x4c
 [ 5222.097846] [&lt;8005f408&gt;] handle_irq_event_percpu+0x34/0x88
 [ 5222.097846] [&lt;8005f480&gt;] handle_irq_event+0x24/0x64
 [ 5222.097846] [&lt;8006218c&gt;] handle_level_irq+0x68/0xdc
 [ 5222.097846] [&lt;8005ec76&gt;] __handle_domain_irq+0x56/0xa8
 [ 5222.097846] [&lt;80450e90&gt;] ck_irq_handler+0xac/0xe4
 [ 5222.097846] [&lt;80029012&gt;] csky_do_IRQ+0x12/0x24
 [ 5222.097846] [&lt;8002a3a0&gt;] csky_irq+0x70/0x80
 [ 5222.097846] [&lt;800ca612&gt;] alloc_set_pte+0xd2/0x238
 [ 5222.097846] [&lt;8002ddd0&gt;] update_mmu_cache+0x0/0xd8
 [ 5222.097846] [&lt;800a0340&gt;] perf_event_exit_task+0x98/0x43c

The original fp check doesn't base on the real kernal stack region.
Invalid fp address may cause kernel panic.

Signed-off-by: Mao Han &lt;han_mao@linux.alibaba.com&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>csky: Fixup msa highest 3 bits mask</title>
<updated>2020-06-03T06:21:13+00:00</updated>
<author>
<name>Liu Yibin</name>
<email>jiulong@linux.alibaba.com</email>
</author>
<published>2020-04-21T07:56:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=f3f23f4c6413bf3c29b092b037b7b4fd3636a95d'/>
<id>f3f23f4c6413bf3c29b092b037b7b4fd3636a95d</id>
<content type='text'>
[ Upstream commit 165f2d2858013253042809df082b8df7e34e86d7 ]

Just as comment mentioned, the msa format:

 cr&lt;30/31, 15&gt; MSA register format:
 31 - 29 | 28 - 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
   BA     Reserved  SH  WA  B   SO SEC  C   D   V

So we should shift 29 bits not 28 bits for mask

Signed-off-by: Liu Yibin &lt;jiulong@linux.alibaba.com&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 165f2d2858013253042809df082b8df7e34e86d7 ]

Just as comment mentioned, the msa format:

 cr&lt;30/31, 15&gt; MSA register format:
 31 - 29 | 28 - 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
   BA     Reserved  SH  WA  B   SO SEC  C   D   V

So we should shift 29 bits not 28 bits for mask

Signed-off-by: Liu Yibin &lt;jiulong@linux.alibaba.com&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>csky: Fixup init_fpu compile warning with __init</title>
<updated>2020-04-23T08:36:41+00:00</updated>
<author>
<name>Guo Ren</name>
<email>guoren@linux.alibaba.com</email>
</author>
<published>2020-02-26T02:23:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=760eecac993b7734d37aa3f0766cea7220f0a048'/>
<id>760eecac993b7734d37aa3f0766cea7220f0a048</id>
<content type='text'>
[ Upstream commit 12879bda3c2a974b7e4fe199a9c21f0c5f6bca04 ]

WARNING: vmlinux.o(.text+0x2366): Section mismatch in reference from the
function csky_start_secondary() to the function .init.text:init_fpu()

The function csky_start_secondary() references
the function __init init_fpu().
This is often because csky_start_secondary lacks a __init
annotation or the annotation of init_fpu is wrong.

Reported-by: Lu Chongzhi &lt;chongzhi.lcz@alibaba-inc.com&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 12879bda3c2a974b7e4fe199a9c21f0c5f6bca04 ]

WARNING: vmlinux.o(.text+0x2366): Section mismatch in reference from the
function csky_start_secondary() to the function .init.text:init_fpu()

The function csky_start_secondary() references
the function __init init_fpu().
This is often because csky_start_secondary lacks a __init
annotation or the annotation of init_fpu is wrong.

Reported-by: Lu Chongzhi &lt;chongzhi.lcz@alibaba-inc.com&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>csky: Fixup get wrong psr value from phyical reg</title>
<updated>2020-04-23T08:36:38+00:00</updated>
<author>
<name>Guo Ren</name>
<email>guoren@linux.alibaba.com</email>
</author>
<published>2020-03-31T15:45:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=57615a8561f0b9fef57f18c2c51cb08f679307c8'/>
<id>57615a8561f0b9fef57f18c2c51cb08f679307c8</id>
<content type='text'>
[ Upstream commit 9c0e343d7654a329d1f9b53d253cbf7fb6eff85d ]

We should get psr value from regs-&gt;psr in stack, not directly get
it from phyiscal register then save the vector number in
tsk-&gt;trap_no.

Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 9c0e343d7654a329d1f9b53d253cbf7fb6eff85d ]

We should get psr value from regs-&gt;psr in stack, not directly get
it from phyiscal register then save the vector number in
tsk-&gt;trap_no.

Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>csky: Fixup cpu speculative execution to IO area</title>
<updated>2020-04-23T08:36:38+00:00</updated>
<author>
<name>Guo Ren</name>
<email>guoren@linux.alibaba.com</email>
</author>
<published>2020-03-28T11:14:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=e907a0d09b34e63163fb73b6826805e334ae3e11'/>
<id>e907a0d09b34e63163fb73b6826805e334ae3e11</id>
<content type='text'>
[ Upstream commit aefd9461d34a1b0a2acad0750c43216c1c27b9d4 ]

For the memory size ( &gt; 512MB, &lt; 1GB), the MSA setting is:

 - SSEG0: PHY_START        , PHY_START + 512MB
 - SSEG1: PHY_START + 512MB, PHY_START + 1GB

But the real memory is no more than 1GB, there is a gap between the
end size of memory and border of 1GB. CPU could speculatively
execute to that gap and if the gap of the bus couldn't respond to
the CPU request, then the crash will happen.

Now make the setting with:

 - SSEG0: PHY_START        , PHY_START + 512MB (no change)
 - SSEG1: Disabled (We use highmem to use the memory of 512MB~1GB)

We also deprecated zhole_szie[] settings, it's only used by arm
style CPUs. All memory gap should use Reserved setting of dts in
csky system.

Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit aefd9461d34a1b0a2acad0750c43216c1c27b9d4 ]

For the memory size ( &gt; 512MB, &lt; 1GB), the MSA setting is:

 - SSEG0: PHY_START        , PHY_START + 512MB
 - SSEG1: PHY_START + 512MB, PHY_START + 1GB

But the real memory is no more than 1GB, there is a gap between the
end size of memory and border of 1GB. CPU could speculatively
execute to that gap and if the gap of the bus couldn't respond to
the CPU request, then the crash will happen.

Now make the setting with:

 - SSEG0: PHY_START        , PHY_START + 512MB (no change)
 - SSEG1: Disabled (We use highmem to use the memory of 512MB~1GB)

We also deprecated zhole_szie[] settings, it's only used by arm
style CPUs. All memory gap should use Reserved setting of dts in
csky system.

Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>csky: Implement copy_thread_tls</title>
<updated>2020-03-12T12:00:32+00:00</updated>
<author>
<name>Guo Ren</name>
<email>guoren@linux.alibaba.com</email>
</author>
<published>2020-02-12T02:24:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=09a8dd779e477ca6f4ab716baf5a9b5a6f2fd1c9'/>
<id>09a8dd779e477ca6f4ab716baf5a9b5a6f2fd1c9</id>
<content type='text'>
commit 0b9f386c4be6493d282aab0af6f9b70c62142777 upstream.

This is required for clone3 which passes the TLS value through a
struct rather than a register.

Cc: Amanieu d'Antras &lt;amanieu@gmail.com&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0b9f386c4be6493d282aab0af6f9b70c62142777 upstream.

This is required for clone3 which passes the TLS value through a
struct rather than a register.

Cc: Amanieu d'Antras &lt;amanieu@gmail.com&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>arch/csky: fix some Kconfig typos</title>
<updated>2020-03-12T12:00:17+00:00</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2020-02-01T01:52:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2ab5bd41c6d7bd94bd172f368ab8602faeb08cdd'/>
<id>2ab5bd41c6d7bd94bd172f368ab8602faeb08cdd</id>
<content type='text'>
[ Upstream commit bebd26ab623616728d6e72b5c74a47bfff5287d8 ]

Fix wording in help text for the CPU_HAS_LDSTEX symbol.

Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: Guo Ren &lt;guoren@kernel.org&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit bebd26ab623616728d6e72b5c74a47bfff5287d8 ]

Fix wording in help text for the CPU_HAS_LDSTEX symbol.

Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: Guo Ren &lt;guoren@kernel.org&gt;
Signed-off-by: Guo Ren &lt;guoren@linux.alibaba.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
