[regression 6.1.80+] "CIFS: VFS: directory entry name would overflow frame end of buf" and invisible files under certain conditions and at least with noserverino mount option
Hi Paulo, hi all
In Debian we got two reports of cifs mounts not functioning, hiding certain files. The two reports are:
https://bugs.debian.org/1069102 https://bugs.debian.org/1069092
On those cases kernel logs error
[ 23.225952] CIFS: VFS: directory entry name would overflow frame end of buf 00000000a44b272c
I do not have yet a minimal reproducing setup, but I was able to reproduce the the issue cerating a simple share (done for simplicity with ksmbd):
[global] ... [poc] path = /srv/data valid users = root read only = no
Within /srv/data create an empty file libfoo:
# touch /srv/data/libfoo
The share is mounted with noserverino (the issue is not reproducible without at least in my case):
mount -t cifs -o noserverino //server/poc /mnt
On each access of /mnt a new error is logged, while not showing the libfoo file:
[ 23.225952] CIFS: VFS: directory entry name would overflow frame end of buf 00000000a44b272c [ 603.494356] CIFS: VFS: directory entry name would overflow frame end of buf 000000001dbf54e1 [ 633.217689] CIFS: VFS: directory entry name would overflow frame end of buf 00000000fb4597c4 [ 642.791862] CIFS: VFS: directory entry name would overflow frame end of buf 0000000023b48528
I have verified that reverting in 6.1.y the commit 0947d0d463d4 ("smb: client: set correct d_type for reparse points under DFS mounts") on top of 6.1.87 fixes the issue.
#regzbot introduced: 0947d0d463d4
I can try to make a clean environment to reproeduce the issue, but I'm not yet there. But the regression is related to 0947d0d463d4 ("smb: client: set correct d_type for reparse points under DFS mounts"). The mentioned commit was as well part of 6.7.7 at least, but I'm not able to reproduce the issue from another client running 6.7,9.
Does that ring some bell?
Regards, Salvatore
Hi Salvatore,
Salvatore Bonaccorso carnil@debian.org writes:
In Debian we got two reports of cifs mounts not functioning, hiding certain files. The two reports are:
https://bugs.debian.org/1069102 https://bugs.debian.org/1069092
On those cases kernel logs error
[ 23.225952] CIFS: VFS: directory entry name would overflow frame end of buf 00000000a44b272c
I couldn't reproduce it. Does the following fix your issue:
diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c index 4c1231496a72..3ee35430595e 100644 --- a/fs/smb/client/smb2pdu.c +++ b/fs/smb/client/smb2pdu.c @@ -5083,7 +5083,7 @@ smb2_parse_query_directory(struct cifs_tcon *tcon, info_buf_size = sizeof(struct smb2_posix_info); break; case SMB_FIND_FILE_FULL_DIRECTORY_INFO: - info_buf_size = sizeof(FILE_FULL_DIRECTORY_INFO); + info_buf_size = sizeof(FILE_FULL_DIRECTORY_INFO) - 1; break; default: cifs_tcon_dbg(VFS, "info level %u isn't supported\n",
If not, please provide network trace and verbose logs.
Thanks.
Hi Paulo,
Thanks a lot for your time on looking into it.
On Wed, Apr 17, 2024 at 07:58:56PM -0300, Paulo Alcantara wrote:
Hi Salvatore,
Salvatore Bonaccorso carnil@debian.org writes:
In Debian we got two reports of cifs mounts not functioning, hiding certain files. The two reports are:
https://bugs.debian.org/1069102 https://bugs.debian.org/1069092
On those cases kernel logs error
[ 23.225952] CIFS: VFS: directory entry name would overflow frame end of buf 00000000a44b272c
I couldn't reproduce it. Does the following fix your issue:
diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c index 4c1231496a72..3ee35430595e 100644 --- a/fs/smb/client/smb2pdu.c +++ b/fs/smb/client/smb2pdu.c @@ -5083,7 +5083,7 @@ smb2_parse_query_directory(struct cifs_tcon *tcon, info_buf_size = sizeof(struct smb2_posix_info); break; case SMB_FIND_FILE_FULL_DIRECTORY_INFO:
info_buf_size = sizeof(FILE_FULL_DIRECTORY_INFO);
info_buf_size = sizeof(FILE_FULL_DIRECTORY_INFO) - 1;If not, please provide network trace and verbose logs.
Yes that appears to fix the issue.
But as you say you are not able to reproduce the issue, I guess we need to try to get it clearly reproducible first to see we face no other fallouts?
Regards, Salvatore
Salvatore Bonaccorso carnil@debian.org writes:
On Wed, Apr 17, 2024 at 07:58:56PM -0300, Paulo Alcantara wrote:
Hi Salvatore,
Salvatore Bonaccorso carnil@debian.org writes:
In Debian we got two reports of cifs mounts not functioning, hiding certain files. The two reports are:
https://bugs.debian.org/1069102 https://bugs.debian.org/1069092
On those cases kernel logs error
[ 23.225952] CIFS: VFS: directory entry name would overflow frame end of buf 00000000a44b272c
I couldn't reproduce it. Does the following fix your issue:
diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c index 4c1231496a72..3ee35430595e 100644 --- a/fs/smb/client/smb2pdu.c +++ b/fs/smb/client/smb2pdu.c @@ -5083,7 +5083,7 @@ smb2_parse_query_directory(struct cifs_tcon *tcon, info_buf_size = sizeof(struct smb2_posix_info); break; case SMB_FIND_FILE_FULL_DIRECTORY_INFO:
info_buf_size = sizeof(FILE_FULL_DIRECTORY_INFO);
info_buf_size = sizeof(FILE_FULL_DIRECTORY_INFO) - 1;If not, please provide network trace and verbose logs.
Yes that appears to fix the issue.
Thanks for quickly testing it. So the above change indicates that we're missing 35235e19b393 ("cifs: Replace remaining 1-element arrays") in v6.1.y.
Can you test it now with 35235e19b393 backported without the above change?
But as you say you are not able to reproduce the issue, I guess we need to try to get it clearly reproducible first to see we face no other fallouts?
I couldn't reproduce it in v6.9-rc4. Forgot to mention it, sorry.
Yes, further testing would be great to make sure we're not missing anything else.
Hi Paulo,
On Thu, Apr 18, 2024 at 10:47:01AM -0300, Paulo Alcantara wrote:
Salvatore Bonaccorso carnil@debian.org writes:
On Wed, Apr 17, 2024 at 07:58:56PM -0300, Paulo Alcantara wrote:
Hi Salvatore,
Salvatore Bonaccorso carnil@debian.org writes:
In Debian we got two reports of cifs mounts not functioning, hiding certain files. The two reports are:
https://bugs.debian.org/1069102 https://bugs.debian.org/1069092
On those cases kernel logs error
[ 23.225952] CIFS: VFS: directory entry name would overflow frame end of buf 00000000a44b272c
I couldn't reproduce it. Does the following fix your issue:
diff --git a/fs/smb/client/smb2pdu.c b/fs/smb/client/smb2pdu.c index 4c1231496a72..3ee35430595e 100644 --- a/fs/smb/client/smb2pdu.c +++ b/fs/smb/client/smb2pdu.c @@ -5083,7 +5083,7 @@ smb2_parse_query_directory(struct cifs_tcon *tcon, info_buf_size = sizeof(struct smb2_posix_info); break; case SMB_FIND_FILE_FULL_DIRECTORY_INFO:
info_buf_size = sizeof(FILE_FULL_DIRECTORY_INFO);
info_buf_size = sizeof(FILE_FULL_DIRECTORY_INFO) - 1;If not, please provide network trace and verbose logs.
Yes that appears to fix the issue.
Thanks for quickly testing it. So the above change indicates that we're missing 35235e19b393 ("cifs: Replace remaining 1-element arrays") in v6.1.y.
Can you test it now with 35235e19b393 backported without the above change?
Done. From the experiment in the avialable setup this seems to indeed fix the issue. The commit can mostly be cherry-picked with one manual whitespace caused fixup.
But as you say you are not able to reproduce the issue, I guess we need to try to get it clearly reproducible first to see we face no other fallouts?
I couldn't reproduce it in v6.9-rc4. Forgot to mention it, sorry.
Ack understand.
Yes, further testing would be great to make sure we're not missing anything else.
I'm still failing to provide you a recipe with a minimal as possible setup, but with the instance I was able to reproduce the issue the regression seems gone with cherry-picking 35235e19b393 ("cifs: Replace remaining 1-element arrays") .
Regards, Salvatore
Salvatore Bonaccorso carnil@debian.org writes:
I'm still failing to provide you a recipe with a minimal as possible setup, but with the instance I was able to reproduce the issue the regression seems gone with cherry-picking 35235e19b393 ("cifs: Replace remaining 1-element arrays") .
It's OK, no problem. Could you please provide the backport to stable team?
Hi Paulo,
On Mon, Apr 22, 2024 at 12:08:53PM -0300, Paulo Alcantara wrote:
Salvatore Bonaccorso carnil@debian.org writes:
I'm still failing to provide you a recipe with a minimal as possible setup, but with the instance I was able to reproduce the issue the regression seems gone with cherry-picking 35235e19b393 ("cifs: Replace remaining 1-element arrays") .
It's OK, no problem. Could you please provide the backport to stable team?
Sure, here it is. Greg or Sasha is it ok to pick that up for the 6.1.y queues?
Regards, Salvatore
On Tue, Apr 23, 2024 at 10:58:09PM +0200, Salvatore Bonaccorso wrote:
Hi Paulo,
On Mon, Apr 22, 2024 at 12:08:53PM -0300, Paulo Alcantara wrote:
Salvatore Bonaccorso carnil@debian.org writes:
I'm still failing to provide you a recipe with a minimal as possible setup, but with the instance I was able to reproduce the issue the regression seems gone with cherry-picking 35235e19b393 ("cifs: Replace remaining 1-element arrays") .
It's OK, no problem. Could you please provide the backport to stable team?
Sure, here it is. Greg or Sasha is it ok to pick that up for the 6.1.y queues?
Glad to, for some reason I thought this caused problems, but if it passes your testing, great! I'll go queue it up now, thanks.
greg k-h
Hi,
On Mon, Apr 29, 2024 at 12:50:45PM +0200, Greg KH wrote:
On Tue, Apr 23, 2024 at 10:58:09PM +0200, Salvatore Bonaccorso wrote:
Hi Paulo,
On Mon, Apr 22, 2024 at 12:08:53PM -0300, Paulo Alcantara wrote:
Salvatore Bonaccorso carnil@debian.org writes:
I'm still failing to provide you a recipe with a minimal as possible setup, but with the instance I was able to reproduce the issue the regression seems gone with cherry-picking 35235e19b393 ("cifs: Replace remaining 1-element arrays") .
It's OK, no problem. Could you please provide the backport to stable team?
Sure, here it is. Greg or Sasha is it ok to pick that up for the 6.1.y queues?
Glad to, for some reason I thought this caused problems, but if it passes your testing, great! I'll go queue it up now, thanks.
Thanks! Unfortunately I'm not having a good test(case/suite) for this myself for such cases. All issues recently forwarded as regressions in the 6.1.y series were unfortunately only uncovered by Debian users once we did release the version :(. Hopefully this will "calm down" now.
Thanks to all of you, for your work!
Regards, Salvatore
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Paulo Alcantara -
Salvatore Bonaccorso