The smbfs ioctls are supposed to only be called when the server is
locked and smbfs is waiting for a connection. There's currently a
problem because the first ioctl has to happen before smbfs knows the pid
of the smbclient process, so the test for locked server is commented
out. Once the mount args are changed to pass a pid, we'll only accept an
ioctl when smbfs is waiting for it, and this will fix the oops problem.
Until then just "don't do that."
> Umm... nope. It enters the retry code and only sometimes does it send
> smbclient a signal. The times it does - everything works. But when it
> doesn't - well, the connection is closed so obviously things don't work.
Please try to track down why a signal isn't being sent. From inspection
of the code there's no way smbfs can fail to send the signal.
> Umm.. perhaps I misunderstand. What I was wondering though, was that if I
> open a file RW, will the server time out the connection - and if so, how is
> this dealt with.
>
> Even if the file is opened RO, and the connection is closed, and the kernel
> does initial a transparent reconnect - how do we know the data in the file
> we apparently have open is still correct?
When we invalidate a connection, smbfs does a shrink_dcache_sb() and
invalidate_inodes(), so this will clear out any cached data. After the
connection is renewed, files will have to be reopened.
> Nether of these two points really matter to me, it just occurred to me that
> there might be an issue here. I started looking at the SMB protocol in more
> detail and have decided either I'm a thickie or the protocol is seriously
> brain-damaged....
Definitely the latter ...
Regards,
Bill