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 15:33:44 -0500 [thread overview]
Message-ID: <1341606824.2214.14.camel@iscandar.digidescorp.com> (raw)
In-Reply-To: <87pq8bokcp.fsf@devron.myhome.or.jp>
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.
Steve
next prev parent reply other threads:[~2012-07-06 20:33 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 [this message]
2012-07-06 21:07 ` OGAWA Hirofumi
2012-07-07 1:16 ` Steven J. Magnani
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=1341606824.2214.14.camel@iscandar.digidescorp.com \
--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
Powered by JetHome