12 Aug, 2014

1 commit

  • Pull vfs updates from Al Viro:
    "Stuff in here:

    - acct.c fixes and general rework of mnt_pin mechanism. That allows
    to go for delayed-mntput stuff, which will permit mntput() on deep
    stack without worrying about stack overflows - fs shutdown will
    happen on shallow stack. IOW, we can do Eric's umount-on-rmdir
    series without introducing tons of stack overflows on new mntput()
    call chains it introduces.
    - Bruce's d_splice_alias() patches
    - more Miklos' rename() stuff.
    - a couple of regression fixes (stable fodder, in the end of branch)
    and a fix for API idiocy in iov_iter.c.

    There definitely will be another pile, maybe even two. I'd like to
    get Eric's series in this time, but even if we miss it, it'll go right
    in the beginning of for-next in the next cycle - the tricky part of
    prereqs is in this pile"

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (40 commits)
    fix copy_tree() regression
    __generic_file_write_iter(): fix handling of sync error after DIO
    switch iov_iter_get_pages() to passing maximal number of pages
    fs: mark __d_obtain_alias static
    dcache: d_splice_alias should detect loops
    exportfs: update Exporting documentation
    dcache: d_find_alias needn't recheck IS_ROOT && DCACHE_DISCONNECTED
    dcache: remove unused d_find_alias parameter
    dcache: d_obtain_alias callers don't all want DISCONNECTED
    dcache: d_splice_alias should ignore DCACHE_DISCONNECTED
    dcache: d_splice_alias mustn't create directory aliases
    dcache: close d_move race in d_splice_alias
    dcache: move d_splice_alias
    namei: trivial fix to vfs_rename_dir comment
    VFS: allow ->d_manage() to declare -EISDIR in rcu_walk mode.
    cifs: support RENAME_NOREPLACE
    hostfs: support rename flags
    shmem: support RENAME_EXCHANGE
    shmem: support RENAME_NOREPLACE
    btrfs: add RENAME_NOREPLACE
    ...

    Linus Torvalds
     

08 Aug, 2014

1 commit

  • This flag gives CIFS the ability to support its native rename semantics.

    Implementation is simple: just bail out before trying to hack around the
    noreplace semantics.

    Signed-off-by: Miklos Szeredi
    Cc: Steve French
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Al Viro

    Miklos Szeredi
     

02 Aug, 2014

1 commit


13 Jun, 2014

1 commit

  • Pull vfs updates from Al Viro:
    "This the bunch that sat in -next + lock_parent() fix. This is the
    minimal set; there's more pending stuff.

    In particular, I really hope to get acct.c fixes merged this cycle -
    we need that to deal sanely with delayed-mntput stuff. In the next
    pile, hopefully - that series is fairly short and localized
    (kernel/acct.c, fs/super.c and fs/namespace.c). In this pile: more
    iov_iter work. Most of prereqs for ->splice_write with sane locking
    order are there and Kent's dio rewrite would also fit nicely on top of
    this pile"

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (70 commits)
    lock_parent: don't step on stale ->d_parent of all-but-freed one
    kill generic_file_splice_write()
    ceph: switch to iter_file_splice_write()
    shmem: switch to iter_file_splice_write()
    nfs: switch to iter_splice_write_file()
    fs/splice.c: remove unneeded exports
    ocfs2: switch to iter_file_splice_write()
    ->splice_write() via ->write_iter()
    bio_vec-backed iov_iter
    optimize copy_page_{to,from}_iter()
    bury generic_file_aio_{read,write}
    lustre: get rid of messing with iovecs
    ceph: switch to ->write_iter()
    ceph_sync_direct_write: stop poking into iov_iter guts
    ceph_sync_read: stop poking into iov_iter guts
    new helper: copy_page_from_iter()
    fuse: switch to ->write_iter()
    btrfs: switch to ->write_iter()
    ocfs2: switch to ->write_iter()
    xfs: switch to ->write_iter()
    ...

    Linus Torvalds
     

22 May, 2014

4 commits

  • Signed-off-by: Steve French

    Steve French
     
  • The handling of the CIFS_INO_INVALID_MAPPING flag is racy. It's possible
    for two tasks to attempt to revalidate the mapping at the same time. The
    first sees that CIFS_INO_INVALID_MAPPING is set. It clears the flag and
    then calls invalidate_inode_pages2 to start shooting down the pagecache.

    While that's going on, another task checks the flag and sees that it's
    clear. It then ends up trusting the pagecache to satisfy a read when it
    shouldn't.

    Fix this by adding a bitlock to ensure that the clearing of the flag is
    atomic with respect to the actual cache invalidation. Also, move the
    other existing users of cifs_invalidate_mapping to use a new
    cifs_zap_mapping() function that just sets the INVALID_MAPPING bit and
    then uses the standard codepath to handle the invalidation.

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

    Jeff Layton
     
  • Consolidate a bit of code. In a later patch we'll expand this to fix
    some races.

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

    Jeff Layton
     
  • Currently, when the top and bottom 32-bit words are equivalent and the
    host is a 32-bit arch, cifs_uniqueid_to_ino_t returns 0 as the ino_t
    value. All we're doing to hash the value down to 32 bits is xor'ing the
    top and bottom 32-bit words and that obviously results in 0 if they are
    equivalent.

    The kernel doesn't really care if it returns this value, but some
    userland apps (like "ls") will ignore dirents that have a zero d_ino
    value.

    Change this function to use hash_64 to convert this value to a 31 bit
    value and then add 1 to ensure that it doesn't ever return 0. Also,
    there's no need to check the sizeof(ino_t) at runtime so create two
    different cifs_uniqueid_to_ino_t functions based on whether
    BITS_PER_LONG is 64 for not.

    This should fix:

    https://bugzilla.kernel.org/show_bug.cgi?id=19282

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

    Jeff Layton
     

