netfs.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* Re: 6.14.6: copy from cifs mount never finishes
       [not found] <50815dea489f26cf2c8d34162d8be5f0a7d3465e.camel@sipsolutions.net>
@ 2025-05-21 11:41 ` Johannes Berg
  2025-05-21 18:15   ` Paulo Alcantara
  0 siblings, 1 reply; 2+ messages in thread
From: Johannes Berg @ 2025-05-21 11:41 UTC (permalink / raw)
  To: linux-cifs; +Cc: netfs, David Howells

+netfs, and adding a bit more information



Hi,

So I'm on 6.14.6 on Fedora, trying to copy a few relatively small files.
I went to lunch and when I came back it still wasn't finished, and the
first file was just growing and growing in size ...

The filesystem was mounted with just

# mount.cifs -ouser=<user>,dom=<dom> '\\server\share\some\deep\path' /mnt

The server is some Windows server, I think, our IT runs it. Probably not
Azure since it's an internal IP address.

I also have a pcap now, but I'm not going to post it to the list.


Reproducing it, I see:

$ ls -l /mnt/dmesg_log.txt
-rwxr-xr-x. 1 root root 271261 May 13 13:00 /mnt/dmesg_log.txt
$ strace cp /mnt/dmesg_log.txt /tmp/
execve("/usr/bin/cp", ["cp", "/mnt/dmesg_log.txt", "/tmp/"], 0x7ffcae506680 /* 85 vars */) = 0
...
openat(AT_FDCWD, "/tmp/", O_RDONLY|O_PATH|O_DIRECTORY) = 3
newfstatat(AT_FDCWD, "/mnt/dmesg_log.txt", {st_mode=S_IFREG|0755, st_size=271261, ...}, 0) = 0
newfstatat(3, "dmesg_log.txt", 0x7ffdcacac290, 0) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/mnt/dmesg_log.txt", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0755, st_size=271261, ...}) = 0
openat(3, "dmesg_log.txt", O_WRONLY|O_CREAT|O_EXCL, 0755) = 5
ioctl(5, BTRFS_IOC_CLONE or FICLONE, 4) = -1 EXDEV (Invalid cross-device link)
fstat(5, {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
fadvise64(4, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
uname({sysname="Linux", nodename="jberg1-mobl2.ger.corp.intel.com", ...}) = 0
copy_file_range(4, NULL, 5, NULL, 9223372035781033984, 0) = -1 EXDEV (Invalid cross-device link)
mmap(NULL, 1056768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1d2a6fe000
read(4, "[ 3410.434280] iwlwifi 0000:3d:0"..., 1048576) = 983040

now that's already wrong, the file is only 271261 bytes! That should
have returned 271261, not 983040.

Next that data is written out, nothing special, except when I look at
the data, after offset 271261 it's filled up with zeroes.

write(5, "[ 3410.434280] iwlwifi 0000:3d:0"..., 983040) = 983040


It gets worse from here though, because now even the next read doesn't
return 0 for EOF:

read(4, "[ 3410.434280] iwlwifi 0000:3d:0"..., 1048576) = 983040
write(5, "[ 3410.434280] iwlwifi 0000:3d:0"..., 983040) = 983040


And that just repeats forever.


johannes


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: 6.14.6: copy from cifs mount never finishes
  2025-05-21 11:41 ` 6.14.6: copy from cifs mount never finishes Johannes Berg
@ 2025-05-21 18:15   ` Paulo Alcantara
  0 siblings, 0 replies; 2+ messages in thread
From: Paulo Alcantara @ 2025-05-21 18:15 UTC (permalink / raw)
  To: Johannes Berg, linux-cifs; +Cc: netfs, David Howells

Johannes Berg <johannes@sipsolutions.net> writes:

> So I'm on 6.14.6 on Fedora, trying to copy a few relatively small files.
> I went to lunch and when I came back it still wasn't finished, and the
> first file was just growing and growing in size ...
>
> The filesystem was mounted with just
>
> # mount.cifs -ouser=<user>,dom=<dom> '\\server\share\some\deep\path' /mnt
>
> The server is some Windows server, I think, our IT runs it. Probably not
> Azure since it's an internal IP address.
>
> I also have a pcap now, but I'm not going to post it to the list.
>
>
> Reproducing it, I see:
>
> $ ls -l /mnt/dmesg_log.txt
> -rwxr-xr-x. 1 root root 271261 May 13 13:00 /mnt/dmesg_log.txt
> $ strace cp /mnt/dmesg_log.txt /tmp/
> execve("/usr/bin/cp", ["cp", "/mnt/dmesg_log.txt", "/tmp/"], 0x7ffcae506680 /* 85 vars */) = 0
> ...
> openat(AT_FDCWD, "/tmp/", O_RDONLY|O_PATH|O_DIRECTORY) = 3
> newfstatat(AT_FDCWD, "/mnt/dmesg_log.txt", {st_mode=S_IFREG|0755, st_size=271261, ...}, 0) = 0
> newfstatat(3, "dmesg_log.txt", 0x7ffdcacac290, 0) = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/mnt/dmesg_log.txt", O_RDONLY) = 4
> fstat(4, {st_mode=S_IFREG|0755, st_size=271261, ...}) = 0
> openat(3, "dmesg_log.txt", O_WRONLY|O_CREAT|O_EXCL, 0755) = 5
> ioctl(5, BTRFS_IOC_CLONE or FICLONE, 4) = -1 EXDEV (Invalid cross-device link)
> fstat(5, {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
> fadvise64(4, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
> uname({sysname="Linux", nodename="jberg1-mobl2.ger.corp.intel.com", ...}) = 0
> copy_file_range(4, NULL, 5, NULL, 9223372035781033984, 0) = -1 EXDEV (Invalid cross-device link)
> mmap(NULL, 1056768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1d2a6fe000
> read(4, "[ 3410.434280] iwlwifi 0000:3d:0"..., 1048576) = 983040
>
> now that's already wrong, the file is only 271261 bytes! That should
> have returned 271261, not 983040.
>
> Next that data is written out, nothing special, except when I look at
> the data, after offset 271261 it's filled up with zeroes.
>
> write(5, "[ 3410.434280] iwlwifi 0000:3d:0"..., 983040) = 983040
>
>
> It gets worse from here though, because now even the next read doesn't
> return 0 for EOF:
>
> read(4, "[ 3410.434280] iwlwifi 0000:3d:0"..., 1048576) = 983040
> write(5, "[ 3410.434280] iwlwifi 0000:3d:0"..., 983040) = 983040
>
>
> And that just repeats forever.

As we've talked, this should be fixed by

        34eb98c6598c ("netfs: Fix setting of transferred bytes with short DIO reads") [1]

I'll make sure to get it through -stable once released.

Thanks.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git #vfs-6.16.netfs

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2025-05-21 18:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <50815dea489f26cf2c8d34162d8be5f0a7d3465e.camel@sipsolutions.net>
2025-05-21 11:41 ` 6.14.6: copy from cifs mount never finishes Johannes Berg
2025-05-21 18:15   ` Paulo Alcantara

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).