Re: NCPFS and brittle connections

From: Petr Vandrovec
Date: Fri Jan 05 2007 - 02:46:25 EST


Pierre Ossman wrote:
Petr Vandrovec wrote:
Nobody is working on it (at least to my knowledge), and to me it is
feature - it always worked this way, like smbfs did back in the past -
if you send signal 9 to process using mount point, and there is some
transaction in progress, nobody can correctly finish that transaction
anymore. Fixing it would require non-trivial amount of code, and
given that NCP itself is more or less dead protocol I do not feel that
it is necessary.


Someone needs to tell our customers then so they'll stop using it. :)

When I asked at Brainshare 2001 when support for files over 4GB files will be added to NCP, they told me that I should switch to CIFS or NFS... Years after that confirmed it - only NW6.5SP3 finally got NCPs to support for files over 4GB, although you could have such files even on NW5.

If you want to fix it, feel free. Culprit is RQ_INPROGRESS handling
in ncp_abort_request - it just aborts whole connection so it does not
have to provide temporary buffers and special handling for reply - as
buffers currently specified as reply buffers are owned by caller, so
after aborting request you cannot use them anymore.

Do you have any pointers to how it was solved with smbfs? Relevant
patches perhaps? Provided a similar solution can be applied here.

I believe it was fixed when smbiod was introduced. When find_request() returns failure, it simple throws away data received from network.

Unfortunately NCP does not run on top of TCP stream, but on top of IPX/UDP, and so dropping reply is not sufficient - you must continue resending request (so you must buffer it somewhere...) until you get result from server - after you receive answer from server, you can finally throw away both request & reply, and move on.
Petr


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/