Message ID | 20230414104308.6591-1-bo.wu@vivo.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp287551vqo; Fri, 14 Apr 2023 03:58:16 -0700 (PDT) X-Google-Smtp-Source: AKy350bRcFvZzKClP+dF4ILCzLF52InNjC5lhEHbAx/9tk6WJQvvUBRUka0SXKcsDd0YYyHxey3A X-Received: by 2002:a17:903:24d:b0:1a6:4a25:c7f7 with SMTP id j13-20020a170903024d00b001a64a25c7f7mr2327902plh.6.1681469896510; Fri, 14 Apr 2023 03:58:16 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1681469896; cv=pass; d=google.com; s=arc-20160816; b=NC6fTo1BkJgdtTAMV+pWnNGY366yUnY3Br9BLcVozIxS4+35cM0wOdz+6+oOud407b ZslkwWF8ztnNzrmIBn9g5wHFZ8wdI8LCaC20nJJvqW6mIq8O+ttCiBsl6J/gcPCzqVLp BFuIyTTqbhTZDKtuO/NluqR1mBltiq0ZXKem9UI8CBoqRcBrN/gYQ/0BDPV0rkWd6sEF OMmaryobQpBG6hqaWDHJqmPhyuyYb/POEZim7FOdxdtQiuLbfkci8sN7tAUgO1tmoXsy 0c7Zznf4ogqtsblTaKHkGSqnLJF4ERL2zGW+l0h8t8U/qI/hi/heaTZP3p+K22ToGqIQ Opng== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :message-id:date:subject:cc:to:from:dkim-signature; bh=xvBKSpJJ9ur63nZUWjsBRNq3EokGIyECwIcne+79Jjo=; b=GJtbl0ZGYwf+9dCPuDbs6W9rFzyMyEjcBlZPDGHJvuaPJx/yS/rDde9c131SpuIpD2 W86wvc6QcpOzm4tLr3w7xEFliOZSw2wYFMNAqMplCaH4GsdmZZOgDhxtzv0IHUZLqVhy fOFXJNUVZ5qpjJSrDSkLFuTAk4AV8mq0H5QClNsVvL76eSuAlQUdxiP52eGbgT01z/kA z/cy/TGNgf+Cc7mOH9RiMTQz3KsLf8/TsxNIpVgfzXZIjabaAkacbYCtPtxq4YYBafNo wrO0VdaO+i9xvy3IWyK36kgxU2CCiKrUdXjb+DxYf2wKPMgoj4OaaNsi3ZSScWa4X95e FELQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@vivo.com header.s=selector2 header.b=btvmRYXb; arc=pass (i=1 spf=pass spfdomain=vivo.com dkim=pass dkdomain=vivo.com dmarc=pass fromdomain=vivo.com); 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=vivo.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d13-20020a65588d000000b00518706a93f1si4393114pgu.361.2023.04.14.03.58.02; Fri, 14 Apr 2023 03:58:16 -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=@vivo.com header.s=selector2 header.b=btvmRYXb; arc=pass (i=1 spf=pass spfdomain=vivo.com dkim=pass dkdomain=vivo.com dmarc=pass fromdomain=vivo.com); 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=vivo.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229895AbjDNKn3 (ORCPT <rfc822;leviz.kernel.dev@gmail.com> + 99 others); Fri, 14 Apr 2023 06:43:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50196 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229647AbjDNKn1 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 14 Apr 2023 06:43:27 -0400 Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on2109.outbound.protection.outlook.com [40.107.255.109]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0BB3595 for <linux-kernel@vger.kernel.org>; Fri, 14 Apr 2023 03:43:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a14OofpwAawlHi96AJaTYf2QsCZV1ucLceYDFQXqUrvKUumbo64C4M56R2kVicfjx1lXfBpeS8Gn4YA1glaawbJTrd+1l0AMIIo4jaUaYlJ/3nfQNECa42bVG4mAdAfg1kvqgV747dwXMiR97uXSGdlxDf3uP3JlNuuofGM2hUPlWmRRX6wrrRzBcVE4WFNETQ0jpQFWSHhaJs5O6JhzGNKssrUBwqKMDbM4miFYjDtIk0e+D+aQtXdMou9H4Hghvuk0foDWt1Q1OLXm+Kqr9Z4j8XeUG5RKBOIQWsYcGQmGRUMeqm48nmz7rz2hkp2HGOLVSObkTiXIuXBSoG6HEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xvBKSpJJ9ur63nZUWjsBRNq3EokGIyECwIcne+79Jjo=; b=TIkx3MTfLzkTuTk6LUL9FZKeHKiDJ7FaAtTfHhN1SKZhl2FuhI2ANGJUitn5jjHPlOB+WJYxFdmH7XHUCuP9qWiy7V72H/AzXi05pMSc0TvPZHhDUcJyyJ/O5mFjmPKDBkBXRt7p864l2+PiAh2pH9zHNyky88WMwoFmYghJ4sJkHLm0CUjKN8qZVEeBy8g6SUdQQnwMRZHZcsEye6+JCghN39vqDFTYU8+ALkOc6/bfwcyWaP1mjBOLUx4bzw6rCDvaB8T1R6emveuWHgmULbCVQ+XOO+UGvcfzY0WzNdm4msxnY0uxMsJK4Ap6+KeUZyy8wYZNTDrJ3gL9yuDUnA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vivo.com; dmarc=pass action=none header.from=vivo.com; dkim=pass header.d=vivo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vivo.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xvBKSpJJ9ur63nZUWjsBRNq3EokGIyECwIcne+79Jjo=; b=btvmRYXb87J7KPoxeVgmc3wqeONZox2Ze3Y8wcV+4PNqAZz9ATfgl3297cG8VeSNY4mO+kpX72nWp3Qx6N6b6x8sjhWIS1iBEoJNKBmIj8unGqcaJ/Q6oEe/A3CPLm9NjN9bXkmm31/ja5kaCInFlOGzHeiZDQPtbX/3PY8XAxQcO+b8RrBLrmufvs0aEMuEPSVSdUkrKfQmtSTmFvjDqCxdX8jEYv26Z4hjHMiuZxTK9pBzcXHr+IYO79QBGJW5o7w/MsHOwZVppFiKXGfHUb2vRXTdUKdlI5byry0BKvEOIib9VMkSBJgZVr/o7INB9VHASGXTc4cEHHx+pD1+CA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=vivo.com; Received: from SL2PR06MB3017.apcprd06.prod.outlook.com (2603:1096:100:3a::16) by SEZPR06MB5521.apcprd06.prod.outlook.com (2603:1096:101:a5::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6298.28; Fri, 14 Apr 2023 10:43:20 +0000 Received: from SL2PR06MB3017.apcprd06.prod.outlook.com ([fe80::4d33:acf:26b3:3d4a]) by SL2PR06MB3017.apcprd06.prod.outlook.com ([fe80::4d33:acf:26b3:3d4a%7]) with mapi id 15.20.6298.030; Fri, 14 Apr 2023 10:43:20 +0000 From: Wu Bo <bo.wu@vivo.com> To: Jaegeuk Kim <jaegeuk@kernel.org>, Chao Yu <chao@kernel.org> Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, wubo.oduw@gmail.com, Wu Bo <bo.wu@vivo.com> Subject: [PATCH 1/1] f2fs: allocate trace path buffer from names_cache Date: Fri, 14 Apr 2023 18:43:08 +0800 Message-Id: <20230414104308.6591-1-bo.wu@vivo.com> X-Mailer: git-send-email 2.35.3 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: SG2PR01CA0171.apcprd01.prod.exchangelabs.com (2603:1096:4:28::27) To SL2PR06MB3017.apcprd06.prod.outlook.com (2603:1096:100:3a::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SL2PR06MB3017:EE_|SEZPR06MB5521:EE_ X-MS-Office365-Filtering-Correlation-Id: 2864380f-5eb2-4b87-6a84-08db3cd50fbb X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: K6BSkZFOOFX4Rrktwyofy4fDn/e/+tBMpq4jy9muEtZqpJrquj7KEhiul9ZUqNeeQ/D0RGytXw22NROULv7twpPAJgDxpgmlRrD7L5xzxa0HhCc3SW0TMaINOkbOfdNMyXiXDjnDRcS5w2/xHLuRXNKFtNZrrA3kCUlxVB0HOWxzzYktYoKOaucNJsMmdinajP0JQNbqpPzkt+xUDLyBk5hG3o9f4vFC7Zm7+x35Au+YMoruaMBzede1awDzG+8zYMA/aMtunegxjoEq7qhE/daLT4RdyCyH9Q4bqFDfCiU4C0nznJVQ4cXrx5cn7ZFR9UEiE9TkDr6cqwwzfq9ohc2cmcUSTL5ts98hj7FgAtVdX/1fvC+shYzbekJcYSTgGeo4H3MquFmn8tw+HLq9QqnCLy43DZytdbOFasu9pKjRUIBs9KbF4+oqpaEAsZVhj0UffYOkw9n6ZXlo82ctNstfwS0Dx4NLyA7kv/5Qvvt+UMzsAqDofjpBjSo5pk2Nkk2q8QzDHKpmYeebVHPBbl+2X9QTGGzvaQ07sfsFFbyYQwe9p4cYEl3qSOypyVAWmaCJQihDYOcn8/UY8UopHV1BzgCClo1AQnO6KCRPmsoOyE5w2vySIBfv65deSsTf X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SL2PR06MB3017.apcprd06.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230028)(4636009)(136003)(346002)(366004)(376002)(396003)(39860400002)(451199021)(36756003)(38100700002)(5660300002)(6512007)(2906002)(38350700002)(4326008)(316002)(86362001)(66946007)(8676002)(8936002)(4744005)(66556008)(41300700001)(66476007)(110136005)(83380400001)(2616005)(186003)(107886003)(26005)(6506007)(1076003)(52116002)(6486002)(6666004)(478600001);DIR:OUT;SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: fKGi03lDbvM1Y0Sz/oWwMyVGeiwityG4sMvlqx5DWMacI2FlufxMYCYO5jkCj9qsVJKNfW0O0IROF2vbKmj8YaNPHEKmx2dAiptH0G6smG3TozhJtStHrjR7/waEE9eqsXtu1CwbDWmuoOQ8UpjBixlpf2h/GyLQFdq//SVprsFC9oglikMUnUsiaLwGZiEmONrRW2CwhpdQgzUYSZlaxedIaVuUTbQ211agzzk67ID9eCYgBe7VR71UPsyaXdgPl7nenPOSYWId5ACueVhKeaxY8Ej8GNgsesrT3VMhZb/vLcf1PXob7BPC5QUAXFVG2TwxQ3ePs6swkppMHq9ppYC6I0ntgihmt/2F4Gg9xNZAo+XDqtAwz+EoE7s/A2fIqP+3qGiyS+dZh9pBQI0VEP5Umjwtpknc4nrrVHUtNZBTVxEMLKP0c64CBHkCYbno8R5SRFnzE4m5cLDFZ1I0Gv5XL2lkIlJiqe797KhdwkR+0QR6PstJ2I7Job59+92MVsdMoZGKkVzqcyU6F8Gen/N/v7iIyidgpejrSDMRIf0SCjvyDST58svqovYce748wEUz3OdoI4f/QaUV8JSKfzrgXmCfknrU0Eo+mpcK/cYZU0U+CEMjOsBQpMciCI0n3+cpZWd6cstGq40OOsl8ljSIT/XvbxMIiBUjgD4ucgReAAgRNt8k2VVoVxqcp7fLsTNO41GAt7NU0KT94SAoOU8rby/OeMIrdpvwXMo7LP7WxVegTo+j5X8ExOW6Ab0nYEkirdiXia6Z5GFR3uUNIc9BLQxBb2UUq6+6GCa947mKdz1Jsdiq+Lmd0DsMq0z6GPNgeRqK+2IX4Tbj4d7Q59QDpOhKxxAuXcQh8oE3MT2SrCX9VVoTJWmr9FClZeVwZK5Rg/oebclvrV97rrgwB4HjIDX1nF0XbhKvx7Asm2Q9tIj9ZZH6Ywwsd3TUczCaJnkKSu0/z2CUu8f9mvZ8fkUl0qNHbFc1LTdrZdivk2XKEy41y5h58foai1hGEMBmCYIBH++7OnxSCk3cmuJVEIOGARvc5d7yaNE69VIHbDHgDCCTRkggqbtRw+blstMHG5gbP4solqNhSwywqFah0LjmcfQxa+dw2WGJJ5JUOE8G2faAyPReozRToGnwj9FdXxEo3NyCSTRCFXhMCVFKLnj6P8qPxGHO8NJo0P8X+l2p68jnxyhbO5DyjhIkNXcecJDQlyhxGuXlJTCbw6mVn8f45eIMpnl/vZhSMMOaeiwxcX8rqOBSL0CGSSPZkten2QHzidJhcKb5f1cFOa4+dZ4eYrbGyk9CldD8wK/XBzHlXaj2W3oP/1dQVc7felArm5pEk6AwavTFx1lftrAmWBmGQqbMzgcbWU/WsUq5Vu5K7QAnon7q4HgtzRY/ZqJNeK6xsWtYhh/XG6JUqKxIkGFsqjZc5Xued6zDgp46NJTlnwb6Vhu/IVWliQsfG6jqCKpnPnPjRp9gl551pNyn/EMoFCQ5pstZbjbW2JLs9KjBbbMi1BCgJlCt2qIk/+zbfvilJ4gLjIshDGLqdgSwrdeiqejWK+kiVzeOSXLfGQQSShmRtxJPR7f+rcX8Ev9m X-OriginatorOrg: vivo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2864380f-5eb2-4b87-6a84-08db3cd50fbb X-MS-Exchange-CrossTenant-AuthSource: SL2PR06MB3017.apcprd06.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2023 10:43:20.2026 (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: O0pxef0ZQE8w50W+Si621QXgDxM7bOWA9FToNLpGqjRK8maX9FyoUMAY4enBsqi7Z4erKw1RH7yLlj0JFwG5aQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SEZPR06MB5521 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 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?1763148978314356509?= X-GMAIL-MSGID: =?utf-8?q?1763148978314356509?= |
Series |
[1/1] f2fs: allocate trace path buffer from names_cache
|
|
Commit Message
Wu Bo
April 14, 2023, 10:43 a.m. UTC
It would be better to use the dedicated slab to store path.
Signed-off-by: Wu Bo <bo.wu@vivo.com>
---
fs/f2fs/file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
On 2023/4/14 18:43, Wu Bo wrote: > It would be better to use the dedicated slab to store path. > > Signed-off-by: Wu Bo <bo.wu@vivo.com> > --- > fs/f2fs/file.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c > index 15dabeac4690..27137873958f 100644 > --- a/fs/f2fs/file.c > +++ b/fs/f2fs/file.c > @@ -4361,7 +4361,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) > struct inode *inode = file_inode(iocb->ki_filp); > char *buf, *path; > > - buf = f2fs_kmalloc(F2FS_I_SB(inode), PATH_MAX, GFP_KERNEL); > + buf = __getname(); How about: buf = f2fs_kmem_cache_alloc(names_cachep, GFP_KERNEL, NULL, F2FS_I_SB(inode)); > if (!buf) > return; > path = dentry_path_raw(file_dentry(iocb->ki_filp), buf, PATH_MAX); > @@ -4374,7 +4374,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) > trace_f2fs_dataread_start(inode, iocb->ki_pos, count, > current->pid, path, current->comm); > free_buf: > - kfree(buf); > + __putname(buf); kmem_cache_free(names_cachep, buf); Thanks, > } > > static ssize_t f2fs_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
On 04/18, Chao Yu wrote: > On 2023/4/14 18:43, Wu Bo wrote: > > It would be better to use the dedicated slab to store path. > > > > Signed-off-by: Wu Bo <bo.wu@vivo.com> > > --- > > fs/f2fs/file.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c > > index 15dabeac4690..27137873958f 100644 > > --- a/fs/f2fs/file.c > > +++ b/fs/f2fs/file.c > > @@ -4361,7 +4361,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) > > struct inode *inode = file_inode(iocb->ki_filp); > > char *buf, *path; > > - buf = f2fs_kmalloc(F2FS_I_SB(inode), PATH_MAX, GFP_KERNEL); > > + buf = __getname(); > > How about: > > buf = f2fs_kmem_cache_alloc(names_cachep, GFP_KERNEL, NULL, F2FS_I_SB(inode)); This looks like a hack using names_cachep? > > > if (!buf) > > return; > > path = dentry_path_raw(file_dentry(iocb->ki_filp), buf, PATH_MAX); > > @@ -4374,7 +4374,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) > > trace_f2fs_dataread_start(inode, iocb->ki_pos, count, > > current->pid, path, current->comm); > > free_buf: > > - kfree(buf); > > + __putname(buf); > > kmem_cache_free(names_cachep, buf); > > Thanks, > > > } > > static ssize_t f2fs_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
On 2023/4/18 23:51, Chao Yu wrote: > On 2023/4/14 18:43, Wu Bo wrote: >> It would be better to use the dedicated slab to store path. >> >> Signed-off-by: Wu Bo <bo.wu@vivo.com> >> --- >> fs/f2fs/file.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c >> index 15dabeac4690..27137873958f 100644 >> --- a/fs/f2fs/file.c >> +++ b/fs/f2fs/file.c >> @@ -4361,7 +4361,7 @@ static void f2fs_trace_rw_file_path(struct >> kiocb *iocb, size_t count, int rw) >> struct inode *inode = file_inode(iocb->ki_filp); >> char *buf, *path; >> - buf = f2fs_kmalloc(F2FS_I_SB(inode), PATH_MAX, GFP_KERNEL); >> + buf = __getname(); > > How about: > > buf = f2fs_kmem_cache_alloc(names_cachep, GFP_KERNEL, NULL, > F2FS_I_SB(inode)); Using f2fs_kmem_cache_alloc is able to inject malloc error. But here is a trace event, is it ok to inject error in a trace path? > >> if (!buf) >> return; >> path = dentry_path_raw(file_dentry(iocb->ki_filp), buf, PATH_MAX); >> @@ -4374,7 +4374,7 @@ static void f2fs_trace_rw_file_path(struct >> kiocb *iocb, size_t count, int rw) >> trace_f2fs_dataread_start(inode, iocb->ki_pos, count, >> current->pid, path, current->comm); >> free_buf: >> - kfree(buf); >> + __putname(buf); > > kmem_cache_free(names_cachep, buf); > > Thanks, > >> } >> static ssize_t f2fs_file_read_iter(struct kiocb *iocb, struct >> iov_iter *to) > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >
On 2023/4/19 0:07, Jaegeuk Kim wrote: > On 04/18, Chao Yu wrote: >> On 2023/4/14 18:43, Wu Bo wrote: >>> It would be better to use the dedicated slab to store path. >>> >>> Signed-off-by: Wu Bo <bo.wu@vivo.com> >>> --- >>> fs/f2fs/file.c | 4 ++-- >>> 1 file changed, 2 insertions(+), 2 deletions(-) >>> >>> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c >>> index 15dabeac4690..27137873958f 100644 >>> --- a/fs/f2fs/file.c >>> +++ b/fs/f2fs/file.c >>> @@ -4361,7 +4361,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) >>> struct inode *inode = file_inode(iocb->ki_filp); >>> char *buf, *path; >>> - buf = f2fs_kmalloc(F2FS_I_SB(inode), PATH_MAX, GFP_KERNEL); >>> + buf = __getname(); >> >> How about: >> >> buf = f2fs_kmem_cache_alloc(names_cachep, GFP_KERNEL, NULL, F2FS_I_SB(inode)); > > This looks like a hack using names_cachep? names_cachep was exported in fs.h. > Using f2fs_kmem_cache_alloc is able to inject malloc error. > But here is a trace event, is it ok to inject error in a trace path? Yes, the fail path handling is very simple, so it's fine to leave it as it is. Reviewed-by: Chao Yu <chao@kernel.org> Thanks, > >> >>> if (!buf) >>> return; >>> path = dentry_path_raw(file_dentry(iocb->ki_filp), buf, PATH_MAX); >>> @@ -4374,7 +4374,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) >>> trace_f2fs_dataread_start(inode, iocb->ki_pos, count, >>> current->pid, path, current->comm); >>> free_buf: >>> - kfree(buf); >>> + __putname(buf); >> >> kmem_cache_free(names_cachep, buf); >> >> Thanks, >> >>> } >>> static ssize_t f2fs_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
On 04/19, Chao Yu wrote: > On 2023/4/19 0:07, Jaegeuk Kim wrote: > > On 04/18, Chao Yu wrote: > > > On 2023/4/14 18:43, Wu Bo wrote: > > > > It would be better to use the dedicated slab to store path. > > > > > > > > Signed-off-by: Wu Bo <bo.wu@vivo.com> > > > > --- > > > > fs/f2fs/file.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c > > > > index 15dabeac4690..27137873958f 100644 > > > > --- a/fs/f2fs/file.c > > > > +++ b/fs/f2fs/file.c > > > > @@ -4361,7 +4361,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) > > > > struct inode *inode = file_inode(iocb->ki_filp); > > > > char *buf, *path; > > > > - buf = f2fs_kmalloc(F2FS_I_SB(inode), PATH_MAX, GFP_KERNEL); > > > > + buf = __getname(); > > > > > > How about: > > > > > > buf = f2fs_kmem_cache_alloc(names_cachep, GFP_KERNEL, NULL, F2FS_I_SB(inode)); > > > > This looks like a hack using names_cachep? > > names_cachep was exported in fs.h. I think that's for __getname() in general, which doesn't indicate you can hack. No one is using like that. $ grep names_cachep fs/* -R fs/dcache.c:struct kmem_cache *names_cachep __read_mostly; fs/dcache.c:EXPORT_SYMBOL(names_cachep); fs/dcache.c: names_cachep = kmem_cache_create_usercopy("names_cache", PATH_MAX, 0, $ grep __getname fs/* -R fs/ceph/mds_client.c: path = __getname(); fs/cifs/cifsproto.h: return __getname(); fs/dcache.c:/* SLAB cache for __getname() consumers */ fs/d_path.c: char *page = __getname(); fs/exfat/dir.c: nb->lfn = __getname(); fs/f2fs/file.c: buf = __getname(); fs/fat/dir.c: *unicode = __getname(); fs/fat/namei_vfat.c: uname = __getname(); fs/hostfs/hostfs_kern.c: char *name = __getname(); fs/namei.c: result = __getname(); fs/namei.c: result = __getname(); fs/ntfs3/dir.c: name = __getname(); fs/ntfs3/xattr.c: buf = __getname(); fs/ntfs3/inode.c: new_de = __getname(); fs/ntfs3/inode.c: de = __getname(); fs/ntfs3/inode.c: de = __getname(); fs/ntfs3/namei.c: struct cpu_str *uni = __getname(); fs/ntfs3/namei.c: de = __getname(); fs/ntfs3/namei.c: struct cpu_str *uni = __getname(); fs/ntfs3/namei.c: uni = __getname(); fs/ntfs3/namei.c: uni1 = __getname(); fs/vboxsf/utils.c: * Returns a shfl_string allocated through __getname (must be freed using fs/vboxsf/utils.c: buf = __getname(); fs/vboxsf/utils.c: shfl_path = __getname(); > > > Using f2fs_kmem_cache_alloc is able to inject malloc error. > > But here is a trace event, is it ok to inject error in a trace path? > > Yes, the fail path handling is very simple, so it's fine to leave it > as it is. > > Reviewed-by: Chao Yu <chao@kernel.org> What is this for? > > Thanks, > > > > > > > > > > if (!buf) > > > > return; > > > > path = dentry_path_raw(file_dentry(iocb->ki_filp), buf, PATH_MAX); > > > > @@ -4374,7 +4374,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) > > > > trace_f2fs_dataread_start(inode, iocb->ki_pos, count, > > > > current->pid, path, current->comm); > > > > free_buf: > > > > - kfree(buf); > > > > + __putname(buf); > > > > > > kmem_cache_free(names_cachep, buf); > > > > > > Thanks, > > > > > > > } > > > > static ssize_t f2fs_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
On 04/19, Jaegeuk Kim wrote: > On 04/19, Chao Yu wrote: > > On 2023/4/19 0:07, Jaegeuk Kim wrote: > > > On 04/18, Chao Yu wrote: > > > > On 2023/4/14 18:43, Wu Bo wrote: > > > > > It would be better to use the dedicated slab to store path. > > > > > > > > > > Signed-off-by: Wu Bo <bo.wu@vivo.com> > > > > > --- > > > > > fs/f2fs/file.c | 4 ++-- > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c > > > > > index 15dabeac4690..27137873958f 100644 > > > > > --- a/fs/f2fs/file.c > > > > > +++ b/fs/f2fs/file.c > > > > > @@ -4361,7 +4361,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) > > > > > struct inode *inode = file_inode(iocb->ki_filp); > > > > > char *buf, *path; > > > > > - buf = f2fs_kmalloc(F2FS_I_SB(inode), PATH_MAX, GFP_KERNEL); > > > > > + buf = __getname(); > > > > > > > > How about: > > > > > > > > buf = f2fs_kmem_cache_alloc(names_cachep, GFP_KERNEL, NULL, F2FS_I_SB(inode)); > > > > > > This looks like a hack using names_cachep? > > > > names_cachep was exported in fs.h. > > I think that's for __getname() in general, which doesn't indicate you can hack. > No one is using like that. > > $ grep names_cachep fs/* -R > fs/dcache.c:struct kmem_cache *names_cachep __read_mostly; > fs/dcache.c:EXPORT_SYMBOL(names_cachep); > fs/dcache.c: names_cachep = kmem_cache_create_usercopy("names_cache", PATH_MAX, 0, > > $ grep __getname fs/* -R > fs/ceph/mds_client.c: path = __getname(); > fs/cifs/cifsproto.h: return __getname(); > fs/dcache.c:/* SLAB cache for __getname() consumers */ > fs/d_path.c: char *page = __getname(); > fs/exfat/dir.c: nb->lfn = __getname(); > fs/f2fs/file.c: buf = __getname(); > fs/fat/dir.c: *unicode = __getname(); > fs/fat/namei_vfat.c: uname = __getname(); > fs/hostfs/hostfs_kern.c: char *name = __getname(); > fs/namei.c: result = __getname(); > fs/namei.c: result = __getname(); > fs/ntfs3/dir.c: name = __getname(); > fs/ntfs3/xattr.c: buf = __getname(); > fs/ntfs3/inode.c: new_de = __getname(); > fs/ntfs3/inode.c: de = __getname(); > fs/ntfs3/inode.c: de = __getname(); > fs/ntfs3/namei.c: struct cpu_str *uni = __getname(); > fs/ntfs3/namei.c: de = __getname(); > fs/ntfs3/namei.c: struct cpu_str *uni = __getname(); > fs/ntfs3/namei.c: uni = __getname(); > fs/ntfs3/namei.c: uni1 = __getname(); > fs/vboxsf/utils.c: * Returns a shfl_string allocated through __getname (must be freed using > fs/vboxsf/utils.c: buf = __getname(); > fs/vboxsf/utils.c: shfl_path = __getname(); > > > > > > Using f2fs_kmem_cache_alloc is able to inject malloc error. > > > But here is a trace event, is it ok to inject error in a trace path? > > > > Yes, the fail path handling is very simple, so it's fine to leave it > > as it is. > > > > Reviewed-by: Chao Yu <chao@kernel.org> > > What is this for? > If we want to keep the error injection, how about this? Signed-off-by: Wu Bo <bo.wu@vivo.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> --- fs/f2fs/f2fs.h | 13 +++++++++++++ fs/f2fs/file.c | 4 ++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 6cae94d51821..d87044516fe9 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -3347,6 +3347,19 @@ static inline void *f2fs_kmalloc(struct f2fs_sb_info *sbi, return kmalloc(size, flags); } +static inline void *f2fs_getname(struct f2fs_sb_info *sbi) +{ + if (time_to_inject(sbi, FAULT_KMALLOC)) + return NULL; + + return __getname(); +} + +static inline void f2fs_putname(char *buf) +{ + __putname(buf); +} + static inline void *f2fs_kzalloc(struct f2fs_sb_info *sbi, size_t size, gfp_t flags) { diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 1b4411271f54..5ac53d2627d2 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -4372,7 +4372,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) struct inode *inode = file_inode(iocb->ki_filp); char *buf, *path; - buf = f2fs_kmalloc(F2FS_I_SB(inode), PATH_MAX, GFP_KERNEL); + buf = f2fs_getname(F2FS_I_SB(inode)); if (!buf) return; path = dentry_path_raw(file_dentry(iocb->ki_filp), buf, PATH_MAX); @@ -4385,7 +4385,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) trace_f2fs_dataread_start(inode, iocb->ki_pos, count, current->pid, path, current->comm); free_buf: - kfree(buf); + f2fs_putname(buf); } static ssize_t f2fs_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
On 2023/4/20 3:45, Jaegeuk Kim wrote: > On 04/19, Jaegeuk Kim wrote: >> On 04/19, Chao Yu wrote: >>> On 2023/4/19 0:07, Jaegeuk Kim wrote: >>>> On 04/18, Chao Yu wrote: >>>>> On 2023/4/14 18:43, Wu Bo wrote: >>>>>> It would be better to use the dedicated slab to store path. >>>>>> >>>>>> Signed-off-by: Wu Bo <bo.wu@vivo.com> >>>>>> --- >>>>>> fs/f2fs/file.c | 4 ++-- >>>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>>> >>>>>> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c >>>>>> index 15dabeac4690..27137873958f 100644 >>>>>> --- a/fs/f2fs/file.c >>>>>> +++ b/fs/f2fs/file.c >>>>>> @@ -4361,7 +4361,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) >>>>>> struct inode *inode = file_inode(iocb->ki_filp); >>>>>> char *buf, *path; >>>>>> - buf = f2fs_kmalloc(F2FS_I_SB(inode), PATH_MAX, GFP_KERNEL); >>>>>> + buf = __getname(); >>>>> >>>>> How about: >>>>> >>>>> buf = f2fs_kmem_cache_alloc(names_cachep, GFP_KERNEL, NULL, F2FS_I_SB(inode)); >>>> >>>> This looks like a hack using names_cachep? >>> >>> names_cachep was exported in fs.h. >> >> I think that's for __getname() in general, which doesn't indicate you can hack. >> No one is using like that. >> >> $ grep names_cachep fs/* -R >> fs/dcache.c:struct kmem_cache *names_cachep __read_mostly; >> fs/dcache.c:EXPORT_SYMBOL(names_cachep); >> fs/dcache.c: names_cachep = kmem_cache_create_usercopy("names_cache", PATH_MAX, 0, >> >> $ grep __getname fs/* -R >> fs/ceph/mds_client.c: path = __getname(); >> fs/cifs/cifsproto.h: return __getname(); >> fs/dcache.c:/* SLAB cache for __getname() consumers */ >> fs/d_path.c: char *page = __getname(); >> fs/exfat/dir.c: nb->lfn = __getname(); >> fs/f2fs/file.c: buf = __getname(); >> fs/fat/dir.c: *unicode = __getname(); >> fs/fat/namei_vfat.c: uname = __getname(); >> fs/hostfs/hostfs_kern.c: char *name = __getname(); >> fs/namei.c: result = __getname(); >> fs/namei.c: result = __getname(); >> fs/ntfs3/dir.c: name = __getname(); >> fs/ntfs3/xattr.c: buf = __getname(); >> fs/ntfs3/inode.c: new_de = __getname(); >> fs/ntfs3/inode.c: de = __getname(); >> fs/ntfs3/inode.c: de = __getname(); >> fs/ntfs3/namei.c: struct cpu_str *uni = __getname(); >> fs/ntfs3/namei.c: de = __getname(); >> fs/ntfs3/namei.c: struct cpu_str *uni = __getname(); >> fs/ntfs3/namei.c: uni = __getname(); >> fs/ntfs3/namei.c: uni1 = __getname(); >> fs/vboxsf/utils.c: * Returns a shfl_string allocated through __getname (must be freed using >> fs/vboxsf/utils.c: buf = __getname(); >> fs/vboxsf/utils.c: shfl_path = __getname(); >> >>> >>>> Using f2fs_kmem_cache_alloc is able to inject malloc error. >>>> But here is a trace event, is it ok to inject error in a trace path? >>> >>> Yes, the fail path handling is very simple, so it's fine to leave it >>> as it is. >>> >>> Reviewed-by: Chao Yu <chao@kernel.org> >> >> What is this for? Oh, I mean I'm okay w/ original patch, because f2fs_trace_rw_file_path() doesn't have complicated error handling. >> > > If we want to keep the error injection, how about this? Both original patch or below patch w/ fault injection is fine to me. Free feel to add rvb tag of me. :) Thanks, > > Signed-off-by: Wu Bo <bo.wu@vivo.com> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> > --- > fs/f2fs/f2fs.h | 13 +++++++++++++ > fs/f2fs/file.c | 4 ++-- > 2 files changed, 15 insertions(+), 2 deletions(-) > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h > index 6cae94d51821..d87044516fe9 100644 > --- a/fs/f2fs/f2fs.h > +++ b/fs/f2fs/f2fs.h > @@ -3347,6 +3347,19 @@ static inline void *f2fs_kmalloc(struct f2fs_sb_info *sbi, > return kmalloc(size, flags); > } > > +static inline void *f2fs_getname(struct f2fs_sb_info *sbi) > +{ > + if (time_to_inject(sbi, FAULT_KMALLOC)) > + return NULL; > + > + return __getname(); > +} > + > +static inline void f2fs_putname(char *buf) > +{ > + __putname(buf); > +} > + > static inline void *f2fs_kzalloc(struct f2fs_sb_info *sbi, > size_t size, gfp_t flags) > { > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c > index 1b4411271f54..5ac53d2627d2 100644 > --- a/fs/f2fs/file.c > +++ b/fs/f2fs/file.c > @@ -4372,7 +4372,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) > struct inode *inode = file_inode(iocb->ki_filp); > char *buf, *path; > > - buf = f2fs_kmalloc(F2FS_I_SB(inode), PATH_MAX, GFP_KERNEL); > + buf = f2fs_getname(F2FS_I_SB(inode)); > if (!buf) > return; > path = dentry_path_raw(file_dentry(iocb->ki_filp), buf, PATH_MAX); > @@ -4385,7 +4385,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) > trace_f2fs_dataread_start(inode, iocb->ki_pos, count, > current->pid, path, current->comm); > free_buf: > - kfree(buf); > + f2fs_putname(buf); > } > > static ssize_t f2fs_file_read_iter(struct kiocb *iocb, struct iov_iter *to)
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index 15dabeac4690..27137873958f 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -4361,7 +4361,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) struct inode *inode = file_inode(iocb->ki_filp); char *buf, *path; - buf = f2fs_kmalloc(F2FS_I_SB(inode), PATH_MAX, GFP_KERNEL); + buf = __getname(); if (!buf) return; path = dentry_path_raw(file_dentry(iocb->ki_filp), buf, PATH_MAX); @@ -4374,7 +4374,7 @@ static void f2fs_trace_rw_file_path(struct kiocb *iocb, size_t count, int rw) trace_f2fs_dataread_start(inode, iocb->ki_pos, count, current->pid, path, current->comm); free_buf: - kfree(buf); + __putname(buf); } static ssize_t f2fs_file_read_iter(struct kiocb *iocb, struct iov_iter *to)