linux-toradex.git/fs/cifs/file.c, branch v4.9.120

CIFS: silence lockdep splat in cifs_relock_file()

2018-04-13T17:47:54+00:00

[ Upstream commit 560d388950ceda5e7c7cdef7f3d9a8ff297bbf9d ]

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: Rabin Vincent 
Acked-by: Pavel Shilovsky 
Signed-off-by: Steve French 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

cifs: Fix missing put_xid in cifs_file_strict_mmap

2018-02-17T12:21:12+00:00

commit f04a703c3d613845ae3141bfaf223489de8ab3eb upstream.

If cifs_zap_mapping() returned an error, we would return without putting
the xid that we got earlier.  Restructure cifs_file_strict_mmap() and
cifs_file_mmap() to be more similar to each other and have a single
point of return that always puts the xid.

Signed-off-by: Matthew Wilcox 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags

2017-10-05T07:44:01+00:00

commit 1013e760d10e614dc10b5624ce9fc41563ba2e65 upstream.

Signed-off-by: Steve French 
Reviewed-by: Ronnie Sahlberg 
Reviewed-by: Pavel Shilovsky 
Signed-off-by: Greg Kroah-Hartman

CIFS: store results of cifs_reopen_file to avoid infinite wait

2017-04-21T07:31:19+00:00

commit 1fa839b4986d648b907d117275869a0e46c324b9 upstream.

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: Germano Percossi 
Reviewed-by: Pavel Shilovsky 
Signed-off-by: Steve French 
Signed-off-by: Greg Kroah-Hartman

CIFS: Fix splice read for non-cached files

2017-03-12T05:41:43+00:00

commit 9c25702cee1405099f982894c865c163de7909a8 upstream.

Currently we call copy_page_to_iter() for uncached reading into a pipe.
This is wrong because it treats pages as VFS cache pages and copies references
rather than actual data. When we are trying to read from the pipe we end up
calling page_cache_pipe_buf_confirm() which returns -ENODATA. This error
is translated into 0 which is returned to a user.

This issue is reproduced by running xfs-tests suite (generic test #249)
against mount points with "cache=none". Fix it by mapping pages manually
and calling copy_to_iter() that copies data into the pipe.

Signed-off-by: Pavel Shilovsky 
Signed-off-by: Greg Kroah-Hartman

CIFS: Fix a possible double locking of mutex during reconnect

2017-01-06T09:40:16+00:00

commit 96a988ffeb90dba33a71c3826086fe67c897a183 upstream.

With the current code it is possible to lock a mutex twice when
a subsequent reconnects are triggered. On the 1st reconnect we
reconnect sessions and tcons and then persistent file handles.
If the 2nd reconnect happens during the reconnecting of persistent
file handles then the following sequence of calls is observed:

cifs_reopen_file -> SMB2_open -> small_smb2_init -> smb2_reconnect
-> cifs_reopen_persistent_file_handles -> cifs_reopen_file (again!).

So, we are trying to acquire the same cfile->fh_mutex twice which
is wrong. Fix this by moving reconnecting of persistent handles to
the delayed work (smb2_reconnect_server) and submitting this work
every time we reconnect tcon in SMB2 commands handling codepath.

This can also lead to corruption of a temporary file list in
cifs_reopen_persistent_file_handles() because we can recursively
call this function twice.

Signed-off-by: Pavel Shilovsky 
Signed-off-by: Greg Kroah-Hartman

CIFS: Reset read oplock to NONE if we have mandatory locks after reopen

2016-10-14T00:48:59+00:00

We are already doing the same thing for an ordinary open case:
we can't keep read oplock on a file if we have mandatory byte-range
locks because pagereading can conflict with these locks on a server.
Fix it by setting oplock level to NONE.

Signed-off-by: Pavel Shilovsky 
Signed-off-by: Steve French

CIFS: Fix persistent handles re-opening on reconnect

2016-10-14T00:48:55+00:00

openFileList of tcon can be changed while cifs_reopen_file() is called
that can lead to an unexpected behavior when we return to the loop.
Fix this by introducing a temp list for keeping all file handles that
need to be reopen.

Signed-off-by: Pavel Shilovsky 
Signed-off-by: Steve French

fs/cifs: reopen persistent handles on reconnect

2016-10-12T17:08:33+00:00

Continuous Availability features like persistent handles
require that clients reconnect their open files, not
just the sessions, soon after the network connection comes
back up, otherwise the server will throw away the state
(byte range locks, leases, deny modes) on those handles
after a timeout.

Add code to reconnect handles when use_persistent set
(e.g. Continuous Availability shares) after tree reconnect.

Signed-off-by: Aurelien Aptel 
Reviewed-by: Germano Percossi 
Signed-off-by: Steve French

Clarify locking of cifs file and tcon structures and make more granular

2016-10-12T17:08:32+00:00

Remove the global file_list_lock to simplify cifs/smb3 locking and
have spinlocks that more closely match the information they are
protecting.

Add new tcon->open_file_lock and file->file_info_lock spinlocks.
Locks continue to follow a heirachy,
	cifs_socket --> cifs_ses --> cifs_tcon --> cifs_file
where global tcp_ses_lock still protects socket and cifs_ses, while the
the newer locks protect the lower level structure's information
(tcon and cifs_file respectively).

CC: Stable 
Signed-off-by: Steve French 
Signed-off-by: Pavel Shilovsky 
Reviewed-by: Aurelien Aptel 
Reviewed-by: Germano Percossi