1. 05 9月, 2017 2 次提交
  2. 01 9月, 2017 1 次提交
  3. 31 8月, 2017 2 次提交
  4. 24 8月, 2017 2 次提交
    • R
      cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup() · d3edede2
      Ronnie Sahlberg 提交于
      Add checking for the path component length and verify it is <= the maximum
      that the server advertizes via FileFsAttributeInformation.
      
      With this patch cifs.ko will now return ENAMETOOLONG instead of ENOENT
      when users to access an overlong path.
      
      To test this, try to cd into a (non-existing) directory on a CIFS share
      that has a too long name:
      cd /mnt/aaaaaaaaaaaaaaa...
      
      and it now should show a good error message from the shell:
      bash: cd: /mnt/aaaaaaaaaaaaaaaa...aaaaaa: File name too long
      
      rh bz 1153996
      Signed-off-by: NRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      Cc: <stable@vger.kernel.org>
      d3edede2
    • S
      cifs: Fix df output for users with quota limits · 42bec214
      Sachin Prabhu 提交于
      The df for a SMB2 share triggers a GetInfo call for
      FS_FULL_SIZE_INFORMATION. The values returned are used to populate
      struct statfs.
      
      The problem is that none of the information returned by the call
      contains the total blocks available on the filesystem. Instead we use
      the blocks available to the user ie. quota limitation when filling out
      statfs.f_blocks. The information returned does contain Actual free units
      on the filesystem and is used to populate statfs.f_bfree. For users with
      quota enabled, it can lead to situations where the total free space
      reported is more than the total blocks on the system ending up with df
      reports like the following
      
       # df -h /mnt/a
      Filesystem         Size  Used Avail Use% Mounted on
      //192.168.22.10/a  2.5G -2.3G  2.5G    - /mnt/a
      
      To fix this problem, we instead populate both statfs.f_bfree with the
      same value as statfs.f_bavail ie. CallerAvailableAllocationUnits. This
      is similar to what is done already in the code for cifs and df now
      reports the quota information for the user used to mount the share.
      
       # df --si /mnt/a
      Filesystem         Size  Used Avail Use% Mounted on
      //192.168.22.10/a  2.7G  101M  2.6G   4% /mnt/a
      Signed-off-by: NSachin Prabhu <sprabhu@redhat.com>
      Signed-off-by: NPierguido Lambri <plambri@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      Cc: <stable@vger.kernel.org>
      42bec214
  5. 10 7月, 2017 1 次提交
  6. 09 7月, 2017 6 次提交
  7. 06 7月, 2017 9 次提交
  8. 03 7月, 2017 1 次提交
  9. 21 6月, 2017 5 次提交
  10. 20 6月, 2017 2 次提交
    • I
      sched/wait: Split out the wait_bit*() APIs from <linux/wait.h> into <linux/wait_bit.h> · 5dd43ce2
      Ingo Molnar 提交于
      The wait_bit*() types and APIs are mixed into wait.h, but they
      are a pretty orthogonal extension of wait-queues.
      
      Furthermore, only about 50 kernel files use these APIs, while
      over 1000 use the regular wait-queue functionality.
      
      So clean up the main wait.h by moving the wait-bit functionality
      out of it, into a separate .h and .c file:
      
        include/linux/wait_bit.h  for types and APIs
        kernel/sched/wait_bit.c   for the implementation
      
      Update all header dependencies.
      
      This reduces the size of wait.h rather significantly, by about 30%.
      
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      5dd43ce2
    • J
      cifs: use get_random_u32 for 32-bit lock random · 51b0817b
      Jason A. Donenfeld 提交于
      Using get_random_u32 here is faster, more fitting of the use case, and
      just as cryptographically secure. It also has the benefit of providing
      better randomness at early boot, which is sometimes when this is used.
      Signed-off-by: NJason A. Donenfeld <Jason@zx2c4.com>
      Cc: Steve French <sfrench@samba.org>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      51b0817b
  11. 13 5月, 2017 4 次提交
  12. 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
  13. 09 5月, 2017 1 次提交
  14. 05 5月, 2017 1 次提交
  15. 04 5月, 2017 1 次提交