public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Paolo Ornati <ornati@fastwebnet.it>
Cc: ornati@fastwebnet.it, linux-kernel@vger.kernel.org,
	vs@namesys.com, neilb@suse.de, schwidefsky@de.ibm.com,
	stable@kernel.org
Subject: Re: Unkillable process in last git -- Bisected
Date: Wed, 28 Jun 2006 22:20:36 -0700	[thread overview]
Message-ID: <20060628222036.e4e40bab.akpm@osdl.org> (raw)
In-Reply-To: <20060628203825.47790a10@localhost>

On Wed, 28 Jun 2006 20:38:25 +0200
Paolo Ornati <ornati@fastwebnet.it> wrote:

> After a git-bisect session I've found that reverting the following
> commit fixes the problem.
> 
> Any idea?
> 
> 
> commit 6527c2bdf1f833cc18e8f42bd97973d583e4aa83
> Author: Vladimir V. Saveliev <vs@namesys.com>
> Date:   Tue Jun 27 02:53:57 2006 -0700
> 
>     [PATCH] generic_file_buffered_write(): deadlock on vectored write



From: Andrew Morton <akpm@osdl.org>

The recent generic_file_write() deadlock fix caused
generic_file_buffered_write() to loop inifinitely when presented with a
zero-length iovec segment.  Fix.

Note that this fix deliberately avoids calling ->prepare_write(),
->commit_write() etc with a zero-length write.  This is because I don't trust
all filesystems to get that right.

This is a cautious approach, for 2.6.17.x.  For 2.6.18 we should just go ahead
and call ->prepare_write() and ->commit_write() with the zero length and fix
any broken filesystems.  So I'll make that change once this code is stabilised
and backported into 2.6.17.x.

The reason for preferring to call ->prepare_write() and ->commit_write() with
the zero-length segment: a zero-length segment _should_ be sufficiently
uncommon that this is the correct way of handling it.  We don't want to
optimise for poorly-written userspace at the expense of well-written
userspace.

Cc: "Vladimir V. Saveliev" <vs@namesys.com>
Cc: Neil Brown <neilb@suse.de>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Chris Wright <chrisw@sous-sol.org>
Cc: Greg KH <greg@kroah.com>
Cc: <stable@kernel.org>
Cc: walt <wa1ter@myrealbox.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 mm/filemap.c |    9 ++++++++-
 mm/filemap.h |    4 ++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff -puN mm/filemap.c~generic_file_buffered_write-handle-zero-length-iovec-segments-stable mm/filemap.c
--- a/mm/filemap.c~generic_file_buffered_write-handle-zero-length-iovec-segments-stable
+++ a/mm/filemap.c
@@ -2125,6 +2125,12 @@ generic_file_buffered_write(struct kiocb
 			break;
 		}
 
+		if (unlikely(bytes == 0)) {
+			status = 0;
+			copied = 0;
+			goto zero_length_segment;
+		}
+
 		status = a_ops->prepare_write(file, page, offset, offset+bytes);
 		if (unlikely(status)) {
 			loff_t isize = i_size_read(inode);
@@ -2154,7 +2160,8 @@ generic_file_buffered_write(struct kiocb
 			page_cache_release(page);
 			continue;
 		}
-		if (likely(copied > 0)) {
+zero_length_segment:
+		if (likely(copied >= 0)) {
 			if (!status)
 				status = copied;
 
diff -puN mm/filemap.h~generic_file_buffered_write-handle-zero-length-iovec-segments-stable mm/filemap.h
--- a/mm/filemap.h~generic_file_buffered_write-handle-zero-length-iovec-segments-stable
+++ a/mm/filemap.h
@@ -88,7 +88,7 @@ filemap_set_next_iovec(const struct iove
 	const struct iovec *iov = *iovp;
 	size_t base = *basep;
 
-	while (bytes) {
+	do {
 		int copy = min(bytes, iov->iov_len - base);
 
 		bytes -= copy;
@@ -97,7 +97,7 @@ filemap_set_next_iovec(const struct iove
 			iov++;
 			base = 0;
 		}
-	}
+	} while (bytes);
 	*iovp = iov;
 	*basep = base;
 }
_


  parent reply	other threads:[~2006-06-29  5:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20060628142918.1b2c25c3@localhost>
2006-06-28 12:53 ` Unkillable process in last git -- 100% reproducible Paolo Ornati
2006-06-28 13:09   ` Paolo Ornati
2006-06-28 13:19     ` Paolo Ornati
2006-06-28 18:38       ` Unkillable process in last git -- Bisected Paolo Ornati
2006-06-28 19:06         ` Vladimir V. Saveliev
2006-06-28 20:14           ` Paolo Ornati
2006-06-29  5:20         ` Andrew Morton [this message]
2006-06-29  6:23           ` Paolo Ornati

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060628222036.e4e40bab.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=ornati@fastwebnet.it \
    --cc=schwidefsky@de.ibm.com \
    --cc=stable@kernel.org \
    --cc=vs@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox