From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org, jejb@kernel.org
Cc: Justin Forbes <jmforbes@linuxtx.org>,
Zwane Mwaikambo <zwane@arm.linux.org.uk>,
"Theodore Ts'o" <tytso@mit.edu>,
Randy Dunlap <rdunlap@xenotime.net>,
Dave Jones <davej@redhat.com>,
Chuck Wolber <chuckw@quantumlinux.com>,
Chris Wedgwood <reviews@ml.cw.f00f.org>,
Michael Krufky <mkrufky@linuxtv.org>,
Chuck Ebbert <cebbert@redhat.com>,
Domenico Andreoli <cavokz@gmail.com>, Willy Tarreau <w@1wt.eu>,
Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
Jake Edge <jake@lwn.net>, Eugene Teo <eteo@redhat.com>,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
alan@lxorguk.ukuu.org.uk, Jeff Layton <jlayton@redhat.com>,
Steve French <sfrench@us.ibm.com>
Subject: [patch 11/16] cifs: fix O_APPEND on directio mounts
Date: Wed, 3 Sep 2008 10:33:05 -0700 [thread overview]
Message-ID: <20080903173305.GL10429@suse.de> (raw)
In-Reply-To: <20080903173218.GA10429@suse.de>
[-- Attachment #1: cifs-fix-o_append-on-directio-mounts.patch --]
[-- Type: text/plain, Size: 2082 bytes --]
2.6.25-stable review patch. If anyone has any objections, please let us know.
------------------
From: Jeff Layton <jlayton@redhat.com>
commit 838726c4756813576078203eb7e1e219db0da870 upstream
The direct I/O write codepath for CIFS is done through
cifs_user_write(). That function does not currently call
generic_write_checks() so the file position isn't being properly set
when the file is opened with O_APPEND. It's also not doing the other
"normal" checks that should be done for a write call.
The problem is currently that when you open a file with O_APPEND on a
mount with the directio mount option, the file position is set to the
beginning of the file. This makes any subsequent writes clobber the data
in the file starting at the beginning.
This seems to fix the problem in cursory testing. It is, however
important to note that NFS disallows the combination of
(O_DIRECT|O_APPEND). If my understanding is correct, the concern is
races with multiple clients appending to a file clobbering each others'
data. Since the write model for CIFS and NFS is pretty similar in this
regard, CIFS is probably subject to the same sort of races. What's
unclear to me is why this is a particular problem with O_DIRECT and not
with buffered writes...
Regardless, disallowing O_APPEND on an entire mount is probably not
reasonable, so we'll probably just have to deal with it and reevaluate
this flag combination when we get proper support for O_DIRECT. In the
meantime this patch at least fixes the existing problem.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
fs/cifs/file.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -835,6 +835,10 @@ ssize_t cifs_user_write(struct file *fil
return -EBADF;
open_file = (struct cifsFileInfo *) file->private_data;
+ rc = generic_write_checks(file, poffset, &write_size, 0);
+ if (rc)
+ return rc;
+
xid = GetXid();
if (*poffset > file->f_path.dentry->d_inode->i_size)
--
next prev parent reply other threads:[~2008-09-03 17:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080903172849.927077124@mini.kroah.org>
2008-09-03 17:32 ` [patch 00/16] 2.6.25-stable review Greg KH
2008-09-03 17:32 ` [patch 01/16] x86: work around MTRR mask setting Greg KH
2008-09-03 17:32 ` [patch 02/16] USB: cdc-acm: dont unlock acm->mutex on error path Greg KH
2008-09-03 17:32 ` [patch 03/16] sunrpc: fix possible overrun on read of /proc/sys/sunrpc/transports Greg KH
2008-09-03 17:32 ` Greg KH
2008-09-03 17:32 ` [patch 04/16] r8169: balance pci_map / pci_unmap pair Greg KH
2008-09-03 17:32 ` [patch 05/16] nfsd: fix buffer overrun decoding NFSv4 acl Greg KH
2008-09-03 17:32 ` Greg KH
2008-09-03 17:32 ` [patch 06/16] mm: make setup_zone_migrate_reserve() aware of overlapping nodes Greg KH
2008-09-03 17:32 ` [patch 07/16] forcedeth: fix checksum flag Greg KH
2008-09-03 17:32 ` [patch 08/16] fbdefio: add set_page_dirty handler to deferred IO FB Greg KH
2008-09-03 17:33 ` [patch 09/16] crypto: authenc - Avoid using clobbered request pointer Greg KH
2008-09-03 17:33 ` [patch 10/16] cramfs: fix named-pipe handling Greg KH
2008-09-03 17:33 ` Greg KH [this message]
2008-09-03 17:33 ` [patch 12/16] sctp: fix potential panics in the SCTP-AUTH API Greg KH
2008-09-03 17:33 ` [patch 13/16] sctp: add verification checks to SCTP_AUTH_KEY option Greg KH
2008-09-03 17:33 ` [patch 14/16] sctp: correct bounds check in sctp_setsockopt_auth_key Greg KH
2008-09-03 17:33 ` [patch 15/16] sctp: fix random memory dereference with SCTP_HMAC_IDENT option Greg KH
2008-09-03 17:33 ` [patch 16/16] sch_prio: Fix nla_parse_nested_compat() regression Greg KH
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=20080903173305.GL10429@suse.de \
--to=gregkh@suse.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cavokz@gmail.com \
--cc=cebbert@redhat.com \
--cc=chuckw@quantumlinux.com \
--cc=davej@redhat.com \
--cc=eteo@redhat.com \
--cc=jake@lwn.net \
--cc=jejb@kernel.org \
--cc=jlayton@redhat.com \
--cc=jmforbes@linuxtx.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkrufky@linuxtv.org \
--cc=rbranco@la.checkpoint.com \
--cc=rdunlap@xenotime.net \
--cc=reviews@ml.cw.f00f.org \
--cc=sfrench@us.ibm.com \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=w@1wt.eu \
--cc=zwane@arm.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.