1. 06 7月, 2017 2 次提交
  2. 03 7月, 2017 1 次提交
  3. 21 6月, 2017 5 次提交
  4. 13 5月, 2017 4 次提交
  5. 10 5月, 2017 2 次提交
    • S
      Don't delay freeing mids when blocked on slow socket write of request · de1892b8
      Steve French 提交于
      When processing responses, and in particular freeing mids (DeleteMidQEntry),
      which is very important since it also frees the associated buffers (cifs_buf_release),
      we can block a long time if (writes to) socket is slow due to low memory or networking
      issues.
      
      We can block in send (smb request) waiting for memory, and be blocked in processing
      responess (which could free memory if we let it) - since they both grab the
      server->srv_mutex.
      
      In practice, in the DeleteMidQEntry case - there is no reason we need to
      grab the srv_mutex so remove these around DeleteMidQEntry, and it allows
      us to free memory faster.
      Signed-off-by: NSteve French <steve.french@primarydata.com>
      Acked-by: NPavel Shilovsky <pshilov@microsoft.com>
      de1892b8
    • R
      CIFS: silence lockdep splat in cifs_relock_file() · 560d3889
      Rabin Vincent 提交于
      cifs_relock_file() can perform a down_write() on the inode's lock_sem even
      though it was already performed in cifs_strict_readv().  Lockdep complains
      about this.  AFAICS, there is no problem here, and lockdep just needs to be
      told that this nesting is OK.
      
       =============================================
       [ INFO: possible recursive locking detected ]
       4.11.0+ #20 Not tainted
       ---------------------------------------------
       cat/701 is trying to acquire lock:
        (&cifsi->lock_sem){++++.+}, at: cifs_reopen_file+0x7a7/0xc00
      
       but task is already holding lock:
        (&cifsi->lock_sem){++++.+}, at: cifs_strict_readv+0x177/0x310
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock(&cifsi->lock_sem);
         lock(&cifsi->lock_sem);
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
       1 lock held by cat/701:
        #0:  (&cifsi->lock_sem){++++.+}, at: cifs_strict_readv+0x177/0x310
      
       stack backtrace:
       CPU: 0 PID: 701 Comm: cat Not tainted 4.11.0+ #20
       Call Trace:
        dump_stack+0x85/0xc2
        __lock_acquire+0x17dd/0x2260
        ? trace_hardirqs_on_thunk+0x1a/0x1c
        ? preempt_schedule_irq+0x6b/0x80
        lock_acquire+0xcc/0x260
        ? lock_acquire+0xcc/0x260
        ? cifs_reopen_file+0x7a7/0xc00
        down_read+0x2d/0x70
        ? cifs_reopen_file+0x7a7/0xc00
        cifs_reopen_file+0x7a7/0xc00
        ? printk+0x43/0x4b
        cifs_readpage_worker+0x327/0x8a0
        cifs_readpage+0x8c/0x2a0
        generic_file_read_iter+0x692/0xd00
        cifs_strict_readv+0x29f/0x310
        generic_file_splice_read+0x11c/0x1c0
        do_splice_to+0xa5/0xc0
        splice_direct_to_actor+0xfa/0x350
        ? generic_pipe_buf_nosteal+0x10/0x10
        do_splice_direct+0xb5/0xe0
        do_sendfile+0x278/0x3a0
        SyS_sendfile64+0xc4/0xe0
        entry_SYSCALL_64_fastpath+0x1f/0xbe
      Signed-off-by: NRabin Vincent <rabinv@axis.com>
      Acked-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      560d3889
  6. 09 5月, 2017 1 次提交
  7. 05 5月, 2017 1 次提交
  8. 04 5月, 2017 3 次提交
  9. 03 5月, 2017 9 次提交
    • R
      CIFS: fix oplock break deadlocks · 3998e6b8
      Rabin Vincent 提交于
      When the final cifsFileInfo_put() is called from cifsiod and an oplock
      break work is queued, lockdep complains loudly:
      
       =============================================
       [ INFO: possible recursive locking detected ]
       4.11.0+ #21 Not tainted
       ---------------------------------------------
       kworker/0:2/78 is trying to acquire lock:
        ("cifsiod"){++++.+}, at: flush_work+0x215/0x350
      
       but task is already holding lock:
        ("cifsiod"){++++.+}, at: process_one_work+0x255/0x8e0
      
       other info that might help us debug this:
        Possible unsafe locking scenario:
      
              CPU0
              ----
         lock("cifsiod");
         lock("cifsiod");
      
        *** DEADLOCK ***
      
        May be due to missing lock nesting notation
      
       2 locks held by kworker/0:2/78:
        #0:  ("cifsiod"){++++.+}, at: process_one_work+0x255/0x8e0
        #1:  ((&wdata->work)){+.+...}, at: process_one_work+0x255/0x8e0
      
       stack backtrace:
       CPU: 0 PID: 78 Comm: kworker/0:2 Not tainted 4.11.0+ #21
       Workqueue: cifsiod cifs_writev_complete
       Call Trace:
        dump_stack+0x85/0xc2
        __lock_acquire+0x17dd/0x2260
        ? match_held_lock+0x20/0x2b0
        ? trace_hardirqs_off_caller+0x86/0x130
        ? mark_lock+0xa6/0x920
        lock_acquire+0xcc/0x260
        ? lock_acquire+0xcc/0x260
        ? flush_work+0x215/0x350
        flush_work+0x236/0x350
        ? flush_work+0x215/0x350
        ? destroy_worker+0x170/0x170
        __cancel_work_timer+0x17d/0x210
        ? ___preempt_schedule+0x16/0x18
        cancel_work_sync+0x10/0x20
        cifsFileInfo_put+0x338/0x7f0
        cifs_writedata_release+0x2a/0x40
        ? cifs_writedata_release+0x2a/0x40
        cifs_writev_complete+0x29d/0x850
        ? preempt_count_sub+0x18/0xd0
        process_one_work+0x304/0x8e0
        worker_thread+0x9b/0x6a0
        kthread+0x1b2/0x200
        ? process_one_work+0x8e0/0x8e0
        ? kthread_create_on_node+0x40/0x40
        ret_from_fork+0x31/0x40
      
      This is a real warning.  Since the oplock is queued on the same
      workqueue this can deadlock if there is only one worker thread active
      for the workqueue (which will be the case during memory pressure when
      the rescuer thread is handling it).
      
      Furthermore, there is at least one other kind of hang possible due to
      the oplock break handling if there is only worker.  (This can be
      reproduced without introducing memory pressure by having passing 1 for
      the max_active parameter of cifsiod.) cifs_oplock_break() can wait
      indefintely in the filemap_fdatawait() while the cifs_writev_complete()
      work is blocked:
      
       sysrq: SysRq : Show Blocked State
         task                        PC stack   pid father
       kworker/0:1     D    0    16      2 0x00000000
       Workqueue: cifsiod cifs_oplock_break
       Call Trace:
        __schedule+0x562/0xf40
        ? mark_held_locks+0x4a/0xb0
        schedule+0x57/0xe0
        io_schedule+0x21/0x50
        wait_on_page_bit+0x143/0x190
        ? add_to_page_cache_lru+0x150/0x150
        __filemap_fdatawait_range+0x134/0x190
        ? do_writepages+0x51/0x70
        filemap_fdatawait_range+0x14/0x30
        filemap_fdatawait+0x3b/0x40
        cifs_oplock_break+0x651/0x710
        ? preempt_count_sub+0x18/0xd0
        process_one_work+0x304/0x8e0
        worker_thread+0x9b/0x6a0
        kthread+0x1b2/0x200
        ? process_one_work+0x8e0/0x8e0
        ? kthread_create_on_node+0x40/0x40
        ret_from_fork+0x31/0x40
       dd              D    0   683    171 0x00000000
       Call Trace:
        __schedule+0x562/0xf40
        ? mark_held_locks+0x29/0xb0
        schedule+0x57/0xe0
        io_schedule+0x21/0x50
        wait_on_page_bit+0x143/0x190
        ? add_to_page_cache_lru+0x150/0x150
        __filemap_fdatawait_range+0x134/0x190
        ? do_writepages+0x51/0x70
        filemap_fdatawait_range+0x14/0x30
        filemap_fdatawait+0x3b/0x40
        filemap_write_and_wait+0x4e/0x70
        cifs_flush+0x6a/0xb0
        filp_close+0x52/0xa0
        __close_fd+0xdc/0x150
        SyS_close+0x33/0x60
        entry_SYSCALL_64_fastpath+0x1f/0xbe
      
       Showing all locks held in the system:
       2 locks held by kworker/0:1/16:
        #0:  ("cifsiod"){.+.+.+}, at: process_one_work+0x255/0x8e0
        #1:  ((&cfile->oplock_break)){+.+.+.}, at: process_one_work+0x255/0x8e0
      
       Showing busy workqueues and worker pools:
       workqueue cifsiod: flags=0xc
         pwq 0: cpus=0 node=0 flags=0x0 nice=0 active=1/1
           in-flight: 16:cifs_oplock_break
           delayed: cifs_writev_complete, cifs_echo_request
       pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=0s workers=3 idle: 750 3
      
      Fix these problems by creating a a new workqueue (with a rescuer) for
      the oplock break work.
      Signed-off-by: NRabin Vincent <rabinv@axis.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      CC: Stable <stable@vger.kernel.org>
      3998e6b8
    • D
      cifs: fix CIFS_ENUMERATE_SNAPSHOTS oops · 6026685d
      David Disseldorp 提交于
      As with 61876395, an open directory may have a NULL private_data
      pointer prior to readdir. CIFS_ENUMERATE_SNAPSHOTS must check for this
      before dereference.
      
      Fixes: 834170c8 ("Enable previous version support")
      Signed-off-by: NDavid Disseldorp <ddiss@suse.de>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      6026685d
    • D
      cifs: fix leak in FSCTL_ENUM_SNAPS response handling · 0e5c7955
      David Disseldorp 提交于
      The server may respond with success, and an output buffer less than
      sizeof(struct smb_snapshot_array) in length. Do not leak the output
      buffer in this case.
      
      Fixes: 834170c8 ("Enable previous version support")
      Signed-off-by: NDavid Disseldorp <ddiss@suse.de>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      0e5c7955
    • S
      Set unicode flag on cifs echo request to avoid Mac error · 26c9cb66
      Steve French 提交于
      Mac requires the unicode flag to be set for cifs, even for the smb
      echo request (which doesn't have strings).
      
      Without this Mac rejects the periodic echo requests (when mounting
      with cifs) that we use to check if server is down
      Signed-off-by: NSteve French <smfrench@gmail.com>
      CC: Stable <stable@vger.kernel.org>
      26c9cb66
    • P
      CIFS: Add asynchronous write support through kernel AIO · c610c4b6
      Pavel Shilovsky 提交于
      This patch adds support to process write calls passed by io_submit()
      asynchronously. It based on the previously introduced async context
      that allows to process i/o responses in a separate thread and
      return the caller immediately for asynchronous calls.
      
      This improves writing performance of single threaded applications
      with increasing of i/o queue depth size.
      Signed-off-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      c610c4b6
    • P
      CIFS: Add asynchronous read support through kernel AIO · 6685c5e2
      Pavel Shilovsky 提交于
      This patch adds support to process read calls passed by io_submit()
      asynchronously. It based on the previously introduced async context
      that allows to process i/o responses in a separate thread and
      return the caller immediately for asynchronous calls.
      
      This improves reading performance of single threaded applications
      with increasing of i/o queue depth size.
      Signed-off-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      6685c5e2
    • P
      CIFS: Add asynchronous context to support kernel AIO · ccf7f408
      Pavel Shilovsky 提交于
      Currently the code doesn't recognize asynchronous calls passed
      by io_submit() and processes all calls synchronously. This is not
      what kernel AIO expects. This patch introduces a new async context
      that keeps track of all issued i/o requests and moves a response
      collecting procedure to a separate thread. This allows to return
      to a caller immediately for async calls and call iocb->ki_complete()
      once all requests are completed. For sync calls the current thread
      simply waits until all requests are completed.
      Signed-off-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      ccf7f408
    • D
      cifs: fix IPv6 link local, with scope id, address parsing · 29bb3158
      Daniel N Pettersson 提交于
      When the IP address is gotten from the UNC, use only the address part
      of the UNC. Else all after the percent sign in an IPv6 link local
      address is interpreted as a scope id. This includes the slash and
      share name. A scope id is expected to be an integer and any trailing
      characters makes the conversion to integer fail.
      Example of mount command that fails:
      mount -i -t cifs //fe80::6a05:caff:fe3e:8ffc%2/test /mnt/t -o sec=none
      Signed-off-by: NDaniel N Pettersson <danielnp@axis.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      29bb3158
    • D
      cifs: small underflow in cnvrtDosUnixTm() · 564277ec
      Dan Carpenter 提交于
      January is month 1.  There is no zero-th month.  If someone passes a
      zero month then it means we read from one space before the start of the
      total_days_of_prev_months[] array.
      
      We may as well also be strict about days as well.
      
      Fixes: 1bd5bbcb ("[CIFS] Legacy time handling for Win9x and OS/2 part 1")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      564277ec
  10. 28 4月, 2017 3 次提交
  11. 21 4月, 2017 1 次提交
  12. 18 4月, 2017 1 次提交
    • S
      cifs: Do not send echoes before Negotiate is complete · 62a6cfdd
      Sachin Prabhu 提交于
      commit 4fcd1813 ("Fix reconnect to not defer smb3 session reconnect
      long after socket reconnect") added support for Negotiate requests to
      be initiated by echo calls.
      
      To avoid delays in calling echo after a reconnect, I added the patch
      introduced by the commit b8c60012 ("Call echo service immediately
      after socket reconnect").
      
      This has however caused a regression with cifs shares which do not have
      support for echo calls to trigger Negotiate requests. On connections
      which need to call Negotiation, the echo calls trigger an error which
      triggers a reconnect which in turn triggers another echo call. This
      results in a loop which is only broken when an operation is performed on
      the cifs share. For an idle share, it can DOS a server.
      
      The patch uses the smb_operation can_echo() for cifs so that it is
      called only if connection has been already been setup.
      
      kernel bz: 194531
      Signed-off-by: NSachin Prabhu <sprabhu@redhat.com>
      Tested-by: NJonathan Liu <net147@gmail.com>
      Acked-by: NPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      62a6cfdd
  13. 13 4月, 2017 1 次提交
    • P
      CIFS: Fix SMB3 mount without specifying a security mechanism · 67dbea2c
      Pavel Shilovsky 提交于
      Commit ef65aaed ("smb2: Enforce sec= mount option") changed the
      behavior of a mount command to enforce a specified security mechanism
      during mounting. On another hand according to the spec if SMB3 server
      doesn't respond with a security context it implies that it supports
      NTLMSSP. The current code doesn't keep it in mind and fails a mount
      for such servers if no security mechanism is specified. Fix this by
      indicating that a server supports NTLMSSP if a security context isn't
      returned during negotiate phase. This allows the code to use NTLMSSP
      by default for SMB3 mounts.
      Signed-off-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      67dbea2c
  14. 11 4月, 2017 5 次提交
    • G
      CIFS: store results of cifs_reopen_file to avoid infinite wait · 1fa839b4
      Germano Percossi 提交于
      This fixes Continuous Availability when errors during
      file reopen are encountered.
      
      cifs_user_readv and cifs_user_writev would wait for ever if
      results of cifs_reopen_file are not stored and for later inspection.
      
      In fact, results are checked and, in case of errors, a chain
      of function calls leading to reads and writes to be scheduled in
      a separate thread is skipped.
      These threads will wake up the corresponding waiters once reads
      and writes are done.
      
      However, given the return value is not stored, when rc is checked
      for errors a previous one (always zero) is inspected instead.
      This leads to pending reads/writes added to the list, making
      cifs_user_readv and cifs_user_writev wait for ever.
      Signed-off-by: NGermano Percossi <germano.percossi@citrix.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      1fa839b4
    • G
      CIFS: remove bad_network_name flag · a0918f1c
      Germano Percossi 提交于
      STATUS_BAD_NETWORK_NAME can be received during node failover,
      causing the flag to be set and making the reconnect thread
      always unsuccessful, thereafter.
      
      Once the only place where it is set is removed, the remaining
      bits are rendered moot.
      
      Removing it does not prevent "mount" from failing when a non
      existent share is passed.
      
      What happens when the share really ceases to exist while the
      share is mounted is undefined now as much as it was before.
      Signed-off-by: NGermano Percossi <germano.percossi@citrix.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      a0918f1c
    • G
      CIFS: reconnect thread reschedule itself · 18ea4311
      Germano Percossi 提交于
      In case of error, smb2_reconnect_server reschedule itself
      with a delay, to avoid being too aggressive.
      Signed-off-by: NGermano Percossi <germano.percossi@citrix.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      18ea4311
    • M
      CIFS: handle guest access errors to Windows shares · 40920c2b
      Mark Syms 提交于
      Commit 1a967d6c ("correctly to
      anonymous authentication for the NTLM(v2) authentication") introduces
      a regression in handling errors related to attempting a guest
      connection to a Windows share which requires authentication. This
      should result in a permission denied error but actually causes the
      kernel module to enter a never-ending loop trying to follow a DFS
      referal which doesn't exist.
      
      The base cause of this is the failure now occurs later in the process
      during tree connect and not at the session setup setup and all errors
      in tree connect are interpreted as needing to follow the DFS paths
      which isn't in this case correct. So, check the returned error against
      EACCES and fail if this is returned error.
      
      Feedback from Aurelien:
      
        PS> net user guest /activate:no
          PS> mkdir C:\guestshare
            PS> icacls C:\guestshare /grant 'Everyone:(OI)(CI)F'
              PS> new-smbshare -name guestshare -path C:\guestshare -fullaccess Everyone
      
              I've tested v3.10, v4.4, master, master+your patch using default options
              (empty or no user "NU") and user=abc (U).
      
              NT_LOGON_FAILURE in session setup: LF
              This is what you seem to have in 3.10.
      
              NT_ACCESS_DENIED in tree connect to the share: AD
              This is what you get before your infinite loop.
      
                           |   NU       U
                           --------------------------------
                           3.10         |   LF       LF
                           4.4          |   LF       LF
                           master       |   AD       LF
                           master+patch |   AD       LF
      
                           No infinite DFS loop :(
                           All these issues result in mount failing very fast with permission denied.
      
                           I guess it could be from either the Windows version or the share/folder
                           ACL. A deeper analysis of the packets might reveal more.
      
                           In any case I did not notice any issues for on a basic DFS setup with
                           the patch so I don't think it introduced any regressions, which is
                           probably all that matters. It still bothers me a little I couldn't hit
                           the bug.
      
                           I've included kernel output w/ debugging output and network capture of
                           my tests if anyone want to have a look at it. (master+patch = ml-guestfix).
      Signed-off-by: NMark Syms <mark.syms@citrix.com>
      Reviewed-by: NAurelien Aptel <aaptel@suse.com>
      Tested-by: NAurelien Aptel <aaptel@suse.com>
      Acked-by: NPavel Shilovsky <pshilov@microsoft.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      40920c2b
    • P
      CIFS: Fix null pointer deref during read resp processing · 350be257
      Pavel Shilovsky 提交于
      Currently during receiving a read response mid->resp_buf can be
      NULL when it is being passed to cifs_discard_remaining_data() from
      cifs_readv_discard(). Fix it by always passing server->smallbuf
      instead and initializing mid->resp_buf at the end of read response
      processing.
      Signed-off-by: NPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org>
      Acked-by: NSachin Prabhu <sprabhu@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      350be257
  15. 07 4月, 2017 1 次提交