Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp679799pxk; Sun, 30 Aug 2020 19:32:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzmQ5ziRxrKBaUUoRkEO5Df92TYAB5dwySFhjUExjBZv/2bq1B5XhI/8vZUsLrIsvgWiX8f X-Received: by 2002:a17:906:5452:: with SMTP id d18mr10432190ejp.163.1598841178016; Sun, 30 Aug 2020 19:32:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598841178; cv=none; d=google.com; s=arc-20160816; b=Yk5DDVjyH8bKHg6YfOqsvIJVoq3gUU0QLilpj8oSH9hSyAiNKSONr/rjCpgr9QJmGv n3gpBW/qBr1QhQ7LkjbBFBRjdLjuh6NGEEUkHIMXp61OTAIVqaLlb1FOZR2pbeNit9Wd I4impBiibpHK/DLg0AEWJd5wIibyPovlGoTTa1M5EJ+YSQYmN95wfXHwH5JotWcgz3y4 k1OHZrkNJxYpQqaoYTKtelh2NuUQtz9KLKDT1GJTz8eDORA1Ekgxm8XZ/7QvOgJ03E/9 T7j1fSajAAXJ8+CHO17dYRzca2i01lk/XXNP0IBdjAe4Mc4wcY93FukexBAjjp0gBrFb w8ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=M6z100x0GH/0V8MYr3y0ixSYX8Zue1goKOxdCo/zhKU=; b=ooQNU4oK4XmfOkW4hMpQciovi638byofUP+oHJYnoNa5BrzRviZ55ntgvhoq0jII3S lw5T+5KPLW9cUAfrMWq5QhgNP3OH7Hc6q7hHfI3zoLhcKE1+viu3C25OvdWaCHYPC3uv /qcWYSY6WUiokweimbwGiK1DoDZieKkhPsJLVK4KnzYilk+9ADkWvG0B5WiwEu/BjJsE Hytt8iZ5bIkdFFDeo08lzbpBvhgjwLUvCSjzsUY+0p+uR4gBzSpFXtBdniVasMEfN+Fx jIAMNZyilix+Qbylm+tQQRwMxQjXvbtD+z4pSk4hMYNB4SC44D1/b+N0WcogNFMLtu6l 7tKA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r10si4228137ejb.340.2020.08.30.19.32.35; Sun, 30 Aug 2020 19:32:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727802AbgHaCb1 (ORCPT + 99 others); Sun, 30 Aug 2020 22:31:27 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:10735 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726913AbgHaCb0 (ORCPT ); Sun, 30 Aug 2020 22:31:26 -0400 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id 920CFA952F9902B1F4F0; Mon, 31 Aug 2020 10:31:22 +0800 (CST) Received: from [10.136.114.67] (10.136.114.67) by smtp.huawei.com (10.3.19.202) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 31 Aug 2020 10:31:17 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: prevent compressed file from being disabled after releasing cblocks To: Daeho Jeong CC: Chao Yu , Daeho Jeong , , , References: <20200828054629.583577-1-daeho43@gmail.com> <61996dcd-6db1-13fc-8239-7e684f3ec49e@kernel.org> From: Chao Yu Message-ID: Date: Mon, 31 Aug 2020 10:31:17 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.136.114.67] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020/8/31 9:44, Daeho Jeong wrote: > Sorry, I didn't get your point. > > So, do you think this patch is ok? And we need to consider that we > need more immutable checks for other cases? Yes, this patch looks good to me. But, IMO, we should discuss about whether we need to add more immutable checks for other ioctl cases. - open(O_RDWR) - ioctl(FS_IOC_SETFLAGS, F2FS_COMPR_FL) - write() - ioctl(RELEASE_COMPRESS_BLOCKS) -- inode is immutable now - ioctl(FS_IOC_SETFLAGS, ~F2FS_COMPR_FL) -- Should we allow to update immutable inode? as we know, normally, immutable inode should deny open(O_WRONLY or O_RDWR) and later update. Thanks, > Or you want to remove this immutable check from here and add the check > to each ioctl functions? > > 2020년 8월 31일 (월) 오전 10:24, Chao Yu 님이 작성: >> >> On 2020/8/31 7:42, Daeho Jeong wrote: >>> Do you have any reason not to put this check here? >> >> No, the place is okay to me. :) >> >>> If we do this check outside of here, we definitely make a mistake >>> sooner or later. >> >> I just want to see whether we can cover all cases in where we missed to >> add immutable check condition if necessary. >> >> Thanks, >> >>> >>> 2020년 8월 30일 (일) 오후 12:24, Chao Yu 님이 작성: >>>> >>>> On 2020-8-28 13:46, Daeho Jeong wrote: >>>>> From: Daeho Jeong >>>>> >>>>> After releasing cblocks, the compressed file can be accidentally >>>>> disabled in compression mode, since it has zero cblocks. As we are >>>>> using IMMUTABLE flag to present released cblocks state, we can add >>>>> IMMUTABLE state check when considering the compressed file disabling. >>>>> >>>>> Signed-off-by: Daeho Jeong >>>>> --- >>>>> fs/f2fs/f2fs.h | 2 ++ >>>>> 1 file changed, 2 insertions(+) >>>>> >>>>> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h >>>>> index 02811ce15059..14d30740ba03 100644 >>>>> --- a/fs/f2fs/f2fs.h >>>>> +++ b/fs/f2fs/f2fs.h >>>>> @@ -3936,6 +3936,8 @@ static inline u64 f2fs_disable_compressed_file(struct inode *inode) >>>>> if (!f2fs_compressed_file(inode)) >>>>> return 0; >>>>> if (S_ISREG(inode->i_mode)) { >>>>> + if (IS_IMMUTABLE(inode)) >>>>> + return 1; >>>> >>>> It looks most of callers are from ioctl, should we add immutable check in f2fs >>>> ioctl interfaces if necessary? or I missed existed check. >>>> >>>> Thanks, >>>> >>>>> if (get_dirty_pages(inode)) >>>>> return 1; >>>>> if (fi->i_compr_blocks) >>>>> >>> >>> >>> _______________________________________________ >>> Linux-f2fs-devel mailing list >>> Linux-f2fs-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >>> > . >