1. 24 7月, 2012 15 次提交
  2. 17 7月, 2012 4 次提交
    • J
      cifs: always update the inode cache with the results from a FIND_* · cd60042c
      Jeff Layton 提交于
      When we get back a FIND_FIRST/NEXT result, we have some info about the
      dentry that we use to instantiate a new inode. We were ignoring and
      discarding that info when we had an existing dentry in the cache.
      
      Fix this by updating the inode in place when we find an existing dentry
      and the uniqueid is the same.
      
      Cc: <stable@vger.kernel.org> # .31.x
      Reported-and-Tested-by: NAndrew Bartlett <abartlet@samba.org>
      Reported-by: NBill Robertson <bill_robertson@debortoli.com.au>
      Reported-by: NDion Edwards <dion_edwards@debortoli.com.au>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      cd60042c
    • J
      cifs: when CONFIG_HIGHMEM is set, serialize the read/write kmaps · 3cf003c0
      Jeff Layton 提交于
      Jian found that when he ran fsx on a 32 bit arch with a large wsize the
      process and one of the bdi writeback kthreads would sometimes deadlock
      with a stack trace like this:
      
      crash> bt
      PID: 2789   TASK: f02edaa0  CPU: 3   COMMAND: "fsx"
       #0 [eed63cbc] schedule at c083c5b3
       #1 [eed63d80] kmap_high at c0500ec8
       #2 [eed63db0] cifs_async_writev at f7fabcd7 [cifs]
       #3 [eed63df0] cifs_writepages at f7fb7f5c [cifs]
       #4 [eed63e50] do_writepages at c04f3e32
       #5 [eed63e54] __filemap_fdatawrite_range at c04e152a
       #6 [eed63ea4] filemap_fdatawrite at c04e1b3e
       #7 [eed63eb4] cifs_file_aio_write at f7fa111a [cifs]
       #8 [eed63ecc] do_sync_write at c052d202
       #9 [eed63f74] vfs_write at c052d4ee
      #10 [eed63f94] sys_write at c052df4c
      #11 [eed63fb0] ia32_sysenter_target at c0409a98
          EAX: 00000004  EBX: 00000003  ECX: abd73b73  EDX: 012a65c6
          DS:  007b      ESI: 012a65c6  ES:  007b      EDI: 00000000
          SS:  007b      ESP: bf8db178  EBP: bf8db1f8  GS:  0033
          CS:  0073      EIP: 40000424  ERR: 00000004  EFLAGS: 00000246
      
      Each task would kmap part of its address array before getting stuck, but
      not enough to actually issue the write.
      
      This patch fixes this by serializing the marshal_iov operations for
      async reads and writes. The idea here is to ensure that cifs
      aggressively tries to populate a request before attempting to fulfill
      another one. As soon as all of the pages are kmapped for a request, then
      we can unlock and allow another one to proceed.
      
      There's no need to do this serialization on non-CONFIG_HIGHMEM arches
      however, so optimize all of this out when CONFIG_HIGHMEM isn't set.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NJian Li <jiali@redhat.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      3cf003c0
    • J
      cifs: on CONFIG_HIGHMEM machines, limit the rsize/wsize to the kmap space · 3ae629d9
      Jeff Layton 提交于
      We currently rely on being able to kmap all of the pages in an async
      read or write request. If you're on a machine that has CONFIG_HIGHMEM
      set then that kmap space is limited, sometimes to as low as 512 slots.
      
      With 512 slots, we can only support up to a 2M r/wsize, and that's
      assuming that we can get our greedy little hands on all of them. There
      are other users however, so it's possible we'll end up stuck with a
      size that large.
      
      Since we can't handle a rsize or wsize larger than that currently, cap
      those options at the number of kmap slots we have. We could consider
      capping it even lower, but we currently default to a max of 1M. Might as
      well allow those luddites on 32 bit arches enough rope to hang
      themselves.
      
      A more robust fix would be to teach the send and receive routines how
      to contend with an array of pages so we don't need to marshal up a kvec
      array at all. That's a fairly significant overhaul though, so we'll need
      this limit in place until that's ready.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NJian Li <jiali@redhat.com>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      3ae629d9
    • S
      Initialise mid_q_entry before putting it on the pending queue · ffc61ccb
      Sachin Prabhu 提交于
      A user reported a crash in cifs_demultiplex_thread() caused by an
      incorrectly set mid_q_entry->callback() function. It appears that the
      callback assignment made in cifs_call_async() was not flushed back to
      memory suggesting that a memory barrier was required here. Changing the
      code to make sure that the mid_q_entry structure was completely
      initialised before it was added to the pending queue fixes the problem.
      Signed-off-by: NSachin Prabhu <sprabhu@redhat.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Reviewed-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: NSteve French <smfrench@gmail.com>
      ffc61ccb
  3. 14 7月, 2012 11 次提交
  4. 04 7月, 2012 1 次提交
    • J
      cifs: when server doesn't set CAP_LARGE_READ_X, cap default rsize at MaxBufferSize · ec01d738
      Jeff Layton 提交于
      When the server doesn't advertise CAP_LARGE_READ_X, then MS-CIFS states
      that you must cap the size of the read at the client's MaxBufferSize.
      Unfortunately, testing with many older servers shows that they often
      can't service a read larger than their own MaxBufferSize.
      
      Since we can't assume what the server will do in this situation, we must
      be conservative here for the default. When the server can't do large
      reads, then assume that it can't satisfy any read larger than its
      MaxBufferSize either.
      
      Luckily almost all modern servers can do large reads, so this won't
      affect them. This is really just for older win9x and OS/2 era servers.
      Also, note that this patch just governs the default rsize. The admin can
      always override this if he so chooses.
      
      Cc: <stable@vger.kernel.org> # 3.2
      Reported-by: NDavid H. Durgee <dhdurgee@acm.org>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteven French <sfrench@w500smf.(none)>
      ec01d738
  5. 13 6月, 2012 1 次提交
    • S
      cifs: fix parsing of password mount option · e73f843a
      Suresh Jayaraman 提交于
      The double delimiter check that allows a comma in the password parsing code is
      unconditional. We set "tmp_end" to the end of the string and we continue to
      check for double delimiter. In the case where the password doesn't contain a
      comma we end up setting tmp_end to NULL and eventually setting "options" to
      "end". This results in the premature termination of the options string and hence
      the values of UNCip and UNC are being set to NULL. This results in mount failure
      with "Connecting to DFS root not implemented yet" error.
      
      This error is usually not noticable as we have password as the last option in
      the superblock mountdata. But when we call expand_dfs_referral() from
      cifs_mount() and try to compose mount options for the submount, the resulting
      mountdata will be of the form
      
         ",ver=1,user=foo,pass=bar,ip=x.x.x.x,unc=\\server\share"
      
      and hence results in the above error. This bug has been seen with older NAS
      servers running Samba 3.0.24.
      
      Fix this by moving the double delimiter check inside the conditional loop.
      
      Changes since -v1
      
         - removed the wrong strlen() micro optimization.
      Signed-off-by: NSuresh Jayaraman <sjayaraman@suse.com>
      Acked-by: NSachin Prabhu <sprabhu@redhat.com>
      Cc: stable@vger.kernel.org [3.1+]
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      e73f843a
  6. 02 6月, 2012 4 次提交
  7. 23 5月, 2012 4 次提交
    • S
      cifs: fix oops while traversing open file list (try #4) · 2c0c2a08
      Shirish Pargaonkar 提交于
      While traversing the linked list of open file handles, if the identfied
      file handle is invalid, a reopen is attempted and if it fails, we
      resume traversing where we stopped and cifs can oops while accessing
      invalid next element, for list might have changed.
      
      So mark the invalid file handle and attempt reopen if no
      valid file handle is found in rest of the list.
      If reopen fails, move the invalid file handle to the end of the list
      and start traversing the list again from the begining.
      Repeat this four times before giving up and returning an error if
      file reopen keeps failing.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      2c0c2a08
    • S
      cifs: Fix comment as d_alloc_root() is replaced by d_make_root() · ea4b5740
      Sedat Dilek 提交于
      For more details see <file: Documentation/filesystems/porting>.
      Signed-off-by: NSedat Dilek <sedat.dilek@gmail.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      ea4b5740
    • S
      CIFS: Introduce SMB2 mounts as vers=2.1 · 1080ef75
      Steve French 提交于
      As with Linux nfs client, which uses "nfsvers=" or "vers=" to
      indicate which protocol to use for mount, specifying
      
      "vers=2.1"
      
      will force an SMB2 mount. When vers is not specified CIFS is used
      
      "vers=1"
      
      We can eventually autonegotiate down from SMB2 to CIFS
      when SMB2 is stable enough to make it the default, but this
      is for the future. At that time we could also implement a
      "maxprotocol" mount option as smbclient and Samba have today,
      but that would be premature until SMB2 is stable.
      
      Intially the SMB2 Kconfig option will depend on "BROKEN"
      until the merge is complete, and then be "EXPERIMENTAL"
      When it is no longer experimental we can consider changing
      the default protocol to attempt first.
      Signed-off-by: NPavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Acked-by: NShirish Pargaonkar <shirishpargaonkar@gmail.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      1080ef75
    • S
      CIFS: Introduce SMB2 Kconfig option · 675f36fb
      Steve French 提交于
      SMB2 is the followon to the CIFS (and SMB) protocols
      and the default for Windows since Windows Vista, and also
      now implemented by various non-Windows servers. SMB2
      is more secure, has various performance advantages, including
      larger i/o sizes, flow control, better caching model and more.
      SMB2 also resolves some scalability limits in the CIFS
      protocol and adds many new features while being much
      simpler (only a few dozen commands instead of hundreds)
      and since the protocol is clearer it is also more consistently
      implemented across servers and thus easier to optimize.
      
      After much discussion with Jeff Layton, Jeremy Allison
      and others at Connectathon, we decided to move the SMB2
      code from a distinct .ko and fstype into distinct
      C files that optionally build in cifs.ko. As a result
      the Kconfig gets simpler.
      
      To avoid destabilizing CIFS, the SMB2 code is going
      to be moved into its own experimental CONFIG_CIFS_SMB2 ifdef
      as it is merged and rereviewed. The changes to stable
      CIFS (builds with the SMB2 ifdef off) are expected to be
      fairly small.
      Reviewed-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      Signed-off-by: NPavel Shilovsky <piastry@etersoft.ru>
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      675f36fb