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