linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: linux-fsdevel@vger.kernel.org
Cc: Namjae Jeon <linkinjeon@kernel.org>,
	Sungjong Seo <sj1557.seo@samsung.com>,
	Petr Vorel <pvorel@suse.cz>, Joe Perches <joe@perches.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v2 1/5] exfat: Return ENAMETOOLONG consistently for oversized paths
Date: Tue, 26 Jul 2022 10:39:25 +0200	[thread overview]
Message-ID: <20220726083929.1684-2-tiwai@suse.de> (raw)
In-Reply-To: <20220726083929.1684-1-tiwai@suse.de>

LTP has a test for oversized file path renames and it expects the
return value to be ENAMETOOLONG.  However, exfat returns EINVAL
unexpectedly in some cases, hence LTP test fails.  The further
investigation indicated that the problem happens only when iocharset
isn't set to utf8.

The difference comes from that, in the case of utf8,
exfat_utf8_to_utf16() returns the error -ENAMETOOLONG directly and
it's treated as the final error code.  Meanwhile, on other iocharsets,
exfat_nls_to_ucs2() returns the max path size but it sets
NLS_NAME_OVERLEN to lossy flag instead; the caller side checks only
whether lossy flag is set or not, resulting in always -EINVAL
unconditionally.

This patch aligns the return code for both cases by checking the lossy
flag bit and returning ENAMETOOLONG when NLS_NAME_OVERLEN bit is set.

BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1201725
Reviewed-by: Petr Vorel <pvorel@suse.cz>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 fs/exfat/namei.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/exfat/namei.c b/fs/exfat/namei.c
index c6eaf7e9ea74..bcb6445eb3b3 100644
--- a/fs/exfat/namei.c
+++ b/fs/exfat/namei.c
@@ -462,7 +462,7 @@ static int __exfat_resolve_path(struct inode *inode, const unsigned char *path,
 		return namelen; /* return error value */
 
 	if ((lossy && !lookup) || !namelen)
-		return -EINVAL;
+		return (lossy & NLS_NAME_OVERLEN) ? -ENAMETOOLONG : -EINVAL;
 
 	exfat_chain_set(p_dir, ei->start_clu,
 		EXFAT_B_TO_CLU(i_size_read(inode), sbi), ei->flags);
-- 
2.35.3


  reply	other threads:[~2022-07-26  8:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-26  8:39 [PATCH v2 0/5] exfat: Fixes for ENAMETOOLONG error handling Takashi Iwai
2022-07-26  8:39 ` Takashi Iwai [this message]
2022-07-26  8:39 ` [PATCH v2 2/5] exfat: Define NLS_NAME_* as bit flags explicitly Takashi Iwai
2022-07-26  8:39 ` [PATCH v2 3/5] exfat: Expand exfat_err() and co directly to pr_*() macro Takashi Iwai
2022-07-26  8:39 ` [PATCH v2 4/5] exfat: Downgrade ENAMETOOLONG error message to debug messages Takashi Iwai
2022-07-26  8:39 ` [PATCH v2 5/5] exfat: Drop superfluous new line for error messages Takashi Iwai
2022-07-29  3:08 ` [PATCH v2 0/5] exfat: Fixes for ENAMETOOLONG error handling Namjae Jeon

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=20220726083929.1684-2-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=joe@perches.com \
    --cc=linkinjeon@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pvorel@suse.cz \
    --cc=sj1557.seo@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).