Received: by 2002:ac0:e34a:0:0:0:0:0 with SMTP id g10csp511577imn; Tue, 26 Jul 2022 01:52:10 -0700 (PDT) X-Google-Smtp-Source: AGRyM1t0LZeJNbCFnEvIsggah6kAZvDpUINOaJkefa2Gsq6kDuoPYQdon9N7Q8eW7J8kRj1SFTJs X-Received: by 2002:a05:6402:4390:b0:43b:e9d9:f9e4 with SMTP id o16-20020a056402439000b0043be9d9f9e4mr11773102edc.361.1658825530467; Tue, 26 Jul 2022 01:52:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658825530; cv=none; d=google.com; s=arc-20160816; b=p3aoiZ12q5nzLONwIW3N2fuwCY2iukxDI+F3Eap6EdE1Jn8Te9XLWQv8W7hLim/xNZ Fs7kgR5HSVqi4XgZfu8cSHawDTXh1ZDJHSH7yNLrPkfVUb4I4GB2As6sDeEf1WIloUmD iMwYa7rAztbdjt4fU2CQJQ3ChMAFRF3IQwte+pDFZRUPIvg+c0uDj5CFS0LU6iTsWi8v PD+XxhgIx7/JTqXTN9fQ53d46Qy7Zt3f7zJ7S+CXkdOhmJNuhaP5hKe6yQqw4HbNnC5Z m4kSxSkMO4toXNNpJ496aJ6UYhy0ETN4FmHBhMQJdqs8uY4KesO4mjeVnqdhSTMIHMJ5 nwtA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature:dkim-signature; bh=kL/lM98YkTCIhTGsAnqujPDGu/oeH8wou9/U4d0Lrjo=; b=UXswDufOnrs3JXoGn3TVU0SVxoz5IL82I3YE+pTfsAVo3vbXc8O+eBcy/qnOasq75O SqOJ3LmPM4Ro3kUMyQI70roeRF1Yw8rJy/toygeO6edxHc25ZHkUJD74MW8eSj2VWfZX EKWPws9QGl0dcbB6KRRtbVgQSmr2jPyGAVNMyGzp3vCNt1T5ne/X4iyBboFesEVXx4ou 6G7269uKZNknevFmlEDEgswsEHC/Pnixalstf+26s/9IYNw2lyQCMG7wZGwmsdY7OB+g lU6LMKcHx+YaiGXQFgimd6hL5ugLhN7ukvSq+15DOIehlPXLqTi5QpDPM9ZwIT+1dW2s l/TQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=JPHGtQQK; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id qb27-20020a1709077e9b00b0072f9b440ffbsi16341753ejc.225.2022.07.26.01.51.45; Tue, 26 Jul 2022 01:52:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.de header.s=susede2_rsa header.b=JPHGtQQK; dkim=neutral (no key) header.i=@suse.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=suse.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237254AbiGZIjf (ORCPT + 99 others); Tue, 26 Jul 2022 04:39:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232274AbiGZIje (ORCPT ); Tue, 26 Jul 2022 04:39:34 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 431112F652; Tue, 26 Jul 2022 01:39:33 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id E20841FA79; Tue, 26 Jul 2022 08:39:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1658824771; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kL/lM98YkTCIhTGsAnqujPDGu/oeH8wou9/U4d0Lrjo=; b=JPHGtQQKJNy6JYC5Z1mNzcgTIXIMPRxS91bsUof47IRAaXhVSUVonPN8ZaEGCyUhCogQrE 1fPcZLsq110rghQaCobmr4Rv/0JiUjEZ75Aog1LcAuQsEg2/CIaQXAGxs33eU/c514Dbex FjVXZIKVZ2t936eglcTmgloZjZs932A= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1658824771; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kL/lM98YkTCIhTGsAnqujPDGu/oeH8wou9/U4d0Lrjo=; b=hpe/1nHoIhAsqupO88IpZ1mcyr5MhZeFSjIouX/A5qYflgHqWUQBNm2Ci2UjuUTCzEb6H6 I1v/tp1Bv9mP7VAA== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B698413ADB; Tue, 26 Jul 2022 08:39:31 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id IMzdK0Oo32LYDQAAMHmgww (envelope-from ); Tue, 26 Jul 2022 08:39:31 +0000 From: Takashi Iwai To: linux-fsdevel@vger.kernel.org Cc: Namjae Jeon , Sungjong Seo , Petr Vorel , Joe Perches , 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 Message-Id: <20220726083929.1684-2-tiwai@suse.de> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20220726083929.1684-1-tiwai@suse.de> References: <20220726083929.1684-1-tiwai@suse.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Signed-off-by: Takashi Iwai --- 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