From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.126.com (m16.mail.126.com [220.197.31.7]) (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 82D91366DAA for ; Thu, 22 Jan 2026 02:09:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=220.197.31.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769047751; cv=none; b=gyWVYycdr2aPi7+1/JZTmDQliUpyqywvyFrSW+LI2s7KfL5ZM7kDzKvYocbXzjM4LSfyjoXhavuq7lVq+vzsEMZ0DMpDb7oD0ReIpc7kV540jBGhuRhKFSYlA09cC5xvOGi3Z5KLdsOwm/XU5xQ5d1wuIzaWwRaeN6U8lP8H7+M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769047751; c=relaxed/simple; bh=eNU46mMAhsfkPjWnJzSQsD6dXvyLn+CPdlJ+W6Qcc3M=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Oxt2lCbBDdeKD6QtMPeStBRTP6GXn5a366lruwRzdRNkMTAJ4tJCT1xg3bmkR/vkGSrPr0X5MuQYKFCsoPxa+9dSOgWG/UBns0j4XPT0dZUxwdHLl4gj3t7udvjUST9qft3BuV7Lgr0XLWRH9f8ZDv3eHJ8Wrf3GNf2FymuQ1d0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=126.com; spf=pass smtp.mailfrom=126.com; dkim=pass (1024-bit key) header.d=126.com header.i=@126.com header.b=Nx4pyAPg; arc=none smtp.client-ip=220.197.31.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=126.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=126.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=126.com header.i=@126.com header.b="Nx4pyAPg" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Message-ID:Date:MIME-Version:Subject:To:From: Content-Type; bh=IRNTD8aA6LWMkBMmEmDIcJ/0jijgrN8LtcD50K0ogEA=; b=Nx4pyAPgBv7H6dGwm8O6LJn2KVwHH1wttqzEWPDdL4UhaSvAPhcP9sduZ6Gqik TuYT/2zi7Jc/fIAoDNlOR2xlrWzhbad6huReGTm4APXPPWpsS5zvU0An4OGf/5ro o9BafN/26dnOB/LOK9pbq3MBk6nk6yM7ft9bzc2PB+8xg= Received: from [192.168.1.126] (unknown []) by gzga-smtp-mtada-g1-3 (Coremail) with SMTP id _____wDnb4AYhXFpypkZCA--.41574S2; Thu, 22 Jan 2026 10:02:00 +0800 (CST) Message-ID: <83419982-77ba-4dac-880e-bf59669a006f@126.com> Date: Thu, 22 Jan 2026 10:02:00 +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: [f2fs-dev] [PATCH] f2fs: fix to prevent clearing immutable for large folio supported inode To: Chao Yu , Barry Song <21cnbao@gmail.com> Cc: jaegeuk@kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net References: <20260109024716.12047-1-chao@kernel.org> <2cdd4281-7e37-4dd0-91b1-1ab16ef772aa@kernel.org> <8c13ca69-a08a-41c7-bbef-0a79a5f44f93@kernel.org> Content-Language: en-US From: Nanzhe Zhao In-Reply-To: <8c13ca69-a08a-41c7-bbef-0a79a5f44f93@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:_____wDnb4AYhXFpypkZCA--.41574S2 X-Coremail-Antispam: 1Uf129KBjvJXoW7KryDGw47tFy7ZFW8Gr43trb_yoW8JFyxpa 15C3s5Kr95GF4FkFykt3WfXryFqrWrtayUJa97WF97A3W5u34SkF1kt3WIkFyktrs7Cr48 Ja1UWryUWFZ5JaUanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07j0oGQUUUUU= X-CM-SenderInfo: xq22xtbr6rjloofrz/xtbBohke7WlxhRleRQAA3X Hi all: 在 2026/1/9 16:44, Chao Yu via Linux-f2fs-devel 写道: > w/ above locks, it seems there is still a race condition as below: > > f2fs_fileattr_set                read >  - f2fs_setflags_common >   - truncate_pagecache >                         - f2fs_read_data_large_folio >                         : read large folios >   - mapping_set_folio_order_range > > Thanks, I noticed that the comment for `mapping_set_folio_order_range()` says: > "Context: This should not be called while the inode is active as it is non-atomic." I'm not sure whether cases like f2fs_fileattr_set falls into the inode active case. >> >> >> If clearing immutable is indeed rare, we may leave this as is, since >> writes are not supported until the page cache is fully dropped. >> Eventually, we will support large folios on non-immutable files. >> >> Thanks >> Barry Also, I couldn’t find any API in `include/linux/pagemap.h` that can atomically set the folio order range. However, I think dynamically setting large folio order while an inode is active is a reasonable requirement. In my non immutable file large folio write work, I need to enable large folio support for a file when it is converted from an inline file to a non-inline file. The lack of an atomic API seems to be a blocker for moving large folio write forward. Any idea on that? Thanks, Nanzhe Zhao