08 Oct, 2011

1 commit


20 Sep, 2011

4 commits

  • Fix sec=ntlmv2/i authentication option during mount of Samba shares.

    cifs client was coding ntlmv2 response incorrectly.
    All that is needed in temp as specified in MS-NLMP seciton 3.3.2

    "Define ComputeResponse(NegFlg, ResponseKeyNT, ResponseKeyLM,
    CHALLENGE_MESSAGE.ServerChallenge, ClientChallenge, Time, ServerName)

    as
    Set temp to ConcatenationOf(Responserversion, HiResponserversion,
    Z(6), Time, ClientChallenge, Z(4), ServerName, Z(4)"

    is MsvAvNbDomainName.

    For sec=ntlmsspi, build_av_pair is not used, a blob is plucked from
    type 2 response sent by the server to use in authentication.

    I tested sec=ntlmv2/i and sec=ntlmssp/i mount options against
    Samba (3.6) and Windows - XP, 2003 Server and 7.
    They all worked.

    Signed-off-by: Shirish Pargaonkar
    Signed-off-by: Steve French

    Shirish Pargaonkar
     
  • Both these options are started with "rw" - that's why the first one
    isn't switched on even if it is specified. Fix this by adding a length
    check for "rw" option check.

    Cc:
    Signed-off-by: Pavel Shilovsky
    Signed-off-by: Steve French

    Steve French
     
  • move it to the beginning of the loop.

    Signed-off-by: Pavel Shilovsky
    Reviewed-by: Jeff Layton
    Signed-off-by: Steve French

    Pavel Shilovsky
     
  • The name_len variable in CIFSFindNext is a signed int that gets set to
    the resume_name_len in the cifs_search_info. The resume_name_len however
    is unsigned and for some infolevels is populated directly from a 32 bit
    value sent by the server.

    If the server sends a very large value for this, then that value could
    look negative when converted to a signed int. That would make that
    value pass the PATH_MAX check later in CIFSFindNext. The name_len would
    then be used as a length value for a memcpy. It would then be treated
    as unsigned again, and the memcpy scribbles over a ton of memory.

    Fix this by making the name_len an unsigned value in CIFSFindNext.

    Cc:
    Reported-by: Darren Lavender
    Signed-off-by: Jeff Layton
    Signed-off-by: Steve French

    Jeff Layton
     

19 Aug, 2011

2 commits


16 Aug, 2011

1 commit

  • Running the cthon tests on a recent kernel caused this message to pop
    occasionally:

    CIFS VFS: did not end path lookup where expected namelen is 0

    Some added debugging showed that namelen and dfsplen were both 0 when
    this occurred. That means that the read_seqretry returned true.

    Assuming that the comment inside the if statement is true, this should
    be harmless and just means that we raced with a rename. If that is the
    case, then there's no need for alarm and we can demote this to cFYI.

    While we're at it, print the dfsplen too so that we can see what
    happened here if the message pops during debugging.

    Cc: stable@kernel.org
    Cc: Al Viro
    Signed-off-by: Jeff Layton
    Signed-off-by: Steve French

    Jeff Layton
     

12 Aug, 2011

2 commits

  • Set security descriptor using path name instead of a file handle.
    We can't be sure that the file handle has adequate permission to
    set a security descriptor (to modify DACL).

    Function set_cifs_acl_by_fid() has been removed since we can't be
    sure how a file was opened for writing, a valid request can fail
    if the file was not opened with two above mentioned permissions.
    We could have opted to add on WRITE_DAC and WRITE_OWNER permissions
    to file opens and then use that file handle but adding addtional
    permissions such as WRITE_DAC and WRITE_OWNER could cause an
    any open to fail.

    And it was incorrect to look for read file handle to set a
    security descriptor anyway.

    Signed-off-by: Shirish Pargaonkar
    Signed-off-by: Steve French

    Shirish Pargaonkar
     
  • Christoph had requested that the stats related code (in
    CONFIG_CIFS_STATS2) be moved into helpers to make code flow more
    readable. This patch should help. For example the following
    section from transport.c

    spin_unlock(&GlobalMid_Lock);
    atomic_inc(&ses->server->num_waiters);
    wait_event(ses->server->request_q,
    atomic_read(&ses->server->inFlight)
    < cifs_max_pending);
    atomic_dec(&ses->server->num_waiters);
    spin_lock(&GlobalMid_Lock);

    becomes simpler (with the patch below):
    spin_unlock(&GlobalMid_Lock);
    cifs_num_waiters_inc(server);
    wait_event(server->request_q,
    atomic_read(&server->inFlight)
    < cifs_max_pending);
    cifs_num_waiters_dec(server);
    spin_lock(&GlobalMid_Lock);

    Reviewed-by: Jeff Layton
    CC: Christoph Hellwig
    Signed-off-by: Steve French
    Reviewed-by: Pavel Shilovsky

    Steve French
     

05 Aug, 2011

2 commits

  • The loop around lookup_one_len doesn't handle the case where it might
    return a negative dentry, which can cause an oops on the next pass
    through the loop. Check for that and break out of the loop with an
    error of -ENOENT if there is one.

    Fixes the panic reported here:

    https://bugzilla.redhat.com/show_bug.cgi?id=727927

    Reported-by: TR Bentley
    Reported-by: Iain Arnell
    Cc: Al Viro
    Cc: stable@kernel.org
    Signed-off-by: Jeff Layton
    Signed-off-by: Steve French

    Jeff Layton
     
  • Regression from 2.6.39...

    The delimiters in the prefixpath are not being converted based on
    whether posix paths are in effect. Fixes:

    https://bugzilla.redhat.com/show_bug.cgi?id=727834

    Reported-and-Tested-by: Iain Arnell
    Reported-by: Patrick Oltmann
    Cc: Pavel Shilovsky
    Cc: stable@kernel.org
    Signed-off-by: Jeff Layton
    Signed-off-by: Steve French

    Jeff Layton
     

04 Aug, 2011

1 commit


03 Aug, 2011

2 commits


01 Aug, 2011

12 commits


27 Jul, 2011

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6:
    cifs: Cleanup: check return codes of crypto api calls
    CIFS: Fix oops while mounting with prefixpath
    [CIFS] Redundant null check after dereference
    cifs: use cifs_dirent in cifs_save_resume_key
    cifs: use cifs_dirent to replace cifs_get_name_from_search_buf
    cifs: introduce cifs_dirent
    cifs: cleanup cifs_filldir

    Linus Torvalds
     

26 Jul, 2011

8 commits


23 Jul, 2011

1 commit

  • * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6: (107 commits)
    vfs: use ERR_CAST for err-ptr tossing in lookup_instantiate_filp
    isofs: Remove global fs lock
    jffs2: fix IN_DELETE_SELF on overwriting rename() killing a directory
    fix IN_DELETE_SELF on overwriting rename() on ramfs et.al.
    mm/truncate.c: fix build for CONFIG_BLOCK not enabled
    fs:update the NOTE of the file_operations structure
    Remove dead code in dget_parent()
    AFS: Fix silly characters in a comment
    switch d_add_ci() to d_splice_alias() in "found negative" case as well
    simplify gfs2_lookup()
    jfs_lookup(): don't bother with . or ..
    get rid of useless dget_parent() in btrfs rename() and link()
    get rid of useless dget_parent() in fs/btrfs/ioctl.c
    fs: push i_mutex and filemap_write_and_wait down into ->fsync() handlers
    drivers: fix up various ->llseek() implementations
    fs: handle SEEK_HOLE/SEEK_DATA properly in all fs's that define their own llseek
    Ext4: handle SEEK_HOLE/SEEK_DATA generically
    Btrfs: implement our own ->llseek
    fs: add SEEK_HOLE and SEEK_DATA flags
    reiserfs: make reiserfs default to barrier=flush
    ...

    Fix up trivial conflicts in fs/xfs/linux-2.6/xfs_super.c due to the new
    shrinker callout for the inode cache, that clashed with the xfs code to
    start the periodic workers later.

    Linus Torvalds
     

21 Jul, 2011

3 commits

  • Signed-off-by: Pavel Shilovsky
    Reviewed-by: Jeff Layton
    Signed-off-by: Steve French

    Pavel Shilovsky
     
  • 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
     
  • This converts everybody to handle SEEK_HOLE/SEEK_DATA properly. In some cases
    we just return -EINVAL, in others we do the normal generic thing, and in others
    we're simply making sure that the properly due-dilligence is done. For example
    in NFS/CIFS we need to make sure the file size is update properly for the
    SEEK_HOLE and SEEK_DATA case, but since it calls the generic llseek stuff itself
    that is all we have to do. Thanks,

    Signed-off-by: Josef Bacik
    Signed-off-by: Al Viro

    Josef Bacik