An error occurred fetching the project authors.
  1. 10 Nov, 2023 1 commit
  2. 09 Nov, 2023 6 commits
  3. 02 Nov, 2023 1 commit
    • Shyam Prasad N's avatar
      cifs: do not reset chan_max if multichannel is not supported at mount · 6e5e64c9
      Shyam Prasad N authored
      If the mount command has specified multichannel as a mount option,
      but multichannel is found to be unsupported by the server at the time
      of mount, we set chan_max to 1. Which means that the user needs to
      remount the share if the server starts supporting multichannel.
      
      This change removes this reset. What it means is that if the user
      specified multichannel or max_channels during mount, and at this
      time, multichannel is not supported, but the server starts supporting
      it at a later point, the client will be capable of scaling out the
      number of channels.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarShyam Prasad N <sprasad@microsoft.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      6e5e64c9
  4. 23 Oct, 2023 1 commit
  5. 30 Aug, 2023 1 commit
  6. 20 Aug, 2023 1 commit
  7. 25 Jul, 2023 1 commit
  8. 24 May, 2023 1 commit
  9. 02 May, 2023 1 commit
  10. 20 Feb, 2023 1 commit
  11. 11 Jan, 2023 1 commit
  12. 05 Jan, 2023 1 commit
  13. 19 Nov, 2022 1 commit
  14. 18 Oct, 2022 1 commit
  15. 15 Oct, 2022 1 commit
  16. 13 Oct, 2022 1 commit
    • Enzo Matsumiya's avatar
      cifs: use ALIGN() and round_up() macros · d7173623
      Enzo Matsumiya authored
      Improve code readability by using existing macros:
      
      Replace hardcoded alignment computations (e.g. (len + 7) & ~0x7) by
      ALIGN()/IS_ALIGNED() macros.
      
      Also replace (DIV_ROUND_UP(len, 8) * 8) with ALIGN(len, 8), which, if
      not optimized by the compiler, has the overhead of a multiplication
      and a division. Do the same for roundup() by replacing it by round_up()
      (division-less version, but requires the multiple to be a power of 2,
      which is always the case for us).
      
      And remove some unnecessary checks where !IS_ALIGNED() would fit, but
      calling round_up() directly is fine as it's a no-op if the value is
      already aligned.
      Signed-off-by: default avatarEnzo Matsumiya <ematsumiya@suse.de>
      Reviewed-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      d7173623
  17. 08 Oct, 2022 1 commit
  18. 05 Aug, 2022 1 commit
    • Steve French's avatar
      cifs: when insecure legacy is disabled shrink amount of SMB1 code · fb157ed2
      Steve French authored
      Currently much of the smb1 code is built even when
      CONFIG_CIFS_ALLOW_INSECURE_LEGACY is disabled.
      
      Move cifssmb.c to only be compiled when insecure legacy is disabled,
      and move various SMB1/CIFS helper functions to that ifdef.  Some
      functions that were not SMB1/CIFS specific needed to be moved out of
      cifssmb.c
      
      This shrinks cifs.ko by more than 10% which is good - but also will
      help with the eventual movement of the legacy code to a distinct
      module.  Follow on patches can shrink the number of ifdefs by
      code restructuring where smb1 code is wedged in functions that
      should be calling dialect specific helper functions instead,
      and also by moving some functions from file.c/dir.c/inode.c into
      smb1 specific c files.
      Reviewed-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: default avatarPaulo Alcantara (SUSE) <pc@cjr.nz>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      fb157ed2
  19. 12 Jul, 2022 1 commit
  20. 24 Jun, 2022 1 commit
    • Shyam Prasad N's avatar
      cifs: avoid deadlocks while updating iface · 8da33fd1
      Shyam Prasad N authored
      We use cifs_tcp_ses_lock to protect a lot of things.
      Not only does it protect the lists of connections, sessions,
      tree connects, open file lists, etc., we also use it to
      protect some fields in each of it's entries.
      
      In this case, cifs_mark_ses_for_reconnect takes the
      cifs_tcp_ses_lock to traverse the lists, and then calls
      cifs_update_iface. However, that can end up calling
      cifs_put_tcp_session, which picks up the same lock again.
      
      Avoid this by taking a ref for the session, drop the lock,
      and then call update iface.
      
      Also, in cifs_update_iface, avoid nested locking of iface_lock
      and chan_lock, as much as possible. When unavoidable, we need
      to pick iface_lock first.
      Signed-off-by: default avatarShyam Prasad N <sprasad@microsoft.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      8da33fd1
  21. 23 Jun, 2022 2 commits
  22. 18 Jun, 2022 1 commit
  23. 10 Jun, 2022 1 commit
  24. 01 Jun, 2022 1 commit
    • Vincent Whitchurch's avatar
      cifs: fix potential deadlock in direct reclaim · cc391b69
      Vincent Whitchurch authored
      The srv_mutex is used during writeback so cifs should ensure that
      allocations done when that mutex is held are done with GFP_NOFS, to
      avoid having direct reclaim ending up waiting for the same mutex and
      causing a deadlock.  This is detected by lockdep with the splat below:
      
       ======================================================
       WARNING: possible circular locking dependency detected
       5.18.0 #70 Not tainted
       ------------------------------------------------------
       kswapd0/49 is trying to acquire lock:
       ffff8880195782e0 (&tcp_ses->srv_mutex){+.+.}-{3:3}, at: compound_send_recv
      
       but task is already holding lock:
       ffffffffa98e66c0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (fs_reclaim){+.+.}-{0:0}:
              fs_reclaim_acquire
              kmem_cache_alloc_trace
              __request_module
              crypto_alg_mod_lookup
              crypto_alloc_tfm_node
              crypto_alloc_shash
              cifs_alloc_hash
              smb311_crypto_shash_allocate
              smb311_update_preauth_hash
              compound_send_recv
              cifs_send_recv
              SMB2_negotiate
              smb2_negotiate
              cifs_negotiate_protocol
              cifs_get_smb_ses
              cifs_mount
              cifs_smb3_do_mount
              smb3_get_tree
              vfs_get_tree
              path_mount
              __x64_sys_mount
              do_syscall_64
              entry_SYSCALL_64_after_hwframe
      
       -> #0 (&tcp_ses->srv_mutex){+.+.}-{3:3}:
              __lock_acquire
              lock_acquire
              __mutex_lock
              mutex_lock_nested
              compound_send_recv
              cifs_send_recv
              SMB2_write
              smb2_sync_write
              cifs_write
              cifs_writepage_locked
              cifs_writepage
              shrink_page_list
              shrink_lruvec
              shrink_node
              balance_pgdat
              kswapd
              kthread
              ret_from_fork
      
       other info that might help us debug this:
      
        Possible unsafe locking scenario:
      
              CPU0                    CPU1
              ----                    ----
         lock(fs_reclaim);
                                      lock(&tcp_ses->srv_mutex);
                                      lock(fs_reclaim);
         lock(&tcp_ses->srv_mutex);
      
        *** DEADLOCK ***
      
       1 lock held by kswapd0/49:
        #0: ffffffffa98e66c0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat
      
       stack backtrace:
       CPU: 2 PID: 49 Comm: kswapd0 Not tainted 5.18.0 #70
       Call Trace:
        <TASK>
        dump_stack_lvl
        dump_stack
        print_circular_bug.cold
        check_noncircular
        __lock_acquire
        lock_acquire
        __mutex_lock
        mutex_lock_nested
        compound_send_recv
        cifs_send_recv
        SMB2_write
        smb2_sync_write
        cifs_write
        cifs_writepage_locked
        cifs_writepage
        shrink_page_list
        shrink_lruvec
        shrink_node
        balance_pgdat
        kswapd
        kthread
        ret_from_fork
        </TASK>
      
      Fix this by using the memalloc_nofs_save/restore APIs around the places
      where the srv_mutex is held.  Do this in a wrapper function for the
      lock/unlock of the srv_mutex, and rename the srv_mutex to avoid missing
      call sites in the conversion.
      
      Note that there is another lockdep warning involving internal crypto
      locks, which was masked by this problem and is visible after this fix,
      see the discussion in this thread:
      
       https://lore.kernel.org/all/20220523123755.GA13668@axis.com/
      
      Link: https://lore.kernel.org/r/CANT5p=rqcYfYMVHirqvdnnca4Mo+JQSw5Qu12v=kPfpk5yhhmg@mail.gmail.com/Reported-by: default avatarShyam Prasad N <nspmangalore@gmail.com>
      Suggested-by: default avatarLars Persson <larper@axis.com>
      Reviewed-by: default avatarRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: default avatarEnzo Matsumiya <ematsumiya@suse.de>
      Signed-off-by: default avatarVincent Whitchurch <vincent.whitchurch@axis.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      cc391b69
  25. 25 May, 2022 1 commit
  26. 24 May, 2022 1 commit
  27. 16 Feb, 2022 1 commit
  28. 03 Feb, 2022 1 commit
  29. 20 Jan, 2022 1 commit
    • Steve French's avatar
      smb3: send NTLMSSP version information · 52d00533
      Steve French authored
      For improved debugging it can be helpful to send version information
      as other clients do during NTLMSSP negotiation. See protocol document
      MS-NLMP section 2.2.1.1
      
      Set the major and minor versions based on the kernel version, and the
      BuildNumber based on the internal cifs.ko module version number,
      and following the recommendation in the protocol documentation
      (MS-NLMP section 2.2.10) we set the NTLMRevisionCurrent field to 15.
      Reviewed-by: default avatarShyam Prasad N <sprasad@microsoft.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      52d00533
  30. 19 Jan, 2022 4 commits
  31. 17 Jan, 2022 1 commit