linux-kernel - Re: [2.6.26 PATCH, RESEND]: fs_stack/eCryptfs: fsstack_copy

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]

Date:	Thu, 1 May 2008 23:11:30 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Erez Zadok <ezk@...sunysb.edu>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	viro@...iv.linux.org.uk, hch@...radead.org, mhalcrow@...ibm.com,
	hugh@...itas.com
Subject: Re: [2.6.26 PATCH, RESEND]: fs_stack/eCryptfs: fsstack_copy_*
 updates

On Fri, 2 May 2008 01:58:05 -0400 Erez Zadok <ezk@...sunysb.edu> wrote:

> In message <20080501170819.bdcb9035.akpm@...ux-foundation.org>, Andrew Morton writes:
> > On Thu, 1 May 2008 19:44:18 -0400
> > Erez Zadok <ezk@...sunysb.edu> wrote:
> [...]
> > i_size is much more important because glitches in there can result in
> > incorrect data being returned from read() and things like that.  i_blocks
> > is just a beancounting curiosity.
> > 
> > > 
> > > 2. I've rewritten your suggested code a bit to reduce stack use.  Modulo
> > >    having 32-bit spin_lock/unlock variants, do you see any problem with this
> > >    code below?  My testing of it so far on 32/64-bit SMP/UMP have all
> > >    passed.
> > > 
> > > void fsstack_copy_inode_size(struct inode *dst, struct inode *src)
> > > {
> > > #if BITS_PER_LONG == 32
> > > 	blkcnt_t i_blocks;
> > > 
> > > 	spin_lock(&src->i_lock);
> > > 	i_blocks = src->i_blocks;
> > > 	spin_unlock(&src->i_lock);
> > > 	spin_lock(&dst->i_lock);
> > > 	dst->i_blocks = i_blocks;
> > > 	spin_unlock(&dst->i_lock);
> > > #else
> > > 	dst->i_blocks = src->i_blocks;
> > > #endif
> > > 	i_size_write(dst, i_size_read(src));
> > > }
> > 
> > That looks sane, as long as we don't care about i_size-vs-i_blocks
> > coherency.
> 
> > However I expect that approximately zero of the sites which modify i_blocks
> > are taking i_lock to do so.
> 
> If i_blocks is indeed less important than i_size, then we can live with some
> incoherency b/t i_size and i_blocks, for now.  Nevertheless, I propose
> adding this to linux/fs.h:
> 
> static inline blkcnt_t i_blocks_read(const struct inode *inode)
> {
> #if BITS_PER_LONG == 32
> 	blkcnt_t i_blocks;
> 	spin_lock(&src->i_lock);
> 	i_blocks = src->i_blocks;
> 	spin_unlock(&src->i_lock);
> 	return i_blocks;
> #else
> 	return src->i_blocks;
> #endif
> }

We actually only need the spinlocked version if blkcnt_t is 64-bit.

So #if BITS_PER_LONG == 32 && defined(CONFIG_LSF), plus explanatory comment.

The spinlocked version will be too large for inlining, I expect.

> and a matching i_blocks_write function.

You'll also need i_blocks_mod() for things like

fs/hpfs/dnode.c:        i->i_blocks += 4;

>  We can then gradually convert those
> "unsafe" users of i_blocks to use the new i_blocks_read/write helpers.
> 
> The nice thing about these two helpers is fsstack_copy_inode_size becomes a
> lot cleaner and more elegant:
> 
> void fsstack_copy_inode_size(struct inode *dst, struct inode *src)
> {
> 	i_blocks_write(dst, i_blocks_read(src));
> 	i_size_write(dst, i_size_read(src));
> }
> 
> And, if we ever wanted to ensure coherency b/t i_blocks and i_size, we'll
> need to create helpers that merge the functionality of i_size_read/write and
> i_blocks_read/write.
> 
> What do you think?
> 


--
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/