Ilya Dryomov <idryomov@xxxxxxxxx> writes:
> Hi Luis, Jeff,
>
> This is an updated version that fixes the problem with pipe buffers.
> I wasn't able to get "trinity -V /some/dir/in/cephfs -c splice" do it
> for me, but a simple "overflow the pipe" test now passes.
>
> I believe this is ready for merging. Please take a look.
Ok, I can confirm that I no longer see splice trashing the kernel when
running trinity. However, I'm currently investigating a leak reported
by kmemleak. It takes a while to trigger (same testcase: splice syscall
stress with trinity), but I eventually see something like:
unreferenced object 0xffff880061a3b9d8 (size 128):
comm "trinity-c0", pid 303, jiffies 4295049336 (age 5361.756s)
hex dump (first 32 bytes):
89 5a 51 c4 1a 90 82 fa 40 5b 8a 01 00 ea ff ff .ZQ.....@[......
c0 82 93 01 00 ea ff ff 80 71 94 01 00 ea ff ff .........q......
backtrace:
[<000000005a0f2bb8>] ceph_read_iter+0xf8e/0x10b0
[<00000000a8278adb>] generic_file_splice_read+0x21b/0x320
[<000000004fcba43d>] __se_sys_splice+0x914/0x9a0
[<00000000276d178b>] do_syscall_64+0xee/0x290
[<00000000f883973e>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[<00000000eab9257f>] 0xffffffffffffffff
It could be a false positive, not sure yet. It may not even been
related with these changes. I'll let you know what I can find.
Cheers,
--
Luis
>
> Thanks,
>
> Ilya
>
>
> Ilya Dryomov (2):
> libceph: add osd_req_op_extent_osd_data_bvecs()
> ceph: fix iov_iter issues in ceph_direct_read_write()
>
> drivers/block/rbd.c | 4 +-
> fs/ceph/file.c | 193 +++++++++++++++++++++++-----------------
> include/linux/ceph/osd_client.h | 12 ++-
> net/ceph/osd_client.c | 27 +++++-
> 4 files changed, 149 insertions(+), 87 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
