From: Chris Wright Date: Sat, 22 Jul 2006 16:26:48 +0000 (-0700) Subject: add fix for existing filemap fix X-Git-Tag: v2.6.17.7~6 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=aeac910b666c355494c33191b67743b7b42326c3;p=thirdparty%2Fkernel%2Fstable-queue.git add fix for existing filemap fix --- diff --git a/pending-2.6.17/generic_file_buffered_write-handle-zero-length-iovec-segments.patch b/pending-2.6.17/generic_file_buffered_write-handle-zero-length-iovec-segments.patch new file mode 100644 index 00000000000..ce5a311ed32 --- /dev/null +++ b/pending-2.6.17/generic_file_buffered_write-handle-zero-length-iovec-segments.patch @@ -0,0 +1,89 @@ +From 81b0c8713385ce1b1b9058e916edcf9561ad76d6 Mon Sep 17 00:00:00 2001 +From: Andrew Morton +Date: Thu, 29 Jun 2006 02:24:26 -0700 +Subject: [PATCH] [PATCH] generic_file_buffered_write(): handle zero-length iovec segments + +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" +Cc: Neil Brown +Cc: Martin Schwidefsky +Cc: Chris Wright +Cc: Greg KH +Cc: +Cc: walt +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Chris Wright +--- + mm/filemap.c | 9 ++++++++- + mm/filemap.h | 4 ++-- + 2 files changed, 10 insertions(+), 3 deletions(-) + +diff --git a/mm/filemap.c b/mm/filemap.c +index 4082b3b..648f2c0 100644 +--- a/mm/filemap.c ++++ b/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 --git a/mm/filemap.h b/mm/filemap.h +index 536979f..3f2a343 100644 +--- a/mm/filemap.h ++++ b/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; + } +