All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jori Koolstra <jkoolstra@xs4all.nl>
To: Vidhu Sarwal <vidhu.linux@gmail.com>
Cc: almaz.alexandrovich@paragon-software.com, ntfs3@lists.linux.dev,
	 linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	skhan@linuxfoundation.org,  linux-kernel-mentees@lists.linux.dev,
	syzbot+57f9327d593d301ce2a2@syzkaller.appspotmail.com
Subject: Re: [RFC PATCH] fs/ntfs3: prevent positive E_NTFS_NONRESIDENT from reaching writeback error handling
Date: Thu, 23 Jul 2026 15:34:55 +0200	[thread overview]
Message-ID: <amIXogW-sKfOhuxO@daedalus> (raw)
In-Reply-To: <20260713084140.249515-1-vidhu.linux@gmail.com>

On Mon, Jul 13, 2026 at 02:11:40PM +0530, Vidhu Sarwal wrote:
> attr_data_write_resident() returns the internal positive status code
> E_NTFS_NONRESIDENT when the DATA attribute becomes non-resident.
> ntfs_writepages() propagates this value into generic writeback error
> handling, which expects a standard negative errno and triggers
> WARN_ON_ONCE(err > 0).
> 
> Translate positive E_NTFS_* status codes to -EIO before recording
> the writeback error. This prevents positive internal status codes from
> reaching generic writeback code while preserving the existing behaviour
> of treating this path as a writeback error.

Should attr_data_write_resident() be returning positive values on error?
If this is correct, and this is a matter of data corruption you can use
EFSCORRUPTED (EIO may also be fine if this is what NTFS uses in other
places).

Thanks,
Jori.

> 
> Reported-by: syzbot+57f9327d593d301ce2a2@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=57f9327d593d301ce2a2
> Signed-off-by: Vidhu Sarwal <vidhu.linux@gmail.com>
> ---
> RFC:
> 
> I'd appreciate guidance on whether -EIO is the appropriate errno here.
> 
> E_NTFS_NONRESIDENT indicates that the DATA attribute became
> non-resident during writeback. Translating it to -EIO prevents the
> positive internal status code from reaching generic writeback code and
> preserves the existing behaviour of treating this path as a writeback
> error.
> 
> However, if the intended behaviour is to retry the write using the
> non-resident path instead of failing it, then the correct solution would
> be more than a simple errno translation. The proposed change assumes the
> current terminal-error behaviour is intentional.
>  fs/ntfs3/inode.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/fs/ntfs3/inode.c b/fs/ntfs3/inode.c
> index 0c9bd669117d..9458867c6b0b 100644
> --- a/fs/ntfs3/inode.c
> +++ b/fs/ntfs3/inode.c
> @@ -1019,6 +1019,15 @@ static int ntfs_writepages(struct address_space *mapping,
>  
>  			folio_unlock(folio);
>  			if (err2) {
> +				/*
> +				 * attr_data_write_resident() can return the
> +				 * positive internal code E_NTFS_NONRESIDENT;
> +				 * both mapping_set_error() and writeback_iter()
> +				 * need a negative errno and warn on a positive
> +				 * value.
> +				 */
> +				if (err2 > 0)
> +					err2 = -EIO;
>  				mapping_set_error(mapping, err2);
>  				if (!err)
>  					err = err2;
> 
> base-commit: a13c140cc289c0b7b3770bce5b3ad42ab35074aa
> -- 
> 2.53.0
> 

      reply	other threads:[~2026-07-23 13:34 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-13  8:41 [RFC PATCH] fs/ntfs3: prevent positive E_NTFS_NONRESIDENT from reaching writeback error handling Vidhu Sarwal
2026-07-23 13:34 ` Jori Koolstra [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amIXogW-sKfOhuxO@daedalus \
    --to=jkoolstra@xs4all.nl \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel-mentees@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ntfs3@lists.linux.dev \
    --cc=skhan@linuxfoundation.org \
    --cc=syzbot+57f9327d593d301ce2a2@syzkaller.appspotmail.com \
    --cc=vidhu.linux@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.