From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH] mm: Make sendfile(2) killable Date: Thu, 15 Oct 2015 13:46:44 -0700 Message-ID: <20151015134644.c072dd7ce26a74d8daa26a12@linux-foundation.org> References: <1444653923-22111-1-git-send-email-jack@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Al Viro , Dmitry Vyukov To: Jan Kara Return-path: Received: from mail.linuxfoundation.org ([140.211.169.12]:59055 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752221AbbJOUqp (ORCPT ); Thu, 15 Oct 2015 16:46:45 -0400 In-Reply-To: <1444653923-22111-1-git-send-email-jack@suse.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, 12 Oct 2015 14:45:23 +0200 Jan Kara 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?