* Re: [PATCH 1/2] [NETFILTER] PPTP helper: Fix compilation of conntrack helper without NAT
From: Harald Welte @ 2005-11-03 13:27 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Linux Netdev List,
Netfilter Development Mailinglist
In-Reply-To: <20051103131917.GJ4479@sunbeam.de.gnumonks.org>
[-- Attachment #1: Type: text/plain, Size: 3000 bytes --]
Ok, here goes the real fix for [1/2]:
[NETFILTER] PPTP helper: Fix compilation of conntrack helper without NAT
This patch fixes compilation of the PPTP conntrack helper when NAT is
configured off.
Signed-off-by: Yasuyuki Kozakai <yasuyuki.kozakai@toshiba.co.jp>
Signed-off-by: Harald Welte <laforge@netfilter.org>
---
commit f6447dcd8a4f13b144c9f49df76682c31562a003
tree e5f7c3a472ba896ee793727fbe4de02f42047d75
parent 928f936ad8e099bd2a84d6e875e1a8c59f55bf7d
author Harald Welte <laforge@hanuman.de.gnumonks.org> Thu, 03 Nov 2005 10:56:16 +0100
committer Harald Welte <laforge@hanuman.de.gnumonks.org> Thu, 03 Nov 2005 10:56:16 +0100
net/ipv4/netfilter/ip_conntrack_helper_pptp.c | 4 ----
net/ipv4/netfilter/ip_nat_helper_pptp.c | 2 ++
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/netfilter/ip_conntrack_helper_pptp.c b/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
--- a/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
+++ b/net/ipv4/netfilter/ip_conntrack_helper_pptp.c
@@ -270,14 +270,10 @@ exp_gre(struct ip_conntrack *master,
exp_orig->expectfn = pptp_expectfn;
exp_orig->flags = 0;
- exp_orig->dir = IP_CT_DIR_ORIGINAL;
-
/* both expectations are identical apart from tuple */
memcpy(exp_reply, exp_orig, sizeof(*exp_reply));
memcpy(&exp_reply->tuple, &exp_tuples[1], sizeof(exp_reply->tuple));
- exp_reply->dir = !exp_orig->dir;
-
if (ip_nat_pptp_hook_exp_gre)
ret = ip_nat_pptp_hook_exp_gre(exp_orig, exp_reply);
else {
diff --git a/net/ipv4/netfilter/ip_nat_helper_pptp.c b/net/ipv4/netfilter/ip_nat_helper_pptp.c
--- a/net/ipv4/netfilter/ip_nat_helper_pptp.c
+++ b/net/ipv4/netfilter/ip_nat_helper_pptp.c
@@ -216,6 +216,7 @@ pptp_exp_gre(struct ip_conntrack_expect
expect_orig->saved_proto.gre.key = htons(nat_pptp_info->pac_call_id);
expect_orig->tuple.src.u.gre.key = htons(nat_pptp_info->pns_call_id);
expect_orig->tuple.dst.u.gre.key = htons(ct_pptp_info->pac_call_id);
+ expect_orig->dir = IP_CT_DIR_ORIGINAL;
inv_t.src.ip = reply_t->src.ip;
inv_t.dst.ip = reply_t->dst.ip;
inv_t.src.u.gre.key = htons(nat_pptp_info->pac_call_id);
@@ -233,6 +234,7 @@ pptp_exp_gre(struct ip_conntrack_expect
expect_reply->saved_proto.gre.key = htons(nat_pptp_info->pns_call_id);
expect_reply->tuple.src.u.gre.key = htons(nat_pptp_info->pac_call_id);
expect_reply->tuple.dst.u.gre.key = htons(ct_pptp_info->pns_call_id);
+ expect_reply->dir = IP_CT_DIR_REPLY;
inv_t.src.ip = orig_t->src.ip;
inv_t.dst.ip = orig_t->dst.ip;
inv_t.src.u.gre.key = htons(nat_pptp_info->pns_call_id);
--
- Harald Welte <laforge@netfilter.org> http://netfilter.org/
============================================================================
"Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed." -- Paul Vixie
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c; kernel 2.6.14
From: Patrick McHardy @ 2005-11-03 16:19 UTC (permalink / raw)
To: Mitchell Blank Jr
Cc: Kris Katterjohn, Herbert Xu, jschlst, davem, acme, netdev,
linux-kernel
In-Reply-To: <20051103065809.GC27232@gaz.sfgoth.com>
Mitchell Blank Jr wrote:
> Kris Katterjohn wrote:
>
>>>So I guess use my patch and take "inline" off? What do you think?
>
> Well the original author presumably thought that the fast-path of
> load_pointer() was critical enough to keep inline (since it can be run many
> times per packet) So they made the deliberate choice of separating it
> into two functions - one inline, one non-inline.
Exactly. __load_pointer is only called rarely, while load_pointer is
called whenever data needs to be read from the packet. It shouldn't
be changed without any justification.
^ permalink raw reply
* Re: [PATCH] Merge __load_pointer() and load_pointer() in net/core/filter.c;kernel 2.6.14
From: Kris Katterjohn @ 2005-11-03 18:13 UTC (permalink / raw)
To: Mitchell Blank Jr, Patrick McHardy
Cc: Herbert Xu, jschlst, davem, acme, netdev, linux-kernel
From: Patrick McHardy
> Mitchell Blank Jr wrote:
> > Well the original author presumably thought that the fast-path of
> > load_pointer() was critical enough to keep inline (since it can be run many
> > times per packet) So they made the deliberate choice of separating it
> > into two functions - one inline, one non-inline.
>
> Exactly. __load_pointer is only called rarely, while load_pointer is
> called whenever data needs to be read from the packet. It shouldn't
> be changed without any justification.
That's a good enough answer for me!
Thanks
^ permalink raw reply
* [PATCH] /drivers/net/dgrs.c - Fixes Warnings when CONFIG_EISA or CONFIG_PCI are not enabled
From: Richard Knutsson @ 2005-11-03 23:13 UTC (permalink / raw)
To: Ashutosh Naik
Cc: netdev, davej, acme, linux-net, akpm, linux-kernel, stable,
trivial
In-Reply-To: <c216304e0511022139j70614ae3l3a96767c0a36358e@mail.gmail.com>
>>>>>This patch fixes compiler warnings when CONFIG_ISA and CONFIG_PCI are
>>>>>not enabled in the dgrc network driver.
>>>>>
>>>>>Signed-off-by: Ashutosh Naik <ashutosh.naik@gmail.com>
>>>>>
>>>>>--
>>>>>diff -Naurp linux-2.6.14/drivers/net/dgrs.c
>>>>>linux-2.6.14-git1/drivers/net/dgrs.c---
>>>>>linux-2.6.14/drivers/net/dgrs.c 2005-10-28 05:32:08.000000000
>>>>>+0530
>>>>>+++ linux-2.6.14-git1/drivers/net/dgrs.c 2005-11-01
>>>>>10:30:03.000000000 +0530
>>>>>@@ -1549,8 +1549,12 @@ MODULE_PARM_DESC(nicmode, "Digi RightSwi
>>>>>static int __init dgrs_init_module (void) {
>>>>> int i;
>>>>>- int eisacount = 0, pcicount = 0;
>>>>>-
>>>>>+#ifdef CONFIG_EISA
>>>>>+ int eisacount = 0;
>>>>>+#endif
>>>>>+#ifdef CONFIG_PCI
>>>>>+ int pcicount = 0;
>>>>>+#endif
>>>>> /*
>>>>> * Command line variable overrides
>>>>> * debug=NNN
>>>>>
>>>>>
>
>Both CONFIG_PCI and CONFIG_EISA cant be undefined at the same time,
>because the device has to be on either of the 2 busses. I think your
>patch is better in that case.
>
>Cheers
>Ashutosh
>
>
OK, then I send in the patch again. Thanks for your help/opinion.
Till the next time...
/Richard
<-- snip -->
This patch fixes compiler warnings when CONFIG_ISA or CONFIG_PCI are not enabled in the dgrc network driver.
Cleanly patched to 2.6.14-git6.
Signed-off-by: Richard Knutsson <ricknu-0@student.ltu.se>
---
diff -Nurp a/drivers/net/dgrs.c b/drivers/net/dgrs.c
--- a/drivers/net/dgrs.c 2005-10-28 02:02:08.000000000 +0200
+++ b/drivers/net/dgrs.c 2005-11-02 10:19:43.000000000 +0100
@@ -1549,7 +1549,7 @@ MODULE_PARM_DESC(nicmode, "Digi RightSwi
static int __init dgrs_init_module (void)
{
int i;
- int eisacount = 0, pcicount = 0;
+ int count;
/*
* Command line variable overrides
@@ -1591,14 +1591,14 @@ static int __init dgrs_init_module (void
* Find and configure all the cards
*/
#ifdef CONFIG_EISA
- eisacount = eisa_driver_register(&dgrs_eisa_driver);
- if (eisacount < 0)
- return eisacount;
+ count = eisa_driver_register(&dgrs_eisa_driver);
+ if (count < 0)
+ return count;
#endif
#ifdef CONFIG_PCI
- pcicount = pci_register_driver(&dgrs_pci_driver);
- if (pcicount)
- return pcicount;
+ count = pci_register_driver(&dgrs_pci_driver);
+ if (count)
+ return count;
#endif
return 0;
}
^ permalink raw reply
* Bug#337089: linux-image-2.6.14-1-powerpc: add CONFIG_TCP_CONG_BIC=y
From: Horms @ 2005-11-04 3:27 UTC (permalink / raw)
To: Benoît Dejean, 337089; +Cc: NetDev
In-Reply-To: <20051102162451.0002CF64E@ibook.free.fr>
On Wed, Nov 02, 2005 at 05:24:50PM +0100, Benoît Dejean wrote:
> Package: linux-image-2.6.14-1-powerpc
> Version: 2.6.14-1
> Severity: normal
>
> Hi,
> Linux < 2.6.14 used to have every TCP congestion algorithms as builtins but
> NewReno + BIC was default.
>
> Linux 2.6.14 has splitted these features into modules. But default remains
> NewReno + BIC accordint to CONFIG_TCP_CONG_ADVANCED help message :
>
> "Nearly all users can safely say no here, and a safe default selection will
> be made (BIC-TCP with new Reno as a fallback)."
>
> And indeed NewReno+BIC is a good and safe default. Much better than NewReno
>
> But Debian .config has CONFIG_TCP_CONG_BIC=m (CONFIG_TCP_CONG_*=m) which
> makes NewReno default. So this is like a "regression". I'd like debian kernel
> to have CONFIG_TCP_CONG_BIC=y provided that one can easily switch to another
> algorithm (using /proc/sys/net/ipv4/tcp_congestion_control).
Hi Netdev,
could someone please comment on what a good default congestion
algorithm setup for distribution kernels is?
Thanks
--
Horms
^ permalink raw reply
* Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
From: Horms @ 2005-11-04 3:29 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: Mikhail Gusarov, debian-kernel, NetDev
In-Reply-To: <20051102162620.GA32696@infradead.org>
On Wed, Nov 02, 2005 at 04:26:21PM +0000, Christoph Hellwig wrote:
> On Wed, Nov 02, 2005 at 12:54:09PM +0600, Mikhail Gusarov wrote:
> > So, having in mind the two levels of 'stablenesss': kernel
> > 'stableness' and modules 'stableness' :) we should find the way to
> > exclude discussed modules from the build, because in-kernel versions
> > will always be, erm..., slightly (1.0.0 is mentioned only as 'stone
> > age' in the mailing list of ipw2200 developers) outdated due to fact
> > integration and testing gets some time in upstream kernels. I propose
> > just to disable compilation of this drivers: everyone will be able to
> > compile the recent version using ipw2200-source we provide.
>
> The kernel drivers aren't stable but obsolete. Because of that ever
> distribution that supports it's users must patch in a more recent one,
> which is what we should do for debian aswell.
>
> It's a pity the braindead Intel policies don't allow us to have an uptodate
> driver in mainline.
Christoph,
do I take that comment to mean that upstream can't update the
drivers but Debian can? And if so, do you recommend updating
Debian's kernel packages, or putting the updates elsewhere?
--
Horms
^ permalink raw reply
* Re: [PATCH][MCAST]Two fix for implementation of MLDv2 .
From: David Stevens @ 2005-11-04 4:30 UTC (permalink / raw)
To: Yan Zheng; +Cc: linux-kernel, netdev
In-Reply-To: <7e77d27c0511030526g45d8f6e6l@mail.gmail.com>
Yan,
I'm looking at this one. My original interpretation was that a
group and source specific query should only be answered if the source
were explicitly listed (which is what the code does), but I see your
point.
A general or group-specific query should still be answered with the
existing code, and the unsolicited reports will also include the EXCLUDE
records for that group, so I'm not aware of any actual circumstances
where a multicast router wouldn't forward. But maybe you have such
a case. An administrator-initiated query, however, would certainly be
misleading to the administrator in the example you provided, and so
far I tend to agree that there should be a record in the report.
However, I'm not sure your solution is appropriate since it
appears to include EXCLUDE records in cases where they aren't
needed.
So, I'll look at this more carefully and see if I still agree
it needs a fix and whether or not your patch, or some alternative
method might be more appropriate. But it'll probably be sometime
next week before I'll be done reviewing/considering alternatives on
this one.
+-DLS
^ permalink raw reply
* Re: [PATCH][MCAST]Two fix for implementation of MLDv2 .
From: Yan Zheng @ 2005-11-04 6:19 UTC (permalink / raw)
To: David Stevens; +Cc: linux-kernel, netdev
In-Reply-To: <OF70243A3E.F658C3A4-ON882570AF.001699E7-882570AF.0018C8DB@us.ibm.com>
> So, I'll look at this more carefully and see if I still agree
> it needs a fix and whether or not your patch, or some alternative
> method might be more appropriate. But it'll probably be sometime
> next week before I'll be done reviewing/considering alternatives on
> this one.
>
> +-DLS
>
>
I am sorry, I can't understand your opinion completely.
Please forgive my poor english :-)
Here is my opinion:
I think Multicast Address and Source Specific Query is sent only when
router want to block traffic from some source. So when the filter
mode is exclude, node should send a report which includes a
MODE_IS_INCLUDE Record with sources in the query but NOT in the
filter's source list. This is the required behaviour in rfc3810, but
it need addiction item in struct ifmcaddr6 to record sources in the
query. So I think make process Multicast Address Specific Query and
Multicast Address and Source Specific Query no difference is a
temporary fix.
the secoend change in is_in(...) is because I think include/exclude
counts also should be checked when type is MLD2_MODE_IS_INCLUDE or
MLD2_MODE_IS_EXCLUDE.
Regards
Here is my modify version is_in(...)
-----------------------------------------------------------------------------------------------
static int is_in(struct ifmcaddr6 *pmc, struct ip6_sf_list *psf, int type,
int gdeleted, int sdeleted)
{
switch (type) {
case MLD2_MODE_IS_INCLUDE:
case MLD2_CHANGE_TO_INCLUDE:
if (gdeleted || sdeleted)
return 0;
if (psf->sf_count[MCAST_INCLUDE] == 0)
return 0; // maybe never happen
if (type == MLD2_CHANGE_TO_INCLUDE)
return 1;
return !((pmc->mca_flags & MAF_GSQUERY) && !psf->sf_gsresp);
case MLD2_MODE_IS_EXCLUDE:
case MLD2_CHANGE_TO_EXCLUDE:
if (gdeleted || sdeleted)
return 0;
if (pmc->mca_sfcount[MCAST_EXCLUDE] == 0 ||
psf->sf_count[MCAST_INCLUDE])
return 0;
return pmc->mca_sfcount[MCAST_EXCLUDE] ==
psf->sf_count[MCAST_EXCLUDE];
case MLD2_ALLOW_NEW_SOURCES:
if (gdeleted || !psf->sf_crcount)
return 0;
return (pmc->mca_sfmode == MCAST_INCLUDE) ^ sdeleted;
case MLD2_BLOCK_OLD_SOURCES:
if (pmc->mca_sfmode == MCAST_INCLUDE)
return gdeleted || (psf->sf_crcount && sdeleted);
return psf->sf_crcount && !gdeleted && !sdeleted;
}
return 0;
}
^ permalink raw reply
* Bug#337089: linux-image-2.6.14-1-powerpc: add CONFIG_TCP_CONG_BIC=y
From: Ian McDonald @ 2005-11-04 18:24 UTC (permalink / raw)
To: Horms; +Cc: Benoît Dejean, 337089, NetDev
In-Reply-To: <20051104032726.GD4708@verge.net.au>
> > But Debian .config has CONFIG_TCP_CONG_BIC=m (CONFIG_TCP_CONG_*=m) which
> > makes NewReno default. So this is like a "regression". I'd like debian kernel
> > to have CONFIG_TCP_CONG_BIC=y provided that one can easily switch to another
> > algorithm (using /proc/sys/net/ipv4/tcp_congestion_control).
>
> could someone please comment on what a good default congestion
> algorithm setup for distribution kernels is?
>
If you want BIC as default then do as suggested here. My personal
opinion is that is the correct thing to do for a standard
distribution.
If it is an experimental distribution then turn on tcp advanced
congestion control and build the rest (except for BIC) as modules.
Ian
--
Ian McDonald
http://wand.net.nz/~iam4
WAND Network Research Group
University of Waikato
New Zealand
^ permalink raw reply
* [PATCH] [IPV4] Fix secondary IP addresses after promotion
From: Brian Pomerantz @ 2005-11-04 18:46 UTC (permalink / raw)
To: netdev; +Cc: davem, kuznet, pekkas, jmorris, yoshfuji, kaber, linux-kernel
When 3 or more IP addresses in the same subnet exist on a device and the
first one is removed, only the promoted IP address can be reached. Just
after promotion of the next IP address, this fix spins through any more
IP addresses on the interface and sends a NETDEV_UP notification for
that address. This repopulates the FIB with the proper route
information.
Signed-off-by: Brian Pomerantz <bapper@piratehaven.org>
---
net/ipv4/devinet.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
applies-to: 9bbb209cab841f700162a96e158dfa3ecd361f46
489d4e25469c8329451aca3e91c8e1929e6ecf63
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 4ec4b2c..72d6c93 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -235,6 +235,7 @@ static void inet_del_ifa(struct in_devic
{
struct in_ifaddr *promote = NULL;
struct in_ifaddr *ifa1 = *ifap;
+ struct in_ifaddr *ifa;
ASSERT_RTNL();
@@ -243,7 +244,6 @@ static void inet_del_ifa(struct in_devic
**/
if (!(ifa1->ifa_flags & IFA_F_SECONDARY)) {
- struct in_ifaddr *ifa;
struct in_ifaddr **ifap1 = &ifa1->ifa_next;
while ((ifa = *ifap1) != NULL) {
@@ -294,7 +294,13 @@ static void inet_del_ifa(struct in_devic
/* not sure if we should send a delete notify first? */
promote->ifa_flags &= ~IFA_F_SECONDARY;
rtmsg_ifa(RTM_NEWADDR, promote);
- notifier_call_chain(&inetaddr_chain, NETDEV_UP, promote);
+
+ /* update fib in the rest of this address list */
+ ifa = promote;
+ while (ifa != NULL) {
+ notifier_call_chain(&inetaddr_chain, NETDEV_UP, ifa);
+ ifa = ifa->ifa_next;
+ }
}
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] ibmveth fix panic in initial replenish cycle
From: John W. Linville @ 2005-11-04 22:23 UTC (permalink / raw)
To: Santiago Leon; +Cc: Linus Torvalds, netdev, lkml, Jeff Garzik
In-Reply-To: <20051101175617.25145.73324.sendpatchset@ltcml8p7.rchland.ibm.com>
On Tue, Nov 01, 2005 at 02:15:09PM -0500, Santiago Leon wrote:
> This patch fixes a panic in the current tree caused by a race condition between the initial replenish cycle and the rx processing of the first packets trying to replenish the buffers.
Please restrain your line widths to less than 80 characters. 72 is
a nice number IMHO.
Thanks,
John
--
John W. Linville
linville@tuxdriver.com
^ permalink raw reply
* Re: ancient ieee80211/ipw2200 drivers in recent kernel (2.6.14)
From: Christoph Hellwig @ 2005-11-05 0:21 UTC (permalink / raw)
To: Mikhail Gusarov, debian-kernel, NetDev
In-Reply-To: <20051104032918.GE4708@verge.net.au>
On Fri, Nov 04, 2005 at 12:29:20PM +0900, Horms wrote:
> do I take that comment to mean that upstream can't update the
> drivers but Debian can? And if so, do you recommend updating
> Debian's kernel packages, or putting the updates elsewhere?
Well, we could upstream, but so far no one is annoyed enough to
overrid the driver maintainer. I'd suggest merging a more recent
driver into the debian kernel package.
^ permalink raw reply
* Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion
From: Patrick McHardy @ 2005-11-05 0:34 UTC (permalink / raw)
To: Brian Pomerantz
Cc: netdev, davem, kuznet, pekkas, jmorris, yoshfuji, kaber,
linux-kernel
In-Reply-To: <20051104184633.GA16256@skull.piratehaven.org>
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
Brian Pomerantz wrote:
> When 3 or more IP addresses in the same subnet exist on a device and the
> first one is removed, only the promoted IP address can be reached. Just
> after promotion of the next IP address, this fix spins through any more
> IP addresses on the interface and sends a NETDEV_UP notification for
> that address. This repopulates the FIB with the proper route
> information.
>
> @@ -294,7 +294,13 @@ static void inet_del_ifa(struct in_devic
> /* not sure if we should send a delete notify first? */
> promote->ifa_flags &= ~IFA_F_SECONDARY;
> rtmsg_ifa(RTM_NEWADDR, promote);
> - notifier_call_chain(&inetaddr_chain, NETDEV_UP, promote);
> +
> + /* update fib in the rest of this address list */
> + ifa = promote;
> + while (ifa != NULL) {
> + notifier_call_chain(&inetaddr_chain, NETDEV_UP, ifa);
> + ifa = ifa->ifa_next;
> + }
> }
> }
You assume all addresses following the primary addresses are secondary
addresses of the primary, which is not true with multiple primaries.
This patch (untested) makes sure only to send notification for real
secondaries of the deleted address. It also removes a racy double-
check for IN_DEV_PROMOTE_SECONDARIES - once we've decided to promote
an address checking again opens a window in which address promotion
could be disabled and we end up with only secondaries without a
primary address.
Signed-off-by: Patrick McHardy <kaber@trash.net>
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1535 bytes --]
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 4ec4b2c..beb02cc 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -234,7 +234,7 @@ static void inet_del_ifa(struct in_devic
int destroy)
{
struct in_ifaddr *promote = NULL;
- struct in_ifaddr *ifa1 = *ifap;
+ struct in_ifaddr *ifa, *ifa1 = *ifap;
ASSERT_RTNL();
@@ -243,7 +243,6 @@ static void inet_del_ifa(struct in_devic
**/
if (!(ifa1->ifa_flags & IFA_F_SECONDARY)) {
- struct in_ifaddr *ifa;
struct in_ifaddr **ifap1 = &ifa1->ifa_next;
while ((ifa = *ifap1) != NULL) {
@@ -283,19 +282,25 @@ static void inet_del_ifa(struct in_devic
*/
rtmsg_ifa(RTM_DELADDR, ifa1);
notifier_call_chain(&inetaddr_chain, NETDEV_DOWN, ifa1);
+
+ if (promote) {
+ /* not sure if we should send a delete notify first? */
+ promote->ifa_flags &= ~IFA_F_SECONDARY;
+ rtmsg_ifa(RTM_NEWADDR, promote);
+ for (ifa = promote; ifa; ifa = ifa->ifa_next) {
+ if (ifa1->ifa_mask != ifa->ifa_mask ||
+ !inet_ifa_match(ifa1->ifa_address, ifa))
+ continue;
+ notifier_call_chain(&inetaddr_chain, NETDEV_UP, ifa);
+ }
+ }
+
if (destroy) {
inet_free_ifa(ifa1);
if (!in_dev->ifa_list)
inetdev_destroy(in_dev);
}
-
- if (promote && IN_DEV_PROMOTE_SECONDARIES(in_dev)) {
- /* not sure if we should send a delete notify first? */
- promote->ifa_flags &= ~IFA_F_SECONDARY;
- rtmsg_ifa(RTM_NEWADDR, promote);
- notifier_call_chain(&inetaddr_chain, NETDEV_UP, promote);
- }
}
static int inet_insert_ifa(struct in_ifaddr *ifa)
^ permalink raw reply related
* Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion
From: Brian Pomerantz @ 2005-11-05 0:58 UTC (permalink / raw)
To: Patrick McHardy
Cc: netdev, davem, kuznet, pekkas, jmorris, yoshfuji, kaber,
linux-kernel
In-Reply-To: <436BFE08.6030906@trash.net>
On Sat, Nov 05, 2005 at 01:34:16AM +0100, Patrick McHardy wrote:
>
> You assume all addresses following the primary addresses are secondary
> addresses of the primary, which is not true with multiple primaries.
> This patch (untested) makes sure only to send notification for real
> secondaries of the deleted address. It also removes a racy double-
> check for IN_DEV_PROMOTE_SECONDARIES - once we've decided to promote
> an address checking again opens a window in which address promotion
> could be disabled and we end up with only secondaries without a
> primary address.
>
Yeah, I was wondering if there could be primaries after the
secondaries. I'm pretty unfamiliar with this code (first looked at it
last week) and still don't have a handle on how the primaries
interact with the secondaries in the route lookup. Which means it's
not clear to me why this was failing to begin with. :)
Your patch works for all of the cases I've been testing with so it
looks good to go from here.
BAPper
^ permalink raw reply
* Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion
From: Thomas Graf @ 2005-11-05 1:07 UTC (permalink / raw)
To: Patrick McHardy
Cc: Brian Pomerantz, netdev, davem, kuznet, pekkas, jmorris, yoshfuji,
kaber, linux-kernel
In-Reply-To: <436BFE08.6030906@trash.net>
* Patrick McHardy <kaber@trash.net> 2005-11-05 01:34
> Brian Pomerantz wrote:
> >When 3 or more IP addresses in the same subnet exist on a device and the
> >first one is removed, only the promoted IP address can be reached. Just
> >after promotion of the next IP address, this fix spins through any more
> >IP addresses on the interface and sends a NETDEV_UP notification for
> >that address. This repopulates the FIB with the proper route
> >information.
> >
> >@@ -294,7 +294,13 @@ static void inet_del_ifa(struct in_devic
> > /* not sure if we should send a delete notify first? */
> > promote->ifa_flags &= ~IFA_F_SECONDARY;
> > rtmsg_ifa(RTM_NEWADDR, promote);
> >- notifier_call_chain(&inetaddr_chain, NETDEV_UP, promote);
> >+
> >+ /* update fib in the rest of this address list */
> >+ ifa = promote;
> >+ while (ifa != NULL) {
> >+ notifier_call_chain(&inetaddr_chain, NETDEV_UP, ifa);
> >+ ifa = ifa->ifa_next;
> >+ }
> > }
> > }
>
> You assume all addresses following the primary addresses are secondary
> addresses of the primary, which is not true with multiple primaries.
> This patch (untested) makes sure only to send notification for real
> secondaries of the deleted address.
Even this corrected version is only a workaround, the real bug is that
or whatever reason all local routes of seconaries get deleted upon an
address promotion. I started debugging it a bit by looking at the
requests generated by fib_magic() and the resulting notifications, the
local routes just disappear when they shouldn't.
Situation is: 10.0.0.[1-4]/24 on dev0, 10.0.0.1 is the primary address
and gets deleted while address promotion is enabled. The following
happens:
[Format:]
Request generated by fib_magic()
Notification event received
RTM_DELROUTE 10.0.0.0/24 dev eth0 scope link
unicast table main protocol 2 preferred-src 10.0.0.1
RTM_DELROUTE 10.0.0.0/24 dev eth0 scope link
unicast table main protocol 2 preferred-src 10.0.0.1
RTM_DELROUTE 10.0.0.255 dev eth0 scope link
broadcast table local protocol 2 preferred-src 10.0.0.1
RTM_DELROUTE 10.0.0.255 dev eth0 scope link
broadcast table local protocol 2 preferred-src 10.0.0.1
RTM_DELROUTE 10.0.0.0 dev eth0 scope link
broadcast table local protocol 2 preferred-src 10.0.0.1
RTM_DELROUTE 10.0.0.0 dev eth0 scope link
broadcast table local protocol 2 preferred-src 10.0.0.1
RTM_DELROUTE 10.0.0.1 dev eth0 scope host
local table local protocol 2 preferred-src 10.0.0.1
RTM_DELROUTE 10.0.0.1 dev eth0 scope host
local table local protocol 2 preferred-src 10.0.0.1
RTM_NEWROUTE 10.0.0.2 dev eth0 scope host
local table local protocol 2 preferred-src 10.0.0.2
RTM_NEWROUTE 10.0.0.2 dev eth0 scope host
local table local protocol 2 preferred-src 10.0.0.2
RTM_NEWROUTE 10.0.0.0/24 dev eth0 scope link
unicast table main protocol 2 preferred-src 10.0.0.2
RTM_NEWROUTE 10.0.0.0/24 dev eth0 scope link
unicast table main protocol 2 preferred-src 10.0.0.2
RTM_NEWROUTE 10.0.0.0 dev eth0 scope link
broadcast table local protocol 2 preferred-src 10.0.0.2
RTM_NEWROUTE 10.0.0.0 dev eth0 scope link
broadcast table local protocol 2 preferred-src 10.0.0.2
RTM_NEWROUTE 10.0.0.255 dev eth0 scope link
broadcast table local protocol 2 preferred-src 10.0.0.2
RTM_NEWROUTE 10.0.0.255 dev eth0 scope link
broadcast table local protocol 2 preferred-src 10.0.0.2
State afterwards:
4: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
inet 10.0.0.2/24 scope global eth0
inet 10.0.0.3/24 scope global secondary eth0
inet 10.0.0.4/24 scope global secondary eth0
broadcast 10.0.0.0 proto kernel scope link src 10.0.0.2
local 10.0.0.2 proto kernel scope host src 10.0.0.2
broadcast 10.0.0.255 proto kernel scope link src 10.0.0.2
Local routes for 10.0.0.3 and 10.0.0.4 have disappeared _without_
any notification.
I think the correct way to fix this is to prevent the deletion of
the local routes, not just readding them. _If_ the deletion of them
is intended, which I doubt, then at least notifications must be
sent out.
Code to get fib_magic() requests to userspace:
Index: linux-2.6/include/linux/rtnetlink.h
===================================================================
--- linux-2.6.orig/include/linux/rtnetlink.h
+++ linux-2.6/include/linux/rtnetlink.h
@@ -880,6 +880,8 @@ enum rtnetlink_groups {
#define RTNLGRP_DECnet_ROUTE RTNLGRP_DECnet_ROUTE
RTNLGRP_IPV6_PREFIX,
#define RTNLGRP_IPV6_PREFIX RTNLGRP_IPV6_PREFIX
+ RTNLGRP_FIB_MAGIC,
+#define RTNLGRP_FIB_MAGIC RTNLGRP_FIB_MAGIC
__RTNLGRP_MAX
};
#define RTNLGRP_MAX (__RTNLGRP_MAX - 1)
Index: linux-2.6/net/ipv4/fib_frontend.c
===================================================================
--- linux-2.6.orig/net/ipv4/fib_frontend.c
+++ linux-2.6/net/ipv4/fib_frontend.c
@@ -359,6 +359,48 @@ int inet_dump_fib(struct sk_buff *skb, s
return skb->len;
}
+static int fib_magic_build(struct sk_buff *skb, int type, struct nlmsghdr *nlh,
+ struct rtmsg *rtm, struct kern_rta *rta)
+{
+ struct nlmsghdr *dst = NULL;
+ struct rtmsg *rtm_dst;
+
+ dst = NLMSG_NEW(skb, current->pid, 0, type, sizeof(*rtm), 0);
+ memcpy(dst, nlh, sizeof(*nlh));
+
+ rtm_dst = NLMSG_DATA(dst);
+ memcpy(rtm_dst, rtm, sizeof(*rtm));
+ rtm_dst->rtm_family = AF_INET;
+
+ RTA_PUT(skb, RTA_DST, 4, rta->rta_dst);
+ RTA_PUT(skb, RTA_PREFSRC, 4, rta->rta_prefsrc);
+ RTA_PUT(skb, RTA_OIF, 4, rta->rta_oif);
+
+ return NLMSG_END(skb, dst);
+rtattr_failure:
+nlmsg_failure:
+ return NLMSG_CANCEL(skb, dst);
+}
+
+static void fib_magic_event(int type, struct nlmsghdr *nlh, struct rtmsg *rtm,
+ struct kern_rta *rta)
+{
+ struct sk_buff *skb;
+
+ skb = alloc_skb(NLMSG_SPACE(sizeof(struct rtmsg) + 256), GFP_KERNEL);
+ if (!skb)
+ return;
+
+ if (fib_magic_build(skb, type, nlh, rtm, rta) < 0) {
+ kfree_skb(skb);
+ return;
+ }
+
+ NETLINK_CB(skb).dst_group = RTNLGRP_FIB_MAGIC;
+ netlink_broadcast(rtnl, skb, 0, RTNLGRP_FIB_MAGIC, GFP_KERNEL);
+}
+
+
/* Prepare and feed intra-kernel routing request.
Really, it should be netlink message, but :-( netlink
can be not configured, so that we feed it directly
@@ -402,6 +444,8 @@ static void fib_magic(int cmd, int type,
rta.rta_prefsrc = &ifa->ifa_local;
rta.rta_oif = &ifa->ifa_dev->dev->ifindex;
+ fib_magic_event(cmd, &req.nlh, &req.rtm, &rta);
+
if (cmd == RTM_NEWROUTE)
tb->tb_insert(tb, &req.rtm, &rta, &req.nlh, NULL);
else
^ permalink raw reply
* Re: [PATCH] [IPV4] Fix secondary IP addresses after promotion
From: Patrick McHardy @ 2005-11-05 1:21 UTC (permalink / raw)
To: Thomas Graf
Cc: Brian Pomerantz, netdev, davem, kuznet, pekkas, jmorris, yoshfuji,
kaber, linux-kernel
In-Reply-To: <20051105010740.GR23537@postel.suug.ch>
Thomas Graf wrote:
> * Patrick McHardy <kaber@trash.net> 2005-11-05 01:34
>
>>You assume all addresses following the primary addresses are secondary
>>addresses of the primary, which is not true with multiple primaries.
>>This patch (untested) makes sure only to send notification for real
>>secondaries of the deleted address.
>
>
> Even this corrected version is only a workaround, the real bug is that
> or whatever reason all local routes of seconaries get deleted upon an
> address promotion. I started debugging it a bit by looking at the
> requests generated by fib_magic() and the resulting notifications, the
> local routes just disappear when they shouldn't.
>
> Situation is: 10.0.0.[1-4]/24 on dev0, 10.0.0.1 is the primary address
> and gets deleted while address promotion is enabled. The following
> happens:
>
> [Format:]
> Request generated by fib_magic()
> Notification event received
>
> RTM_DELROUTE 10.0.0.0/24 dev eth0 scope link
> unicast table main protocol 2 preferred-src 10.0.0.1
> RTM_DELROUTE 10.0.0.0/24 dev eth0 scope link
> unicast table main protocol 2 preferred-src 10.0.0.1
>
> RTM_DELROUTE 10.0.0.255 dev eth0 scope link
> broadcast table local protocol 2 preferred-src 10.0.0.1
> RTM_DELROUTE 10.0.0.255 dev eth0 scope link
> broadcast table local protocol 2 preferred-src 10.0.0.1
>
> RTM_DELROUTE 10.0.0.0 dev eth0 scope link
> broadcast table local protocol 2 preferred-src 10.0.0.1
> RTM_DELROUTE 10.0.0.0 dev eth0 scope link
> broadcast table local protocol 2 preferred-src 10.0.0.1
>
> RTM_DELROUTE 10.0.0.1 dev eth0 scope host
> local table local protocol 2 preferred-src 10.0.0.1
> RTM_DELROUTE 10.0.0.1 dev eth0 scope host
> local table local protocol 2 preferred-src 10.0.0.1
>
> RTM_NEWROUTE 10.0.0.2 dev eth0 scope host
> local table local protocol 2 preferred-src 10.0.0.2
> RTM_NEWROUTE 10.0.0.2 dev eth0 scope host
> local table local protocol 2 preferred-src 10.0.0.2
>
> RTM_NEWROUTE 10.0.0.0/24 dev eth0 scope link
> unicast table main protocol 2 preferred-src 10.0.0.2
> RTM_NEWROUTE 10.0.0.0/24 dev eth0 scope link
> unicast table main protocol 2 preferred-src 10.0.0.2
>
> RTM_NEWROUTE 10.0.0.0 dev eth0 scope link
> broadcast table local protocol 2 preferred-src 10.0.0.2
> RTM_NEWROUTE 10.0.0.0 dev eth0 scope link
> broadcast table local protocol 2 preferred-src 10.0.0.2
>
> RTM_NEWROUTE 10.0.0.255 dev eth0 scope link
> broadcast table local protocol 2 preferred-src 10.0.0.2
> RTM_NEWROUTE 10.0.0.255 dev eth0 scope link
> broadcast table local protocol 2 preferred-src 10.0.0.2
>
> State afterwards:
> 4: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
> inet 10.0.0.2/24 scope global eth0
> inet 10.0.0.3/24 scope global secondary eth0
> inet 10.0.0.4/24 scope global secondary eth0
>
> broadcast 10.0.0.0 proto kernel scope link src 10.0.0.2
> local 10.0.0.2 proto kernel scope host src 10.0.0.2
> broadcast 10.0.0.255 proto kernel scope link src 10.0.0.2
>
> Local routes for 10.0.0.3 and 10.0.0.4 have disappeared _without_
> any notification.
>
> I think the correct way to fix this is to prevent the deletion of
> the local routes, not just readding them. _If_ the deletion of them
> is intended, which I doubt, then at least notifications must be
> sent out.
I agree, the routes should ideally not be deleted at all. The missing
notifications appear to be a different bug. Let me have another look ..
^ permalink raw reply
* Re: [PATCH]dgrs - Fixes Warnings when CONFIG_ISA and CONFIG_PCI are not enabled
From: Andrew Morton @ 2005-11-05 2:25 UTC (permalink / raw)
To: Richard Knutsson
Cc: ashutosh.lkml, netdev, davej, acme, linux-net, linux-kernel,
stable
In-Reply-To: <436927CA.3090105@student.ltu.se>
Richard Knutsson <ricknu-0@student.ltu.se> wrote:
>
> >
> >
> >>>This patch fixes compiler warnings when CONFIG_ISA and CONFIG_PCI are
> >>>not enabled in the dgrc network driver.
> >>>
> >>>Signed-off-by: Ashutosh Naik <ashutosh.naik@gmail.com>
> >>>
> >>>--
> >>>diff -Naurp linux-2.6.14/drivers/net/dgrs.c
> >>>linux-2.6.14-git1/drivers/net/dgrs.c---
> >>>linux-2.6.14/drivers/net/dgrs.c 2005-10-28 05:32:08.000000000
> >>>+0530
> >>>+++ linux-2.6.14-git1/drivers/net/dgrs.c 2005-11-01
> >>>10:30:03.000000000 +0530
> >>>@@ -1549,8 +1549,12 @@ MODULE_PARM_DESC(nicmode, "Digi RightSwi
> >>>static int __init dgrs_init_module (void) {
> >>> int i;
> >>>- int eisacount = 0, pcicount = 0;
> >>>-
> >>>+#ifdef CONFIG_EISA
> >>>+ int eisacount = 0;
> >>>+#endif
> >>>+#ifdef CONFIG_PCI
> >>>+ int pcicount = 0;
> >>>+#endif
> >>> /*
> >>> * Command line variable overrides
> >>> * debug=NNN
> >>>-
> >>>
> >>>
>
> >>Signed-off-by: Richard Knutsson <ricknu-0@student.ltu.se>
> >>
> >>---
> >>
> >>diff -uNr a/drivers/net/dgrs.c b/drivers/net/dgrs.c
> >>--- a/drivers/net/dgrs.c 2005-08-29 01:41:01.000000000 +0200
> >>+++ b/drivers/net/dgrs.c 2005-10-26 15:53:43.000000000 +0200
> >>@@ -1549,7 +1549,7 @@
> >> static int __init dgrs_init_module (void)
> >> {
> >> int i;
> >>- int eisacount = 0, pcicount = 0;
> >>+ int count;
> >>
> >> /*
> >> * Command line variable overrides
> >>@@ -1591,14 +1591,14 @@
> >> * Find and configure all the cards
> >> */
> >> #ifdef CONFIG_EISA
> >>- eisacount = eisa_driver_register(&dgrs_eisa_driver);
> >>- if (eisacount < 0)
> >>- return eisacount;
> >>+ count = eisa_driver_register(&dgrs_eisa_driver);
> >>+ if (count < 0)
> >>+ return count;
> >> #endif
> >> #ifdef CONFIG_PCI
> >>- pcicount = pci_register_driver(&dgrs_pci_driver);
> >>- if (pcicount)
> >>- return pcicount;
> >>+ count = pci_register_driver(&dgrs_pci_driver);
> >>+ if (count)
> >>+ return count;
> >> #endif
> >> return 0;
> >> }
> >>
> >>
> >
> >Well, both of them do the same stuff, but one of these patches needs
> >to be committed.
> >
> >Cheers
> >Ashutosh
> >
> >
> Can both CONFIG_PCI and CONFIG_EISA be undefined at the same time? If
> so
Not for this driver. From drivers/net/dgrs.c:
config DGRS
tristate "Digi Intl. RightSwitch SE-X support"
depends on NET_PCI && (PCI || EISA)
> I think you patch is better.
Let's go with Ashutosh's patch then, thanks.
^ permalink raw reply
* Re: [PATCH]dgrs - Fixes Warnings when CONFIG_ISA and CONFIG_PCI are not enabled
From: Andrew Morton @ 2005-11-05 2:30 UTC (permalink / raw)
To: ricknu-0, ashutosh.lkml, netdev, davej, acme, linux-net,
linux-kernel, stable
In-Reply-To: <20051104182537.741be3d9.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> wrote:
>
> Let's go with Ashutosh's patch then, thanks.
(It was wordwrapped. Please fix your email client)
In fact we can de-ifdef things a bit.
diff -puN drivers/net/dgrs.c~dgrs-fixes-warnings-when-config_isa-and-config_pci-are-not-enabled drivers/net/dgrs.c
--- devel/drivers/net/dgrs.c~dgrs-fixes-warnings-when-config_isa-and-config_pci-are-not-enabled 2005-11-04 18:26:59.000000000 -0800
+++ devel-akpm/drivers/net/dgrs.c 2005-11-04 18:29:24.000000000 -0800
@@ -1549,7 +1549,7 @@ MODULE_PARM_DESC(nicmode, "Digi RightSwi
static int __init dgrs_init_module (void)
{
int i;
- int eisacount = 0, pcicount = 0;
+ int cardcount = 0;
/*
* Command line variable overrides
@@ -1591,15 +1591,13 @@ static int __init dgrs_init_module (void
* Find and configure all the cards
*/
#ifdef CONFIG_EISA
- eisacount = eisa_driver_register(&dgrs_eisa_driver);
- if (eisacount < 0)
- return eisacount;
-#endif
-#ifdef CONFIG_PCI
- pcicount = pci_register_driver(&dgrs_pci_driver);
- if (pcicount)
- return pcicount;
+ cardcount = eisa_driver_register(&dgrs_eisa_driver);
+ if (cardcount < 0)
+ return cardcount;
#endif
+ cardcount = pci_register_driver(&dgrs_pci_driver);
+ if (cardcount)
+ return cardcount;
return 0;
}
_
^ permalink raw reply
* Re: [PATCH] kill 8139too kernel thread (sorta)
From: Jeff Garzik @ 2005-11-05 3:47 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, linux-kernel
In-Reply-To: <20051031211143.GA6409@gondor.apana.org.au>
[-- Attachment #1: Type: text/plain, Size: 65 bytes --]
Here's a better version, that uses cancel_rearming_...
Jeff
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 4707 bytes --]
diff --git a/drivers/net/8139too.c b/drivers/net/8139too.c
index 30bee11..120baaa 100644
--- a/drivers/net/8139too.c
+++ b/drivers/net/8139too.c
@@ -586,16 +586,16 @@ struct rtl8139_private {
dma_addr_t tx_bufs_dma;
signed char phys[4]; /* MII device addresses. */
char twistie, twist_row, twist_col; /* Twister tune state. */
- unsigned int default_port:4; /* Last dev->if_port value. */
+ unsigned int default_port : 4; /* Last dev->if_port value. */
+ unsigned int have_thread : 1;
spinlock_t lock;
spinlock_t rx_lock;
chip_t chipset;
- pid_t thr_pid;
- wait_queue_head_t thr_wait;
- struct completion thr_exited;
u32 rx_config;
struct rtl_extra_stats xstats;
- int time_to_die;
+
+ struct work_struct thread;
+
struct mii_if_info mii;
unsigned int regs_len;
unsigned long fifo_copy_timeout;
@@ -620,7 +620,7 @@ static int rtl8139_open (struct net_devi
static int mdio_read (struct net_device *dev, int phy_id, int location);
static void mdio_write (struct net_device *dev, int phy_id, int location,
int val);
-static void rtl8139_start_thread(struct net_device *dev);
+static void rtl8139_start_thread(struct rtl8139_private *tp);
static void rtl8139_tx_timeout (struct net_device *dev);
static void rtl8139_init_ring (struct net_device *dev);
static int rtl8139_start_xmit (struct sk_buff *skb,
@@ -637,6 +637,7 @@ static struct net_device_stats *rtl8139_
static void rtl8139_set_rx_mode (struct net_device *dev);
static void __set_rx_mode (struct net_device *dev);
static void rtl8139_hw_start (struct net_device *dev);
+static void rtl8139_thread (void *_data);
static struct ethtool_ops rtl8139_ethtool_ops;
/* write MMIO register, with flush */
@@ -1007,8 +1008,7 @@ static int __devinit rtl8139_init_one (s
(debug < 0 ? RTL8139_DEF_MSG_ENABLE : ((1 << debug) - 1));
spin_lock_init (&tp->lock);
spin_lock_init (&tp->rx_lock);
- init_waitqueue_head (&tp->thr_wait);
- init_completion (&tp->thr_exited);
+ INIT_WORK(&tp->thread, rtl8139_thread, dev);
tp->mii.dev = dev;
tp->mii.mdio_read = mdio_read;
tp->mii.mdio_write = mdio_write;
@@ -1345,7 +1345,7 @@ static int rtl8139_open (struct net_devi
dev->irq, RTL_R8 (MediaStatus),
tp->mii.full_duplex ? "full" : "half");
- rtl8139_start_thread(dev);
+ rtl8139_start_thread(tp);
return 0;
}
@@ -1594,55 +1594,37 @@ static inline void rtl8139_thread_iter (
RTL_R8 (Config1));
}
-static int rtl8139_thread (void *data)
+static void rtl8139_thread (void *_data)
{
- struct net_device *dev = data;
+ struct net_device *dev = _data;
struct rtl8139_private *tp = netdev_priv(dev);
- unsigned long timeout;
-
- daemonize("%s", dev->name);
- allow_signal(SIGTERM);
-
- while (1) {
- timeout = next_tick;
- do {
- timeout = interruptible_sleep_on_timeout (&tp->thr_wait, timeout);
- /* make swsusp happy with our thread */
- try_to_freeze();
- } while (!signal_pending (current) && (timeout > 0));
-
- if (signal_pending (current)) {
- flush_signals(current);
- }
-
- if (tp->time_to_die)
- break;
- if (rtnl_lock_interruptible ())
- break;
+ if (rtnl_shlock_nowait() == 0) {
rtl8139_thread_iter (dev, tp, tp->mmio_addr);
rtnl_unlock ();
}
- complete_and_exit (&tp->thr_exited, 0);
+ schedule_delayed_work(&tp->thread, next_tick);
}
-static void rtl8139_start_thread(struct net_device *dev)
+static void rtl8139_start_thread(struct rtl8139_private *tp)
{
- struct rtl8139_private *tp = netdev_priv(dev);
-
- tp->thr_pid = -1;
tp->twistie = 0;
- tp->time_to_die = 0;
if (tp->chipset == CH_8139_K)
tp->twistie = 1;
else if (tp->drv_flags & HAS_LNK_CHNG)
return;
- tp->thr_pid = kernel_thread(rtl8139_thread, dev, CLONE_FS|CLONE_FILES);
- if (tp->thr_pid < 0) {
- printk (KERN_WARNING "%s: unable to start kernel thread\n",
- dev->name);
+ tp->have_thread = 1;
+
+ schedule_delayed_work(&tp->thread, next_tick);
+}
+
+static void rtl8139_stop_thread(struct rtl8139_private *tp)
+{
+ if (tp->have_thread) {
+ cancel_rearming_delayed_work(&tp->thread);
+ tp->have_thread = 0;
}
}
@@ -2224,22 +2206,12 @@ static int rtl8139_close (struct net_dev
{
struct rtl8139_private *tp = netdev_priv(dev);
void __iomem *ioaddr = tp->mmio_addr;
- int ret = 0;
unsigned long flags;
netif_stop_queue (dev);
- if (tp->thr_pid >= 0) {
- tp->time_to_die = 1;
- wmb();
- ret = kill_proc (tp->thr_pid, SIGTERM, 1);
- if (ret) {
- printk (KERN_ERR "%s: unable to signal thread\n", dev->name);
- return ret;
- }
- wait_for_completion (&tp->thr_exited);
- }
-
+ rtl8139_stop_thread(tp);
+
if (netif_msg_ifdown(tp))
printk(KERN_DEBUG "%s: Shutting down ethercard, status was 0x%4.4x.\n",
dev->name, RTL_R16 (IntrStatus));
^ permalink raw reply related
* Re: [PATCH] kill 8139too kernel thread (sorta)
From: Herbert Xu @ 2005-11-05 4:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linux-kernel
In-Reply-To: <436C2B47.3030505@pobox.com>
On Fri, Nov 04, 2005 at 10:47:19PM -0500, Jeff Garzik wrote:
> Here's a better version, that uses cancel_rearming_...
Yep it certainly solves the race condition.
> + if (rtnl_shlock_nowait() == 0) {
> rtl8139_thread_iter (dev, tp, tp->mmio_addr);
> rtnl_unlock ();
> }
>
> - complete_and_exit (&tp->thr_exited, 0);
> + schedule_delayed_work(&tp->thread, next_tick);
My only concern is the potential for starvation here should we fail
to obtain the RTNL. Since any local user can hold the RTNL by issuing
rtnetlink requests, it is theoretically possible for the rtl8139 work
to be delayed indefinitely.
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: [PATCH] [IPV4] Fix secondary IP addresses after promotion
From: Patrick McHardy @ 2005-11-05 4:28 UTC (permalink / raw)
To: Thomas Graf
Cc: Brian Pomerantz, netdev, davem, kuznet, pekkas, jmorris, yoshfuji,
kaber, linux-kernel
In-Reply-To: <436C090D.5020201@trash.net>
Patrick McHardy wrote:
> Thomas Graf wrote:
>
>> broadcast 10.0.0.0 proto kernel scope link src 10.0.0.2 local
>> 10.0.0.2 proto kernel scope host src 10.0.0.2 broadcast 10.0.0.255
>> proto kernel scope link src 10.0.0.2
>> Local routes for 10.0.0.3 and 10.0.0.4 have disappeared _without_
>> any notification.
>>
>> I think the correct way to fix this is to prevent the deletion of
>> the local routes, not just readding them. _If_ the deletion of them
>> is intended, which I doubt, then at least notifications must be
>> sent out.
>
> I agree, the routes should ideally not be deleted at all. The missing
> notifications appear to be a different bug. Let me have another look ..
The reason why all routes are deleted is because their prefered
source addresses is the primary address. fn_flush_list should
probably send the missing notifications for the deleted routes.
Changing address promotion to not delete the other routes at all
looks extremly complicated, I think just fixing it to behave
correctly is good enough (which my patch didn't do entirely,
I'll send a new one this weekend).
^ permalink raw reply
* Re: [PATCH]dgrs - Fixes Warnings when CONFIG_ISA and CONFIG_PCI are not enabled
From: Ashutosh Naik @ 2005-11-05 4:51 UTC (permalink / raw)
To: Andrew Morton
Cc: ricknu-0, netdev, davej, acme, linux-net, linux-kernel, stable
In-Reply-To: <20051104183043.27a2229c.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1859 bytes --]
Hi Andrew,
On 11/5/05, Andrew Morton <akpm@osdl.org> wrote:
> Andrew Morton <akpm@osdl.org> wrote:
> >
> > Let's go with Ashutosh's patch then, thanks.
>
> (It was wordwrapped. Please fix your email client)
I am attaching the patch.
Signed-off-by: Ashutosh Naik <ashutosh.naik@gmail.com>
> In fact we can de-ifdef things a bit.
>
> diff -puN drivers/net/dgrs.c~dgrs-fixes-warnings-when-config_isa-and-config_pci-are-not-enabled drivers/net/dgrs.c
> --- devel/drivers/net/dgrs.c~dgrs-fixes-warnings-when-config_isa-and-config_pci-are-not-enabled 2005-11-04 18:26:59.000000000 -0800
> +++ devel-akpm/drivers/net/dgrs.c 2005-11-04 18:29:24.000000000 -0800
> @@ -1549,7 +1549,7 @@ MODULE_PARM_DESC(nicmode, "Digi RightSwi
> static int __init dgrs_init_module (void)
> {
> int i;
> - int eisacount = 0, pcicount = 0;
> + int cardcount = 0;
>
> /*
> * Command line variable overrides
> @@ -1591,15 +1591,13 @@ static int __init dgrs_init_module (void
> * Find and configure all the cards
> */
> #ifdef CONFIG_EISA
> - eisacount = eisa_driver_register(&dgrs_eisa_driver);
> - if (eisacount < 0)
> - return eisacount;
> -#endif
> -#ifdef CONFIG_PCI
> - pcicount = pci_register_driver(&dgrs_pci_driver);
> - if (pcicount)
> - return pcicount;
> + cardcount = eisa_driver_register(&dgrs_eisa_driver);
> + if (cardcount < 0)
> + return cardcount;
> #endif
> + cardcount = pci_register_driver(&dgrs_pci_driver);
> + if (cardcount)
> + return cardcount;
> return 0;
> }
>
Signed-off-by: Ashutosh Naik <ashutosh.naik@gmail.com>
Acked. The above patch does the trick too. Any one can be committed.
Cheers
Ashutosh
[-- Attachment #2: dgrs-patch.txt --]
[-- Type: text/plain, Size: 540 bytes --]
diff -Naurp linux-2.6.14/drivers/net/dgrs.c linux-2.6.14-git1/drivers/net/dgrs.c
--- linux-2.6.14/drivers/net/dgrs.c 2005-10-28 05:32:08.000000000 +0530
+++ linux-2.6.14-git1/drivers/net/dgrs.c 2005-11-01 10:30:03.000000000 +0530
@@ -1549,8 +1549,12 @@ MODULE_PARM_DESC(nicmode, "Digi RightSwi
static int __init dgrs_init_module (void)
{
int i;
- int eisacount = 0, pcicount = 0;
-
+#ifdef CONFIG_EISA
+ int eisacount = 0;
+#endif
+#ifdef CONFIG_PCI
+ int pcicount = 0;
+#endif
/*
* Command line variable overrides
* debug=NNN
^ permalink raw reply
* Re: [PATCH] kill 8139too kernel thread (sorta)
From: Jeff Garzik @ 2005-11-05 4:58 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, linux-kernel
In-Reply-To: <20051105042008.GA25823@gondor.apana.org.au>
Herbert Xu wrote:
> My only concern is the potential for starvation here should we fail
> to obtain the RTNL. Since any local user can hold the RTNL by issuing
> rtnetlink requests, it is theoretically possible for the rtl8139 work
> to be delayed indefinitely.
Yes, but highly unlikely, for very few users, with the negative effects
negligible.
Jeff
^ permalink raw reply
* Re: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Herbert Xu @ 2005-11-05 6:30 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: netdev, netfilter-devel, kaber
In-Reply-To: <20051027.235732.01166239.yoshfuji@linux-ipv6.org>
On Thu, Oct 27, 2005 at 11:57:32PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
> Well, I really care.
> I strongly believe that we SHOULD NOT mix encrypted
> packets and plain text packets at the same hook.
> e.g. LOCAL_IN is NOT for decrypted plain text packets,
> but for the original encrypted ones.
OK. Would it be workable for you if LOCAL_IN only saw the decrypted
packets without ever seeing the encrypted ones?
I'd like to know where the boundaries are so we can find a compromise
that works for everyone.
Thanks,
--
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: [NF+IPsec 4/6]: Make IPsec input processing symetrical to output
From: Patrick McHardy @ 2005-11-05 7:55 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, netfilter-devel
In-Reply-To: <20051105063030.GA32385@gondor.apana.org.au>
Herbert Xu wrote:
> On Thu, Oct 27, 2005 at 11:57:32PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
>
>>Well, I really care.
>>I strongly believe that we SHOULD NOT mix encrypted
>>packets and plain text packets at the same hook.
>>e.g. LOCAL_IN is NOT for decrypted plain text packets,
>>but for the original encrypted ones.
>
>
> OK. Would it be workable for you if LOCAL_IN only saw the decrypted
> packets without ever seeing the encrypted ones?
How exactly would that work? I guess we couldn't do NAT with
the encrypted packet anymore?
> I'd like to know where the boundaries are so we can find a compromise
> that works for everyone.
I would prefer something similar to the second set of patches.
Instead of calling netif_rx we could use NF_HOOK and simulate
the relevant parts of the input path for IPv4 and NAT. This
would assure that statistics are still correct and tcpdump is
not affected, which were Yoshifuji's biggest concerns if I
understood correctly.
^ permalink raw reply
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