1. 02 4月, 2019 1 次提交
    • S
      smb3: Fix enumerating snapshots to Azure · 153322f7
      Steve French 提交于
      Some servers (see MS-SMB2 protocol specification
      section 3.3.5.15.1) expect that the FSCTL enumerate snapshots
      is done twice, with the first query having EXACTLY the minimum
      size response buffer requested (16 bytes) which refreshes
      the snapshot list (otherwise that and subsequent queries get
      an empty list returned).  So had to add code to set
      the maximum response size differently for the first snapshot
      query (which gets the size needed for the second query which
      contains the actual list of snapshots).
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Reviewed-by: NRonnie Sahlberg <lsahlber@redhat.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      CC: Stable <stable@vger.kernel.org> # 4.19+
      153322f7
  2. 15 3月, 2019 2 次提交
  3. 31 12月, 2018 1 次提交
  4. 24 12月, 2018 1 次提交
  5. 19 12月, 2018 1 次提交
    • R
      smb3: Fix rmdir compounding regression to strict servers · 271b9c0c
      Ronnie Sahlberg 提交于
      Some servers require that the setinfo matches the exact size,
      and in this case compounding changes introduced by
      commit c2e0fe3f ("cifs: make rmdir() use compounding")
      caused us to send 8 bytes (padded length) instead of 1 byte
      (the size of the structure).  See MS-FSCC section 2.4.11.
      
      Fixing this when we send a SET_INFO command for delete file
      disposition, then ends up as an iov of a single byte but this
      causes problems with SMB3 and encryption.
      
      To avoid this, instead of creating a one byte iov for the disposition value
      and then appending an additional iov with a 7 byte padding we now handle
      this as a single 8 byte iov containing both the disposition byte as well as
      the padding in one single buffer.
      Signed-off-by: NRonnie Sahlberg <lsahlber@redhat.com>
      Signed-off-by: NSteve French <stfrench@microsoft.com>
      Acked-by: NPaulo Alcantara <palcantara@suse.de>
      271b9c0c
  6. 24 10月, 2018 7 次提交
  7. 10 8月, 2018 1 次提交
  8. 09 8月, 2018 3 次提交
  9. 08 8月, 2018 3 次提交
  10. 06 7月, 2018 1 次提交
  11. 16 6月, 2018 1 次提交
  12. 15 6月, 2018 1 次提交
  13. 08 6月, 2018 1 次提交
  14. 01 6月, 2018 1 次提交
  15. 28 5月, 2018 3 次提交
  16. 13 4月, 2018 1 次提交
  17. 02 4月, 2018 2 次提交
  18. 27 1月, 2018 1 次提交
  19. 19 10月, 2017 1 次提交
  20. 05 9月, 2017 2 次提交
  21. 09 7月, 2017 1 次提交
  22. 06 7月, 2017 1 次提交
  23. 07 4月, 2017 1 次提交
    • S
      Handle mismatched open calls · 38bd4906
      Sachin Prabhu 提交于
      A signal can interrupt a SendReceive call which result in incoming
      responses to the call being ignored. This is a problem for calls such as
      open which results in the successful response being ignored. This
      results in an open file resource on the server.
      
      The patch looks into responses which were cancelled after being sent and
      in case of successful open closes the open fids.
      
      For this patch, the check is only done in SendReceive2()
      
      RH-bz: 1403319
      Signed-off-by: NSachin Prabhu <sprabhu@redhat.com>
      Reviewed-by: NPavel Shilovsky <pshilov@microsoft.com>
      Cc: Stable <stable@vger.kernel.org>
      38bd4906
  24. 03 3月, 2017 1 次提交
  25. 02 3月, 2017 1 次提交