Originally reported by @cfstras in #18180.
Description of problem:
As mentioned in #18180, linux@296291cd made sendfile(2) killable.
I confirmed sendfile(2) is actually killable on Docker with AUFS and overlayfs.
However, it is not killable on Docker with btrfs.
Note that it is killable on a non-Docker host with btrfs.
docker version:
Client version: 1.6.2
Client API version: 1.18
Go version (client): go1.5.1
Git commit (client): 7c8fca2
OS/Arch (client): linux/amd64
Server version: 1.6.2
Server API version: 1.18
Go version (server): go1.5.1
Git commit (server): 7c8fca2
OS/Arch (server): linux/amd64
docker info:
Containers: 1
Images: 16
Storage Driver: btrfs
Build Version: Btrfs v4.0
Library Version: 101
Execution Driver: native-0.2
Kernel Version: 4.2.0-22-generic
Operating System: Ubuntu 15.10
CPUs: 1
Total Memory: 1.952 GiB
Name: ip-172-31-6-180
ID: FRRJ:2J5Q:UNYM:ZAX6:3AUI:YQCA:J6TB:LRBI:FK4S:4PUK:MBNQ:XLUY
WARNING: No swap limit support
uname -a: Linux ip-172-31-6-180 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu 15.10)
Also reproducible with 3.19.9-42-generic (Ubuntu 15.04), as reported by @cfstras in #18180.
Both of the kernels contains 296291cd.
Environment details (AWS, VirtualBox, physical, etc.):
AWS t2.small, but I don't think it is related to the problem.
How reproducible:
100%
Steps to Reproduce:
- Set up btrfs: https://docs.docker.com/engine/userguide/storagedriver/btrfs-driver/
- In a Docker container, create
sendfile-test.c like this:
#include <fcntl.h>
#include <sys/sendfile.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <unistd.h>
int
main (int ac, char *av[])
{
int fd;
off_t off = 0;
fd = open ("/tmp/sendfile-test-tmp", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644);
ftruncate (fd, 2);
lseek (fd, 0, SEEK_END);
sendfile (fd, fd, &off, 0xfffffff);
return 0;
}(Just copied from torvalds/linux@296291cd, actually we'd better check errno..)
3. Run gcc -o sendfile-test sendfile-test.c
4. Run sendfile-test
5. Try to kill the sendfile-test process by running kill -9 $PID.
You can also use my test18180 to reproduce the bug in just one-line command:
$ docker run -it --rm akihirosuda/test18180
[INFO] Checking whether hitting docker#18180.
[INFO] OK. not hitting docker#18180.
[INFO] Checking whether sendfile(2) is killable.
[INFO] If the container hangs up here, you are still facing the bug that linux@296291cd tried to fix.
-->Hangs up here
Actual Results:
kill itself exits with 0, but sendfile-test is still alive as a normal process (i.e., not a zombie as in #18180).
Expected Results:
sendfile-test should be dead.
Additional info:
Stack trace (/proc/$PID/stack) of sendfile-test:
[<ffffffffc021ea60>] write_all_supers.isra.45+0x960/0xb00 [btrfs]
[<ffffffffc02200f7>] write_ctree_super+0x17/0x20 [btrfs]
[<ffffffffc026b1c7>] btrfs_sync_log+0x897/0xb40 [btrfs]
[<ffffffffc023d0c8>] btrfs_sync_file+0x328/0x360 [btrfs]
[<ffffffff8122fe9b>] vfs_fsync_range+0x4b/0xb0
[<ffffffffc023d307>] btrfs_file_write_iter+0x207/0x510 [btrfs]
[<ffffffff811fca0b>] new_sync_write+0x9b/0xe0
[<ffffffff811fca76>] __vfs_write+0x26/0x40
[<ffffffff811fce13>] __kernel_write+0x53/0xf0
[<ffffffff8122d832>] write_pipe_buf+0x72/0xa0
[<ffffffff8122d349>] __splice_from_pipe+0xf9/0x170
[<ffffffff8122eeee>] splice_from_pipe+0x5e/0x90
[<ffffffff8122ef5d>] default_file_splice_write+0x1d/0x30
[<ffffffff8122cda6>] direct_splice_actor+0x36/0x40
[<ffffffff8122d9d6>] splice_direct_to_actor+0xe6/0x210
[<ffffffff8122db98>] do_splice_direct+0x98/0xd0
[<ffffffff811fddef>] do_sendfile+0x1bf/0x3a0
[<ffffffff811fea2e>] SyS_sendfile64+0x5e/0xb0
[<ffffffff817f02b2>] entry_SYSCALL_64_fastpath+0x16/0x75
[<ffffffffffffffff>] 0xffffffffffffffff
Originally reported by @cfstras in #18180.
Description of problem:
As mentioned in #18180, linux@296291cd made
sendfile(2)killable.I confirmed
sendfile(2)is actually killable on Docker with AUFS and overlayfs.However, it is not killable on Docker with btrfs.
Note that it is killable on a non-Docker host with btrfs.
docker version:docker info:uname -a:Linux ip-172-31-6-180 4.2.0-22-generic #27-Ubuntu SMP Thu Dec 17 22:57:08 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux(Ubuntu 15.10)Also reproducible with 3.19.9-42-generic (Ubuntu 15.04), as reported by @cfstras in #18180.
Both of the kernels contains 296291cd.
Environment details (AWS, VirtualBox, physical, etc.):
AWS t2.small, but I don't think it is related to the problem.
How reproducible:
100%
Steps to Reproduce:
sendfile-test.clike this:(Just copied from torvalds/linux@296291cd, actually we'd better check errno..)
3. Run
gcc -o sendfile-test sendfile-test.c4. Run
sendfile-test5. Try to kill the
sendfile-testprocess by runningkill -9 $PID.You can also use my test18180 to reproduce the bug in just one-line command:
Actual Results:
killitself exits with 0, butsendfile-testis still alive as a normal process (i.e., not a zombie as in #18180).Expected Results:
sendfile-testshould be dead.Additional info:
Stack trace (
/proc/$PID/stack) ofsendfile-test: