linux-kernel - Re: [PATCH 2/2] fat (exportfs): reconnect file handles to evicted inodes/dentries

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: <1341623782.2021.9.camel@iscandar>
Date:	Fri, 06 Jul 2012 20:16:22 -0500
From:	"Steven J. Magnani" <steve@...idescorp.com>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] fat (exportfs): reconnect file handles to evicted
 inodes/dentries

On Sat, 2012-07-07 at 06:07 +0900, OGAWA Hirofumi wrote: 
> "Steven J. Magnani" <steve@...idescorp.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>

--
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/