On 4/19/21 8:19 PM, Will Deacon wrote:
> On Fri, Apr 16, 2021 at 02:34:41PM +0100, Mark Rutland wrote:
>> On Fri, Apr 16, 2021 at 01:33:22PM +0100, Catalin Marinas wrote:
>>> On Fri, Apr 16, 2021 at 03:55:31PM +0800, He Zhe wrote:
>>>> The general version of is_s
On 4/16/21 8:33 PM, Catalin Marinas wrote:
> On Fri, Apr 16, 2021 at 03:55:31PM +0800, He Zhe wrote:
>> The general version of is_syscall_success does not handle 32-bit
>> compatible case, which would cause 32-bit negative return code to be
>> recoganized as a positive num
On 4/16/21 5:43 PM, Oleg Nesterov wrote:
> On 04/16, He Zhe wrote:
>> --- a/arch/arm64/include/asm/syscall.h
>> +++ b/arch/arm64/include/asm/syscall.h
>> @@ -44,7 +44,12 @@ static inline long syscall_get_error(struct task_struct
>> *task,
>> static inline lon
:582): arch=4028 syscall=322
success=yes exit=4294967283
We just added proper sign extension in syscall_get_return_value which
should be used instead.
Signed-off-by: He Zhe
---
include/linux/audit.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/audit.h b
Add sign extension handling in syscall_get_return_value so that it can
handle 32-bit compatible case and can be used by for example audit, just
like what syscall_get_error does.
Signed-off-by: He Zhe
---
arch/arm64/include/asm/syscall.h | 7 ++-
1 file changed, 6 insertions(+), 1 deletion
ce.h would introduce build failure due to
recursive inclusion of some basic headers like mutex.h. We put the
implementation to ptrace.c
Signed-off-by: He Zhe
---
arch/arm64/include/asm/ptrace.h | 3 +++
arch/arm64/kernel/ptrace.c | 10 ++
2 files changed, 13 insertions(+)
diff --
On 4/15/21 12:55 AM, Oleg Nesterov wrote:
> On 04/14, David Laight wrote:
>> From: Oleg Nesterov
>>> Sent: 14 April 2021 16:08
>>>
>>> Add audit maintainers...
>>>
>>> On 04/14, He Zhe wrote:
>>>> When 32-bit userspace applicatio
below.
type=SYSCALL msg=audit(160715.887:582): arch=4028 syscall=322
success=yes exit=4294967283
This patch forces the u32->s32->s64 for compat tasks.
Signed-off-by: He Zhe
---
include/linux/ptrace.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include
(160715.887:582): arch=4028 syscall=322
success=yes exit=4294967283
This patch forces the u32->s32->s64 for compat tasks.
Signed-off-by: He Zhe
---
include/linux/audit.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/audit.h b/include/linux/a
Oops, add some supporters from get_maintainer.pl
Zhe
On 2/23/21 4:25 PM, He Zhe wrote:
> There may be multiple reasons for EOPNOTSUPP. Sometimes we cannot determine
> which one it is.
>
> For example, when we set up uprobe with 32-bit perf and arm64 kernel on
> some hardwar
es may not support 32-bit instruction probing.
Signed-off-by: He Zhe
---
tools/perf/util/evsel.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 1bf76864c4f2..aa56511ddf60 100644
--- a/tools/perf/util/evse
)
Use EOPNOTSUPP instead to indicate such cases.
Signed-off-by: He Zhe
---
arch/arm64/kernel/probes/uprobes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/probes/uprobes.c
b/arch/arm64/kernel/probes/uprobes.c
index a412d8edbcd2..2c247634552b 100644
--- a/arch
l: core: print gpio in pins debugfs file")
Signed-off-by: He Zhe
---
drivers/pinctrl/core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pinctrl/core.c b/drivers/pinctrl/core.c
index 3663d87f51a0..9fc4433fece4 100644
--- a/drivers/pinctrl/core.c
+++ b/drivers/pinctrl/
On 9/22/20 10:14 PM, Chuck Lever wrote:
>
>> On Sep 22, 2020, at 3:13 AM, He Zhe wrote:
>>
>>
>>
>> On 9/21/20 3:51 AM, Chuck Lever wrote:
>>> On platforms that implement flush_dcache_page(), a large NFS WRITE
>>> triggers the WARN_ONCE in
_delayed_work+0x115/0x115
> Sep 20 14:01:05 klimt.1015granger.net kernel: ret_from_fork+0x22/0x30
>
> Reported-by: He Zhe
> Fixes: ca07eda33e01 ("SUNRPC: Refactor svc_recvfrom()")
> Signed-off-by: Chuck Lever
> ---
> net/sunrpc/svcsock.c |2 +-
> 1 file cha
On 9/19/20 12:23 AM, Chuck Lever wrote:
>
>> On Sep 18, 2020, at 8:50 AM, zhe...@windriver.com wrote:
>>
>> From: He Zhe
>>
>> commit ca07eda33e01 ("SUNRPC: Refactor svc_recvfrom()") introduces
>> svc_flush_bvec to after sock_recvmsg, but
On 8/21/20 3:48 PM, Thomas Bogendoerfer wrote:
> On Thu, Aug 20, 2020 at 08:54:40PM +0800, zhe...@windriver.com wrote:
>> From: He Zhe
>>
>> We want neither
>> "
>> include/linux/compiler_attributes.h:201:41: warning: statement will never
>>
On 7/22/20 5:01 PM, Juri Lelli wrote:
> On 13/07/20 15:22, Juri Lelli wrote:
>
> [...]
>
>> Gentle ping about this issue (mainly addressing relevant maintainers and
>> potential reviewers). It's easily reproducible with PREEMPT_RT.
> Ping. Any comment at all? :-)
Hi Maintainer(s),
It's been 4
On 7/3/20 4:12 PM, Juri Lelli wrote:
> Hi,
>
> On 10/04/20 19:47, zhe...@windriver.com wrote:
>> From: He Zhe
>>
>> commit b5e683d5cab8 ("eventfd: track eventfd_signal() recursion depth")
>> introduces a percpu counter that tracks the percpu recursio
Can this be considered for this moment?
This is actually v2 of
"[PATCH 1/2] eventfd: Make wake counter work for single fd instead of all".
Thanks,
Zhe
On 4/10/20 7:47 PM, zhe...@windriver.com wrote:
> From: He Zhe
>
> commit b5e683d5cab8 ("eventfd: track eventfd_
Can this be considered for this moment?
This is actually v2 of
"[PATCH 1/2] eventfd: Make wake counter work for single fd instead of all".
Thanks,
Zhe
On 4/10/20 7:47 PM, zhe...@windriver.com wrote:
> From: He Zhe
>
> commit b5e683d5cab8 ("eventfd: track eventfd_
The following commit has been merged into the perf/core branch of tip:
Commit-ID: 44d041b7b2c11b6739501fd3763cc6fed62cf0ed
Gitweb:
https://git.kernel.org/tip/44d041b7b2c11b6739501fd3763cc6fed62cf0ed
Author:He Zhe
AuthorDate:Sun, 08 Mar 2020 18:59:17 +08:00
Committer
The following commit has been merged into the ras/core branch of tip:
Commit-ID: 3b4ff4eb904fef04c36b39052ca8eb31fa41fad0
Gitweb:
https://git.kernel.org/tip/3b4ff4eb904fef04c36b39052ca8eb31fa41fad0
Author:He Zhe
AuthorDate:Wed, 04 Mar 2020 14:39:07 +08:00
Committer
On 4/28/20 2:19 AM, Luck, Tony wrote:
> On Thu, Apr 16, 2020 at 04:40:31PM +0800, He Zhe wrote:
>> Can this be considered for the moment?
>>
>> Thanks,
>> Zhe
>>
>> On 3/4/20 2:39 PM, zhe...@windriver.com wrote:
>>> From: He Zhe
>>>
On 9/23/19 7:39 PM, Petr Mladek wrote:
> On Mon 2019-09-23 18:45:18, He Zhe wrote:
>>
>> On 9/23/19 6:05 PM, Sergey Senozhatsky wrote:
>>> On (09/18/19 21:31), zhe...@windriver.com wrote:
>>>> When users read the buffer from start, there is no need to r
On 9/23/19 6:05 PM, Sergey Senozhatsky wrote:
> On (09/18/19 21:31), zhe...@windriver.com wrote:
>> When users read the buffer from start, there is no need to return -EPIPE
>> since the possible overflows will not affect the output.
>>
> [..]
>> -if (user->seq < log_first_seq) {
>> +if (
On 8/26/19 11:11 PM, Greg KH wrote:
> On Mon, Aug 26, 2019 at 10:42:53PM +0800, He Zhe wrote:
>> Hi All,
>>
>> Since 3193c0836f20 ("bpf: Disable GCC -fgcse optimization for
>> ___bpf_prog_run()"),
>> We have got the following warn
Hi All,
Since 3193c0836f20 ("bpf: Disable GCC -fgcse optimization for
___bpf_prog_run()"),
We have got the following warning,
kernel/bpf/core.o: warning: objtool: ___bpf_prog_run.cold()+0x7: call without
frame pointer save/setup
If reverting the above commit, we will get the following warning,
On 8/14/19 1:59 AM, Jessica Yu wrote:
> +++ zhe...@windriver.com [10/08/19 15:22 +0800]:
>> From: He Zhe
>>
>> When loading modules with CONFIG_ARCH_HAS_STRICT_MODULE_RWX enabled and
>> CONFIG_STRICT_MODULE_RWX disabled, the memory allocated for modules would
>&
Commit-ID: 5f5e25f1c7933a6e1673515c0b1d5acd82fea1ed
Gitweb: https://git.kernel.org/tip/5f5e25f1c7933a6e1673515c0b1d5acd82fea1ed
Author: He Zhe
AuthorDate: Fri, 2 Aug 2019 16:29:52 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 8 Aug 2019 15:41:10 -0300
perf cpumap: Fix
Commit-ID: cf30ae726c011e0372fd4c2d588466c8b50a8907
Gitweb: https://git.kernel.org/tip/cf30ae726c011e0372fd4c2d588466c8b50a8907
Author: He Zhe
AuthorDate: Fri, 2 Aug 2019 16:29:51 +0800
Committer: Arnaldo Carvalho de Melo
CommitDate: Thu, 8 Aug 2019 15:41:10 -0300
perf ftrace: Fix
Please ignore this one. Resent.
Thanks,
Zhe
On 8/6/19 5:38 PM, zhe...@windriver.com wrote:
> From: He Zhe
>
> reply_cache_stats uses wrong parameter as seq file private structure and
> thus causes the following kernel crash when users read
> /proc/fs/nfsd/reply_ca
On 8/2/19 9:06 PM, Jiri Olsa wrote:
> On Fri, Aug 02, 2019 at 04:29:51PM +0800, zhe...@windriver.com wrote:
>> From: He Zhe
>>
>> The buffer containing string used to set cpumask is overwritten by end of
>> string later in cpu_map__snprint_mask due to not enough mem
On 6/28/19 2:49 AM, Pablo Neira Ayuso wrote:
> On Mon, Jun 24, 2019 at 11:17:38AM +0800, zhe...@windriver.com wrote:
>> From: He Zhe
>>
>> Since v5.1-rc1, some types of packets do not get unreachable reply with the
>> following iptables setting. Fox example,
>&g
Hi,
https://lore.kernel.org/lkml/20190320221534.165ab...@oasis.local.home/ didn't
get merged. And the crash it was trying to fix still happens on the latest
master branch. If rebasing the patch on the latest top, the following new crash
come up.
Sometimes,
root@intel-x86-64:~# echo 1 > /sys/k
>From the last replies in the thread, it seems some work is going on. May I ask
when we can possibly roughly have a fix or workaround?
Thanks,
Zhe
On 3/21/19 10:15 AM, Steven Rostedt wrote:
> From: Steven Rostedt (VMware)
>
> He Zhe reported a crash by enabling trace events a
Hi,
User stack tracer causes crash and hang since the following commit till
now(5.1-rc1).
c3bc8fd637a9 ("tracing: Centralize preemptirq tracepoints and unify their
usage")
echo 1 > /proc/sys/kernel/stack_tracer_enabled
echo userstacktrace > /sys/kernel/debug/tracing/trace_options
echo 1 > /sys
On 1/26/19 3:32 AM, Jens Axboe wrote:
> On 1/24/19 8:20 PM, Jens Axboe wrote:
>> On 1/24/19 8:14 PM, He Zhe wrote:
>>> On 1/25/19 10:26 AM, Jens Axboe wrote:
>>>> On 1/24/19 7:22 PM, He Zhe wrote:
>>>>> On 1/25/19 10:05 AM, Jens Axboe wrote:
>>
On 1/25/19 10:26 AM, Jens Axboe wrote:
> On 1/24/19 7:22 PM, He Zhe wrote:
>>
>> On 1/25/19 10:05 AM, Jens Axboe wrote:
>>> On 1/24/19 6:40 PM, He Zhe wrote:
>>>> On 1/24/19 11:40 PM, Jens Axboe wrote:
>>>>> On 1/24/19 1:23 AM, He Zhe
On 1/25/19 10:05 AM, Jens Axboe wrote:
> On 1/24/19 6:40 PM, He Zhe wrote:
>>
>> On 1/24/19 11:40 PM, Jens Axboe wrote:
>>> On 1/24/19 1:23 AM, He Zhe wrote:
>>>> On 1/24/19 12:05 AM, Jens Axboe wrote:
>>>>> On 1/22/19 8:39 PM, Jens Axboe wrote
On 1/24/19 12:05 AM, Jens Axboe wrote:
> On 1/22/19 8:39 PM, Jens Axboe wrote:
>> On Jan 22, 2019, at 8:13 PM, He Zhe wrote:
>>> LTP case read_all_proc(read_all -d /proc -q -r 10) often, but not every
>>> time, fails with the following call traces, since 600335205b8
LTP case read_all_proc(read_all -d /proc -q -r 10) often, but not every time,
fails with the following call traces, since 600335205b8d "ide: convert to
blk-mq"(5.0-rc1) till now(5.0-rc3).
qemu-system-x86_64 -drive file=rootfs.ext4,if=virtio,format=raw -object
rng-random,filename=/dev/urandom,
On 1/11/19 9:46 AM, He Zhe wrote:
>
> On 1/11/19 1:27 AM, Konrad Rzeszutek Wilk wrote:
>> Let's skip it. There was another patch that would allocate a default 4MB
>> size if it there was an misue of swiotlb parameters.
> But this patch mainly fixes a crash. Could
Thanks,
Zhe
>
>
>
> On Mon, Jan 7, 2019, 4:07 AM Christoph Hellwig <mailto:h...@lst.de> wrote:
>
> On Mon, Jan 07, 2019 at 04:46:51PM +0800, He Zhe wrote:
> > Kindly ping.
>
> Konrad, I'll pick this up through the DMA mapping tree unless you
> protest in the next few days.
>
Kindly ping.
Zhe
On 12/3/18 6:22 PM, zhe...@windriver.com wrote:
> From: He Zhe
>
> setup_io_tlb_npages does not check input argument before passing it
> to isdigit. The argument would be a NULL pointer if "swiotlb", without
> its value, is set in command line and
On 1/5/19 2:37 AM, Catalin Marinas wrote:
> On Fri, Jan 04, 2019 at 10:29:13PM +0800, zhe...@windriver.com wrote:
>> It's not necessary to keep consistency between readers and writers of
>> kmemleak_lock. RCU is more proper for this case. And in order to gain better
>> performance, we turn the r
On 2018/12/19 23:30, Sebastian Andrzej Siewior wrote:
> On 2018-12-18 15:07:45 [+], Catalin Marinas wrote:
> …
>> It may be worth running some performance/latency tests during kmemleak
>> scanning (echo scan > /sys/kernel/debug/kmemleak) but at a quick look,
>> I don't think we'd see any dif
On 2018/12/18 19:47, Sebastian Andrzej Siewior wrote:
> On 2018-12-18 12:37:00 [+0100], Peter Zijlstra wrote:
>> On Tue, Dec 18, 2018 at 12:31:19PM +0100, Peter Zijlstra wrote:
>>> On Tue, Dec 18, 2018 at 12:16:37PM +0100, Sebastian Andrzej Siewior wrote:
On 2018-12-18 12:02:09 [+0100], Pet
On 2018/12/6 03:14, Sebastian Andrzej Siewior wrote:
> On 2018-12-05 21:53:37 [+0800], He Zhe wrote:
>> For call trace 1:
> …
>> Since kmemleak would most likely be used to debug in environments where
>> we would not expect as great performance as without it, and kfree()
On 2018/12/1 02:19, Sebastian Andrzej Siewior wrote:
> On 2018-11-24 22:26:46 [+0800], He Zhe wrote:
>> On latest v4.19.1-rt3, both of the call traces can be reproduced with
>> kmemleak
>> enabied. And none can be reproduced with kmemleak disabled.
> okay. So it needs a
On 2018/11/23 17:53, Sebastian Andrzej Siewior wrote:
> On 2018-11-22 17:04:19 [+0800], zhe...@windriver.com wrote:
>> From: He Zhe
>>
>> kmemleak_lock, as a rwlock on RT, can possibly be held in atomic context and
>> causes the follow BUG.
>>
>> BUG: sc
On 2018年10月08日 21:59, Petr Mladek wrote:
> I tried this patch with log_buf_len=5G. The kernel did not crash
> but dmesg shown some mess. There are several 32-bit variables
> to store the size, for example:
>
> static u32 log_buf_len = __LOG_BUF_LEN;
> u32 log_buf_len_get(void)
> static u32 log_f
> OK.
>
>> It is enough to describe the problem.
> OK.
> He Zhe, will you pick it up?
Yes, I agree, I'll send v3 ASAP.
Thanks,
Zhe
>
> -ss
>
On 2018年09月25日 21:31, Sergey Senozhatsky wrote:
> On (09/25/18 14:23), Petr Mladek wrote:
>> The 32GB was mentioned as an example one year ego. This is not enough
>> for a new syscall from my point of view.
> I agree. I didn't think of syslog(); was merely thinking about logbuf
> and flushing it
On 2018年09月23日 00:19, Steven Rostedt wrote:
> On Sat, 22 Sep 2018 23:40:51 +0800
> wrote:
>
>> From: He Zhe
>>
>> log_buf_len_setup does not check input argument before passing it to
>> simple_strtoull. The argument would be a NULL pointer if "log_buf
On 2018年09月21日 15:37, Petr Mladek wrote:
> On Thu 2018-09-20 12:30:56, Steven Rostedt wrote:
>> On Fri, 21 Sep 2018 00:16:50 +0800
>> He Zhe wrote:
>>
>>> On 2018年09月19日 10:43, Steven Rostedt wrote:
>>>> On Wed, 19 Sep 2018 11:39:32 +0900
>>>
On 2018年09月19日 10:43, Steven Rostedt wrote:
> On Wed, 19 Sep 2018 11:39:32 +0900
> Sergey Senozhatsky wrote:
>
>> On (09/19/18 10:27), He Zhe wrote:
>>> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
>>>> On (09/19/18 01:17), zhe...@windriver.com wrote:
On 2018年09月19日 14:44, Sergey Senozhatsky wrote:
> On (09/19/18 10:27), He Zhe wrote:
>> On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
>>> On (09/19/18 01:17), zhe...@windriver.com wrote:
>>>> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned
On 2018年09月19日 05:19, Andrew Morton wrote:
> On Tue, 18 Sep 2018 23:33:08 +0800 wrote:
>
>> From: He Zhe
>>
>> debug_guardpage_minorder_setup and cmdline_parse_kernelcore do not check
>> input argument before using it. The argument would be a NULL pointer if
&g
On 2018年09月19日 09:50, Sergey Senozhatsky wrote:
> On (09/19/18 01:17), zhe...@windriver.com wrote:
>> @@ -1048,7 +1048,14 @@ static void __init log_buf_len_update(unsigned size)
>> /* save requested log_buf_len since it's too early to process it */
>> static int __init log_buf_len_setup(char *
May I have your input?
Thanks,
Zhe
On 2018年08月09日 16:34, zhe...@windriver.com wrote:
> From: He Zhe
>
> The check may fail not only because ${CC} does not support the asm
> feature, but also due to potential defects of ${CC} itself like what
> we experienced below or ev
Commit-ID: b1e3a25f5879017fc50ca17f03118b26a19df49a
Gitweb: https://git.kernel.org/tip/b1e3a25f5879017fc50ca17f03118b26a19df49a
Author: He Zhe
AuthorDate: Tue, 14 Aug 2018 23:33:43 +0800
Committer: Ingo Molnar
CommitDate: Mon, 10 Sep 2018 14:47:33 +0200
x86/corruption-check: Use pr_
Commit-ID: ccde460b9ae5c2bd5e4742af0a7f623c2daad566
Gitweb: https://git.kernel.org/tip/ccde460b9ae5c2bd5e4742af0a7f623c2daad566
Author: He Zhe
AuthorDate: Tue, 14 Aug 2018 23:33:42 +0800
Committer: Ingo Molnar
CommitDate: Mon, 10 Sep 2018 14:47:32 +0200
x86/corruption-check: Fix panic
Could you please provide your input? Thanks.
Zhe
On 2018年08月14日 23:33, zhe...@windriver.com wrote:
> From: He Zhe
>
> memory_corruption_check[{_period|_size}]'s handlers do not check input
> argument before passing it to kstrtoul or simple_strtoull. The argument
> would
ompat_sigaction *, struct compat_sigaction *)' and 'long int(long int, long
int, long int)' [-Werror=attribute-alias]
asmlinkage long sys##name(__MAP(x,__SC_DECL,__VA_ARGS__)) \
^~~
Signed-off-by: He Zhe
---
arch/mips/kernel/signal32.c | 4
1 file changed,
65 matches
Mail list logo
