Re: [PATCH 2/2] smb: client: let smbd_post_send_iter() respect the peers max_send_size and transmit all data

[David Howells <dhowells@redhat.com>]

David Howells <dhowells@redhat.com> wrote:

> > > +		if (iter && iov_iter_count(iter) > 0) {
> > > +			/*
> > > +			 * There is more data to send
> > > +			 */
> > > +			goto wait_credit;
> > 
> > But, shouldn't the caller have done this overflow check, and looped on
> > the fragments and credits? It seems wrong to push the credit check down
> > to this level.
> 
> Fair point.  There's retry handling in the netfs layer - though that only
> applies to reads and writes that go through that.  Can RDMA be used to
> transfer data for other large calls?  Dir enumeration or ioctl, for instance.

Actually, I'm wrong.  We do need this because we can come down this path from
non-netfs generated RPC ops.  I stuck a WARN_ON_ONCE() on the path to see what
generated it, and got:

 WARNING: CPU: 0 PID: 6773 at fs/smb/client/smbdirect.c:980 smbd_post_send_iter+0x768/0x840
 ...
 RIP: 0010:smbd_post_send_iter+0x768/0x840
 ...
 Call Trace:
  <TASK>
  smbd_send+0x1bb/0x280
  ? __smb_send_rqst+0x7c/0x3c0
  __smb_send_rqst+0x7c/0x3c0
  ? rb_erase+0x30/0x280
  smb_send_rqst+0x6a/0x150
  ? remove_hrtimer+0x5e/0x70
  compound_send_recv+0x31b/0x650
  ? __kmalloc_noprof+0x262/0x290
  ? kmem_cache_debug_flags+0xc/0x20
  cifs_send_recv+0x1f/0x30
  SMB2_open+0x22d/0x4b0
  ? smb2_open_file+0xd3/0x310
  smb2_open_file+0xd3/0x310
  cifs_nt_open+0x182/0x280
  cifs_open+0x463/0x650
  ? __pfx_cifs_open+0x10/0x10
  ? do_dentry_open+0x218/0x390
  do_dentry_open+0x218/0x390
  vfs_open+0x28/0x50
  do_open+0x216/0x2c0
  path_openat+0x140/0x1b0
  do_filp_open+0xb8/0x120
  ? kmem_cache_debug_flags+0xc/0x20
  ? kmem_cache_alloc_noprof+0x201/0x230
  ? getname_flags.part.0+0x24/0x180
  do_sys_openat2+0x6e/0xc0
  do_sys_open+0x37/0x60
  __x64_sys_openat+0x1b/0x30
  do_syscall_64+0x80/0x170
  entry_SYSCALL_64_after_hwframe+0x71/0x79

David