* [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal
@ 2026-07-13 6:19 David Timber
2026-07-13 6:53 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: David Timber @ 2026-07-13 6:19 UTC (permalink / raw)
To: Namjae Jeon, Sungjong Seo, Yuezhang Mo
Cc: Andy Wu, Aoyama Wataru, David Timber, stable
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
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal
2026-07-13 6:19 [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal David Timber
@ 2026-07-13 6:53 ` Greg KH
2026-07-13 6:56 ` David Timber
2026-07-13 7:55 ` David Timber
0 siblings, 2 replies; 6+ messages in thread
From: Greg KH @ 2026-07-13 6:53 UTC (permalink / raw)
To: David Timber
Cc: Namjae Jeon, Sungjong Seo, Yuezhang Mo, Andy Wu, Aoyama Wataru,
stable
On Mon, Jul 13, 2026 at 03:19:54PM +0900, David Timber wrote:
> commit 82a81a7352bcf5f2756ac33d47ee0582737e9a85 upstream.
No this is not :(
confused,
gre gk-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal
2026-07-13 6:53 ` Greg KH
@ 2026-07-13 6:56 ` David Timber
2026-07-13 7:55 ` David Timber
1 sibling, 0 replies; 6+ messages in thread
From: David Timber @ 2026-07-13 6:56 UTC (permalink / raw)
To: Greg KH
Cc: Namjae Jeon, Sungjong Seo, Yuezhang Mo, Andy Wu, Aoyama Wataru,
stable
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal
2026-07-13 6:53 ` Greg KH
2026-07-13 6:56 ` David Timber
@ 2026-07-13 7:55 ` David Timber
2026-07-13 12:05 ` Greg KH
1 sibling, 1 reply; 6+ messages in thread
From: David Timber @ 2026-07-13 7:55 UTC (permalink / raw)
To: Greg KH
Cc: Namjae Jeon, Sungjong Seo, Yuezhang Mo, Andy Wu, Aoyama Wataru,
stable
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal
2026-07-13 7:55 ` David Timber
@ 2026-07-13 12:05 ` Greg KH
2026-07-13 12:14 ` David Timber
0 siblings, 1 reply; 6+ messages in thread
From: Greg KH @ 2026-07-13 12:05 UTC (permalink / raw)
To: David Timber
Cc: Namjae Jeon, Sungjong Seo, Yuezhang Mo, Andy Wu, Aoyama Wataru,
stable
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal
2026-07-13 12:05 ` Greg KH
@ 2026-07-13 12:14 ` David Timber
0 siblings, 0 replies; 6+ messages in thread
From: David Timber @ 2026-07-13 12:14 UTC (permalink / raw)
To: Greg KH
Cc: Namjae Jeon, Sungjong Seo, Yuezhang Mo, Andy Wu, Aoyama Wataru,
stable
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-07-13 12:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-13 6:19 [PATCH v1] exfat: bail prematurely from exfat_extend_valid_size() upon fatal signal David Timber
2026-07-13 6:53 ` Greg KH
2026-07-13 6:56 ` David Timber
2026-07-13 7:55 ` David Timber
2026-07-13 12:05 ` Greg KH
2026-07-13 12:14 ` David Timber
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox