1. 14 Aug, 2023 1 commit
    • Russell Harmon via samba-technical's avatar
      cifs: Release folio lock on fscache read hit. · 69513dd6
      Russell Harmon via samba-technical authored
      Under the current code, when cifs_readpage_worker is called, the call
      contract is that the callee should unlock the page. This is documented
      in the read_folio section of Documentation/filesystems/vfs.rst as:
      
      > The filesystem should unlock the folio once the read has completed,
      > whether it was successful or not.
      
      Without this change, when fscache is in use and cache hit occurs during
      a read, the page lock is leaked, producing the following stack on
      subsequent reads (via mmap) to the page:
      
      $ cat /proc/3890/task/12864/stack
      [<0>] folio_wait_bit_common+0x124/0x350
      [<0>] filemap_read_folio+0xad/0xf0
      [<0>] filemap_fault+0x8b1/0xab0
      [<0>] __do_fault+0x39/0x150
      [<0>] do_fault+0x25c/0x3e0
      [<0>] __handle_mm_fault+0x6ca/0xc70
      [<0>] handle_mm_fault+0xe9/0x350
      [<0>] do_user_addr_fault+0x225/0x6c0
      [<0>] exc_page_fault+0x84/0x1b0
      [<0>] asm_exc_page_fault+0x27/0x30
      
      This requires a reboot to resolve; it is a deadlock.
      
      Note however that the call to cifs_readpage_from_fscache does mark the
      page clean, but does not free the folio lock. This happens in
      __cifs_readpage_from_fscache on success. Releasing the lock at that
      point however is not appropriate as cifs_readahead also calls
      cifs_readpage_from_fscache and *does* unconditionally release the lock
      after its return. This change therefore effectively makes
      cifs_readpage_worker work like cifs_readahead.
      Signed-off-by: default avatarRussell Harmon <russ@har.mn>
      Acked-by: default avatarPaulo Alcantara (SUSE) <pc@manguebit.com>
      Reviewed-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      69513dd6
  2. 11 Aug, 2023 1 commit
    • Steve French's avatar
      cifs: fix potential oops in cifs_oplock_break · e8f5f849
      Steve French authored
      With deferred close we can have closes that race with lease breaks,
      and so with the current checks for whether to send the lease response,
      oplock_response(), this can mean that an unmount (kill_sb) can occur
      just before we were checking if the tcon->ses is valid.  See below:
      
      [Fri Aug  4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs]
      [Fri Aug  4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e <48> 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39
      [Fri Aug  4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206
      [Fri Aug  4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009
      [Fri Aug  4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188
      [Fri Aug  4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900
      [Fri Aug  4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138
      [Fri Aug  4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000
      [Fri Aug  4 04:12:50 2023] FS:  0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000
      [Fri Aug  4 04:12:50 2023] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [Fri Aug  4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0
      [Fri Aug  4 04:12:50 2023] Call Trace:
      [Fri Aug  4 04:12:50 2023]  <TASK>
      [Fri Aug  4 04:12:50 2023]  process_one_work+0x225/0x3d0
      [Fri Aug  4 04:12:50 2023]  worker_thread+0x4d/0x3e0
      [Fri Aug  4 04:12:50 2023]  ? process_one_work+0x3d0/0x3d0
      [Fri Aug  4 04:12:50 2023]  kthread+0x12a/0x150
      [Fri Aug  4 04:12:50 2023]  ? set_kthread_struct+0x50/0x50
      [Fri Aug  4 04:12:50 2023]  ret_from_fork+0x22/0x30
      [Fri Aug  4 04:12:50 2023]  </TASK>
      
      To fix this change the ordering of the checks before sending the oplock_response
      to first check if the openFileList is empty.
      
      Fixes: da787d5b ("SMB3: Do not send lease break acknowledgment if all file handles have been closed")
      Suggested-by: default avatarBharath SM <bharathsm@microsoft.com>
      Reviewed-by: default avatarBharath SM <bharathsm@microsoft.com>
      Reviewed-by: default avatarShyam Prasad N <sprasad@microsoft.com>
      Signed-off-by: default avatarPaulo Alcantara (SUSE) <pc@manguebit.com>
      Signed-off-by: default avatarSteve French <stfrench@microsoft.com>
      e8f5f849
  3. 05 Aug, 2023 5 commits
  4. 04 Aug, 2023 10 commits
  5. 03 Aug, 2023 23 commits