Received: by 2002:ab2:69cc:0:b0:1f4:be93:e15a with SMTP id n12csp1774052lqp; Mon, 15 Apr 2024 17:57:47 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVXWh/k/nJhGa3XxXBhd9kTGDWltbrQGTnnoaPFyP8Ha0GSPvjClpXzSmpFrJYNu1KxFzJfqIFyEQtrp5IvHyUn/9zLHxIAo1EQcCl0xg== X-Google-Smtp-Source: AGHT+IGWPq1eWEGYZ9oZW7MQgIhMkLoyD10V45evwOxI0F4cGk2lhvyKG+nXOvh2OibUIJ5MXwMl X-Received: by 2002:a17:90a:7c06:b0:2a2:7494:15df with SMTP id v6-20020a17090a7c0600b002a2749415dfmr832347pjf.9.1713229067578; Mon, 15 Apr 2024 17:57:47 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713229067; cv=pass; d=google.com; s=arc-20160816; b=jNj878+8YIQojfJkEhhYEy+pyiCQ4OnyerhcYifnNYSFN0tQKW8V8eCKGIYvaDy1Hd KAwhtfLt2f33Fe3U7KPp373Jq5PXWa2RWytam7n0xh8+H/X+NQf08S52QlGxnxN6Zlah OH2T14BO1xsd4wf/43igzZDDTrhcsdohWcYOR33dHSLuxKj6YGNzlDnJ//WWhnFTXXag oub+BL+mQVQQt6IeWSYO/OBAOMLF3flaz3PLHP+OIPj1TmuGHkoNvk8cgQC09wipsuit d3sL5R2yKLVx+oV2BzqXsOnfJFJwxciCDs3F/Y3EOtFZIML2A+yrJKcfSxKdJqPsG1Zz +dWA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature; bh=X0+nrubxreTc1Lz3jG96l3GbTZGOmTwC4L2nn294nUg=; fh=EHZJ3/FWIFBr8hUa4mwFUiZPmwo6YOXRbrVWnaIX2eQ=; b=HJSPNSnxWx0w0PzW/PIN2o3L1quFqkzM7Vl2z2qFUZI/8WkB774PkjXQWAEP33Yptf z+tWxdLt9o3AAaVUOVqkN8j8SbM3ZPbzYSfxArMFtDWl+8ugizY296uTkkwxmxxrsKgv jkPrhV/iNbovcieDU4/5FhzLmfHwEf4/h8QNybeo4octTXdX/A5qTHQHul6lCIjOc8tF JjKlPpAfTzz96HpscdlSIQpA44bwKK0CVcN/amJMTbPqvWgkkmZOfKp1Tgu9Q8XQYBLV Ii92Emw67B/jR2zdegfwy03okAQPGGBUHaBLq6n8jsTXqzhTCLVBZ+qAqvD/cOU98JW0 J11g==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=MAPfjboq; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-146052-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-146052-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id d19-20020a17090ac25300b002a537deacc5si8910205pjx.56.2024.04.15.17.57.47 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Apr 2024 17:57:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-146052-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=MAPfjboq; arc=pass (i=1 dkim=pass dkdomain=kernel.org); spf=pass (google.com: domain of linux-kernel+bounces-146052-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-146052-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org 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 sv.mirrors.kernel.org (Postfix) with ESMTPS id 01F3028309A for ; Tue, 16 Apr 2024 00:57:47 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B73C93FD4; Tue, 16 Apr 2024 00:57:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MAPfjboq" Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 E440D1849 for ; Tue, 16 Apr 2024 00:57:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713229061; cv=none; b=rOUimOBoqq+q4coCgz7sDVhgKouZJbkaH+mYqZmRLLvIMaDNdqEz+RxIfTORbbT7dF9C5Y41UFxMNyjKXx11TZGYaLf8NcQghhSZql2AcWMA/7wyqKTVe0q52DmV8ly6/eyblZAIDioaQ6A/M2svatIxou1AQ92GbGljPYNuu7s= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1713229061; c=relaxed/simple; bh=e+mZ8gSzLwQyrTBa4o3G3i7rgdxAvvnf8ZmX93KlrW4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=e4yUBnPULsnI31VsrsiPai6Lje8T+VUZ5kBsrKZAY4u5iakPVTAHGoWMpsUdM4jA2NJ98jECH9M0/9Fwl2fiFH4pkUQfXJkh1pBI5h9sAHyFb/2GFIivKBB3covbhpoSd5QawRa4FoYsMK1da3zyV0SiaIIpQloRWQuYXGcyj8o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MAPfjboq; arc=none smtp.client-ip=10.30.226.201 Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4398FC113CC; Tue, 16 Apr 2024 00:57:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713229060; bh=e+mZ8gSzLwQyrTBa4o3G3i7rgdxAvvnf8ZmX93KlrW4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MAPfjboqItuLZRgArjOyRoVElAn/2mJFMZi1IqSXjmlOVjdECxiubReZqWyREN+oy MC2KnpMq96rgwh4houoreP/85lJPdcFWxbyQMWKR2NvZruAp11HegcpIPkDKLT9F4A lIKuvOP5wzhl8sx6zWdEfyZtv8CjfQqUcif9TtwlQH6zvRA3lAJCMqXxYqLhS6x3+S bAN4tH+t+H6KRiMQbmHOshcr5JKBCFBbSWanTf4q7iS/KDQX/CAE58WUZTW7y1nyPy CvWNSa6xiZmd2l8SJh0470bR67G4OiGXUEb3hxvaSgOvuYeXsP2adwiO/qpINC4kN5 P1Gq+kWKLykEw== Date: Tue, 16 Apr 2024 08:57:38 +0800 From: Gao Xiang To: Baokun Li , Christian Brauner Cc: linux-erofs@lists.ozlabs.org, xiang@kernel.org, chao@kernel.org, huyue2@coolpad.com, jefflexu@linux.alibaba.com, viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org, yangerkun@huawei.com, houtao1@huawei.com Subject: Re: [PATCH] erofs: set SB_NODEV sb_flags when mounting with fsid Message-ID: Mail-Followup-To: Baokun Li , Christian Brauner , linux-erofs@lists.ozlabs.org, xiang@kernel.org, chao@kernel.org, huyue2@coolpad.com, jefflexu@linux.alibaba.com, viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org, yangerkun@huawei.com, houtao1@huawei.com References: <20240415121746.1207242-1-libaokun1@huawei.com> <20240415-betagten-querlatte-feb727ed56c1@brauner> <15ab9875-5123-7bc2-bb25-fc683129ad9e@huawei.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <15ab9875-5123-7bc2-bb25-fc683129ad9e@huawei.com> Hi Christian, Baokun, On Mon, Apr 15, 2024 at 11:23:58PM +0800, Baokun Li wrote: > On 2024/4/15 21:38, Christian Brauner wrote: > > On Mon, Apr 15, 2024 at 08:17:46PM +0800, 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 > > > [...] > > > ============================================ > > > > > > To avoid this problem, add SB_NODEV to fc->sb_flags after successfully > > > parsing the fsid, and then the superblock inherits this flag when it is > > > allocated, so that the sb_flags can be used to distinguish whether it is > > > in block dev based mode when calling erofs_kill_sb(). > > > > > > Signed-off-by: Baokun Li > > > --- > > > fs/erofs/super.c | 7 +++---- > > > 1 file changed, 3 insertions(+), 4 deletions(-) > > > > > > diff --git a/fs/erofs/super.c b/fs/erofs/super.c > > > index b21bd8f78dc1..7539ce7d64bc 100644 > > > --- a/fs/erofs/super.c > > > +++ b/fs/erofs/super.c > > > @@ -520,6 +520,7 @@ static int erofs_fc_parse_param(struct fs_context *fc, > > > ctx->fsid = kstrdup(param->string, GFP_KERNEL); > > > if (!ctx->fsid) > > > return -ENOMEM; > > > + fc->sb_flags |= SB_NODEV; > > Hm, I wouldn't do it this way. That's an abuse of that flag imho. > > Record the information in the erofs_fs_context if you need to. > The stack diagram that triggers the problem is as follows, the call to > erofs_kill_sb() fails before fill_super() has been executed, and we can > only use super_block to determine whether it is currently in nodev > fscahe mode or block device based mode. So if it is recorded in > erofs_fs_context (aka fc->fs_private), we can't access the recorded data > unless we pass fc into erofs_kill_sb() as well. > If I understand correctly, from the discussion above, I think there exists a gap between alloc_super() and sb->s_bdev is set. But .kill_sb() can be called between them and fc is not passed into .kill_sb(). I'm not sure how to resolve it in EROFS itself, anyway... Thanks, Gao Xiang