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;
From:   Wu Bo <bo.wu@vivo.com>
To:     chao@kernel.org
Cc:     bo.wu@vivo.com, jaegeuk@kernel.org,
        linux-f2fs-devel@lists.sourceforge.net,
        linux-kernel@vger.kernel.org, wubo.oduw@gmail.com
Subject: Re: [f2fs-dev] [PATCH 1/1] f2fs: allocate trace path buffer from names_cache
Date:   Wed, 19 Apr 2023 09:32:15 +0800
Message-Id: <20230419013215.28663-1-bo.wu@vivo.com>
In-Reply-To: <e2ec7e19-634c-a065-fe7a-b052d02d4752@kernel.org>
References: <e2ec7e19-634c-a065-fe7a-b052d02d4752@kernel.org>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?bpjtD/fReXf2Lfq+pg/hY5q5ePsI4Oh0WYD44VmlabnfzpkFrKpANuam+zyW?=
 =?us-ascii?Q?F9Ul13nt3C9GPJ7Vtt5tI/oDCqA3AkKmWaLsysgJ7H0SRsoD8EBXXQp9/dNu?=
 =?us-ascii?Q?PVtyUqhJm4uI/CNkfcaxf+JQ0ZPl2DBqfAN95miOPe8rVf+3DUmgGSe/PjC0?=
 =?us-ascii?Q?b5u88F0gocSHvCNggIJ6HNEiz5/1UE2+rISieJ1pxmH84MjzLsivNcYgpigo?=
 =?us-ascii?Q?of2ctd4bcijADzDCzVTaUiMZHAdn6LInWzMzyqw4pfkAphed4tbx8dYor4uF?=
 =?us-ascii?Q?rIGCYqcsc8eVQo8EHVLkgB4ArLoIe3Ck9nkQ4Q/H6Q7blWVqMyxKMNRii/8Z?=
 =?us-ascii?Q?jeseSnREFAiz9YtBasymeNCES8IgOo+4qdTR5j243RYDNOP6BSF2Y3mZRI6u?=
 =?us-ascii?Q?tYHJcaekxMfj7haZzTPaMTS5ITGy+BOBjbVHrrpWahyQNLtwKDAVGrZ7qLvO?=
 =?us-ascii?Q?aAFpjWdqNyjA4DNCOISqoBgpHatHn/NKI8h0/aWW3rulmj6GUHG3FPNZCEdQ?=
 =?us-ascii?Q?lCdvi4lIvgw5WssRBMtEePZVolTN6prQeokCH+RUsb4FmODcbx3Q1CsN+5i0?=
 =?us-ascii?Q?Lv0t0ft/YjzkUBnNEixaqcYBUezjM3QLB5PtT+YWwZAK9iagBTOd02jyw8Mt?=
 =?us-ascii?Q?YTfeadXVO4X1ptp/G1KYxTeDYCA+9rggDDKEDE0V7AzvJY0MgYzTnrX6WDiW?=
 =?us-ascii?Q?eJc2+AkVBmkN3Yi9MlbtVUR9S1ZNijZOJVyniLYd/PnGKJshqR/zXmQxhj6C?=
 =?us-ascii?Q?bra6DpF9B+60/2z5jwQVLrM1p5lkNbu5bq+vJlvDZQ7f6JSpUEiyjyXLTd3Z?=
 =?us-ascii?Q?2+7fsqiINIPaPOtO6Ce6/OV3ILfHOsgWvPQxPAZlty4fFf0MB52HnzrnpaCS?=
 =?us-ascii?Q?7xLXiifEHA1jOO19YVSQbzzWsJDoJkixGJMH73WfFFXvV6WpPJUkuuTGJfxR?=
 =?us-ascii?Q?u8H2JcMwAch7ZxEMuAXIyq4XS9ixuji3NT/M/r5Qm1MFkkPt126z791Rv8Xp?=
 =?us-ascii?Q?RPgBFAGF/mhf+uU9i2ot/eX1g+J6nOC6vteaHLB4h2fs+uQaznG54te3ipby?=
 =?us-ascii?Q?NHYGkCDpyBsWGRSTIJ4Bc2I1ylEnsXoeOyuEiZH2Cb00z5boJyTaitMOQKQA?=
 =?us-ascii?Q?+C1Q6rWnGi9FeVrumoAfdN6E3KRAQG3tvp2HbDNlnva6lW0NRhbSI+Dq3uhv?=
 =?us-ascii?Q?gW13rR1hsC8+Rt5Ng2i8dloMQFDbM/AcwVAKyI34XmT+67lFTuNNMFpAaPZh?=
 =?us-ascii?Q?faO7iD07xXZMNP6tfXPuYFOWCRLOAaVq5ac+oK/xEC9SlR5kS2SwL4Y5o+Mp?=
 =?us-ascii?Q?cCWcI++vwTXFUZHgVvU/KvzHGJcnHWLnVSAhqjoCoBsVU4J8XgJdCSsXIj/V?=
 =?us-ascii?Q?29GmgSHaHNSSwoYxko8U5MB2ZuKxgpgSc/gVDOiu126YXyCU4OHCLseh10KE?=
 =?us-ascii?Q?hcUIB/DvAVb0jOTFyoEM+cbB5vbGgUiqb75Ty6pRF5zHsv1mHRmuOw37CDKg?=
 =?us-ascii?Q?fvgUuYEzu5gURwx4pw45VhdG9N09cONhh/Z8np51zRSzgag4tGsscFtSRzet?=
 =?us-ascii?Q?0vdiz6PeXXL/NozS1SgqfEXfR4nFKa46MygVqNqh?=
