On Mon, 12 Oct 2015 14:45:23 +0200 Jan Kara <jack@xxxxxxxx> wrote:
> Currently a simple program below issues a sendfile(2) system call which
> takes about 62 days to complete in my test KVM instance.
Geeze some people are impatient.
> int fd;
> off_t off = 0;
>
> fd = open("file", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644);
> ftruncate(fd, 2);
> lseek(fd, 0, SEEK_END);
> sendfile(fd, fd, &off, 0xfffffff);
>
> Now you should not ask kernel to do a stupid stuff like copying 256MB in
> 2-byte chunks and call fsync(2) after each chunk but if you do, sysadmin
> should have a way to stop you.
>
> We actually do have a check for fatal_signal_pending() in
> generic_perform_write() which triggers in this path however because we
> always succeed in writing something before the check is done, we return
> value > 0 from generic_perform_write() and thus the information about
> signal gets lost.
ah.
> Fix the problem by doing the signal check before writing anything. That
> way generic_perform_write() returns -EINTR, the error gets propagated up
> and the sendfile loop terminates early.
>
> ...
>
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -2488,6 +2488,11 @@ again:
> break;
> }
>
> + if (fatal_signal_pending(current)) {
> + status = -EINTR;
> + break;
> + }
> +
> status = a_ops->write_begin(file, mapping, pos, bytes, flags,
> &page, &fsdata);
> if (unlikely(status < 0))
> @@ -2525,10 +2530,6 @@ again:
> written += copied;
>
> balance_dirty_pages_ratelimited(mapping);
> - if (fatal_signal_pending(current)) {
> - status = -EINTR;
> - break;
> - }
> } while (iov_iter_count(i));
>
> return written ? written : status;
This won't work, will it? If user hits ^C after we've written a few
pages, `written' is non-zero and the same thing happens?
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
