* Re: [RFC 3/7] NetLabel: CIPSOv4 engine
From: David Miller @ 2006-06-22 9:12 UTC (permalink / raw)
To: paul.moore
Cc: redhat-lspp, selinux, linux-security-module, netdev, sds, jmorris,
sgrubb
In-Reply-To: <20060621200031.589235000@flek.zko.hp.com>
From: paul.moore@hp.com
Date: Wed, 21 Jun 2006 15:42:38 -0400
> Add support for the Commercial IP Security Option (CIPSO) to the
> IPv4 network stack. CIPSO has become a de-facto standard for
> trusted/labeled networking amongst existing Trusted Operating
> Systems such as Trusted Solaris, HP-UX CMW, etc. This
> implementation is designed to be used with the NetLabel subsystem to
> provide explicit packet labeling to LSM developers.
The thing that concerns me most about CIPSO is that even once users
migrate to a more SELINUX native approach from this CIPSO stuff, the
CIPSO code, it's bloat, and it's maintainence burdon will remain.
It's easy to put stuff it, it's impossible to take stuff out even
once it's largely unused by even it's original target audience.
And that's what I see happening here.
This is why, to be perfectly honest with you, I'd much rather
something like this stay out-of-tree and people are strongly
encouraged to use the more native stuff under Linux.
^ permalink raw reply
* Re: Memory corruption in 8390.c ? (was Re: Possible leaks in network drivers)
From: Herbert Xu @ 2006-06-22 9:12 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Alan Cox, snakebyte, linux-kernel, netdev, davem
In-Reply-To: <20060622090227.GA28367@gondor.apana.org.au>
On Thu, Jun 22, 2006 at 07:02:27PM +1000, herbert wrote:
>
> > >cassini.c
> > >starfire.c
> > >yellowfin.c
> >
> > That doesn't really invalidate the point :) These drivers are still
> > only padding very small packets.
>
> Hmm, at least cassini pads it to 255 for gigabit...
The one in starfire looks especially dodgy. It supports SG and also
requires the whole length to be a multiple of 4 if the firmware is
broken. The question is do they really intend this or do they want
each fragment to terminate on a 4-byte boundary.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: No interfaces under /proc/sys/net/ipv4/conf/
From: Hasso Tepper @ 2006-06-22 9:20 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <200606221154.20999.hasso@estpak.ee>
Hasso Tepper:
> I can think of workarounds for most of problems (although it breaks a
> hell lot of software here), but how I suppose to configure ipv6
> settings for interfaces which have to obtain global ipv6 address via
> autoconf so that it will work even if cable is not plugged in? I did
> via /etc/sysctl.conf, but now ... machine boots with no link => no
> link-local address => no /proc/sys/net/ipv6/conf/<interfce> =>
> configuration fails.
Just realized (via practical experience) that same question applies to
interfaces configured via dhcp.
regards,
--
Hasso Tepper
^ permalink raw reply
* Re: [NET]: Prevent transmission after dev_deactivate
From: David Miller @ 2006-06-22 9:28 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20060622080856.GA21723@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 22 Jun 2006 18:08:56 +1000
> I found a bug in my GSO patches with the shutdown handling in
> dev_deactivate. It provided enough impetus for me to finally
> clean up this function :)
>
> This patch is against Linus's tree.
>
> [NET]: Prevent transmission after dev_deactivate
Looks good, applied, thanks a lot!
^ permalink raw reply
* [2.6 patch] make drivers/net/forcedeth.c:nv_update_pause() static
From: Adrian Bunk @ 2006-06-22 10:03 UTC (permalink / raw)
To: Ayaz Abdulla; +Cc: Manfred Spraul, linux-kernel, jgarzik, netdev
This patch makes the needlessly global nv_update_pause() static.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
This patch was already sent on:
- 16 May 2006
--- linux-2.6.17-rc4-mm1-full/drivers/net/forcedeth.c.old 2006-05-16 13:03:01.000000000 +0200
+++ linux-2.6.17-rc4-mm1-full/drivers/net/forcedeth.c 2006-05-16 13:03:08.000000000 +0200
@@ -2221,7 +2221,7 @@
spin_unlock_irq(&np->lock);
}
-void nv_update_pause(struct net_device *dev, u32 pause_flags)
+static void nv_update_pause(struct net_device *dev, u32 pause_flags)
{
struct fe_priv *np = netdev_priv(dev);
u8 __iomem *base = get_hwbase(dev);
^ permalink raw reply
* Re: [0/5] GSO: Generic Segmentation Offload
From: David Miller @ 2006-06-22 10:08 UTC (permalink / raw)
To: herbert; +Cc: netdev
In-Reply-To: <20060622081211.GA22505@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 22 Jun 2006 18:12:11 +1000
> This is a repost of the GSO patches. The main change is the fix to a bug
> in the way dev->gso_skb is freed. This series requires the dev_deactivate
> patch that I just posted.
Applied, thanks a lot Herbert.
^ permalink raw reply
* Re: [Bugme-new] [Bug 6730] New: pptp connection hang on heavy network load.
From: Andrew Morton @ 2006-06-22 10:15 UTC (permalink / raw)
To: bugme-daemon@kernel-bugs.osdl.org, netdev, wizard580
In-Reply-To: <200606221006.k5MA60v2020594@fire-2.osdl.org>
On Thu, 22 Jun 2006 03:06:00 -0700
bugme-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=6730
>
> Summary: pptp connection hang on heavy network load.
> Kernel Version: 2.6.17
> Status: NEW
> Severity: blocking
> Owner: acme@conectiva.com.br
> Submitter: wizard580@gmail.com
>
>
> Most recent kernel where this bug did not occur: 2.6.17
> Distribution: debian
> Hardware Environment: NVidia nForce2 GF6600 forcedeth driver.
> Software Environment: latest debian sid dist-upgrade on 22 june 2006
> Problem Description: when I make a many files (about 500 files near 1 Gb of total size,
> *.deb from last and previous upgrade for example ) upload to a server via ssh/scp, my vpn
> pptp connection hangs till i restart ppp connection. This problem persist not only a latest
> kernel. I don't remember when it begin to hangs. It very-very annoying and makes me
> difficult to make my daily job. If I do not make such "heavy" network vpn traffic, I can
> work for a weeks without reboots and any problems
>
> Steps to reproduce:
> Start to copy big amount of data over pptp connection from a client linux machine. Ex. via
> ssh/scp.
>
We thought we'd fixed this :(
^ permalink raw reply
* Re: Suspending 802.11 drivers
From: Luis R. Rodriguez @ 2006-06-22 10:56 UTC (permalink / raw)
To: Stefan Rompf
Cc: Michael Buesch, Jiri Benc, John W. Linville, netdev, bcm43xx-dev
In-Reply-To: <200606220007.07467.stefan@loplof.de>
On 6/21/06, Stefan Rompf <stefan@loplof.de> wrote:
> Am Mittwoch 21 Juni 2006 17:08 schrieb Luis R. Rodriguez:
>
> > Since d80211 is already being patched for sysfs how about we use sysfs
> > (and kobjects) to maintain the state at suspend() and resume(). This
> > would allow userspace tools like supplicant running in the background
> > to pick up from sysfs where it left off and for our drivers to save
> > where we left off.
>
> Forgive me that I'm so insistant on this question, but this is important: What
> state that goes beyond the data settable with wireless ioctls/iwconfig (that
> is kept anyway) needs to be saved by the stack? Last association info is
> worthless, the assocation can be restored using the ESSID/BSSID/channel set
> with iwconfig or by wpa_supplicant. Important is that userspace is notified
> about the connection loss. Is there _any_ other information not recreatable
> from iwconfig settings that needs to be kept?
>
> Stefan
Stefan, this is an excellent and valid question. Let me elaborate --
Its exactly those settings you mention I'm suggesting get saved onto
sysfs by the driver and later get picked up by userspace. There are,
however, other settings which could get saved when suspending too
though, settings for example, which otherwise would get set by current
private wireless ioctls. There are too many here to describe really,
each device has their own set of of private attributes.
More on this in another e-mail I'm about to send to netdev.
Luis
^ permalink raw reply
* Re: ipv6 source address selection in addrconf.c (2.6.17)
From: Lukasz Stelmach @ 2006-06-22 11:04 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: netdev
In-Reply-To: <20060622.092659.76693840.yoshfuji@linux-ipv6.org>
[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]
YOSHIFUJI Hideaki / 吉藤英明 wrote:
> In article <4499CEF4.2050308@poczta.fm> (at Thu, 22 Jun 2006 00:57:56 +0200), Lukasz Stelmach <stlman@poczta.fm> says:
>
>> Lukasz Stelmach wrote:
>>> Lukasz Stelmach wrote:
[....]
>>
>> fd24:6f44:46bd:face:EUI64 fd24:6f44:46bd:face:RANDOM
>> and
>> 2002:531f:d667:face:EUI64 2002:531f:d667:face::RANDOM
>>
>> there seem to be no way to prefere 2002:: over fc00:: in rule 7 and it will be
>> selected as long as it is before 2002:: on the list. I can see here that an
>> implicit assumption has been made that an interface either is multihomed or
>> "private". The seventh rule should not IMHO break the whole process of
>> selection but rather mark as selectable all "private" (random) addresses. And
>> it should rather be done before rule 6.
>
> Hmm? We do not have such intention.
> In above case, when you connect to 2001:200:0:8002:203:47ff:fea5:3085,
> either 2002:531f:d667:face:EUI64 or 2002:531f:d667:face::RANDOM
> should be selected (depending on if use_tempaddr >= 2),
> by the longest matching rule (Rule 8).
I've chewd the code line by line and it tastes like it should work the way you
say... OK I see the problem. I've used ifconfig which doesn't show
"deprecated" flag and "valid"/"prefered" times which, combined with "privacy",
*seem* to cause some problems . I don't know yet if it is a problem of proper
intervals in radvd.conf or is there still a bug in kernel. I'll let you know
when I learn it.
OK. That's enough for now. Let me get back to the real work ;-)
Best regards.
--
Było mi bardzo miło. Czwarta pospolita klęska, [...]
>Łukasz< Już nie katolicka lecz złodziejska. (c)PP
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply
* [PATCH 0/32] TIPC updates
From: Per Liden @ 2006-06-22 11:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, per.liden
Here's a resend of the latest TIPC updates. I apologize for not properly
submitting the patches for review the first time around.
This patch set includes several minor bugfixes. Most of them ported over
from an older TIPC 1.5.x branch maintained on sourceforge (that branch is
being phased).
Patches can be pulled from:
git://tipc.cslab.ericsson.net/pub/git/tipc.git
Summary:
include/net/tipc/tipc_bearer.h | 12 ++
net/tipc/bcast.c | 79 ++++++++-------
net/tipc/bcast.h | 2
net/tipc/bearer.c | 70 +++++++------
net/tipc/cluster.c | 22 ++--
net/tipc/config.c | 85 +++++++---------
net/tipc/core.c | 7 +
net/tipc/core.h | 21 +++-
net/tipc/discover.c | 13 +-
net/tipc/eth_media.c | 29 +++--
net/tipc/link.c | 217 +++++++++++++++++++++++++++++++---------
net/tipc/name_distr.c | 30 ++++--
net/tipc/name_table.c | 203 ++++++++++++++++++++-----------------
net/tipc/node.c | 78 ++++++++------
net/tipc/node.h | 2
net/tipc/node_subscr.c | 15 +--
net/tipc/port.c | 41 ++++----
net/tipc/ref.c | 31 +++++-
net/tipc/socket.c | 100 +++++++++++-------
net/tipc/subscr.c | 18 ++-
net/tipc/zone.c | 19 ++--
21 files changed, 661 insertions(+), 433 deletions(-)
Allan Stephens:
[TIPC] Prevent name table corruption if no room for new publication
[TIPC] Use correct upper bound when validating network zone number.
[TIPC] Corrected potential misuse of tipc_media_addr structure.
[TIPC] Allow ports to receive multicast messages through native API.
[TIPC] Links now validate destination node specified by incoming messages.
[TIPC] Multicast link failure now resets all links to "nacking" node.
[TIPC] Allow compilation when CONFIG_TIPC_DEBUG is not set.
[TIPC] Fixed privilege checking typo in dest_name_check().
[TIPC] Fix misleading comment in buf_discard() routine.
[TIPC] Added support for MODULE_VERSION capability.
[TIPC] Validate entire interface name when locating bearer to enable.
[TIPC] Non-operation-affecting corrections to comments & function definitions.
[TIPC] Fixed connect() to detect a dest address that is missing or too short.
[TIPC] Implied connect now saves dest name for retrieval as ancillary data.
[TIPC] Can now return destination name of form {0,x,y} via ancillary data.
[TIPC] Connected send now checks socket state when retrying congested send.
[TIPC] Stream socket send indicates partial success if data partially sent.
[TIPC] Improved performance of error checking during socket creation.
[TIPC] recvmsg() now returns TIPC ancillary data using correct level (SOL_TIPC)
[TIPC] Simplify code for returning partial success of stream send request.
[TIPC] Optimized argument validation done by connect().
[TIPC] Withdrawing all names from nameless port now returns success, not error
[TIPC] Added missing warning for out-of-memory condition
[TIPC] Fixed memory leak in tipc_link_send() when destination is unreachable
[TIPC] Disallow config operations that aren't supported in certain modes.
[TIPC] First phase of assert() cleanup
[TIPC] Enhanced & cleaned up system messages; fixed 2 obscure memory leaks.
[TIPC] Fixed link switchover bugs
[TIPC] Get rid of dynamically allocated arrays in broadcast code.
[TIPC] Fix incorrect correction to discovery timer frequency computation.
Eric Sesterhenn:
[TIPC] Fix for NULL pointer dereference
Jon Maloy:
[TIPC] Improved tolerance to promiscuous mode interface
/Per
^ permalink raw reply
* Re: Memory corruption in 8390.c ?
From: Alan Cox @ 2006-06-22 11:34 UTC (permalink / raw)
To: David Miller; +Cc: herbert, snakebyte, linux-kernel, jgarzik, netdev
In-Reply-To: <20060622.013440.97293561.davem@davemloft.net>
Ar Iau, 2006-06-22 am 01:34 -0700, ysgrifennodd David Miller:
> From: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Thu, 22 Jun 2006 18:30:37 +1000
>
> > On Thu, Jun 22, 2006 at 01:26:09AM -0700, David Miller wrote:
> > >
> > > Want me to let this cook in 2.6.18 for a while before sending
> > > it off to -stable?
> >
> > You know I'm never one to push anything quickly so absolutely yes :)
>
> Ok, applied to net-2.6.18 for now :)
The 8390 change (corrected version) also makes 8390.c faster so should
be applied anyway, and the orinoco one fixes some code that isn't even
needed and someone forgot to remove long ago. Otherwise the skb_padto
behaviour change with the newer skb style makes a lot more sense I
agree.
^ permalink raw reply
* Re: Memory corruption in 8390.c ?
From: Herbert Xu @ 2006-06-22 11:29 UTC (permalink / raw)
To: Alan Cox; +Cc: davem, herbert, snakebyte, linux-kernel, jgarzik, netdev
In-Reply-To: <1150976063.15275.146.camel@localhost.localdomain>
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> The 8390 change (corrected version) also makes 8390.c faster so should
> be applied anyway, and the orinoco one fixes some code that isn't even
> needed and someone forgot to remove long ago. Otherwise the skb_padto
Yeah I agree totally. However, I haven't actually seen the fixed 8390
version being posted yet or at least not to netdev :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Memory corruption in 8390.c ?
From: Arjan van de Ven @ 2006-06-22 11:33 UTC (permalink / raw)
To: Alan Cox; +Cc: David Miller, herbert, snakebyte, linux-kernel, jgarzik, netdev
In-Reply-To: <1150976063.15275.146.camel@localhost.localdomain>
On Thu, 2006-06-22 at 12:34 +0100, Alan Cox wrote:
> Ar Iau, 2006-06-22 am 01:34 -0700, ysgrifennodd David Miller:
> > From: Herbert Xu <herbert@gondor.apana.org.au>
> > Date: Thu, 22 Jun 2006 18:30:37 +1000
> >
> > > On Thu, Jun 22, 2006 at 01:26:09AM -0700, David Miller wrote:
> > > >
> > > > Want me to let this cook in 2.6.18 for a while before sending
> > > > it off to -stable?
> > >
> > > You know I'm never one to push anything quickly so absolutely yes :)
> >
> > Ok, applied to net-2.6.18 for now :)
>
> The 8390 change (corrected version) also makes 8390.c faster so should
> be applied anyway,
8390 is such a race monster that a few cycles matter a lot! :-)
^ permalink raw reply
* Re: Memory corruption in 8390.c ?
From: Erik Mouw @ 2006-06-22 12:00 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Alan Cox, David Miller, herbert, snakebyte, linux-kernel, jgarzik,
netdev
In-Reply-To: <1150976016.3120.19.camel@laptopd505.fenrus.org>
On Thu, Jun 22, 2006 at 01:33:36PM +0200, Arjan van de Ven wrote:
> On Thu, 2006-06-22 at 12:34 +0100, Alan Cox wrote:
> > The 8390 change (corrected version) also makes 8390.c faster so should
> > be applied anyway,
>
> 8390 is such a race monster that a few cycles matter a lot! :-)
It sure is. Back in the old days I could saturate a 10 Mbit ethernet
segment using a Western Digital 8003 (the 8 bit ISA card) in a 386DX40
(running Linux 1.0, 1.2, and 1.3).
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
^ permalink raw reply
* [RFC] sysfs + configfs on 802.11 wireless drivers
From: Luis R. Rodriguez @ 2006-06-22 12:12 UTC (permalink / raw)
To: netdev; +Cc: John W. Linville, Greg KH
Rebel fleet of wireless developers,
Here's some changes which I think our current wireless stacks could
use to assist cleaning up WEs, private ioctls, and provide userspace a
cleaner framework to interact with our wireless drivers.
Kernel level:
(1) Use the new *configfs* for all user-specific attributes
(2) Use *sysfs* read-only kobjects for device-specific attributes like
values which can be saved for suspend() and collected for resume().
IEEE 802.11 capabilities, features (for example radiotap), and what is
currently settable/gettable from private ioctl realm along with its
restrictions can also be exported via sysfs.
(3) On resume() talk to userspace via netlink to read our sysfs and configfs us
Userspace applications can then:
(1) Interact with configfs for configuring wireless devices, including
what used to be set by private ioctls
(2) Retrieve attributes saved from sysfs and set them onto configfs
after resume(). Sysfs will also tell us this card's capabilities,
features and private data along with their respective restrictions we
can work with so -- userspace can modify the available options which
can be gettable/settable.
(3) Respond to netlink communication from driver after resume() to set
data through configfs
---
I know we recently moved WE to netlink but I figured celebrating the
happy marriage of Mr. sysfs and Mrs. configfs on 2.6.16 by giving them
offspring would be nice and more appropriate. Here's an example
run-through of how this would work:
(1) A wireless device comes up and spits out device-specific default
settings on sysfs
(2) If a user wants to change essid, channel, power-save-mode (this is
not suspend()), rate, and so forth userspace writes the settings into
configfs, these would in turn get updated on sysfs by the driver.
(3) Should the device go into suspend() the driver can then update its
necessary attributes on sysfs required to recover from suspend() which
may not have been updated yet (whatever they may be)
(4) At resume() we could just have our driver read our sysfs
attributes and try to set all of them back exactly how they were
before but to reduce bloat on our drivers and since our state is
already exported we could just have userspace do it for us so... we
use netlink to communicate to userspace to go ahead and ask it to
resume() us. Advantages of this would be userspace would always
consistantly handle the assoc/desassoc and WPA in a consistent manner
and as mentioned above, driver bloatness killing.
(5) At resume() userspace reads sysfs and sets us back up through configfs
Comments are appreciated, if this is something that seems desirable I
can start cranking up some code.
Luis
^ permalink raw reply
* Re: Memory corruption in 8390.c ?
From: Alan Cox @ 2006-06-22 13:10 UTC (permalink / raw)
To: Arjan van de Ven
Cc: David Miller, herbert, snakebyte, linux-kernel, jgarzik, netdev
In-Reply-To: <1150976016.3120.19.camel@laptopd505.fenrus.org>
Ar Iau, 2006-06-22 am 13:33 +0200, ysgrifennodd Arjan van de Ven:
> > The 8390 change (corrected version) also makes 8390.c faster so should
> > be applied anyway,
>
> 8390 is such a race monster that a few cycles matter a lot! :-)
There are generic 8390 clones for 100Mbit. I'm not suggesting its a good
idea but people did it.
Alan
^ permalink raw reply
* Re: Memory corruption in 8390.c ?
From: Alan Cox @ 2006-06-22 13:25 UTC (permalink / raw)
To: Herbert Xu; +Cc: davem, snakebyte, linux-kernel, jgarzik, netdev
In-Reply-To: <E1FtNNQ-0001QW-00@gondolin.me.apana.org.au>
Ar Iau, 2006-06-22 am 21:29 +1000, ysgrifennodd Herbert Xu:
> Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> >
> > The 8390 change (corrected version) also makes 8390.c faster so should
> > be applied anyway, and the orinoco one fixes some code that isn't even
> > needed and someone forgot to remove long ago. Otherwise the skb_padto
>
> Yeah I agree totally. However, I haven't actually seen the fixed 8390
> version being posted yet or at least not to netdev :)
Ah the resounding clang of a subtle hint ;)
Signed-off-by: Alan Cox <alan@redhat.com>
- Return 8390.c to the old way of handling short packets (which is also
faster)
- Remove the skb_padto from orinoco. This got left in when the padding bad
write patch was added and is actually not needed. This is fixing a merge
error way back when.
- Wavelan can also use the stack based buffer trick if you want
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.17/drivers/net/8390.c linux-2.6.17/drivers/net/8390.c
--- linux.vanilla-2.6.17/drivers/net/8390.c 2006-06-19 17:17:32.000000000 +0100
+++ linux-2.6.17/drivers/net/8390.c 2006-06-21 21:23:12.000000000 +0100
@@ -275,12 +275,14 @@
struct ei_device *ei_local = (struct ei_device *) netdev_priv(dev);
int send_length = skb->len, output_page;
unsigned long flags;
+ char buf[ETH_ZLEN];
+ char *data = skb->data;
if (skb->len < ETH_ZLEN) {
- skb = skb_padto(skb, ETH_ZLEN);
- if (skb == NULL)
- return 0;
+ memset(buf, 0, ETH_ZLEN); /* more efficient than doing just the needed bits */
+ memcpy(buf, data, skb->len);
send_length = ETH_ZLEN;
+ data = buf;
}
/* Mask interrupts from the ethercard.
@@ -347,7 +349,7 @@
* trigger the send later, upon receiving a Tx done interrupt.
*/
- ei_block_output(dev, send_length, skb->data, output_page);
+ ei_block_output(dev, send_length, data, output_page);
if (! ei_local->txing)
{
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.17/drivers/net/wireless/orinoco.c linux-2.6.17/drivers/net/wireless/orinoco.c
--- linux.vanilla-2.6.17/drivers/net/wireless/orinoco.c 2006-06-19 17:29:48.000000000 +0100
+++ linux-2.6.17/drivers/net/wireless/orinoco.c 2006-06-21 18:19:02.000000000 +0100
@@ -491,11 +491,8 @@
}
/* Length of the packet body */
- /* FIXME: what if the skb is smaller than this? */
+ /* A shorter data_len will be padded by hermes_bap_pwrite_pad */
len = max_t(int, ALIGN(skb->len, 2), ETH_ZLEN);
- skb = skb_padto(skb, len);
- if (skb == NULL)
- goto fail;
len -= ETH_HLEN;
eh = (struct ethhdr *)skb->data;
diff -u --new-file --recursive --exclude-from /usr/src/exclude linux.vanilla-2.6.17/drivers/net/wireless/wavelan.c linux-2.6.17/drivers/net/wireless/wavelan.c
--- linux.vanilla-2.6.17/drivers/net/wireless/wavelan.c 2006-06-19 17:29:48.000000000 +0100
+++ linux-2.6.17/drivers/net/wireless/wavelan.c 2006-06-21 18:32:47.000000000 +0100
@@ -2903,6 +2903,7 @@
{
net_local *lp = (net_local *) dev->priv;
unsigned long flags;
+ char data[ETH_ZLEN];
#ifdef DEBUG_TX_TRACE
printk(KERN_DEBUG "%s: ->wavelan_packet_xmit(0x%X)\n", dev->name,
@@ -2937,15 +2938,16 @@
* able to detect collisions, therefore in theory we don't really
* need to pad. Jean II */
if (skb->len < ETH_ZLEN) {
- skb = skb_padto(skb, ETH_ZLEN);
- if (skb == NULL)
- return 0;
+ memset(data, 0, ETH_ZLEN);
+ memcpy(data, skb->data, skb->len);
+ /* Write packet on the card */
+ if(wv_packet_write(dev, data, ETH_ZLEN))
+ return 1; /* We failed */
}
-
- /* Write packet on the card */
- if(wv_packet_write(dev, skb->data, skb->len))
+ else if(wv_packet_write(dev, skb->data, skb->len))
return 1; /* We failed */
+
dev_kfree_skb(skb);
#ifdef DEBUG_TX_TRACE
^ permalink raw reply
* Re: [RFC 2/7] NetLabel: core network changes
From: Paul Moore @ 2006-06-22 13:20 UTC (permalink / raw)
To: David Miller
Cc: jmorris, sds, redhat-lspp, linux-security-module, selinux, netdev,
sgrubb
In-Reply-To: <20060622.020748.85685000.davem@davemloft.net>
On Thursday 22 June 2006 5:07 am, David Miller wrote:
> From: paul.moore@hp.com
> Date: Wed, 21 Jun 2006 15:42:37 -0400
>
> > Index: linux-2.6.17.i686-quilt/net/ipv4/Makefile
> > ===================================================================
> > --- linux-2.6.17.i686-quilt.orig/net/ipv4/Makefile
> > +++ linux-2.6.17.i686-quilt/net/ipv4/Makefile
> > @@ -42,6 +42,9 @@ obj-$(CONFIG_TCP_CONG_HYBLA) += tcp_hybl
> > obj-$(CONFIG_TCP_CONG_HTCP) += tcp_htcp.o
> > obj-$(CONFIG_TCP_CONG_VEGAS) += tcp_vegas.o
> > obj-$(CONFIG_TCP_CONG_SCALABLE) += tcp_scalable.o
> > +ifeq ($(CONFIG_NETLABEL_CIPSOV4),y)
> > +obj-y += cipso_ipv4.o
> > +endif
>
> Why not "obj-$CONFIG_NETLABEL_CIPSOV4 += cipso_ipv4.o"?
>
> The whole idea behind the obj-$CONFIG_OPTION technique is
> to avoid conditionals all over the makefile.
Because it's not supported as a module and I thought I saw some similar
examples in other Makefiles. No matter, I'll make the change.
> > Index: linux-2.6.17.i686-quilt/net/ipv4/af_inet.c
> > ===================================================================
> > --- linux-2.6.17.i686-quilt.orig/net/ipv4/af_inet.c
> > +++ linux-2.6.17.i686-quilt/net/ipv4/af_inet.c
> > @@ -114,6 +114,7 @@
> > #ifdef CONFIG_IP_MROUTE
> > #include <linux/mroute.h>
> > #endif
> > +#include <net/netlabel.h>
> >
> > DEFINE_SNMP_STAT(struct linux_mib, net_statistics) __read_mostly;
> >
> > @@ -616,6 +617,8 @@ int inet_accept(struct socket *sock, str
> >
> > sock_graft(sk2, newsock);
> >
> > + netlbl_socket_inet_accept(sock, newsock);
> > +
> > newsock->state = SS_CONNECTED;
> > err = 0;
> > release_sock(sk2);
>
> Neither the netlabel.h header not the implementation of
> the netlbl_socket_inet_accept() function exist at this
> point in your patch set.
>
> At each patch point, the tree must build and function
> properly.
>
> This means you have to split up and order your changes
> correctly, gradually building up the infrastructure and
> then finally plugging it in and making use of it.
>
> Nobody can test your work in an incremental fashion, and
> thus it's not possible to determine if a bug or behavior
> gets introduced at patch 2, 3 or 4, for example.
I intended the entire patch set to be digested as a whole, the only reason I
split it up into several different patches was to get around size limitations
in the mailing list. I'll go ahead and rearrange things so they build
incrementally.
Thanks for your patience.
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: [RFC 3/7] NetLabel: CIPSOv4 engine
From: Paul Moore @ 2006-06-22 13:43 UTC (permalink / raw)
To: David Miller
Cc: redhat-lspp, selinux, linux-security-module, netdev, sds, jmorris,
sgrubb
In-Reply-To: <20060622.021223.125894633.davem@davemloft.net>
On Thursday 22 June 2006 5:12 am, David Miller wrote:
> From: paul.moore@hp.com
> Date: Wed, 21 Jun 2006 15:42:38 -0400
>
> > Add support for the Commercial IP Security Option (CIPSO) to the
> > IPv4 network stack. CIPSO has become a de-facto standard for
> > trusted/labeled networking amongst existing Trusted Operating
> > Systems such as Trusted Solaris, HP-UX CMW, etc. This
> > implementation is designed to be used with the NetLabel subsystem to
> > provide explicit packet labeling to LSM developers.
>
> The thing that concerns me most about CIPSO is that even once users
> migrate to a more SELINUX native approach from this CIPSO stuff, the
> CIPSO code, it's bloat, and it's maintainence burdon will remain.
>
> It's easy to put stuff it, it's impossible to take stuff out even
> once it's largely unused by even it's original target audience.
>
> And that's what I see happening here.
>
> This is why, to be perfectly honest with you, I'd much rather
> something like this stay out-of-tree and people are strongly
> encouraged to use the more native stuff under Linux.
Well, not exactly the response I was hoping for, but let me plead my case one
more time :)
Traditional MLS CIPSO is a niche "protocol", I won't try to argue that point,
and I also won't try to argue that the NetLabel patch is late to the party,
the IPsec/XFRM labeling approach has already been accepted as "the" SELinux
packet labeling mechanism. However, the XFRM labeling mechanism in not
currently supported by any OS other than Linux/SELinux. I have spoken with
users that need CIPSO to interoperate with their other trusted systems, the
XFRM approach is simply not a viable solution for them. I strongly believe
that failure to support an interoperable packet labeling mechanism on Linux
will seriously restrict Linux's deployment in trusted networks.
It's all about compatibility and enabling Linux to be used in places it can't
be used now. True, other OS vendors might support the SELinux/IPsec packet
labeling approach, but I see very little in the way of motivation for them to
do the work.
If it makes you feel any better I do intend to support the Selopt approach (or
at least something very similar) for CIPSO as envisioned by James Morris for
the SELinux networking hooks of long ago. This will allow CIPSO to carry the
full SELinux context making it a more "SELINUX native approach" than
traditional MLS CIPSO. I just wanted to keep this initial patch set as small
as possible (you can see how well that worked out) ... :)
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: [PATCH 0/2][RFC] Network Event Notifier Mechanism
From: Steve Wise @ 2006-06-22 13:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20060622.015728.59653992.davem@davemloft.net>
On Thu, 2006-06-22 at 01:57 -0700, David Miller wrote:
> From: Steve Wise <swise@opengridcomputing.com>
> Date: Wed, 21 Jun 2006 13:45:19 -0500
>
> > This patch implements a mechanism that allows interested clients to
> > register for notification of certain network events.
>
> We have a generic network event notification facility called
> netlink, please use it and extend it for your needs if necessary.
I'll investigate this.
Thanks,
Steve.
^ permalink raw reply
* [PATCH 4/32] [TIPC] Corrected potential misuse of tipc_media_addr structure.
From: Per Liden @ 2006-06-22 13:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Allan Stephens
In-Reply-To: <Pine.LNX.4.64.0606221233570.15853@ulinpc219.uab.ericsson.se>
From: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Per Liden <per.liden@ericsson.com>
---
include/net/tipc/tipc_bearer.h | 12 ++++++++++--
net/tipc/eth_media.c | 4 +++-
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/include/net/tipc/tipc_bearer.h b/include/net/tipc/tipc_bearer.h
index 098607c..e07136d 100644
--- a/include/net/tipc/tipc_bearer.h
+++ b/include/net/tipc/tipc_bearer.h
@@ -49,10 +49,18 @@ #include <linux/spinlock.h>
#define TIPC_MEDIA_TYPE_ETH 1
+/*
+ * Destination address structure used by TIPC bearers when sending messages
+ *
+ * IMPORTANT: The fields of this structure MUST be stored using the specified
+ * byte order indicated below, as the structure is exchanged between nodes
+ * as part of a link setup process.
+ */
+
struct tipc_media_addr {
- __u32 type;
+ __u32 type; /* bearer type (network byte order) */
union {
- __u8 eth_addr[6]; /* Ethernet bearer */
+ __u8 eth_addr[6]; /* 48 bit Ethernet addr (byte array) */
#if 0
/* Prototypes for other possible bearer types */
diff --git a/net/tipc/eth_media.c b/net/tipc/eth_media.c
index b646619..3ecb100 100644
--- a/net/tipc/eth_media.c
+++ b/net/tipc/eth_media.c
@@ -254,7 +254,9 @@ int tipc_eth_media_start(void)
if (eth_started)
return -EINVAL;
- memset(&bcast_addr, 0xff, sizeof(bcast_addr));
+ bcast_addr.type = htonl(TIPC_MEDIA_TYPE_ETH);
+ memset(&bcast_addr.dev_addr, 0xff, ETH_ALEN);
+
memset(eth_bearers, 0, sizeof(eth_bearers));
res = tipc_register_media(TIPC_MEDIA_TYPE_ETH, "eth",
--
1.4.0
^ permalink raw reply related
* [PATCH 5/32] [TIPC] Allow ports to receive multicast messages through native API.
From: Per Liden @ 2006-06-22 13:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Allan Stephens
In-Reply-To: <Pine.LNX.4.64.0606221233570.15853@ulinpc219.uab.ericsson.se>
From: Allan Stephens <allan.stephens@windriver.com>
This fix prevents a kernel panic if an application mistakenly sends a
multicast message to TIPC's topology service or configuration service.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Per Liden <per.liden@ericsson.com>
---
net/tipc/port.c | 26 ++++++++++++++++----------
1 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/net/tipc/port.c b/net/tipc/port.c
index 67e96cb..360920b 100644
--- a/net/tipc/port.c
+++ b/net/tipc/port.c
@@ -810,18 +810,20 @@ static void port_dispatcher_sigh(void *d
void *usr_handle;
int connected;
int published;
+ u32 message_type;
struct sk_buff *next = buf->next;
struct tipc_msg *msg = buf_msg(buf);
u32 dref = msg_destport(msg);
+ message_type = msg_type(msg);
+ if (message_type > TIPC_DIRECT_MSG)
+ goto reject; /* Unsupported message type */
+
p_ptr = tipc_port_lock(dref);
- if (!p_ptr) {
- /* Port deleted while msg in queue */
- tipc_reject_msg(buf, TIPC_ERR_NO_PORT);
- buf = next;
- continue;
- }
+ if (!p_ptr)
+ goto reject; /* Port deleted while msg in queue */
+
orig.ref = msg_origport(msg);
orig.node = msg_orignode(msg);
up_ptr = p_ptr->user_port;
@@ -832,7 +834,7 @@ static void port_dispatcher_sigh(void *d
if (unlikely(msg_errcode(msg)))
goto err;
- switch (msg_type(msg)) {
+ switch (message_type) {
case TIPC_CONN_MSG:{
tipc_conn_msg_event cb = up_ptr->conn_msg_cb;
@@ -874,6 +876,7 @@ static void port_dispatcher_sigh(void *d
&orig);
break;
}
+ case TIPC_MCAST_MSG:
case TIPC_NAMED_MSG:{
tipc_named_msg_event cb = up_ptr->named_msg_cb;
@@ -886,7 +889,8 @@ static void port_dispatcher_sigh(void *d
goto reject;
dseq.type = msg_nametype(msg);
dseq.lower = msg_nameinst(msg);
- dseq.upper = dseq.lower;
+ dseq.upper = (message_type == TIPC_NAMED_MSG)
+ ? dseq.lower : msg_nameupper(msg);
skb_pull(buf, msg_hdr_sz(msg));
cb(usr_handle, dref, &buf, msg_data(msg),
msg_data_sz(msg), msg_importance(msg),
@@ -899,7 +903,7 @@ static void port_dispatcher_sigh(void *d
buf = next;
continue;
err:
- switch (msg_type(msg)) {
+ switch (message_type) {
case TIPC_CONN_MSG:{
tipc_conn_shutdown_event cb =
@@ -931,6 +935,7 @@ err:
msg_data_sz(msg), msg_errcode(msg), &orig);
break;
}
+ case TIPC_MCAST_MSG:
case TIPC_NAMED_MSG:{
tipc_named_msg_err_event cb =
up_ptr->named_err_cb;
@@ -940,7 +945,8 @@ err:
break;
dseq.type = msg_nametype(msg);
dseq.lower = msg_nameinst(msg);
- dseq.upper = dseq.lower;
+ dseq.upper = (message_type == TIPC_NAMED_MSG)
+ ? dseq.lower : msg_nameupper(msg);
skb_pull(buf, msg_hdr_sz(msg));
cb(usr_handle, dref, &buf, msg_data(msg),
msg_data_sz(msg), msg_errcode(msg), &dseq);
--
1.4.0
^ permalink raw reply related
* [PATCH 3/32] [TIPC] Use correct upper bound when validating network zone number.
From: Per Liden @ 2006-06-22 13:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Allan Stephens
In-Reply-To: <Pine.LNX.4.64.0606221233570.15853@ulinpc219.uab.ericsson.se>
From: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Per Liden <per.liden@ericsson.com>
---
net/tipc/core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/tipc/core.c b/net/tipc/core.c
index 3d0a8ee..31c7dd5 100644
--- a/net/tipc/core.c
+++ b/net/tipc/core.c
@@ -198,7 +198,7 @@ static int __init tipc_init(void)
tipc_max_publications = 10000;
tipc_max_subscriptions = 2000;
tipc_max_ports = delimit(CONFIG_TIPC_PORTS, 127, 65536);
- tipc_max_zones = delimit(CONFIG_TIPC_ZONES, 1, 511);
+ tipc_max_zones = delimit(CONFIG_TIPC_ZONES, 1, 255);
tipc_max_clusters = delimit(CONFIG_TIPC_CLUSTERS, 1, 1);
tipc_max_nodes = delimit(CONFIG_TIPC_NODES, 8, 2047);
tipc_max_slaves = delimit(CONFIG_TIPC_SLAVE_NODES, 0, 2047);
--
1.4.0
^ permalink raw reply related
* [PATCH 7/32] [TIPC] Multicast link failure now resets all links to "nacking" node.
From: Per Liden @ 2006-06-22 13:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Allan Stephens
In-Reply-To: <Pine.LNX.4.64.0606221233570.15853@ulinpc219.uab.ericsson.se>
From: Allan Stephens <allan.stephens@windriver.com>
This fix prevents node from crashing.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Per Liden <per.liden@ericsson.com>
---
net/tipc/bcast.c | 32 +++++++++++---
net/tipc/link.c | 124 +++++++++++++++++++++++++++++++++++++++++++++---------
2 files changed, 128 insertions(+), 28 deletions(-)
diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index 2c4ecbe..00691b7 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -49,13 +49,19 @@ #include "bearer.h"
#include "name_table.h"
#include "bcast.h"
-
#define MAX_PKT_DEFAULT_MCAST 1500 /* bcast link max packet size (fixed) */
#define BCLINK_WIN_DEFAULT 20 /* bcast link window size (default) */
#define BCLINK_LOG_BUF_SIZE 0
+/*
+ * Loss rate for incoming broadcast frames; used to test retransmission code.
+ * Set to N to cause every N'th frame to be discarded; 0 => don't discard any.
+ */
+
+#define TIPC_BCAST_LOSS_RATE 0
+
/**
* struct bcbearer_pair - a pair of bearers used by broadcast link
* @primary: pointer to primary bearer
@@ -165,21 +171,18 @@ static int bclink_ack_allowed(u32 n)
* @after: sequence number of last packet to *not* retransmit
* @to: sequence number of last packet to retransmit
*
- * Called with 'node' locked, bc_lock unlocked
+ * Called with bc_lock locked
*/
static void bclink_retransmit_pkt(u32 after, u32 to)
{
struct sk_buff *buf;
- spin_lock_bh(&bc_lock);
buf = bcl->first_out;
while (buf && less_eq(buf_seqno(buf), after)) {
buf = buf->next;
}
- if (buf != NULL)
- tipc_link_retransmit(bcl, buf, mod(to - after));
- spin_unlock_bh(&bc_lock);
+ tipc_link_retransmit(bcl, buf, mod(to - after));
}
/**
@@ -399,7 +402,10 @@ int tipc_bclink_send_msg(struct sk_buff
*/
void tipc_bclink_recv_pkt(struct sk_buff *buf)
-{
+{
+#if (TIPC_BCAST_LOSS_RATE)
+ static int rx_count = 0;
+#endif
struct tipc_msg *msg = buf_msg(buf);
struct node* node = tipc_node_find(msg_prevnode(msg));
u32 next_in;
@@ -420,9 +426,13 @@ void tipc_bclink_recv_pkt(struct sk_buff
tipc_node_lock(node);
tipc_bclink_acknowledge(node, msg_bcast_ack(msg));
tipc_node_unlock(node);
+ spin_lock_bh(&bc_lock);
bcl->stats.recv_nacks++;
+ bcl->owner->next = node; /* remember requestor */
bclink_retransmit_pkt(msg_bcgap_after(msg),
msg_bcgap_to(msg));
+ bcl->owner->next = NULL;
+ spin_unlock_bh(&bc_lock);
} else {
tipc_bclink_peek_nack(msg_destnode(msg),
msg_bcast_tag(msg),
@@ -433,6 +443,14 @@ void tipc_bclink_recv_pkt(struct sk_buff
return;
}
+#if (TIPC_BCAST_LOSS_RATE)
+ if (++rx_count == TIPC_BCAST_LOSS_RATE) {
+ rx_count = 0;
+ buf_discard(buf);
+ return;
+ }
+#endif
+
tipc_node_lock(node);
receive:
deferred = node->bclink.deferred_head;
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 955b87d..ba7d3f1 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1604,40 +1604,121 @@ void tipc_link_push_queue(struct link *l
tipc_bearer_schedule(l_ptr->b_ptr, l_ptr);
}
+static void link_reset_all(unsigned long addr)
+{
+ struct node *n_ptr;
+ char addr_string[16];
+ u32 i;
+
+ read_lock_bh(&tipc_net_lock);
+ n_ptr = tipc_node_find((u32)addr);
+ if (!n_ptr) {
+ read_unlock_bh(&tipc_net_lock);
+ return; /* node no longer exists */
+ }
+
+ tipc_node_lock(n_ptr);
+
+ warn("Resetting all links to %s\n",
+ addr_string_fill(addr_string, n_ptr->addr));
+
+ for (i = 0; i < MAX_BEARERS; i++) {
+ if (n_ptr->links[i]) {
+ link_print(n_ptr->links[i], TIPC_OUTPUT,
+ "Resetting link\n");
+ tipc_link_reset(n_ptr->links[i]);
+ }
+ }
+
+ tipc_node_unlock(n_ptr);
+ read_unlock_bh(&tipc_net_lock);
+}
+
+static void link_retransmit_failure(struct link *l_ptr, struct sk_buff *buf)
+{
+ struct tipc_msg *msg = buf_msg(buf);
+
+ warn("Retransmission failure on link <%s>\n", l_ptr->name);
+ tipc_msg_print(TIPC_OUTPUT, msg, ">RETR-FAIL>");
+
+ if (l_ptr->addr) {
+
+ /* Handle failure on standard link */
+
+ link_print(l_ptr, TIPC_OUTPUT, "Resetting link\n");
+ tipc_link_reset(l_ptr);
+
+ } else {
+
+ /* Handle failure on broadcast link */
+
+ struct node *n_ptr;
+ char addr_string[16];
+
+ tipc_printf(TIPC_OUTPUT, "Msg seq number: %u, ", msg_seqno(msg));
+ tipc_printf(TIPC_OUTPUT, "Outstanding acks: %u\n", (u32)TIPC_SKB_CB(buf)->handle);
+
+ n_ptr = l_ptr->owner->next;
+ tipc_node_lock(n_ptr);
+
+ addr_string_fill(addr_string, n_ptr->addr);
+ tipc_printf(TIPC_OUTPUT, "Multicast link info for %s\n", addr_string);
+ tipc_printf(TIPC_OUTPUT, "Supported: %d, ", n_ptr->bclink.supported);
+ tipc_printf(TIPC_OUTPUT, "Acked: %u\n", n_ptr->bclink.acked);
+ tipc_printf(TIPC_OUTPUT, "Last in: %u, ", n_ptr->bclink.last_in);
+ tipc_printf(TIPC_OUTPUT, "Gap after: %u, ", n_ptr->bclink.gap_after);
+ tipc_printf(TIPC_OUTPUT, "Gap to: %u\n", n_ptr->bclink.gap_to);
+ tipc_printf(TIPC_OUTPUT, "Nack sync: %u\n\n", n_ptr->bclink.nack_sync);
+
+ tipc_k_signal((Handler)link_reset_all, (unsigned long)n_ptr->addr);
+
+ tipc_node_unlock(n_ptr);
+
+ l_ptr->stale_count = 0;
+ }
+}
+
void tipc_link_retransmit(struct link *l_ptr, struct sk_buff *buf,
u32 retransmits)
{
struct tipc_msg *msg;
+ if (!buf)
+ return;
+
+ msg = buf_msg(buf);
+
dbg("Retransmitting %u in link %x\n", retransmits, l_ptr);
- if (tipc_bearer_congested(l_ptr->b_ptr, l_ptr) && buf && !skb_cloned(buf)) {
- msg_dbg(buf_msg(buf), ">NO_RETR->BCONG>");
- dbg_print_link(l_ptr, " ");
- l_ptr->retransm_queue_head = msg_seqno(buf_msg(buf));
- l_ptr->retransm_queue_size = retransmits;
- return;
+ if (tipc_bearer_congested(l_ptr->b_ptr, l_ptr)) {
+ if (!skb_cloned(buf)) {
+ msg_dbg(msg, ">NO_RETR->BCONG>");
+ dbg_print_link(l_ptr, " ");
+ l_ptr->retransm_queue_head = msg_seqno(msg);
+ l_ptr->retransm_queue_size = retransmits;
+ return;
+ } else {
+ /* Don't retransmit if driver already has the buffer */
+ }
+ } else {
+ /* Detect repeated retransmit failures on uncongested bearer */
+
+ if (l_ptr->last_retransmitted == msg_seqno(msg)) {
+ if (++l_ptr->stale_count > 100) {
+ link_retransmit_failure(l_ptr, buf);
+ return;
+ }
+ } else {
+ l_ptr->last_retransmitted = msg_seqno(msg);
+ l_ptr->stale_count = 1;
+ }
}
+
while (retransmits && (buf != l_ptr->next_out) && buf && !skb_cloned(buf)) {
msg = buf_msg(buf);
msg_set_ack(msg, mod(l_ptr->next_in_no - 1));
msg_set_bcast_ack(msg, l_ptr->owner->bclink.last_in);
if (tipc_bearer_send(l_ptr->b_ptr, buf, &l_ptr->media_addr)) {
- /* Catch if retransmissions fail repeatedly: */
- if (l_ptr->last_retransmitted == msg_seqno(msg)) {
- if (++l_ptr->stale_count > 100) {
- tipc_msg_print(TIPC_CONS, buf_msg(buf), ">RETR>");
- info("...Retransmitted %u times\n",
- l_ptr->stale_count);
- link_print(l_ptr, TIPC_CONS, "Resetting Link\n");
- tipc_link_reset(l_ptr);
- break;
- }
- } else {
- l_ptr->stale_count = 0;
- }
- l_ptr->last_retransmitted = msg_seqno(msg);
-
msg_dbg(buf_msg(buf), ">RETR>");
buf = buf->next;
retransmits--;
@@ -1650,6 +1731,7 @@ void tipc_link_retransmit(struct link *l
return;
}
}
+
l_ptr->retransm_queue_head = l_ptr->retransm_queue_size = 0;
}
--
1.4.0
^ permalink raw reply related
* [PATCH 6/32] [TIPC] Links now validate destination node specified by incoming messages.
From: Per Liden @ 2006-06-22 13:59 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Allan Stephens
In-Reply-To: <Pine.LNX.4.64.0606221233570.15853@ulinpc219.uab.ericsson.se>
From: Allan Stephens <allan.stephens@windriver.com>
This fix prevents link flopping and name table inconsistency problems arising
when a node is assigned a different <Z.C.N> value than it used previously.
(Changing the <Z.C.N> value causes other nodes to have two link endpoints
sending to the same MAC address using two different destination <Z.C.N> values,
requiring the receiving node to filter out the unwanted messages.)
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Per Liden <per.liden@ericsson.com>
---
net/tipc/link.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 784b24b..955b87d 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1720,6 +1720,11 @@ #endif
link_recv_non_seq(buf);
continue;
}
+
+ if (unlikely(!msg_short(msg) &&
+ (msg_destnode(msg) != tipc_own_addr)))
+ goto cont;
+
n_ptr = tipc_node_find(msg_prevnode(msg));
if (unlikely(!n_ptr))
goto cont;
--
1.4.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox