Petr Vandrovec wrote:
>
> Hello,
> it would be nice if these two copies (request->txbuf, and
> rxbuf->reply) could be eliminated, but I see no easy way how to do
> that...
>
At least we have the basic functionality now. One can start looking at
optimising it after that.
>
> Acked-by: Petr Vandr
Pierre Ossman wrote:
Sorry this took so long but I got occupied with other things and this
had to move down the pile a bit.
New patch which uses dedicated buffers for the currently active packet.
Also adds a new state RQ_ABANDONED which basically means "the caller no
longer cares about this requ
Sorry this took so long but I got occupied with other things and this
had to move down the pile a bit.
New patch which uses dedicated buffers for the currently active packet.
Also adds a new state RQ_ABANDONED which basically means "the caller no
longer cares about this request so the pointers are
Pierre Ossman wrote:
Petr Vandrovec wrote:
Problem is with these pointers - reply_buf & server->packet. Now code
will just read packet from server->packet, and write result to
reply_buf, most probably transmiting some random data to network, and
overwriting innocent memory on receiption... I b
Petr Vandrovec wrote:
>
> Problem is with these pointers - reply_buf & server->packet. Now code
> will just read packet from server->packet, and write result to
> reply_buf, most probably transmiting some random data to network, and
> overwriting innocent memory on receiption... I believe that yo
Pierre Ossman wrote:
Ok... how about this baby instead. I've replaced the stack allocated
request structure by one allocated with kmalloc() and reference counted
using an atomic_t. I couldn't see anything else that was associated to
the process, so I believe this should suffice.
(This is just a
ping!
Pierre Ossman wrote:
> Ok... how about this baby instead. I've replaced the stack allocated
> request structure by one allocated with kmalloc() and reference counted
> using an atomic_t. I couldn't see anything else that was associated to
> the process, so I believe this should suffice.
>
>
Ok... how about this baby instead. I've replaced the stack allocated
request structure by one allocated with kmalloc() and reference counted
using an atomic_t. I couldn't see anything else that was associated to
the process, so I believe this should suffice.
(This is just a RFC. Once I get an ok f
Pierre Ossman wrote:
Petr Vandrovec wrote:
Hello,
create test scenario where first transmit of NCP request is lost by
network, and before resend you kill this process. So it stops
resending, but local sequence count is already incremented. Then when
next process tries to access ncpfs, server
Petr Vandrovec wrote:
>
> Hello,
> create test scenario where first transmit of NCP request is lost by
> network, and before resend you kill this process. So it stops
> resending, but local sequence count is already incremented. Then when
> next process tries to access ncpfs, server will ignore
Pierre Ossman wrote:
Sorry this took some time, I've been busy with other things.
Petr Vandrovec wrote:
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...)
Sorry this took some time, I've been busy with other things.
Petr Vandrovec wrote:
>
> 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
>
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
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 t
Pierre Ossman wrote:
Hi Petr,
What is the status of this bug?
http://bugzilla.kernel.org/show_bug.cgi?id=3328
I do not see anything in the history of fs/ncpfs that seems to suggest that
this, rather critical, issue has been resolved. Is anyone working on it?
Nobody is working on it (at leas
15 matches
Mail list logo