X-OriginatorOrg: vivo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a7c88992-ab1b-452f-7bdf-08db4075ed39
X-MS-Exchange-CrossTenant-AuthSource: SL2PR06MB3017.apcprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Apr 2023 01:32:24.0656
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 923e42dc-48d5-4cbe-b582-1a797a6412ed
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: xI7iB1OwuGQ54al+DrQIvfBkLA9WWVDIw1b883T81u3SS+MkM9Nf75xTByDj41vvNA57jEgyHGRhdWYjYXjSDA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1PR0601MB3875
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE,
        URIBL_BLOCKED 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

On 2023/4/18 23:51, Chao Yu wrote:=0D
> On 2023/4/14 18:43, Wu Bo wrote:=0D
>> It would be better to use the dedicated slab to store path.=0D
>>=0D
>> Signed-off-by: Wu Bo <bo.wu@vivo.com>=0D
>> ---=0D
>>   fs/f2fs/file.c | 4 ++--=0D
>>   1 file changed, 2 insertions(+), 2 deletions(-)=0D
>>=0D
>> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c=0D
>> index 15dabeac4690..27137873958f 100644=0D
>> --- a/fs/f2fs/file.c=0D
>> +++ b/fs/f2fs/file.c=0D
>> @@ -4361,7 +4361,7 @@ static void f2fs_trace_rw_file_path(struct=0D
>> kiocb *iocb, size_t count, int rw)=0D
>>       struct inode *inode =3D file_inode(iocb->ki_filp);=0D
>>       char *buf, *path;=0D
>>   -    buf =3D f2fs_kmalloc(F2FS_I_SB(inode), PATH_MAX, GFP_KERNEL);=0D
>> +    buf =3D __getname();=0D
>=0D
> How about:=0D
>=0D
> buf =3D f2fs_kmem_cache_alloc(names_cachep, GFP_KERNEL, NULL,=0D
> F2FS_I_SB(inode));=0D
=0D
Using f2fs_kmem_cache_alloc is able to inject malloc error.=0D
But here is a trace event, is it ok to inject error in a trace path?=0D
=0D
>=0D
>>       if (!buf)=0D
>>           return;=0D
>>       path =3D dentry_path_raw(file_dentry(iocb->ki_filp), buf, PATH_MAX=
);=0D
>> @@ -4374,7 +4374,7 @@ static void f2fs_trace_rw_file_path(struct=0D
>> kiocb *iocb, size_t count, int rw)=0D
>>           trace_f2fs_dataread_start(inode, iocb->ki_pos, count,=0D
>>                   current->pid, path, current->comm);=0D
>>   free_buf:=0D
>> -    kfree(buf);=0D
>> +    __putname(buf);=0D
>=0D
> kmem_cache_free(names_cachep, buf);=0D
>=0D
> Thanks,=0D
>=0D
>>   }=0D
>>     static ssize_t f2fs_file_read_iter(struct kiocb *iocb, struct=0D
>> iov_iter *to)=0D
>=0D
>=0D
> _______________________________________________=0D
> Linux-f2fs-devel mailing list=0D
> Linux-f2fs-devel@lists.sourceforge.net=0D
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel=0D
>=0D