linux-kernel - Re: [PATCH v3] ocfs2: Let ocfs2_setattr use new truncate sequence.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100610122833.GF26335@laptop>
Date:	Thu, 10 Jun 2010 22:28:33 +1000
From:	Nick Piggin <npiggin@...e.de>
To:	Tao Ma <tao.ma@...cle.com>
Cc:	Christoph Hellwig <hch@....de>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, Joel Becker <joel.becker@...cle.com>,
	mfasheh@...e.com
Subject: Re: [PATCH v3] ocfs2: Let ocfs2_setattr use new truncate sequence.

On Thu, Jun 10, 2010 at 08:09:36PM +0800, Tao Ma wrote:
> Joel Becker wrote:
> >On Thu, Jun 10, 2010 at 10:27:11AM +0200, Christoph Hellwig wrote:
> >>You just leave the duplicate inode_newsize_ok in, but still have
> >>one as part of inode_change_ok.  See the previous thread - we'll
> >>need to move inode_change_ok to under the cluster locks, both
> >>for the truncate and non-truncate case.
> >
> >	Is your concern that the u/gid checks may be against stale ids?
> So I think we should have one inode_change_ok before the cluster
> lock and another after the cluster lock.
> The first one will save us a lot of cluster lock effort if the user
> pass us the wrong arguments while the later
> one will test again with the refreshed inode info.

If attributes cannot be stale, then do the checks before the cluster
lock and not again. If they can be stale, then the check outside the
cluster lock might give incorrect results so it is not harmless to do
it twice.

If you have a mix of some attributes may be stale, then why not do the
inode_change_ok check inside the lock, and then do some open code checks
for optimization before taking the lock.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/