01 Oct, 2006

1 commit


27 Sep, 2006

2 commits

  • This eliminates the i_blksize field from struct inode. Filesystems that want
    to provide a per-inode st_blksize can do so by providing their own getattr
    routine instead of using the generic_fillattr() function.

    Note that some filesystems were providing pretty much random (and incorrect)
    values for i_blksize.

    [bunk@stusta.de: cleanup]
    [akpm@osdl.org: generic_fillattr() fix]
    Signed-off-by: "Theodore Ts'o"
    Signed-off-by: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Theodore Ts'o
     
  • * Removing useless casts
    * Removing useless wrapper
    * Conversion from kmalloc+memset to kzalloc

    Signed-off-by: Panagiotis Issaris
    Acked-by: Dave Kleikamp
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Panagiotis Issaris
     

27 Mar, 2006

1 commit


24 Mar, 2006

2 commits


23 Mar, 2006

1 commit


24 Feb, 2006

1 commit


04 Oct, 2005

4 commits


23 Sep, 2005

1 commit


09 Sep, 2005

1 commit


08 Sep, 2005

1 commit


16 Aug, 2005

1 commit


27 Jun, 2005

1 commit

  • The situation: VFS inode X on a mounted ntfs volume is dirty. For
    same inode X, the ntfs_inode is dirty and thus corresponding on-disk
    inode, i.e. mft record, which is in a dirty PAGE_CACHE_PAGE belonging
    to the table of inodes, i.e. $MFT, inode 0.
    What happens:
    Process 1: sys_sync()/umount()/whatever... calls
    __sync_single_inode() for $MFT -> do_writepages() -> write_page for
    the dirty page containing the on-disk inode X, the page is now locked
    -> ntfs_write_mst_block() which clears PageUptodate() on the page to
    prevent anyone else getting hold of it whilst it does the write out.
    This is necessary as the on-disk inode needs "fixups" applied before
    the write to disk which are removed again after the write and
    PageUptodate is then set again. It then analyses the page looking
    for dirty on-disk inodes and when it finds one it calls
    ntfs_may_write_mft_record() to see if it is safe to write this
    on-disk inode. This then calls ilookup5() to check if the
    corresponding VFS inode is in icache(). This in turn calls ifind()
    which waits on the inode lock via wait_on_inode whilst holding the
    global inode_lock.
    Process 2: pdflush results in a call to __sync_single_inode for the
    same VFS inode X on the ntfs volume. This locks the inode (I_LOCK)
    then calls write-inode -> ntfs_write_inode -> map_mft_record() ->
    read_cache_page() for the page (in page cache of table of inodes
    $MFT, inode 0) containing the on-disk inode. This page has
    PageUptodate() clear because of Process 1 (see above) so
    read_cache_page() blocks when it tries to take the page lock for the
    page so it can call ntfs_read_page().
    Thus Process 1 is holding the page lock on the page containing the
    on-disk inode X and it is waiting on the inode X to be unlocked in
    ifind() so it can write the page out and then unlock the page.
    And Process 2 is holding the inode lock on inode X and is waiting for
    the page to be unlocked so it can call ntfs_readpage() or discover
    that Process 1 set PageUptodate() again and use the page.
    Thus we have a deadlock due to ifind() waiting on the inode lock.
    The solution: The fix is to use the newly introduced
    ilookup5_nowait() which does not wait on the inode's lock and hence
    avoids the deadlock. This is safe as we do not care about the VFS
    inode and only use the fact that it is in the VFS inode cache and the
    fact that the vfs and ntfs inodes are one struct in memory to find
    the ntfs inode in memory if present. Also, the ntfs inode has its
    own locking so it does not matter if the vfs inode is locked.

    Signed-off-by: Anton Altaparmakov

    Anton Altaparmakov
     

26 Jun, 2005

1 commit


05 May, 2005

5 commits


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds