From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 8A45F3B42C7 for ; Mon, 24 Aug 2026 08:53:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787561591; cv=none; b=MBVc6K22PQlISTIy0Op3tBDuLdrx0RAJQbRJ3myJVd1I4OhzXLiufngEH2eLBzUC6kLORuWzuoBA7LC/LrAR9HhD4ZNs6a0q2/WYkZPo+rFmAOBLXxFP9Xi7jyPaZSlSxX4+ktub4izJxnaeSCNEWojwKo4lmnx6zDcr2xJTYZY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787561591; c=relaxed/simple; bh=52Ku6Wm6WVs1o02AOeTul2pTbojwW95Sb58xlCLUff4=; h=Message-ID:Date:MIME-Version:Cc:Subject:To:References:From: In-Reply-To:Content-Type; b=PXZNIF/ziNDKh7rPHBcZ0gY3/t6e2Oq7S1frGqOJS+2nEYNO9nMqDLDOkpGh7uKkBfEo1CkHei4gH09OfVSWstaytO3aFwLjZuKMsKnGJY4p2UuH+mXMzUEMEez55gDumVxTzQU9BnjYPHpxYlLFgmi8j34Ll/ptNXLYj8F3g6c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gwPtful9; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gwPtful9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F19F1F000E9; Mon, 24 Aug 2026 08:53:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1787561590; bh=WFecKIK1PJcHmVFcLdR//8ys7vYPyoBgiIwphMnMYGQ=; h=Date:Cc:Subject:To:References:From:In-Reply-To; b=gwPtful9/Eyr6DlHaUmu1ixqPll+CrUh8iM4+xTh1bLrGisuTvcnfkmcmtCN0AggR pdJ/0EcAw2Bex89z/tjW+ThJhV9roSAslPogdAZnUdBendKAHEcFUiD6nblGqY5O8+ Y4SzdZ2eq6VmXqpn9xgwj9rTxK66fm5E1aThhwp+ep39czj9xBQ2iexVED/YIXHFE2 gxK737dJ+YIAYusilmqazpH3sTbKNaUw5lhb1Ql9BAXzqkZC7kpna/WwibzSFL/O1i AenmQwlcHz0BcfCb/mm1NtaRKEGDen8dLFIeJJOPP7c/qLLMV44M4W9kYxevwvx9tv uriqFEp+4IPtQ== Message-ID: <0229529e-03e0-4684-a8c5-015113858640@kernel.org> Date: Mon, 24 Aug 2026 16:53:06 +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 Cc: chao@kernel.org, Daeho Jeong , Yonggil Song , Hans Holmberg , linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] f2fs: use adjusted write range after f2fs_write_checks() To: Seongjae Jeong , Jaegeuk Kim References: <20260824023231.24616-1-jsjlee1020@gmail.com> Content-Language: en-US From: Chao Yu In-Reply-To: <20260824023231.24616-1-jsjlee1020@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/24/26 10:32, Seongjae Jeong wrote: > generic_write_checks() in f2fs_write_checks() can adjust iocb->ki_pos > for append writes and truncate the iterator to limit the number of bytes > to write. > > In f2fs_file_write_iter(), the pinned-file overwrite check currently > uses the position and count saved before f2fs_write_checks(), so it > can check a range different from the actual write range. > > The forced buffered I/O cleanup also uses orig_pos saved before > f2fs_write_checks(). For O_APPEND writes, this can make the cleanup > flush and invalidate the wrong page cache range. > > Move the pinned-file overwrite check after f2fs_write_checks() and use > the adjusted iocb->ki_pos and iov_iter_count(from). Also save the > adjusted write position and use it for the forced buffered I/O cleanup. > > Fixes: 3fdd89b452c2 ("f2fs: prevent writing without fallocate() for pinned files") > Fixes: 92318f20d703 ("f2fs: preserve direct write semantics when buffering is forced") > Signed-off-by: Seongjae Jeong Reviewed-by: Chao Yu Thanks,