Hi,
Is the following fix clean or are there better solutions?
There is a race condition in the Linux X.25 protocol stack. The stack
has an x25_kick() function which dequeues as many skb´s from
sk->write_queue as the send windows allows and sends them downwards.
This kick function is called fro
Hi,
> "kuznet" == kuznet <[EMAIL PROTECTED]> writes:
kuznet> Hello!
>> atomic_inc(&sk->protinfo.x25->kick_it);
>> if((atomic_read(&sk->protinfo.x25->kick_it)) != 1) return;
>>
>> do { __x25_kick(sk); } while
>> (!atomic_dec_and_test(&sk->protinfo.x25->kic
Hello!
> I guess I´d also need to call lock_sock() from sendmsg(). And before
> calling x25_kick from socket input path, I´d need to verify that
> sk->lock.users is zero. If sk->lock.users was !=0, I´d need some atomic
> variable anyway in order to defer the kick.
In input path you have a packe
Hi,
> "kuznet" == kuznet <[EMAIL PROTECTED]> writes:
kuznet> Hello!
kuznet> In input path you have a packet. Add it to backlog and
kuznet> processing will be resumed after lock is released. Compare
kuznet> with tcp.
>> serializing the kick. Well, maybe my solution cou
Hello!
> Yes, I see. I did not realize before that the lock_sock and the
> sk->backlog framework are not two independent things. They really
> seem to be designed for team work only. Did I get this right?
Yes.
Actually, in 2.4 lock_sock() is also semaphore and in some cases
(f.e. for stateless
Hi,
> "kuznet" == kuznet <[EMAIL PROTECTED]> writes:
>> Anyway, it seems that I can already make use the lock_sock()
>> infrastructure for fixing the output serialization, even
>> without making the whole protocol stack SMP-aware at once.
kuznet> Actually, the last task is
Hello!
> timer events where the protocol specs require immediate reaction and
> which need to change socket state. For such events, it might not
> be obvious how to defer them when sk->lock.users != 0.
After some thinking, you will understand that "timer" and "immediate"
are incompatible.
TCP
Hi,
> "kuznet" == kuznet <[EMAIL PROTECTED]> writes:
>> when sk->lock.users!=0. Is there a particular reason why such
>> task queue does not exist?
kuznet> Because it appeared to be useless overhead. I also
kuznet> believed that it will be required in tcp, but one day I
Hello!
> But I realized another problem X.25 related SMP problem -- this time
> related to input. The protocol design assumes that the transmission
> path preserves the packet ordering. It seems that with 2.4.0 SMP, the ordering
> of the packets when received from the wire is not necessarily the
[EMAIL PROTECTED] said:
> I think its fixable to make it do the RR/RNR after bouncing it up the
> stack. -
ARCnet does ACK in hardware. Packets don't hit the wire until the
destination has indicated that it's got a buffer available.
You really want to be able to reserve space on the queue bef
Hi,
> "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:
Alan> LAPB does not expect ever to see re-ordering. Its a point to
Alan> point wire level MAC protocol.
Yes, it was never designed for handling re-ordering because this cannot
happen on a single wire (and for that reason it is no
Hello!
> scheduler may re-order frames
It cannot, provided sender holds order until dev_queue_xmit().
Actually, it is true about all the schedulers, except for
the cases, when reordering is allowed explicitly with special
policing rules.
> or drop them.
Yes. And if you share _single_ device
> > With the current scheme, lapb first acknowleges reception of the frame
> > and after that, netif_rx() might still discard it -- which is evil.
>
> This might screw things a bit. Can you defer to say first call
> netif_rx() then acknowledge or is this hard-coded into the f/ware?
I think its f
On Sat, Sep 16, 2000 at 11:39:45PM +0200, Henner Eisen wrote:
> int netif_would_drop(dev)
> {
> return (queue->input_pkt_queue.qlen > netdev_max_backlog)
> || ( (queue->input_pkt_queue.qlen) && (queue->throttle) )
> }
>
> would fulfil those requirements.
It would just be racy.
Hi,
> "kuznet" == kuznet <[EMAIL PROTECTED]> writes:
kuznet> Hello!
>> scheduler may re-order frames
kuznet> It cannot, provided sender holds order until
kuznet> dev_queue_xmit().
But if I set different skb->priority? ;) Well that would be my fault than ..
>> or dro
Hi,
> "Alan" == Alan Cox <[EMAIL PROTECTED]> writes:
>> However, for drivers which support intelligent controllers
>> (with lapb in firmware) this is not an option and the problem
>> will persist.
Alan> 'Smart hardware is broken' repeat .. ;) - but yes its an
Alan> issu
Seems all the good network stuff gets discussed on l-k instead ;-<
(hint: some people are not subscribed to l-k)
On Sat, 16 Sep 2000, Henner Eisen wrote:
>
> What about a function to query the state of the backlog queue?
>
> Something like
>
> if(netif_would_drop(dev)){
> kfree_skb(s
> "Andi" == Andi Kleen <[EMAIL PROTECTED]> writes:
Andi> It would just be racy. You test, get a not drop and then
Andi> another different interrupt would deliver another packet
Andi> before you can and fill the queue. Jamal's extended
Andi> netif_rx probably makes more sense,
Hi,
> "jamal" == jamal <[EMAIL PROTECTED]> writes:
>> With the current scheme, lapb first acknowleges reception of
>> the frame and after that, netif_rx() might still discard it --
>> which is evil.
>>
jamal> This might screw things a bit. Can you defer to say first
On Sun, 17 Sep 2000, Henner Eisen wrote:
> Yes, a) that would make life much simpler for driver writers (but more
> difficult for you ;). If it is doable without adding overhead to the
> general path, it would be nice to provide that semantics to HW_FLOWCONTROLed
> devices.
>
There would be a
From: [EMAIL PROTECTED]
Date: Fri, 15 Sep 2000 21:07:38 +0400 (MSK DST)
[ Dave, all this sounds bad. ]
Well, there are two things:
1) If exact sequencing is so important, then we can make
special netif_rx tasklet for these guys which serializes
around a spinlock.
Actually, ev
On Sun, 17 Sep 2000, Henner Eisen wrote:
> > "jamal" == jamal <[EMAIL PROTECTED]> writes:
> No. Just, if you do not accept a frame, you must not acknowledge it.
> Once it has been acknowledged, you must not discard it.
Ok so no problem then
>
> jamal> Can you stop mid-window and cl
> "jamal" == jamal <[EMAIL PROTECTED]> writes:
jamal> Hmm.. More complexity ;-> Does X.25 mandate you accept all
jamal> the window?
No. Just, if you do not accept a frame, you must not acknowledge it.
Once it has been acknowledged, you must not discard it.
jamal> Can you stop m
> "jamal" == jamal <[EMAIL PROTECTED]> writes:
jamal> Packets in flight?
>> In the extreme case, there could still arrive up to the window
>> size frames.
jamal> Assuming this depends on path latency and not some bad
jamal> programming
Yes. Although the latter could al
Hi,
> "David" == David S Miller <[EMAIL PROTECTED]> writes:
David>It smells rotten to the core, can someone tell me
David> exactly why reordering is strictly disallowed? I do not
David> even know how other OSes can handle this properly since
David> most, if not all, use
> LAPB itsself should be able to recover from reordering, although it is
> not optimzed for this. It will just discard any received out-of-sequence
> frame. The discarded frames will be retransmitted later (exacly like
> frames which had been discarded due to CRC errors).
LAPB does not expect eve
>I sense that usually, LAPB handles this issue at a different
>level, in the hardware? Does LAPB specify how to maintain
>reliably delivery and could we hook into this "how" when we
>need to drop LAPB frames? Perhaps it is too late by the time
>netif_rx is dealing with it.
L
27 matches
Mail list logo
