Forwarded message:
- From owner-linux-ipsec@clinet.fi Wed Sep 29 16:20:32 1999
X-Authentication-Warning: lohi.clinet.fi: majordom set sender to owner-linux-ipsec@clinet.fi using -f
From: Richard Guy Briggs <rgb@conscoop.ottawa.on.ca>
Message-Id: <199909292001.QAA26703@grendel.conscoop.ottawa.on.ca>
Subject: Re: linux-ipsec: Error in klips
To: mikael.andresen@i-data.com
Date: Wed, 29 Sep 1999 16:01:33 -0400 (EDT)
Cc: linux-ipsec@clinet.fi, peter.videcrantz@i-data.com,
david.roerup@i-data.com
In-Reply-To: <C12567FB.0060D8C2.00@idanst.i-data.com> from "mikael.andresen@i-data.com" at Sep 29, 99 07:37:48 pm
X-Mailer: ELM [version 2.4 PL25 PGP8]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-ipsec@clinet.fi
Precedence: bulk
> I think I have found a serious bug in klips (I am not using the
> latest version so I don't know if it's allready been corrected).
> Everytime a program calls netif_rx, interrupts should be disabled.
> This is NOT the case in the ipsec_rcv function! The reason for
> doing this is because when the network is fully loaded and a program
> calls the netif_rx without disabling interrupts the backlog_size can
> get screwed up if net_bh modifies the backlog_size at the same time.
Hmmm, having a look at net/ipv4/ipip.c and net/ipv4/ip_gre.c, neither
one of them does that either. Do they exhibit the same problems? How
can I monitor backlog_size?
Presumably whoever called us would have already set that, since
netif_rx() is originally handed the packet to make the decision to
hand it to us?
> I discovered the error because the backlog_size got out of sync with
> the actual number of packets in the backlog queue. The backlog_size
> was actually one bigger than the number of packets. When there is
> the maximum number of packets in the queue it will drop all
> following packets until the backlog queue is completely empty. When
> it is emptied the backlog_size will be one, but the netif_rx will
> only stop dropping packets until the backlog_size is zero. Therefore
> the network is completely stalled!
I could see how this might be a problem...
> This could be a solution for the problem (in ipsec_rcv) :
>
> cli();
> netif_rx(skb);
> sti();
Should this not be preceded by save_flags() to store and followed with
restore_flags() to restore the flags afterwards? (or whatever it is...)?
Right now I am having other locking problems, I suspect. See ||ugh
Daniel's post on 'Weekend Edition...' problem report. Again, ipip.c
and ip_gre.c aren't giving me much to go on...
> Regards Mikael Andresen, Lasat Networks.
slainte mhath, RGB
- --
Richard Guy Briggs -- PGP key available Auto-Free Ottawa! Canada
<http://www.conscoop.ottawa.on.ca/rgb/> </www.flora.org/afo/>
Prevent Internet Wiretapping! -- FreeS/WAN:<www.xs4all.nl/~freeswan>
Thanks for voting Green! -- <green.ca> Marillion:<www.marillion.co.uk>
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBN/LKIN+sBuIhFagtAQE+zgP/WLeAFmm6A3FnE2E08hT68n+X29uFrNpy
Teg97BFU9J641Timut4pTj4JUyovprTz1TwvXi7ebjUJO3sGJLwsCP3TUvAWlMT0
HITrMVHnQJsf/in871njdVY109GGTJHGg97j5wtduetgBkUiErCrR20DrMF+qUWs
8sYrjTCz1/A=
=se3C
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/