03 Mar, 2009

1 commit


28 Feb, 2009

4 commits

  • Commit 8e961870bb9804110d5c8211d5d9d500451c4518 removed the FREEZE/THAW
    handling in xfs_compat_ioctl but never added any compat handler back, so
    now any freeze/thaw request from a 32-bit binary ond 64-bit userspace
    will fail.

    As these ioctls are 32/64-bit compatible two simple COMPATIBLE_IOCTL
    entries in fs/compat_ioctl.c will do the job.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Linus Torvalds

    Christoph Hellwig
     
  • Commit 4ea3ada2955e4519befa98ff55dd62d6dfbd1705 declares d_obtain_alias()
    as EXPORT_SYMBOL_GPL where it's supposed to replace d_alloc_anon which was
    previously declared as EXPORT_SYMBOL and thus available to any loadable
    module.

    This patch reverts that.

    Signed-off-by: Benny Halevy
    Acked-by: Linus Torvalds
    Cc: Christoph Hellwig
    Cc: "J. Bruce Fields"
    Cc: Trond Myklebust
    Acked-by: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Benny Halevy
     
  • In fs/Makefile, ext3 was placed before ext2 so that a root filesystem
    that possessed a journal, it would be mounted as ext3 instead of ext2.
    This was necessary because a cleanly unmounted ext3 filesystem was
    fully backwards compatible with ext2, and could be mounted by ext2 ---
    but it was desirable that it be mounted with ext3 so that the
    journaling would be enabled.

    The ext4 filesystem supports new incompatible features, so there is no
    danger of an ext4 filesystem being mistaken for an ext2 filesystem.
    At that point, the relative ordering of ext4 with respect to ext2
    didn't matter until ext4 gained the ability to mount filesystems
    without a journal starting in 2.6.29-rc1. Now that this is the case,
    given that ext4 is before ext2, it means that root filesystems that
    were using the plain-jane ext2 format are getting mounted using the
    ext4 filesystem driver, which is a change in behavior which could be
    surprising to users.

    It's doubtful that there are that many ext2-only root filesystem users
    that would also have ext4 compiled into the kernel, but to adhere to
    the principle of least surprise, the correct ordering in fs/Makefile
    is ext3, followed by ext2, and finally ext4.

    Signed-off-by: "Theodore Ts'o"

    Theodore Ts'o
     
  • Commit c4be0c1d added error checking to ext4_freeze() when calling
    ext4_commit_super(). Unfortunately the patch failed to remove the
    original call to ext4_commit_super(), with the net result that when
    freezing the filesystem, the superblock gets written twice, the first
    time without error checking.

    Signed-off-by: "Theodore Ts'o"

    Theodore Ts'o
     

27 Feb, 2009

11 commits


26 Feb, 2009

2 commits


25 Feb, 2009

3 commits


24 Feb, 2009

1 commit

  • de_get is called before every proc_get_inode, but corresponding de_put is
    called only when dropping last reference to an inode. This might cause
    something like
    remove_proc_entry: /proc/stats busy, count=14496
    to be printed to the syslog.

    The fix is to call de_put in case of an already initialized inode in
    proc_get_inode.

    Signed-off-by: Krzysztof Sachanowicz
    Tested-by: Marcin Pilipczuk
    Acked-by: Al Viro
    Signed-off-by: Linus Torvalds

    Krzysztof Sachanowicz
     

23 Feb, 2009

1 commit

  • Functions ext4_write_begin() and ext4_da_write_begin() call
    grab_cache_page_write_begin() without AOP_FLAG_NOFS. Thus it
    can happen that page reclaim is triggered in that function
    and it recurses back into the filesystem (or some other filesystem).
    But this can lead to various problems as a transaction is already
    started at that point. Add the necessary flag.

    http://bugzilla.kernel.org/show_bug.cgi?id=11688

    Signed-off-by: Jan Kara
    Signed-off-by: "Theodore Ts'o"

    Jan Kara
     

22 Feb, 2009

2 commits

  • This is a workaround for find_group_flex() which badly needs to be
    replaced. One of its problems (besides ignoring the Orlov algorithm)
    is that it is a bit hyperactive about returning failure under
    suspicious circumstances. This can lead to spurious ENOSPC failures
    even when there are inodes still available.

    Work around this for now by retrying the search using
    find_group_other() if find_group_flex() returns -1. If
    find_group_other() succeeds when find_group_flex() has failed, log a
    warning message.

    A better block/inode allocator that will fix this problem for real has
    been queued up for the next merge window.

    Signed-off-by: "Theodore Ts'o"

    Theodore Ts'o
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6:
    [CIFS] Fix multiuser mounts so server does not invalidate earlier security contexts
    [CIFS] improve posix semantics of file create
    [CIFS] Fix oops in cifs_strfromUCS_le mounting to servers which do not specify their OS
    cifs: posix fill in inode needed by posix open
    cifs: properly handle case where CIFSGetSrvInodeNumber fails
    cifs: refactor new_inode() calls and inode initialization
    [CIFS] Prevent OOPs when mounting with remote prefixpath.
    [CIFS] ipv6_addr_equal for address comparison

    Linus Torvalds
     

