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]

Message-Id: <20080501170819.bdcb9035.akpm@linux-foundation.org>
Date:	Thu, 1 May 2008 17:08:19 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Erez Zadok <ezk@...sunysb.edu>
Cc:	ezk@...sunysb.edu, 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 Thu, 1 May 2008 19:44:18 -0400
Erez Zadok <ezk@...sunysb.edu> wrote:

> In message <20080501122136.bc2215c9.akpm@...ux-foundation.org>, Andrew Morton writes:
> > On Thu, 1 May 2008 13:18:09 -0400
> > Erez Zadok <ezk@...sunysb.edu> wrote:
> > 
> > > In message <20080430101704.9cbd6384.akpm@...ux-foundation.org>, Andrew Morton writes:
> > > [...[
> > > > Can we avoid having to think?
> > > > 
> > > > void fsstack_copy_inode_size(struct inode *dst, const struct inode *src)
> > > > {
> > > > 	blkcnt_t i_blocks;
> > > > 	loff_t i_size;
> > > > 
> > > > 	i_size = i_size_read(src);
> > > > 	spin_lock_32bit(&src->i_lock);
> > > > 	i_blocks = src->i_blocks;
> > > > 	spin_unlock_32bit(&src->i_lock);
> > > > 
> > > > 	i_size_write(dst, i_size);
> > > > 	spin_lock_32bit(&dst->i_lock)
> > > > 	dst->i_blocks = i_blocks;
> > > > 	spin_unlock_32bit(&dst->i_lock)
> > > > }
> > > 
> > > I can't find spin_[um]lock_32bit anywhere (checkd latest mmotm and linus's
> > > tree).  I therefore assume this was just your way of saying I should:
> > > 
> > > #if BITS_PER_LONG == 32
> > > 	spin_unlock(&dst->i_lock);
> > > #endif
> > 
> > Nope, it was my way of suggesting that you implement it ;)
> > include/linux/spinlock.h would be a good place.
> 
> Sure, I can implement it and submit a patch.  But I've got two questions
> first:
> 
> 1. i_size_read has a tri-state behaviour:
> 
> #if BITS_PER_LONG==32 && defined(CONFIG_SMP)
> 	// play with seqcount
> #elif BITS_PER_LONG==32 && defined(CONFIG_PREEMPT)
> 	// wrap in preempt_disable/enable
> #else
> 	// just return value
> #endif
> 
> Shouldn't the same be done for i_blocks, with matching i_blocks_read(),
> i_blocks_write(), and adding an inode->i_blocks_seqcount field?

I guess so, yes.  Maybe there are other things too.  We just haven't cared
enough to do all this fuss for i_blocks.  Even i_size was a bit marginal.

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.

otoh, many of them _will_ accidentally have i_mutex coverage.  On the
write() path at least.  What happened to that idea?
--
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/