[lkml]   [2008]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [Unionfs] Re: [PATCH -mm] unionfs: build fixes

    On Tue, 2008-07-29 at 21:02 -0400, Erez Zadok wrote:
    > In message <>, Andrew Morton writes:
    > > On Tue, 29 Jul 2008 19:12:47 +0100 (BST)
    > > Hugh Dickins <> wrote:
    > >
    > > > Get unionfs building and working in mmotm with the 2.6.27-rc1 VFS changes:
    > > > permission() has been replaced by inode_permission() without nameidata arg;
    > > > unionfs_permission() without nameidata arg; vfs_symlink() without mode arg;
    > > > LOOKUP_ACCESS no longer defined; and kmem_cache_create() no longer passes
    > > > kmem_cachep to the init_once() constructor.
    > > >
    > > > Note: while okay for inclusion in -mm for now, unionfs_permission() mods
    > > > will need review and perhaps correction by Erez: without a nameidata arg,
    > > > some locking vanishes from unionfs_permission(), and a MNT_NOEXEC check on
    > > > its lower_inode; I have not studied the VFS changes enough to tell whether
    > > > that amounts to a real issue for unionfs, or just removal of dead code.
    > >
    > > thanks.
    > >
    > > > This should follow git-unionfs.patch
    > > > I notice my unionfs-fix-memory-leak.patch
    > > > and fsstack-fsstack_copy_inode_size-locking.patch
    > > > are currently commented out, yet I don't recall the
    > > > mm-commits dispatch rider bringing me a telegram to explain why?
    > >
    > > git-unionfs got commented out because of some upstream git (or build)
    > > catastrophe. So its fixes got comemnted out too. Then git-unionfs was
    > > restored but I forgot to manually restore the followon fixes. It
    > > happens.
    > Shortly I'm going to post fixes which include Hugh's stuff and more. Sorry
    > for the delay.
    > > I must say that I'm not really sure why we're struggling along with
    > > unionfs. Last I heard there were fundamental, unresolveable design
    > > disagreements with the VFS guys. Those issues should be where 100% of
    > > the effort is being devoted, but instead we seem to be cruising along
    > > in a different direction?
    > Some of my upcoming patches begin to address this (took longer than
    > expected):
    > - extracting all whiteout related code into callable methods in unionfs, so
    > that I can "drop in" the new whiteout code that Bharata et al. are
    > reportedly working on. I really hope to see some new whiteout code in -mm
    > soon. Bharata?
    > - reworking the lookup code to handle vfsmounts: this'll be needed when we
    > switch from vfs_* to path_* (Miklos's patches).
    > As for other fundamental issues, I've been posting some suggestions in
    > recent months. For example
    > - the need for cleaner handling of vma->fault(), a relatively minor patch I
    > posted, based on hch's LSF08 suggestions. Got no response from any of the
    > VFS folks.
    > - a post I made regarding suggestions on how to handle lower f/s changes,
    > based on Viro's LSF08 comments: to have a superblock level writers count
    > (I suggested that it's a superset of the superblock->s_vfs_rename_mutex,
    > and perhaps be elevated to be one). Again, got no responses from anyone
    > on the VFS team.

    Erez, do you have links to email threads or a commentary of the things
    that are causing concern somewhere?

    I spotted one but it seems light on for descriptive value (or maybe it's
    me who's light on for understanding, ;)).

    > So I'm not sure how much the VFS guys have time now to review such patches
    > and help me address these issues. We can't seem to get through even simpler
    > issues, nor get simple patches merged (ala the copy_inode_size) despite
    > repeated attempts.

    Yeah, life is like that a lot for me too.

    But why not assume that, given a reasonable amount of time, a "no
    response" is equivalent to a "no complaints" and push on with the
    updates. Sooner or later someone who cares enough will take a look and
    give the needed feedback.


     \ /
      Last update: 2008-08-12 17:45    [W:0.026 / U:6.140 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site