linux-kernel - Re: [PATCH] f2fs: fix the assign logic of iocb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7d8de936-fa3c-3bd8-2415-e97c8a868666@kernel.org>
Date:   Thu, 20 Oct 2022 18:26:07 +0800
From:   Chao Yu <chao@...nel.org>
To:     Mukesh Ojha <quic_mojha@...cinc.com>, jaegeuk@...nel.org,
        mhiramat@...nel.org
Cc:     linux-f2fs-devel@...ts.sourceforge.net,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] f2fs: fix the assign logic of iocb

On 2022/10/20 17:27, Mukesh Ojha wrote:
> Hi,
> 
> On 10/20/2022 2:31 PM, Chao Yu wrote:
>> On 2022/10/20 0:17, Mukesh Ojha wrote:
>>> commit 18ae8d12991b ("f2fs: show more DIO information in tracepoint")
>>> introduces iocb field in 'f2fs_direct_IO_enter' trace event
>>> And it only assigns the pointer and later it accesses its field
>>> in trace print log.
>>>
>>> Fix it by correcting data type and memcpy the content of iocb.
>>
>> So the implementation below is wrong, right? since it just assign __entry->name
>> with dentry->d_name.name rather than copyiny entirely, so that, during printing
> 
> I think, yes.
> 
> About the patch, we were getting error as below on doing

Thanks for the explanation. :)

What do you think of adding below info into commit message? and fixing all
similar issues of include/trace/events/f2fs.h in one patch?

Thanks,

> 
> echo 51200 > /d/tracing/buffer_size_kb
> echo 1 > /d/tracing/events/f2fs/f2fs_direct_IO_enter/enable
> echo 1 > /d/tracing/tracing_on
> cat /d/tracing/trace_pipe > ftrace.log
> 
> Run something which exercise this path.
> 
> Unable to handle kernel paging request at virtual address ffffffc04cef3d30
> Mem abort info:
> ESR = 0x96000007
> EC = 0x25: DABT (current EL), IL = 32 bits
> 
>   pc : trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4
>   lr : trace_raw_output_f2fs_direct_IO_enter+0x2c/0xa4
>   sp : ffffffc0443cbbd0
>   x29: ffffffc0443cbbf0 x28: ffffff8935b120d0 x27: ffffff8935b12108
>   x26: ffffff8935b120f0 x25: ffffff8935b12100 x24: ffffff8935b110c0
>   x23: ffffff8935b10000 x22: ffffff88859a936c x21: ffffff88859a936c
>   x20: ffffff8935b110c0 x19: ffffff8935b10000 x18: ffffffc03b195060
>   x17: ffffff8935b11e76 x16: 00000000000000cc x15: ffffffef855c4f2c
>   x14: 0000000000000001 x13: 000000000000004e x12: ffff0000ffffff00
>   x11: ffffffef86c350d0 x10: 00000000000010c0 x9 : 000000000fe0002c
>   x8 : ffffffc04cef3d28 x7 : 7f7f7f7f7f7f7f7f x6 : 0000000002000000
>   x5 : ffffff8935b11e9a x4 : 0000000000006250 x3 : ffff0a00ffffff04
>   x2 : 0000000000000002 x1 : ffffffef86a0a31f x0 : ffffff8935b10000
>   Call trace:
>    trace_raw_output_f2fs_direct_IO_enter+0x54/0xa4
>    print_trace_fmt+0x9c/0x138
>    print_trace_line+0x154/0x254
>    tracing_read_pipe+0x21c/0x380
>    vfs_read+0x108/0x3ac
>    ksys_read+0x7c/0xec
>    __arm64_sys_read+0x20/0x30
>    invoke_syscall+0x60/0x150
>    el0_svc_common.llvm.1237943816091755067+0xb8/0xf8
>    do_el0_svc+0x28/0xa0
> 
> -Mukesh