From: Christoph Hellwig <hch@lst.de>
To: Jan Kara <jack@suse.cz>
Cc: Nick Piggin <npiggin@suse.de>, Christoph Hellwig <hch@lst.de>,
viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org,
mfasheh@suse.de
Subject: Re: [PATCH 2/2] check ATTR_SIZE contraints in inode_change_ok
Date: Wed, 9 Jun 2010 12:07:15 +0200 [thread overview]
Message-ID: <20100609100715.GA15837@lst.de> (raw)
In-Reply-To: <20100609094121.GC3393@quack.suse.cz>
On Wed, Jun 09, 2010 at 11:41:21AM +0200, Jan Kara wrote:
> That's a good point. For all local filesystems I know, holding i_mutex is
> enough for having stable i_size. But for clustered filesystems it
> definitely isn't. They have to hold cluster locks to be able to reliably
> check current i_size (at least OCFS2 does). Looking at what
> inode_newsize_ok currently does, i_size is only used to decide whether
> we need to check for rlimit or not. So we could falsely miss this
> check (other node is truncating the file below new offset)... Hmm, OK, so
> we really need the cluster lock...
> BTW: Mark, don't we need the cluster lock also for the permission
> checks in inode_change_ok? Otherwise we could see:
Yes, we should have it for all of the checks. It would be good if
the cluster folks came up with proper patches for vfs.git #for-next
to fix up the cluster locking for all of ->setattr.
next prev parent reply other threads:[~2010-06-09 10:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-01 11:39 [PATCH 0/2] new truncate sequence, part3 Christoph Hellwig
2010-06-01 11:39 ` [PATCH 1/2] always call inode_change_ok early in ->setattr Christoph Hellwig
2010-06-01 11:39 ` [PATCH 2/2] check ATTR_SIZE contraints in inode_change_ok Christoph Hellwig
2010-06-01 11:49 ` Steven Whitehouse
2010-06-01 11:47 ` Christoph Hellwig
2010-06-09 7:33 ` Nick Piggin
2010-06-09 9:41 ` Jan Kara
2010-06-09 10:06 ` Nick Piggin
2010-06-09 10:07 ` Christoph Hellwig [this message]
2010-06-09 10:26 ` Nick Piggin
2010-06-10 8:21 ` Christoph Hellwig
2010-06-09 10:59 ` Steven Whitehouse
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=20100609100715.GA15837@lst.de \
--to=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=mfasheh@suse.de \
--cc=npiggin@suse.de \
--cc=viro@zeniv.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.