[PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal

[PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal

[David Timber]

commit 82a81a7352bcf5f2756ac33d47ee0582737e9a85 upstream.

If a file in an exfat volume has a large (isize - VDL) gap and userspace
write past a large amount of unwritten clusters, write amplification
occurs. Currently there was no way for userspace to cancel this.

As tasks with pending fatal signal receives preferential treatment in
mm/vmscan.c, if the userspace process is killed during the iteration,
the excessive use of pages in block_write may lead to system instability
and OOM killer activating in vain to free up some pages.

Demo:

	truncate -s 16G /mnt/exfat/file
	dd if=/dev/urandom of=/mnt/exfat/file bs=1 count=1 seek=16G &
	kill -KILL $!

To fix this, add the fatal_signal_pending() check in the loop. This
mirrors the behaviour of iomap variant of exfat. Note that the iomap
exfat implementation is unaffected as the check is already present in
iomap_zero_range().

Fixes: 11a347fb6cef ("exfat: change to get file size from DataLength")
Cc: <stable@vger.kernel.org> # 6.18+
Signed-off-by: David Timber <dxdt@dev.snart.me>
---
 fs/exfat/file.c | 24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/fs/exfat/file.c b/fs/exfat/file.c
index 91e5511945d1..4db6a4b773fd 100644
--- a/fs/exfat/file.c
+++ b/fs/exfat/file.c
@@ -656,6 +656,11 @@ static int exfat_extend_valid_size(struct inode *inode, loff_t new_valid_size)
 		struct folio *folio;
 		unsigned long off;
 
+		if (fatal_signal_pending(current)) {
+			err = -EINTR;
+			goto out;
+		}
+
 		len = PAGE_SIZE - (pos & (PAGE_SIZE - 1));
 		if (pos + len > new_valid_size)
 			len = new_valid_size - pos;
@@ -717,13 +722,20 @@ static ssize_t exfat_file_write_iter(struct kiocb *iocb, struct iov_iter *iter)
 
 	if (pos > valid_size) {
 		ret = exfat_extend_valid_size(inode, pos);
-		if (ret < 0 && ret != -ENOSPC) {
-			exfat_err(inode->i_sb,
-				"write: fail to zero from %llu to %llu(%zd)",
-				valid_size, pos, ret);
-		}
-		if (ret < 0)
+		if (ret < 0) {
+			/* Do not report trivial errors. */
+			switch (ret) {
+			case -ENOSPC:
+			case -EINTR:
+				break;
+			default:
+				exfat_err(inode->i_sb,
+					"write: fail to zero from %llu to %llu(%zd)",
+					valid_size, pos, ret);
+			}
+
 			goto unlock;
+		}
 	}
 
 	ret = __generic_file_write_iter(iocb, iter);
-- 
2.55.0

Re: [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal

[Greg KH]

On Mon, Jul 13, 2026 at 03:19:54PM +0900, David Timber wrote:
> commit 82a81a7352bcf5f2756ac33d47ee0582737e9a85 upstream.

No this is not :(

confused,

gre gk-h

Re: [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal

[David Timber]

On 7/13/26 15:53, Greg KH wrote:
> On Mon, Jul 13, 2026 at 03:19:54PM +0900, David Timber wrote:
>> commit 82a81a7352bcf5f2756ac33d47ee0582737e9a85 upstream.
> No this is not :(
>
> confused,
>
> gre gk-h
I'm sorry. I know. This still under review. Stupid git send-email cc'd
the list address.

Davo

Re: [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal

[David Timber]

GKH,

Just a quick question: the
handbook(Documentation/process/stable-kernel-rules.rst) really insists
on putting an upstream commit, but this is an interesting issue that
goes away with the iomap patchset set for release in v7.2. There isn't
really an upstream that explicitly fixes it. I don't think it falls
under any of Options 1, 2 or 3. Should I just remove that line?

Also, in the last patch I submitted to you(SEEK_DATA/SEEK_HOLE on
/dev/null), you were against the idea of using switch...case for
inaction rather than action on a value. If you ACK, should I just use an
if statement like so?

+ if (ret < 0 && ret != -ENOSPC && ret != -EINTR)  {

Davo

On 7/13/26 15:53, Greg KH wrote:
> On Mon, Jul 13, 2026 at 03:19:54PM +0900, David Timber wrote:
>> commit 82a81a7352bcf5f2756ac33d47ee0582737e9a85 upstream.
> No this is not :(
>
> confused,
>
> gre gk-h

Re: [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal

[Greg KH]

On Mon, Jul 13, 2026 at 04:55:34PM +0900, David Timber wrote:
> GKH,

Please don't top-post.

> Just a quick question: the
> handbook(Documentation/process/stable-kernel-rules.rst) really insists
> on putting an upstream commit, but this is an interesting issue that
> goes away with the iomap patchset set for release in v7.2. There isn't
> really an upstream that explicitly fixes it. I don't think it falls
> under any of Options 1, 2 or 3. Should I just remove that line?

If this is not a problem in Linus's tree, and this needs to be fixed in
a stable kernel, you need to document it really really really well why
we can't just take the same commits that are in Linus's tree for the
issue.

And even then I'll push back hard for why this is needed.  Be warned :)

> Also, in the last patch I submitted to you(SEEK_DATA/SEEK_HOLE on
> /dev/null), you were against the idea of using switch...case for
> inaction rather than action on a value. If you ACK, should I just use an
> if statement like so?
> 
> + if (ret < 0 && ret != -ENOSPC && ret != -EINTR)  {

I have no context here at all, sorry.  I'm not a exfat developer, and I
get 1000+ emails a day...

thanks,

greg k-h

Re: [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal

[David Timber]

On 7/13/26 21:05, Greg KH wrote:
> On Mon, Jul 13, 2026 at 04:55:34PM +0900, David Timber wrote:
>> GKH,
> Please don't top-post.
>
>> Just a quick question: the
>> handbook(Documentation/process/stable-kernel-rules.rst) really insists
>> on putting an upstream commit, but this is an interesting issue that
>> goes away with the iomap patchset set for release in v7.2. There isn't
>> really an upstream that explicitly fixes it. I don't think it falls
>> under any of Options 1, 2 or 3. Should I just remove that line?
> If this is not a problem in Linus's tree, and this needs to be fixed in
> a stable kernel, you need to document it really really really well why
> we can't just take the same commits that are in Linus's tree for the
> issue.
>
> And even then I'll push back hard for why this is needed.  Be warned :)
Alrighty! Won't bother you anymore. I tried :)

Davo