All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: hooanon05@yahoo.co.jp, linux-fsdevel@vger.kernel.org,
	ecryptfs-devel@lists.launchpad.net, linux-kernel@vger.kernel.org,
	mhalcrow@us.ibm.com
Subject: Re: [Ecryptfs-devel] [PATCH] ecryptfs: some inode attrs, and a question
Date: Thu, 15 Jan 2009 17:39:08 -0600	[thread overview]
Message-ID: <496FC91C.10806@linux.vnet.ibm.com> (raw)
In-Reply-To: <20090115150332.f72ad0f8.akpm@linux-foundation.org>

[-- Attachment #1: Type: text/plain, Size: 3339 bytes --]

Andrew Morton wrote:
> On Tue, 13 Jan 2009 15:20:21 +0900
> hooanon05@yahoo.co.jp wrote:
> 
>> Here are several fixes for linux-2.6.27/fs/ecryptfs.
>>
>> - The ecryptfs inode holds a reference to the lower inode, but doesn't
>>   increment the reference counter. When a user sets inotify to the
>>   ecryptfs inode, it may live without the corresponding dentry. In this
>>   case the referecen to the lower inode may be broken.
>>   This patch maintains the reference of the lower inode.
>>
>> - follow the VFS unlink sequence in ecryptfs_unlink() which is
>>   inrementing and decrementing the inode->i_count and the reference
>>   counter for the dentry.
>>
>> - maintain the link count and ctime in ecryptfs_rmdir() because a user
>>   may issue fstat(2) later.
>>
>> - remove the unnecessary d_drop()s in ecryptfs_link().
>>
>> And I have experienced a strange behaviour. When ecryptfs gets -ENOSPC
>> from the lower fs, it converts and returns EINVAL to the userspace. Is
>> this an intended behaviour?
>>
> 
> I am puzzled by the current ecryptfs maintenance situation.
> 

http://article.gmane.org/gmane.linux.kernel/768122

The torch has been passed to me.  :)

> I queued this for 2.6.30.  It could be bumped up for 2.6.29 (and even
> backported to 2.6.28 and earlier) with suitable acks from the
> maintainer(?)
> 

The changes to ecryptfs_rmdir() are valid, but not the rest of the patch.

>> ...
>>
>> +	atomic_inc_return(&lower_dentry->d_inode->i_count);
>> +	atomic_inc_return(&lower_inode->i_count);
> 
> atomic_inc() would suffice here, yes?
> 
> From: Andrew Morton <akpm@linux-foundation.org>
> 
> s/atomic_inc_return/atomic_inc/
> 
> Cc: Dave Kleikamp <shaggy@linux.vnet.ibm.com>
> Cc: J. R. Okajima <hooanon05@yahoo.co.jp>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  fs/ecryptfs/inode.c |    2 +-
>  fs/ecryptfs/super.c |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff -puN fs/ecryptfs/inode.c~ecryptfs-some-inode-attr-fixes-fix fs/ecryptfs/inode.c
> --- a/fs/ecryptfs/inode.c~ecryptfs-some-inode-attr-fixes-fix
> +++ a/fs/ecryptfs/inode.c
> @@ -479,7 +479,7 @@ static int ecryptfs_unlink(struct inode 
> 
>  	lower_dir_dentry = lock_parent(lower_dentry);
>  	dget(lower_dentry);
> -	atomic_inc_return(&lower_dentry->d_inode->i_count);
> +	atomic_inc(&lower_dentry->d_inode->i_count);
>  	rc = vfs_unlink(lower_dir_inode, lower_dentry);
>  	dput(lower_dentry);
>  	if (rc) {
> diff -puN fs/ecryptfs/super.c~ecryptfs-some-inode-attr-fixes-fix fs/ecryptfs/super.c
> --- a/fs/ecryptfs/super.c~ecryptfs-some-inode-attr-fixes-fix
> +++ a/fs/ecryptfs/super.c
> @@ -102,7 +102,7 @@ static void ecryptfs_destroy_inode(struc
>   */
>  void ecryptfs_init_inode(struct inode *inode, struct inode *lower_inode)
>  {
> -	atomic_inc_return(&lower_inode->i_count);
> +	atomic_inc(&lower_inode->i_count);
>  	ecryptfs_set_inode_lower(inode, lower_inode);
>  	inode->i_ino = lower_inode->i_ino;
>  	inode->i_version++;
> _
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~ecryptfs-devel
> Post to     : ecryptfs-devel@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ecryptfs-devel
> More help   : https://help.launchpad.net/ListHelp



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]

  reply	other threads:[~2009-01-15 23:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-13  6:20 [PATCH] ecryptfs: some inode attrs, and a question hooanon05
2009-01-13 13:17 ` Dave Kleikamp
2009-01-15 21:51   ` [Ecryptfs-devel] " Tyler Hicks
2009-01-16  7:36     ` hooanon05
2009-01-16 16:59       ` Dave Kleikamp
2009-01-17  6:03         ` hooanon05
2009-01-17 16:42           ` Dave Kleikamp
2009-01-17 17:42             ` hooanon05
2009-01-17 18:11               ` Dave Kleikamp
2009-01-19  2:17                 ` hooanon05
2009-01-19 15:01                   ` Dave Kleikamp
2009-01-19 15:25                     ` hooanon05
2009-01-19 15:30                       ` Dave Kleikamp
2009-01-19 15:35                         ` hooanon05
2009-01-19  2:15               ` hooanon05
2009-01-19  2:15                 ` hooanon05
2009-01-16  8:04     ` hooanon05
2009-01-15 23:03 ` Andrew Morton
2009-01-15 23:39   ` Tyler Hicks [this message]
2009-01-15 23:51     ` [Ecryptfs-devel] " Andrew Morton
2009-01-16  7:42   ` hooanon05
2009-01-16  7:53     ` Andrew Morton

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=496FC91C.10806@linux.vnet.ibm.com \
    --to=tyhicks@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ecryptfs-devel@lists.launchpad.net \
    --cc=hooanon05@yahoo.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhalcrow@us.ibm.com \
    /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.