Re: Search for advice on testing whether a local CIFS fd closed remotely

[Steve French <smfrench@gmail.com>]

Presumably the attempt to close a file (from the Linux client) which
the server has force closed on their side, would lead to
/proc/fs/cifs/Stats logging an error on close.   It is an unusual
situation to have a server force closed a handle in such a way that it
would return an error on an attempt by an SMB3 client to use it (more
typical would be for a resource constrained server to expire the
session and let the client reconnect its open handles as needed).

To test use of directory handles after a force close of server handles
(ie for the unusual case where the file handle is force closed on the
server side through some tool, but the client has the file still
open), you could try something similar to the "PASSTHRU_FSCTL" for
doing a query info (see e.g. the function fsctlgetobjid in cifs-utils
package smbinfo.c) after you have left a directory handle open long
enough for your force close on the server side to be done.

This is an unusual scenario though where you want to have the server
throw away state (network file handles open on a connection) without
killing the smb session (in which case the client can reconnect
transparently).

On Sun, Jul 28, 2019 at 10:03 PM Gefei Li <gefeili.2013@gmail.com> wrote:
>
> Thanks a lot for the '/proc/fs/cifs/Stats | grep "Open files"' tip,
> Steve. But it seems not working in my case(not crashing case).
>
> I have an SMB server that is able to close handles from server side,
> and if closed remotely I want to check from client side. I've done
> several experiments:
> 1. CIFS client open, server side close
>   -  both "/proc/fs/cifs/Stats" and "cat /proc/fs/cifs/open_files"
> remain unchanged
> 2. CIFS client open, server side close, client side call "close"
> function to check fd
>   - "Closes" in "/proc/fs/cifs/Stats" changes "4 total 1 failed"    <-
> 1 failed due to server side closed?
> 3. CIFS client open, server side close, client side call "read"
> function to check fd
>   - EBADF returned while trying to "read", this is what I expect.  But
> for dir handle and WR-only handles, which function should I use?
>
> Regards,
> Gefei
>
> On Sun, Jul 28, 2019 at 8:08 AM Steve French <smfrench@gmail.com> wrote:
> >
> > On Fri, Jul 26, 2019 at 3:22 AM Gefei Li <gefeili.2013@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > From some stack overflow result I know that on a local ext4/fat32
> > > system, we can test whether a file descriptor is valid through
> > > "fcntl(fd, F_GETFD)". But in cifs cases, a fd typically bind a local
> > > fd to remote handle, do we have some c function/syscall that can test
> > > whether the fd is remotely closed?
> > >
> > > I've tried some windows way like "ioctl", which works well, and in
> > > linux local file system "fcntl" works. Tried to use "fcntl" on kernel
> > > 5.1.15, found no server request is received.. Could you please give me
> > > some advice on testing whether a fd is remoted closed in CIFS client?
> >
> > both F_GETFD and F_GETFL look like they check in the local VFS only
> > (aren't passed down to the file system, whether ext4 or cifs or even nfs)
> > for the value of these flags (see do_fcntl function in fs/fcntl.c)
> >
> > In general an open of a file (over an SMB3 mount) will result in a open
> > over a file on the server.   You can see the detailed information on
> > the network file handle ("PersistentFileID") open on the server by (on
> > the Linux client) doing:
> >
> >        cat /proc/fs/cifs/open_files
> >
> > If you were worried about a network crash temporarily closing remote handles
> > (in which case you might temporarily have a local handle which is not
> > open on the
> > server) you could (in theory) do:
> >
> >       /proc/fs/cifs/Stats | grep "Open files"
> >
> > but I did notice a bug (in the processing of one of those counters for
> > that /proc file)
> > in which we are leaking one of those two counters (the counter is
> > informational only
> > so presumably not a serious bug) and it can go negative so looking at the count
> > of open files on the server may not be as useful.
> >
> > --
> > Thanks,
> >
> > Steve



-- 
Thanks,

Steve