linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Steven J. Magnani" <steve@digidescorp.com>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] fat (exportfs): reconnect file handles to evicted inodes/dentries
Date: Fri, 06 Jul 2012 20:16:22 -0500	[thread overview]
Message-ID: <1341623782.2021.9.camel@iscandar> (raw)
In-Reply-To: <871ukobntl.fsf@devron.myhome.or.jp>

On Sat, 2012-07-07 at 06:07 +0900, OGAWA Hirofumi wrote: 
> "Steven J. Magnani" <steve@digidescorp.com> writes:
> 
> > On Wed, 2012-07-04 at 20:07 +0900, OGAWA Hirofumi wrote: 
> >> Please don't add new lock_super() usage if it is not necessary. Almost
> >> all of lock_super() just replaced lock_kernel() usage. It rather should
> >> be removed in future.  Probably, this should use inode->i_mutex instead.
> >> 
> >> BTW, the above issue is same with all of directory read.
> >
> > I don't think there's really an alternative here. The cases addressed by
> > this patch all involve walking on-disk structures via
> > unofficial/temporary inodes created from information in the NFS handle
> > (i.e., outside the normal inode creation paths). When this process is
> > successful we end up with "official" connected inodes/dentries, but
> > getting there is really a "bottom up" strategy instead of the usual "top
> > down" approach.
> >
> > Because the "bottom up" method is lacking guarantees that "top down"
> > takes for granted - i.e., that a cluster on disk that's supposed to be a
> > directory actually *is* a directory -  I am adding some defensive code
> > in the next spin of the patch.
> 
> I'm not sure what you meant. Where is the problem? ->get_name()? If so,
> it has parent dentry parameter. What is the wrong if we take
> mutex_lock(parent->d_inode)?

The temporary/"unofficial" inodes are unhashed and thus not visible
outside of the functions using them. They exist only to support access
to directory contents when we can't gain that access via other means
(because we only have "bottom up" information, about an object and
perhaps its parent, in a form that can't be used to look up hashed
inodes/dentries). Hashing them wouldn't help, because they don't have
the correct key (for instance, in the case of a ".." entry).

Am I missing something?

Steve
------------------------------------------------------------------------
Steven J. Magnani               "I claim this network for MARS!
www.digidescorp.com              Earthling, return my space modulator!"

#include <standard.disclaimer>



  reply	other threads:[~2012-07-07  1:16 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-03 19:09 [PATCH 0/2] fat (exportfs): fix NFS file handle decode Steven J. Magnani
2012-07-03 19:09 ` [PATCH 1/2] fat (exportfs): drop ineffective get_parent code Steven J. Magnani
2012-07-04 10:30   ` OGAWA Hirofumi
2012-07-03 19:09 ` [PATCH 2/2] fat (exportfs): reconnect file handles to evicted inodes/dentries Steven J. Magnani
2012-07-04 11:07   ` OGAWA Hirofumi
2012-07-04 18:03     ` Steve Magnani
2012-07-05  3:59       ` OGAWA Hirofumi
2012-07-05 20:03         ` Steven J. Magnani
2012-07-06 20:33     ` Steven J. Magnani
2012-07-06 21:07       ` OGAWA Hirofumi
2012-07-07  1:16         ` Steven J. Magnani [this message]
2012-07-07  6:03           ` OGAWA Hirofumi
2012-07-07 16:41             ` Steven J. Magnani
2012-07-07 17:00               ` OGAWA Hirofumi
2012-07-09 12:03                 ` Steven J. Magnani
2012-07-09 13:43                   ` OGAWA Hirofumi
2012-07-09 14:47                     ` Steven J. Magnani
2012-07-09 16:10                       ` OGAWA Hirofumi
2012-07-09 16:27                         ` Steven J. Magnani
2012-07-09 17:09                           ` Steven J. Magnani
2012-07-09 17:23                             ` Steven J. Magnani
2012-07-09 19:10                             ` OGAWA Hirofumi
2012-07-09 20:26                               ` Steven J. Magnani
2012-07-09 21:34                                 ` OGAWA Hirofumi
2012-07-09 22:03                                   ` Steven J. Magnani
2012-07-09 22:17                                     ` OGAWA Hirofumi

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=1341623782.2021.9.camel@iscandar \
    --to=steve@digidescorp.com \
    --cc=hirofumi@mail.parknet.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).