From: Andrew Morton <akpm@linux-foundation.org>
To: Erez Zadok <ezk@cs.sunysb.edu>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
viro@zeniv.linux.org.uk, hch@infradead.org, mhalcrow@us.ibm.com,
hugh@veritas.com
Subject: Re: [2.6.26 PATCH, RESEND]: fs_stack/eCryptfs: fsstack_copy_* updates
Date: Wed, 30 Apr 2008 10:17:04 -0700 [thread overview]
Message-ID: <20080430101704.9cbd6384.akpm@linux-foundation.org> (raw)
In-Reply-To: <200804210650.m3L6ogJe019566@agora.fsl.cs.sunysb.edu>
On Mon, 21 Apr 2008 02:50:42 -0400
Erez Zadok <ezk@cs.sunysb.edu> wrote:
>
> 1. remove the 3rd arg to fsstack_copy_attr_all. There are no users for it:
> ecryptfs never used the 3rd arg; unionfs stopped using it a long time
> ago. Halcrow ok'ed this patch some time ago.
>
> 2. add necessary locking for 32-bit smp systems in fsstack_copy_inode_size
> (courtesy Hugh Dickins).
>
> 3. minor commenting style changes, and addition of copyrights which were
> missing.
>
> Acked-by: Mike Halcrow <mhalcrow@us.ibm.com>
> Signed-off-by: Erez Zadok <ezk@cs.sunysb.edu>
>
> ...
>
> void fsstack_copy_inode_size(struct inode *dst, const struct inode *src)
> {
> - i_size_write(dst, i_size_read((struct inode *)src));
> +#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
> + spin_lock(&dst->i_lock);
> +#endif
The defined(CONFIG_SMP) is wrong. The spinlock is here to protect
dst->i_blocks, but it can be corrupted via preemption on uniprocessor as
well. So a plain old
#if BITS_PER_LONG == 32
would fix that.
> + i_size_write(dst, i_size_read(src));
> dst->i_blocks = src->i_blocks;
> +#if BITS_PER_LONG == 32 && defined(CONFIG_SMP)
> + spin_unlock(&dst->i_lock);
> +#endif
> }
However, what about src->i_blocks? It is protected by src->i_lock. The
code as you have it here could read transient values.
Furthermore, i_lock is defined as an innermost lock, for protection of
inode internals. But here we're proposing "taking" inode->i_size_seqcount
inside i_lock. Not necessarily a problem, but it broke the old rule.
We're also doing a read_seqlock of a _different_ inode inside this inode's
i_lock. Again, this is not necessarily a problem (but it might be!) but it
adds complexity and needs thought.
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)
}
next prev parent reply other threads:[~2008-04-30 17:28 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-21 6:50 [2.6.26 PATCH, RESEND]: fs_stack/eCryptfs: fsstack_copy_* updates Erez Zadok
2008-04-30 17:17 ` Andrew Morton [this message]
2008-04-30 21:09 ` Erez Zadok
2008-04-30 21:25 ` Andrew Morton
2008-05-01 17:18 ` Erez Zadok
2008-05-01 19:21 ` Andrew Morton
2008-05-01 23:44 ` Erez Zadok
2008-05-02 0:08 ` Andrew Morton
2008-05-02 5:58 ` Erez Zadok
2008-05-02 6:11 ` Andrew Morton
2008-05-12 0:44 ` hooanon05
2008-05-02 13:17 ` Hugh Dickins
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=20080430101704.9cbd6384.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=ezk@cs.sunysb.edu \
--cc=hch@infradead.org \
--cc=hugh@veritas.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhalcrow@us.ibm.com \
--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.