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;
MIME-Version: 1.0
References: <20221114040441.1649940-1-zhangpeng362@huawei.com>
 <CAKFNMomu3Sf4_QHOm=zXM-QiLaVxASpMqpjek0F3SQnXwje4KA@mail.gmail.com>
 <CAKFNMonXdyMw9mrQeGe_KtSfMDPSC_jNai8FZGceVyV9Nxw8AQ@mail.gmail.com> <422d9c54-a119-b2a2-f381-11f83af3d9ea@huawei.com>
In-Reply-To: <422d9c54-a119-b2a2-f381-11f83af3d9ea@huawei.com>
From:   Ryusuke Konishi <konishi.ryusuke@gmail.com>
Date:   Sat, 19 Nov 2022 16:24:43 +0900
Message-ID: <CAKFNMokh1fQNyqVCMWoQVnRnXf65j__Op9p+a3Prz_qk-YnoVQ@mail.gmail.com>
Subject: Re: [PATCH] nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()
To:     "zhangpeng (AS)" <zhangpeng362@huawei.com>
Cc:     ye.xingchen@zte.com.cn, chi.minghao@zte.com.cn,
        vishal.moola@gmail.com, linux-nilfs@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        syzbot+ebe05ee8e98f755f61d0@syzkaller.appspotmail.com
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Nov 19, 2022 at 3:38 PM zhangpeng (AS)  wrote:
>
> Hi, ZhangPeng,
>
> On Tue, Nov 15, 2022 at 3:39 AM Ryusuke Konishi  wrote:
> As for the current outlook, it seems difficult to eliminate
> duplication of the virtual block number, so I think we will call
> nilfs_error() as follows:
>
>         nilfs_dat_commit_entry(dat, req);
> +        if (unlikely(req->pr_desc_bh == NULL || req->pr_bitmap_bh == NULL)) {
> +                nilfs_error(dat->i_sb,
> +                            "state inconsistency due to duplicate use
> of vblocknr = %llu",
> +                            (unsigned long long)req->pr_entry_nr);
> +                return;
> +       }
>         nilfs_palloc_commit_free_entry(dat, req);
>
> In that case, I would like to modify your patch and send it upstream
> as your patch.  Is that OK ?
> Or do you want to fix it more by yourself ?
>
> Thanks,
> Ryusuke Konishi
>
> Thanks for your advice.
>
> Please modify my patch and send it upstream.
>
> That is really a complicated problem. Duplication of the virtual block
> number is not easy to fix. It is necessary to prevent further operations
>  of the filesystem when the filesystem has a fatal flaw. I will continue
>  to follow up.

All right, thanks!

Ryusuke Konishi