Date: Fri, 5 Jul 2019 15:59:41 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Hans Petter Selasky <hps@selasky.org>, "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Cc: "kib@freebsd.org" <kib@FreeBSD.org>, Alan Somers <asomers@freebsd.org> Subject: Re: should a copy_file_range(2) syscall be interrupted via a signal Message-ID: <YTXPR01MB028590BD5EB6D4CCE785133BDDF50@YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <8c7707d7-f315-d613-705f-40b1619a7553@selasky.org> References: <YTXPR01MB0285E79DFAAE250FD7A7A181DDF50@YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM>, <8c7707d7-f315-d613-705f-40b1619a7553@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hans Petter Selasky wrote: >On 2019-07-05 02:28, Rick Macklem wrote: >> I am thinking that copy_file_range(2) should do this also. >> However, if it returns an error, it is impossible for the caller to know= how much >> of the data range got copied. > >How can you kill a program stuck on copy_file_range(2) w/o catching signal= s? Well, if "stuck" means sleeping somewhere inside the VOP_WRITE() call for the file system, I think it is "stuck" forever, just like write(2), isn't i= t? For NFS, the "intr" option might allow write(2) to return EINTR, but it oft= en takes a forced dismount (actually "umount -N") to get it "unstuck". However, I think for the case where the signal is detected outside of VOP_READ()/VOP_WRITE() in the copy loop, it does make sense to terminate it and I think the suggestion of returning "bytes copied" instead of EINTR = is a good one. rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTXPR01MB028590BD5EB6D4CCE785133BDDF50>