07 May, 2014

2 commits


25 Oct, 2013

1 commit


26 Sep, 2013

1 commit


04 Jul, 2013

1 commit

  • Pull cifs updates from Steve French:
    "Various CIFS/SMB2/SMB3 updates for 3.11. Includes bug fixes - SMB3
    support should be much more stable with key DFS fix and also signing
    possible now (although is more work to do to get SMB3 signing working
    well with multiuser).

    Mounts using the new SMB 3.02 dialect can now be done (specify
    "vers=3.02" on mount) against the most current Microsoft systems.

    Also includes a big cleanup of the cifs/smb2/smb3 authentication code
    from Jeff which fixes some long standing problems with the way allowed
    authentication flavors and signing are configured.

    Some followon patches later in the cycle will clean up allocation of
    structures for the various security mechanisms depending on what
    dialect is chosen (reduces memory usage a little) and to add support
    for the secure negotiate fsctl (for smb3) which prevents downgrade
    attacks."

    * 'for-next' of git://git.samba.org/sfrench/cifs-2.6: (39 commits)
    cifs: fill TRANS2_QUERY_FILE_INFO ByteCount fields
    cifs: fix SMB2 signing enablement in cifs_enable_signing
    [CIFS] Fix build warning
    [CIFS] SMB3 Signing enablement
    [CIFS] Do not set DFS flag on SMB2 open
    [CIFS] fix static checker warning
    cifs: try to handle the MUST SecurityFlags sanely
    When server doesn't provide SecurityBuffer on SMB2Negotiate pick default
    Handle big endianness in NTLM (ntlmv2) authentication
    revalidate directories instiantiated via FIND_* in order to handle DFS referrals
    SMB2 FSCTL and IOCTL worker function
    Charge at least one credit, if server says that it supports multicredit
    Remove typo
    Some missing share flags
    cifs: using strlcpy instead of strncpy
    Update headers to update various SMB3 ioctl definitions
    Update cifs version number
    Add ability to dipslay SMB3 share flags and capabilities for debugging
    Add some missing SMB3 and SMB3.02 flags
    Add SMB3.02 dialect support
    ...

    Linus Torvalds
     

29 Jun, 2013

1 commit


24 Jun, 2013

1 commit


14 Mar, 2013

1 commit

  • cifsFileInfo objects hold references to dentries and it is possible that
    these will still be around in workqueues when VFS decides to kill super
    block during unmount.

    This results in panics like this one:
    BUG: Dentry ffff88001f5e76c0{i=66b4a,n=1M-2} still in use (1) [unmount of cifs cifs]
    ------------[ cut here ]------------
    kernel BUG at fs/dcache.c:943!
    [..]
    Process umount (pid: 1781, threadinfo ffff88003d6e8000, task ffff880035eeaec0)
    [..]
    Call Trace:
    [] shrink_dcache_for_umount+0x33/0x60
    [] generic_shutdown_super+0x2c/0xe0
    [] kill_anon_super+0x16/0x30
    [] cifs_kill_sb+0x1a/0x30 [cifs]
    [] deactivate_locked_super+0x57/0x80
    [] deactivate_super+0x4e/0x70
    [] mntput_no_expire+0xd7/0x130
    [] sys_umount+0x9c/0x3c0
    [] system_call_fastpath+0x16/0x1b

    Fix this by making each cifsFileInfo object hold a reference to cifs
    super block, which implicitly keeps VFS super block around as well.

    Signed-off-by: Mateusz Guzik
    Reviewed-by: Jeff Layton
    Cc:
    Reported-and-Tested-by: Ben Greear
    Signed-off-by: Steve French

    Mateusz Guzik
     

25 Sep, 2012

1 commit


14 Jul, 2012

6 commits


04 May, 2012

1 commit


28 Mar, 2012

1 commit


04 Jan, 2012

3 commits


29 Oct, 2011

1 commit


13 Oct, 2011

1 commit


19 Aug, 2011

1 commit


01 Aug, 2011

1 commit

  • Currently, we take a sb->s_active reference and a cifsFileInfo reference
    when an oplock break workqueue job is queued. This is unnecessary and
    more complicated than it needs to be. Also as Al points out,
    deactivate_super has non-trivial locking implications so it's best to
    avoid that if we can.

    Instead, just cancel any pending oplock breaks for this filehandle
    synchronously in cifsFileInfo_put after taking it off the lists.
    That should ensure that this job doesn't outlive the structures it
    depends on.

    Reported-by: Al Viro
    Signed-off-by: Jeff Layton
    Signed-off-by: Steve French

    Jeff Layton
     

21 Jul, 2011

1 commit

  • Btrfs needs to be able to control how filemap_write_and_wait_range() is called
    in fsync to make it less of a painful operation, so push down taking i_mutex and
    the calling of filemap_write_and_wait() down into the ->fsync() handlers. Some
    file systems can drop taking the i_mutex altogether it seems, like ext3 and
    ocfs2. For correctness sake I just pushed everything down in all cases to make
    sure that we keep the current behavior the same for everybody, and then each
    individual fs maintainer can make up their mind about what to do from there.
    Thanks,

    Acked-by: Jan Kara
    Signed-off-by: Josef Bacik
    Signed-off-by: Al Viro

    Josef Bacik
     

13 Jul, 2011

1 commit


15 Jun, 2011

1 commit


19 May, 2011

5 commits