Message ID | 1666196277-27014-1-git-send-email-quic_mojha@quicinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp415079wrs; Wed, 19 Oct 2022 09:20:50 -0700 (PDT) X-Google-Smtp-Source: AMsMyM69IeLqn45RBXez0vVzBkvcdSUpCTt3UhxO8YO3q0ut/hSWGcA4rd6YAWfZu8eQCJxvwJ36 X-Received: by 2002:a65:68cb:0:b0:460:b552:fbf4 with SMTP id k11-20020a6568cb000000b00460b552fbf4mr7897471pgt.457.1666196449938; Wed, 19 Oct 2022 09:20:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666196449; cv=none; d=google.com; s=arc-20160816; b=YBZkQD7u44IbEE3jlmSCCoCNooYNQVfURPr1oItNRkJrmQ0zY1nAEjWEQtR1S3QaMm RxANbaVCbWkXvQwIxm2TCXDzMPkQLX8fZWpagQAuWgfyuGqA5bV35IZ5XA2KS7ctvM8Q 5YpPtnFvhMQ1D0QzZrv4arax5KIH+IbaT1G/E52tqQSVkVR+v+a59NKK076sr9Br26uA DjRQ5Ys3b7Wbl1eRerVUbPZMmJaQHl9/ivI9wUssUVLz/YG9yI0xtPSdpKTPIwqF5rNj XP1yIDt0iNqcMSOlMA2WKeu5BmtckJEmmYN1rHESo6F+WzsesqAoOmxIuhjKG+S53qnU kGsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from :dkim-signature; bh=zD/R05w9rQH2nIBrqXkHmKmhtd3douq60/H0+KYKCxg=; b=E9u76fVFihSvg6FPON+TTpugHtKjcNqSYPrv61iO+mxG5LmBGlaY3y/l+cVcaJLMSq DEPnYhxXu1viamUDt8C/hILdYoPRRlIMSINQTQniZYboqfgzvWX97808+WahLsJJmltr dlPMGmIBdQkmHwl2E+nqN/xk2NmQ54/+6De8YUu0yR2N5qnwT5wALUgn8w5f7YIU44dz G0OB0xeNFyA7TkAs9LcLyb83PMo6osM8BnurctkZGE2cSd/rtOkG5jc7MlvhSifsRAbe ZFCMzj9lTVMkKTL4QWArooNAoMpKuIYjFDKKApOe3QyWPt7hOZOK065sKuGIY5zyN6W6 vRFQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=dVzgO9Mb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d5-20020aa78e45000000b005635bfe397bsi16855183pfr.218.2022.10.19.09.20.34; Wed, 19 Oct 2022 09:20:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@quicinc.com header.s=qcppdkim1 header.b=dVzgO9Mb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=quicinc.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230410AbiJSQSq (ORCPT <rfc822;samuel.l.nystrom@gmail.com> + 99 others); Wed, 19 Oct 2022 12:18:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47448 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230053AbiJSQSd (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Oct 2022 12:18:33 -0400 Received: from mx0a-0031df01.pphosted.com (mx0a-0031df01.pphosted.com [205.220.168.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F085A1BF22C for <linux-kernel@vger.kernel.org>; Wed, 19 Oct 2022 09:18:30 -0700 (PDT) Received: from pps.filterd (m0279866.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29J8BHbV027441; Wed, 19 Oct 2022 16:18:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quicinc.com; h=from : to : cc : subject : date : message-id : mime-version : content-type; s=qcppdkim1; bh=zD/R05w9rQH2nIBrqXkHmKmhtd3douq60/H0+KYKCxg=; b=dVzgO9Mb7K1f7zsB6P9QNWKeBgnGIC4mW7e8y5GbOzJZhbmnZQK+FsRXe0h4fCZleOe7 4a1av88PjeZMEgtml36EmQvee2lE8j50hVPgtqBiapKg2Akbp3HUn76P1bL2aDiwJGPU 1lfiYZhUxgeHLYh5SAaQohbC455CI7mBKvZYewEnahO371Ln+ugf1/ypphBC0gSSV/Pf LQzrIINbXWglqV5uTBkNhqnzPdTQuXSMym3Af2xNqZMHYHzJJbxwMFhgS5cfwSIbFW/C 0OLnKaLWE4yeuiA77wB/TO+pPCW82OVYkEswIjIgLEjODuJAZKuGh9xkqRHKMvfeyMF0 7A== Received: from nasanppmta01.qualcomm.com (i-global254.qualcomm.com [199.106.103.254]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 3ka3j1uhqp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Oct 2022 16:18:13 +0000 Received: from nasanex01c.na.qualcomm.com (corens_vlan604_snip.qualcomm.com [10.53.140.1]) by NASANPPMTA01.qualcomm.com (8.17.1.5/8.17.1.5) with ESMTPS id 29JGID2D028693 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Oct 2022 16:18:13 GMT Received: from hu-mojha-hyd.qualcomm.com (10.80.80.8) by nasanex01c.na.qualcomm.com (10.45.79.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.29; Wed, 19 Oct 2022 09:18:11 -0700 From: Mukesh Ojha <quic_mojha@quicinc.com> To: <jaegeuk@kernel.org>, <chao@kernel.org>, <mhiramat@kernel.org> CC: <linux-f2fs-devel@lists.sourceforge.net>, <linux-kernel@vger.kernel.org>, <quic_mojha@quicinc.com> Subject: [PATCH] f2fs: fix the assign logic of iocb Date: Wed, 19 Oct 2022 21:47:57 +0530 Message-ID: <1666196277-27014-1-git-send-email-quic_mojha@quicinc.com> X-Mailer: git-send-email 2.7.4 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanex01b.na.qualcomm.com (10.46.141.250) To nasanex01c.na.qualcomm.com (10.45.79.139) X-QCInternal: smtphost X-Proofpoint-Virus-Version: vendor=nai engine=6200 definitions=5800 signatures=585085 X-Proofpoint-ORIG-GUID: mjlz_ZOW_AuU4Z9v5eIXSpeO4_68gAL8 X-Proofpoint-GUID: mjlz_ZOW_AuU4Z9v5eIXSpeO4_68gAL8 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-10-19_09,2022-10-19_04,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 adultscore=0 mlxlogscore=875 bulkscore=0 mlxscore=0 phishscore=0 impostorscore=0 spamscore=0 priorityscore=1501 malwarescore=0 lowpriorityscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2210190092 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747133608757361364?= X-GMAIL-MSGID: =?utf-8?q?1747133608757361364?= |
Series |
f2fs: fix the assign logic of iocb
|
|
Commit Message
Mukesh Ojha
Oct. 19, 2022, 4:17 p.m. UTC
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.
Fixes: 18ae8d12991b ("f2fs: show more DIO information in tracepoint")
Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
---
include/trace/events/f2fs.h | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
Comments
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 of tracepoint, __entry->name may be invalid. TRACE_EVENT(f2fs_unlink_enter, TP_PROTO(struct inode *dir, struct dentry *dentry), TP_ARGS(dir, dentry), TP_STRUCT__entry( __field(dev_t, dev) __field(ino_t, ino) __field(loff_t, size) __field(blkcnt_t, blocks) __field(const char *, name) ), TP_fast_assign( __entry->dev = dir->i_sb->s_dev; __entry->ino = dir->i_ino; __entry->size = dir->i_size; __entry->blocks = dir->i_blocks; __entry->name = dentry->d_name.name; ), > > Fixes: 18ae8d12991b ("f2fs: show more DIO information in tracepoint") > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> > --- > include/trace/events/f2fs.h | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h > index c6b3724..7727ec9 100644 > --- a/include/trace/events/f2fs.h > +++ b/include/trace/events/f2fs.h > @@ -940,7 +940,7 @@ TRACE_EVENT(f2fs_direct_IO_enter, > TP_STRUCT__entry( > __field(dev_t, dev) > __field(ino_t, ino) > - __field(struct kiocb *, iocb) > + __field_struct(struct kiocb, iocb) > __field(unsigned long, len) > __field(int, rw) > ), > @@ -948,17 +948,17 @@ TRACE_EVENT(f2fs_direct_IO_enter, > TP_fast_assign( > __entry->dev = inode->i_sb->s_dev; > __entry->ino = inode->i_ino; > - __entry->iocb = iocb; > + memcpy(&__entry->iocb, iocb, sizeof(*iocb)); > __entry->len = len; > __entry->rw = rw; > ), > > TP_printk("dev = (%d,%d), ino = %lu pos = %lld len = %lu ki_flags = %x ki_ioprio = %x rw = %d", > show_dev_ino(__entry), > - __entry->iocb->ki_pos, > + __entry->iocb.ki_pos, > __entry->len, > - __entry->iocb->ki_flags, > - __entry->iocb->ki_ioprio, > + __entry->iocb.ki_flags, > + __entry->iocb.ki_ioprio, > __entry->rw) > ); >
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 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
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
Hi Mukesh, On Wed, Oct 19, 2022 at 09:47:57PM +0530, 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. > > Fixes: 18ae8d12991b ("f2fs: show more DIO information in tracepoint") > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> > --- > include/trace/events/f2fs.h | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h > index c6b3724..7727ec9 100644 > --- a/include/trace/events/f2fs.h > +++ b/include/trace/events/f2fs.h > @@ -940,7 +940,7 @@ TRACE_EVENT(f2fs_direct_IO_enter, > TP_STRUCT__entry( > __field(dev_t, dev) > __field(ino_t, ino) > - __field(struct kiocb *, iocb) > + __field_struct(struct kiocb, iocb) > __field(unsigned long, len) > __field(int, rw) > ), > @@ -948,17 +948,17 @@ TRACE_EVENT(f2fs_direct_IO_enter, > TP_fast_assign( > __entry->dev = inode->i_sb->s_dev; > __entry->ino = inode->i_ino; > - __entry->iocb = iocb; > + memcpy(&__entry->iocb, iocb, sizeof(*iocb)); > __entry->len = len; > __entry->rw = rw; > ), > Why copy the whole structure (48 bytes)? cache the three members you need. Thanks, Pavan
On Fri, 21 Oct 2022 10:30:46 +0530 Pavan Kondeti <quic_pkondeti@quicinc.com> wrote: > Hi Mukesh, > > On Wed, Oct 19, 2022 at 09:47:57PM +0530, 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. > > > > Fixes: 18ae8d12991b ("f2fs: show more DIO information in tracepoint") > > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com> > > --- > > include/trace/events/f2fs.h | 10 +++++----- > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h > > index c6b3724..7727ec9 100644 > > --- a/include/trace/events/f2fs.h > > +++ b/include/trace/events/f2fs.h > > @@ -940,7 +940,7 @@ TRACE_EVENT(f2fs_direct_IO_enter, > > TP_STRUCT__entry( > > __field(dev_t, dev) > > __field(ino_t, ino) > > - __field(struct kiocb *, iocb) > > + __field_struct(struct kiocb, iocb) > > __field(unsigned long, len) > > __field(int, rw) > > ), > > @@ -948,17 +948,17 @@ TRACE_EVENT(f2fs_direct_IO_enter, > > TP_fast_assign( > > __entry->dev = inode->i_sb->s_dev; > > __entry->ino = inode->i_ino; > > - __entry->iocb = iocb; > > + memcpy(&__entry->iocb, iocb, sizeof(*iocb)); > > __entry->len = len; > > __entry->rw = rw; > > ), > > > > Why copy the whole structure (48 bytes)? cache the three members you > need. +1. If this only prints ki_pos, ki_flags and ki_ioprio, I recommend you to save those 3 fields to the entry. It should not expose in-kernel data structure because it can be changed. Thank you, > > Thanks, > Pavan
diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h index c6b3724..7727ec9 100644 --- a/include/trace/events/f2fs.h +++ b/include/trace/events/f2fs.h @@ -940,7 +940,7 @@ TRACE_EVENT(f2fs_direct_IO_enter, TP_STRUCT__entry( __field(dev_t, dev) __field(ino_t, ino) - __field(struct kiocb *, iocb) + __field_struct(struct kiocb, iocb) __field(unsigned long, len) __field(int, rw) ), @@ -948,17 +948,17 @@ TRACE_EVENT(f2fs_direct_IO_enter, TP_fast_assign( __entry->dev = inode->i_sb->s_dev; __entry->ino = inode->i_ino; - __entry->iocb = iocb; + memcpy(&__entry->iocb, iocb, sizeof(*iocb)); __entry->len = len; __entry->rw = rw; ), TP_printk("dev = (%d,%d), ino = %lu pos = %lld len = %lu ki_flags = %x ki_ioprio = %x rw = %d", show_dev_ino(__entry), - __entry->iocb->ki_pos, + __entry->iocb.ki_pos, __entry->len, - __entry->iocb->ki_flags, - __entry->iocb->ki_ioprio, + __entry->iocb.ki_flags, + __entry->iocb.ki_ioprio, __entry->rw) );