21 Feb, 2009

10 commits

  • At scan time we observed following scenario:

    node A inserted
    node B inserted
    node C inserted -> sets overlapped flag on node B

    node A is removed due to CRC failure -> overlapped flag on node B remains

    while (tn->overlapped)
    tn = tn_prev(tn);

    ==> crash, when tn_prev(B) is referenced.

    When the ultimate node is removed at scan time and the overlapped flag
    is set on the penultimate node, then nothing updates the overlapped
    flag of that node. The overlapped iterators blindly expect that the
    ultimate node does not have the overlapped flag set, which causes the
    scan code to crash.

    It would be a huge overhead to go through the node chain on node
    removal and fix up the overlapped flags, so detecting such a case on
    the fly in the overlapped iterators is a simpler and reliable
    solution.

    Cc: stable@kernel.org
    Signed-off-by: Thomas Gleixner
    Signed-off-by: David Woodhouse

    Thomas Gleixner
     
  • When two different users mount the same Windows 2003 Server share using CIFS,
    the first session mounted can be invalidated. Some servers invalidate the first
    smb session when a second similar user (e.g. two users who get mapped by server to "guest")
    authenticates an smb session from the same client.

    By making sure that we set the 2nd and subsequent vc numbers to nonzero values,
    this ensures that we will not have this problem.

    Fixes Samba bug 6004, problem description follows:
    How to reproduce:

    - configure an "open share" (full permissions to Guest user) on Windows 2003
    Server (I couldn't reproduce the problem with Samba server or Windows older
    than 2003)
    - mount the share twice with different users who will be authenticated as guest.

    noacl,noperm,user=john,dir_mode=0700,domain=DOMAIN,rw
    noacl,noperm,user=jeff,dir_mode=0700,domain=DOMAIN,rw

    Result:

    - just the mount point mounted last is accessible:

    Signed-off-by: Steve French

    Steve French
     
  • Samba server added support for a new posix open/create/mkdir operation
    a year or so ago, and we added support to cifs for mkdir to use it,
    but had not added the corresponding code to file create.

    The following patch helps improve the performance of the cifs create
    path (to Samba and servers which support the cifs posix protocol
    extensions). Using Connectathon basic test1, with 2000 files, the
    performance improved about 15%, and also helped reduce network traffic
    (17% fewer SMBs sent over the wire) due to saving a network round trip
    for the SetPathInfo on every file create.

    It should also help the semantics (and probably the performance) of
    write (e.g. when posix byte range locks are on the file) on file
    handles opened with posix create, and adds support for a few flags
    which would have to be ignored otherwise.

    Signed-off-by: Steve French

    Steve French
     
  • Fixes kernel bug #10451 http://bugzilla.kernel.org/show_bug.cgi?id=10451

    Certain NAS appliances do not set the operating system or network operating system
    fields in the session setup response on the wire. cifs was oopsing on the unexpected
    zero length response fields (when trying to null terminate a zero length field).

    This fixes the oops.

    Acked-by: Jeff Layton
    CC: stable
    Signed-off-by: Steve French

    Steve French
     
  • function needed to prepare for posix open

    Signed-off-by: Jeff Layton
    Signed-off-by: Steve French

    Jeff Layton
     
  • ...if it does then we pass a pointer to an unintialized variable for
    the inode number to cifs_new_inode. Have it pass a NULL pointer instead.

    Also tweak the function prototypes to reduce the amount of casting.

    Signed-off-by: Jeff Layton
    Signed-off-by: Steve French

    Jeff Layton
     
  • Move new inode creation into a separate routine and refactor the
    callers to take advantage of it.

    Signed-off-by: Jeff Layton
    Signed-off-by: Steve French

    Jeff Layton
     
  • Fixes OOPs with message 'kernel BUG at fs/cifs/cifs_dfs_ref.c:274!'.
    Checks if the prefixpath in an accesible while we are still in cifs_mount
    and fails with reporting a error if we can't access the prefixpath

    Should fix Samba bugs 6086 and 5861 and kernel bug 12192

    Signed-off-by: Igor Mammedov
    Acked-by: Jeff Layton
    Signed-off-by: Steve French

    Igor Mammedov
     
  • * git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable:
    Btrfs: check file pointer in btrfs_sync_file

    Linus Torvalds
     
  • This is a step in the direction of better -ENOSPC handling. Instead of
    checking the global bytes counter we check the space_info bytes counters to
    make sure we have enough space.

    If we don't we go ahead and try to allocate a new chunk, and then if that fails
    we return -ENOSPC. This patch adds two counters to btrfs_space_info,
    bytes_delalloc and bytes_may_use.

    bytes_delalloc account for extents we've actually setup for delalloc and will
    be allocated at some point down the line.

    bytes_may_use is to keep track of how many bytes we may use for delalloc at
    some point. When we actually set the extent_bit for the delalloc bytes we
    subtract the reserved bytes from the bytes_may_use counter. This keeps us from
    not actually being able to allocate space for any delalloc bytes.

    Signed-off-by: Josef Bacik

    Josef Bacik
     

20 Feb, 2009

5 commits