Date: Fri, 5 Jul 2019 10:38:45 -0400 From: Mark Johnston <markj@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: "freebsd-current@FreeBSD.org" <freebsd-current@freebsd.org>, "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: <20190705143845.GA50901@raichu> In-Reply-To: <YTXPR01MB0285E79DFAAE250FD7A7A181DDF50@YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM> References: <YTXPR01MB0285E79DFAAE250FD7A7A181DDF50@YTXPR01MB0285.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 05, 2019 at 12:28:51AM +0000, Rick Macklem wrote: > Hi, > > I have been working on a Linux compatible copy_file_range(2) syscall > (the current code can be found at https://reviews.freebsd.org/D20584). > > One outstanding issue is how it should deal with signals. > Right now, I have vn_start_write() without PCATCH, so that it won't be > interrupted by a signal, but I notice that vn_write() {ie. write syscall } does > have PCATCH on vn_start_write() and so does vn_rdwr() when it is called > without IO_NODELOCKED. > > 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. Couldn't copy_file_range() return the number of bytes copied in this case? (The Linux man page notes that short writes are possible.) I would expect to see the same error handling that we have in dofilewrite(), where certain errnos are squashed. > What do you think the copy_file_range(2) code should do? I'd find it surprising if copy_file_range() isn't interruptible.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190705143845.GA50901>