Received: by 2002:a05:6500:1b45:b0:1f5:f2ab:c469 with SMTP id cz5csp1019741lqb; Wed, 17 Apr 2024 19:16:35 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXAPmwCkoPPsy1MmICLmRf7YKgD1fOAIIfbLJI7ni70FgvGnawM9QjaxMuPIl7lO+YmlOlyihGMNAV1cMmX8lSVWxaFHCBjmTndCmfK8Q== X-Google-Smtp-Source: AGHT+IGkE8rNyRLOqMS8XSxYjKgqeFA7LK6f6N+f9SskGELWSMDyU5+p+KrEeslR/rD9KNcjyv2y X-Received: by 2002:a50:d4d7:0:b0:56d:ed86:c6f4 with SMTP id e23-20020a50d4d7000000b0056ded86c6f4mr830985edj.11.1713406595648; Wed, 17 Apr 2024 19:16:35 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713406595; cv=pass; d=google.com; s=arc-20160816; b=IPi7JXjV5RIPeKDn0zQyt5YYFUdoqZwPwgEmQGnVUke78+t1/g0HrEyE32MqYPsKu6 0JyZd83wrgu2WG1jKki9/iSyDCxK8wa1nGQ82MRMVXPmLY0C535IDy871UWpbdqwVJuW 8JcA+HwJ5l2NZiES86zXM5yyKY+HvTjqy010/VG8RCHBL926ghIYrvM5yS/iRExs1LJz b/z3XiiX1XtYAaImhT9X8BYw3/DeQlYHTfP4/65f1MPVnRsKF9hc5bcVlpR8wWuSaSJy VdBGfAqosnHRqfIRnVi6ToFnyaFPG2hg8D7p2tloDqxL3xsd5DdOsReLDCWU05KZdf3T Nv2A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=TM7yh3Pc+NlyrCnP/xTpDY59CYpvgC4vK6lCHL3DuuQ=; fh=h4xgT+VjSOkXTJ1n8g9Vx/kXxmSZ6NLbRFy7FQaC8WY=; b=gmQTAqcB8Sl2irLkszTofxxo+VbdPMZCgLZrCURwj9T8ABC6BVAOdY0ZM9IlqyfZGd mTLsgLPc90BW7J+jlMHpqDsPLkMDQ1Oq1GIziQ8fGDwr5ghxzwLJ/XCIqhxWniNPijvs PrqumCgWLcbsvVAhY/CDtJdfg1hj/Fd1pjjcOaPmKCcMUUDTn6FRizkGUmz85Q6nVvV8 353w3INMSkAskLZzx+xrhPt0YKqRaXeQpCUJsNgs9o6fzZwX+tDId53oSKJLu0uxBKLH ZnJNzl8B/phgNEOspgPAQhJ1Rbt4Gn6GVtD7NtDs2kIp/YAmk2xAe9GNaQbWeWR8732T TKeg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.alibaba.com header.s=default header.b=rTh0DBgu; arc=pass (i=1 spf=pass spfdomain=linux.alibaba.com dkim=pass dkdomain=linux.alibaba.com dmarc=pass fromdomain=linux.alibaba.com); spf=pass (google.com: domain of linux-kernel+bounces-149433-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-149433-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.alibaba.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id i22-20020a50d756000000b0057017437b15si271593edj.674.2024.04.17.19.16.35 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Apr 2024 19:16:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-149433-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.alibaba.com header.s=default header.b=rTh0DBgu; arc=pass (i=1 spf=pass spfdomain=linux.alibaba.com dkim=pass dkdomain=linux.alibaba.com dmarc=pass fromdomain=linux.alibaba.com); spf=pass (google.com: domain of linux-kernel+bounces-149433-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-149433-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.alibaba.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 3C6DD1F2261A for ; Thu, 18 Apr 2024 02:16:35 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B7490495CB; Thu, 18 Apr 2024 02:16:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="rTh0DBgu" Received: from out30-133.freemail.mail.aliyun.com (out30-133.freemail.mail.aliyun.com [115.124.30.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 574DA53AC for ; Thu, 18 Apr 2024 02:16:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713406587; cv=none; b=X+dYzjVfI2LvvIOhQPqRNDRjoaH4oCnb7uJb97VJncy5Gn1gm35eq83EwW+gSfiJGW/VJE/nODSyIHv/YUMeJ2dSYsU9mYxmGtVL+x2Q5jUsYQwnYqlW6fDHbzfYno4eLo493KZy61xxrXbsnyMSMQpC8gYkFgqz6US2ldO3Ru8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713406587; c=relaxed/simple; bh=om5S56drMap1VIxWGUiL99nWRa3VfL3sZ1hI3fORSts=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=sWNvQ6zRl8mkJxeL9h6mHnQhYO1uollpqG6TN5pUp/GbZXChXKmwWG5aKX6rpL41p8VU5bMiGrZuG+Gq1uF4LqBadRGQH2G11KX/I7iLUF4xF5nVV+pBbP5zhpH6GCm33jpvHYFWl8QT/CLw5F7uzrxv7neL49rRUJPq+wtSXwk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=rTh0DBgu; arc=none smtp.client-ip=115.124.30.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1713406581; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=TM7yh3Pc+NlyrCnP/xTpDY59CYpvgC4vK6lCHL3DuuQ=; b=rTh0DBguVLd8j+ibpuK9B1l8/MqCHrh58g9GVNgsuHmAo41LpwnlUFedXZMyOGWctjYBqws1RaEJDzwDMDae2Mg0Z1xW7LkFGDoZxRpeMfnstufAWdUge4xs6YTuOv4NSbxGVaeU7GgswyyEiNMb8heyC+yd4YPFo9OoEvJGIAs= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046051;MF=jefflexu@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0W4mrYNk_1713406579; Received: from 30.221.145.60(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0W4mrYNk_1713406579) by smtp.aliyun-inc.com; Thu, 18 Apr 2024 10:16:21 +0800 Message-ID: <71e66b02-9c2b-4981-83e1-8af72d6c0975@linux.alibaba.com> Date: Thu, 18 Apr 2024 10:16:18 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] erofs: reliably distinguish block based and fscache mode To: Baokun Li , linux-erofs@lists.ozlabs.org Cc: xiang@kernel.org, chao@kernel.org, huyue2@coolpad.com, viro@zeniv.linux.org.uk, brauner@kernel.org, linux-kernel@vger.kernel.org, yangerkun@huawei.com, houtao1@huawei.com References: <20240417065513.3409744-1-libaokun1@huawei.com> Content-Language: en-US From: Jingbo Xu In-Reply-To: <20240417065513.3409744-1-libaokun1@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Baokun, Thanks for catching this and move forward fixing this! On 4/17/24 2:55 PM, Baokun Li wrote: > When erofs_kill_sb() is called in block dev based mode, s_bdev may not have > been initialised yet, and if CONFIG_EROFS_FS_ONDEMAND is enabled, it will > be mistaken for fscache mode, and then attempt to free an anon_dev that has > never been allocated, triggering the following warning: > > ============================================ > ida_free called for id=0 which is not allocated. > WARNING: CPU: 14 PID: 926 at lib/idr.c:525 ida_free+0x134/0x140 > Modules linked in: > CPU: 14 PID: 926 Comm: mount Not tainted 6.9.0-rc3-dirty #630 > RIP: 0010:ida_free+0x134/0x140 > Call Trace: > > erofs_kill_sb+0x81/0x90 > deactivate_locked_super+0x35/0x80 > get_tree_bdev+0x136/0x1e0 > vfs_get_tree+0x2c/0xf0 > do_new_mount+0x190/0x2f0 > [...] > ============================================ > > Instead of allocating the erofs_sb_info in fill_super() allocate it > during erofs_get_tree() and ensure that erofs can always have the info > available during erofs_kill_sb(). I'm not sure if allocating erofs_sb_info in erofs_init_fs_context() will be better, as I see some filesystems (e.g. autofs) do this way. Maybe another potential advantage of doing this way is that erofs_fs_context is not needed anymore and we can use sbi directly. > > Signed-off-by: Christian Brauner > Signed-off-by: Baokun Li > --- > Changes since v1: > Allocate and initialise fc->s_fs_info in erofs_fc_get_tree() instead of > modifying fc->sb_flags. > > V1: https://lore.kernel.org/r/20240415121746.1207242-1-libaokun1@huawei.com/ > > fs/erofs/super.c | 51 ++++++++++++++++++++++++++---------------------- > 1 file changed, 28 insertions(+), 23 deletions(-) > > diff --git a/fs/erofs/super.c b/fs/erofs/super.c > index b21bd8f78dc1..4104280be2ea 100644 > --- a/fs/erofs/super.c > +++ b/fs/erofs/super.c > @@ -581,8 +581,7 @@ static const struct export_operations erofs_export_ops = { > static int erofs_fc_fill_super(struct super_block *sb, struct fs_context *fc) > { > struct inode *inode; > - struct erofs_sb_info *sbi; > - struct erofs_fs_context *ctx = fc->fs_private; > + struct erofs_sb_info *sbi = EROFS_SB(sb); > int err; > > sb->s_magic = EROFS_SUPER_MAGIC; > @@ -590,19 +589,6 @@ static int erofs_fc_fill_super(struct super_block *sb, struct fs_context *fc) > sb->s_maxbytes = MAX_LFS_FILESIZE; > sb->s_op = &erofs_sops; > > - sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); > - if (!sbi) > - return -ENOMEM; > - > - sb->s_fs_info = sbi; > - sbi->opt = ctx->opt; > - sbi->devs = ctx->devs; > - ctx->devs = NULL; > - sbi->fsid = ctx->fsid; > - ctx->fsid = NULL; > - sbi->domain_id = ctx->domain_id; > - ctx->domain_id = NULL; > - > sbi->blkszbits = PAGE_SHIFT; > if (erofs_is_fscache_mode(sb)) { > sb->s_blocksize = PAGE_SIZE; > @@ -704,11 +690,32 @@ static int erofs_fc_fill_super(struct super_block *sb, struct fs_context *fc) > return 0; > } > > -static int erofs_fc_get_tree(struct fs_context *fc) > +static void erofs_ctx_to_info(struct fs_context *fc) > { > struct erofs_fs_context *ctx = fc->fs_private; > + struct erofs_sb_info *sbi = fc->s_fs_info; > + > + sbi->opt = ctx->opt; > + sbi->devs = ctx->devs; > + ctx->devs = NULL; > + sbi->fsid = ctx->fsid; > + ctx->fsid = NULL; > + sbi->domain_id = ctx->domain_id; > + ctx->domain_id = NULL; > +} I'm not sure if abstracting this logic into a seperate helper really helps understanding the code as the logic itself is quite simple and easy to be understood. Usually it's a hint of over-abstraction when a simple helper has only one caller. > > - if (IS_ENABLED(CONFIG_EROFS_FS_ONDEMAND) && ctx->fsid) > +static int erofs_fc_get_tree(struct fs_context *fc) > +{ > + struct erofs_sb_info *sbi; > + > + sbi = kzalloc(sizeof(*sbi), GFP_KERNEL); > + if (!sbi) > + return -ENOMEM; > + > + fc->s_fs_info = sbi; > + erofs_ctx_to_info(fc); > + > + if (IS_ENABLED(CONFIG_EROFS_FS_ONDEMAND) && sbi->fsid) > return get_tree_nodev(fc, erofs_fc_fill_super); > > return get_tree_bdev(fc, erofs_fc_fill_super); > @@ -767,6 +774,7 @@ static void erofs_fc_free(struct fs_context *fc) > kfree(ctx->fsid); > kfree(ctx->domain_id); > kfree(ctx); > + kfree(fc->s_fs_info); > } > > static const struct fs_context_operations erofs_context_ops = { > @@ -783,6 +791,7 @@ static int erofs_init_fs_context(struct fs_context *fc) > ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); > if (!ctx) > return -ENOMEM; > + > ctx->devs = kzalloc(sizeof(struct erofs_dev_context), GFP_KERNEL); > if (!ctx->devs) { > kfree(ctx); > @@ -799,17 +808,13 @@ static int erofs_init_fs_context(struct fs_context *fc) > > static void erofs_kill_sb(struct super_block *sb) > { > - struct erofs_sb_info *sbi; > + struct erofs_sb_info *sbi = EROFS_SB(sb); > > - if (erofs_is_fscache_mode(sb)) > + if (IS_ENABLED(CONFIG_EROFS_FS_ONDEMAND) && sbi->fsid) > kill_anon_super(sb); > else > kill_block_super(sb); > > - sbi = EROFS_SB(sb); > - if (!sbi) > - return; > - > erofs_free_dev_context(sbi->devs); > fs_put_dax(sbi->dax_dev, NULL); > erofs_fscache_unregister_fs(sb); -- Thanks, Jingbo