* Re: [PATCH] PHYLIB: IRQ event workqueue handling fixes
From: Maciej W. Rozycki @ 2007-10-18 11:37 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Andy Fleming, Andrew Morton, Jeff Garzik, netdev, linux-kernel
In-Reply-To: <20071018063157.GA1694@ff.dom.local>
On Thu, 18 Oct 2007, Jarek Poplawski wrote:
> After rethinking, it looks like this last cancel should be useless.
> So, if phy_interrupt() schedules only if !PHY_HALTED and phy_change()
> does enable_irq() with no exeptions, it seems phy_interrupt() even
> without lock must see PHY_HALTED state before this free_irq() with
> possible DEBUG_SHIRQ call, then maybe only this safety:
>
> WARN_ON(work_pending(&phydev->phy_queue));
Good point.
Maciej
^ permalink raw reply
* Re: [PATCH 0/2] Interface groups, round two
From: Patrick McHardy @ 2007-10-18 11:42 UTC (permalink / raw)
To: panther; +Cc: netdev, netfilter-devel
In-Reply-To: <471744C3.3000801@balabit.hu>
Laszlo Attila Toth wrote:
> Patrick McHardy írta:
>> Laszlo Attila Toth wrote:
>
>> The only reason why it can't be set to zero again seems to
>> be this part from the iproute patch:
>>
>> + if (rtnl_ifgroup_a2n(&group, *argv) || group == 0)
>>
>> Why don't you allow a value of zero?
>>
>
> It has historical reason. The original version which didn't use netlink
> (at kernel 2.6.17) used zero to indicate that group was not set. You
> wrote previously that this part is useless for new kernels. I'll fix
> this (with type of "group" variable to unsigned int32 to be consistent
> with the kernel part).
Support for ifgroups in the ioctl part is useless since that will
never be used with kernel supporting this feature. Setting it to
zero is not useless.
-
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at virtual address 000000b0
From: Patrick McHardy @ 2007-10-18 11:46 UTC (permalink / raw)
To: Krzysztof Oledzki; +Cc: Eric Dumazet, netdev
In-Reply-To: <Pine.LNX.4.64.0710181320170.12701@bizon.gios.gov.pl>
Krzysztof Oledzki wrote:
>> Hum, you are using IPT_TPROXY thing, which is not in linux-2.6.22.9
>
> It is only compiled in, not used at the moment.
But at least the previous version (before those patches posted a week
ago) touches the routing code in exactly that function.
^ permalink raw reply
* Re: ip_frag_reasm() can return uninitialized variable
From: David Miller @ 2007-10-18 11:47 UTC (permalink / raw)
To: bunk; +Cc: herbert, netdev, linux-kernel
In-Reply-To: <20071018105203.GJ3778@stusta.de>
From: Adrian Bunk <bunk@kernel.org>
Date: Thu, 18 Oct 2007 12:52:03 +0200
> Since commit 1706d58763c36133d7fce6cc78b1444fd40db28c ip_frag_reasm()
> can return the value of an uninitialized variable:
I have a fix for this in my net-2.6 tree, thanks Adrian.
^ permalink raw reply
* [PATCH 1/3] Lost locking when inserting a flowlabel in ipv6_fl_list
From: Pavel Emelyanov @ 2007-10-18 11:51 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
The new flowlabels should be inserted into the sock list
under the ip6_sk_fl_lock. This was lost in one place.
This list is naturally protected with the socket lock, but
the fl6_sock_lookup() is called without it, so another
protection is required.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 217d60f..8550df2 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -409,6 +409,16 @@ static int ipv6_opt_cmp(struct ipv6_txoptions *o1, struct ipv6_txoptions *o2)
return 0;
}
+static inline void fl_link(struct ipv6_pinfo *np, struct ipv6_fl_socklist *sfl,
+ struct ip6_flowlabel *fl)
+{
+ write_lock_bh(&ip6_sk_fl_lock);
+ sfl->fl = fl;
+ sfl->next = np->ipv6_fl_list;
+ np->ipv6_fl_list = sfl;
+ write_unlock_bh(&ip6_sk_fl_lock);
+}
+
int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
{
int err;
@@ -513,11 +523,7 @@ int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
fl1->linger = fl->linger;
if ((long)(fl->expires - fl1->expires) > 0)
fl1->expires = fl->expires;
- write_lock_bh(&ip6_sk_fl_lock);
- sfl1->fl = fl1;
- sfl1->next = np->ipv6_fl_list;
- np->ipv6_fl_list = sfl1;
- write_unlock_bh(&ip6_sk_fl_lock);
+ fl_link(np, sfl1, fl1);
fl_free(fl);
return 0;
@@ -545,9 +551,7 @@ release:
}
}
- sfl1->fl = fl;
- sfl1->next = np->ipv6_fl_list;
- np->ipv6_fl_list = sfl1;
+ fl_link(np, sfl1, fl);
return 0;
default:
--
1.5.3.4
^ permalink raw reply related
* [PATCH 2/3] Lost locking in fl6_sock_lookup
From: Pavel Emelyanov @ 2007-10-18 11:53 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
This routine scans the ipv6_fl_list whose update is
protected with the socket lock and the ip6_sk_fl_lock.
Since the socket lock is not taken in the lookup, use
the other one.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index 8550df2..f40a086 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -190,14 +190,17 @@ struct ip6_flowlabel * fl6_sock_lookup(struct sock *sk, __be32 label)
label &= IPV6_FLOWLABEL_MASK;
+ read_lock_bh(&ip6_sk_fl_lock);
for (sfl=np->ipv6_fl_list; sfl; sfl = sfl->next) {
struct ip6_flowlabel *fl = sfl->fl;
if (fl->label == label) {
+ read_unlock_bh(&ip6_sk_fl_lock);
fl->lastuse = jiffies;
atomic_inc(&fl->users);
return fl;
}
}
+ read_unlock_bh(&ip6_sk_fl_lock);
return NULL;
}
^ permalink raw reply related
* [PATCH 3/3] Fix race in ipv6_flowlabel_opt() when inserting two labels
From: Pavel Emelyanov @ 2007-10-18 11:59 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel
In the IPV6_FL_A_GET case the hash is checked for flowlabels
with the given label. If it is not found, the lock, protecting
the hash, is dropped to be re-get for writing. After this a
newly allocated entry is inserted, but no checks are performed
to catch a classical SMP race, when the conflicting label may
be inserted on another cpu.
Use the (currently unused) return value from fl_intern() to
return the conflicting entry (if found) and re-check, whether
we can reuse it (IPV6_FL_F_EXCL) or return -EEXISTS.
Also add the comment, about why not re-lookup the current
sock for conflicting flowlabel entry.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
---
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index f40a086..e55ae1a 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -154,8 +154,10 @@ static void ip6_fl_gc(unsigned long dummy)
write_unlock(&ip6_fl_lock);
}
-static int fl_intern(struct ip6_flowlabel *fl, __be32 label)
+static struct ip6_flowlabel *fl_intern(struct ip6_flowlabel *fl, __be32 label)
{
+ struct ip6_flowlabel *lfl;
+
fl->label = label & IPV6_FLOWLABEL_MASK;
write_lock_bh(&ip6_fl_lock);
@@ -163,12 +165,26 @@ static int fl_intern(struct ip6_flowlabel *fl, __be32 label)
for (;;) {
fl->label = htonl(net_random())&IPV6_FLOWLABEL_MASK;
if (fl->label) {
- struct ip6_flowlabel *lfl;
lfl = __fl_lookup(fl->label);
if (lfl == NULL)
break;
}
}
+ } else {
+ /*
+ * we dropper the ip6_fl_lock, so this entry could reappear
+ * and we need to recheck with it.
+ *
+ * OTOH no need to search the active socket first, like it is
+ * done in ipv6_flowlabel_opt - sock is locked, so new entry
+ * with the same label can only appear on another sock
+ */
+ lfl = __fl_lookup(fl->label);
+ if (lfl != NULL) {
+ atomic_inc(&lfl->users);
+ write_unlock_bh(&ip6_fl_lock);
+ return lfl;
+ }
}
fl->lastuse = jiffies;
@@ -176,7 +192,7 @@ static int fl_intern(struct ip6_flowlabel *fl, __be32 label)
fl_ht[FL_HASH(fl->label)] = fl;
atomic_inc(&fl_size);
write_unlock_bh(&ip6_fl_lock);
- return 0;
+ return NULL;
}
@@ -429,7 +445,8 @@ int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
struct in6_flowlabel_req freq;
struct ipv6_fl_socklist *sfl1=NULL;
struct ipv6_fl_socklist *sfl, **sflp;
- struct ip6_flowlabel *fl;
+ struct ip6_flowlabel *fl, *fl1 = NULL;
+
if (optlen < sizeof(freq))
return -EINVAL;
@@ -485,8 +502,6 @@ int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
sfl1 = kmalloc(sizeof(*sfl1), GFP_KERNEL);
if (freq.flr_label) {
- struct ip6_flowlabel *fl1 = NULL;
-
err = -EEXIST;
read_lock_bh(&ip6_sk_fl_lock);
for (sfl = np->ipv6_fl_list; sfl; sfl = sfl->next) {
@@ -505,6 +520,7 @@ int ipv6_flowlabel_opt(struct sock *sk, char __user *optval, int optlen)
if (fl1 == NULL)
fl1 = fl_lookup(freq.flr_label);
if (fl1) {
+recheck:
err = -EEXIST;
if (freq.flr_flags&IPV6_FL_F_EXCL)
goto release;
@@ -543,9 +559,9 @@ release:
if (sfl1 == NULL || (err = mem_check(sk)) != 0)
goto done;
- err = fl_intern(fl, freq.flr_label);
- if (err)
- goto done;
+ fl1 = fl_intern(fl, freq.flr_label);
+ if (fl1 != NULL)
+ goto recheck;
if (!freq.flr_label) {
if (copy_to_user(&((struct in6_flowlabel_req __user *) optval)->flr_label,
^ permalink raw reply related
* Re: [PATCH 2/3] Lost locking in fl6_sock_lookup
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-10-18 12:00 UTC (permalink / raw)
To: xemul; +Cc: davem, netdev, devel, yoshfuji
In-Reply-To: <47174950.6060409@openvz.org>
In article <47174950.6060409@openvz.org> (at Thu, 18 Oct 2007 15:53:52 +0400), Pavel Emelyanov <xemul@openvz.org> says:
> This routine scans the ipv6_fl_list whose update is
> protected with the socket lock and the ip6_sk_fl_lock.
> struct ip6_flowlabel *fl = sfl->fl;
> if (fl->label == label) {
> + read_unlock_bh(&ip6_sk_fl_lock);
> fl->lastuse = jiffies;
> atomic_inc(&fl->users);
> return fl;
We should increment fl->users within the critical section, shouldn't we?
--yoshfuji
^ permalink raw reply
* Re: [PATCH] [TCP]: Remove lost_retrans zero special cases
From: David Miller @ 2007-10-18 12:08 UTC (permalink / raw)
To: ilpo.jarvinen; +Cc: takano, y-kodama, netdev
In-Reply-To: <Pine.LNX.4.64.0710181357370.3767@kivilampi-30.cs.helsinki.fi>
From: "Ilpo_Järvinen" <ilpo.jarvinen@helsinki.fi>
Date: Thu, 18 Oct 2007 14:07:42 +0300 (EEST)
> Dave, please put this one to net-2.6 and forget the other patch with
> title "[TCP]: Add highest_sack_end_seq check back...", it would just
> add another (wrong) zero special case back (they won't conflict with
> each other, so being this verbose here) :-).
Done, thanks everyone.
^ permalink raw reply
* Re: [Bugme-new] [Bug 9174] New: linux-2.6.23-git11 kernel panic
From: David Miller @ 2007-10-18 12:09 UTC (permalink / raw)
To: kaber; +Cc: plamen.petrov, akpm, bugme-daemon, netdev, shemminger
In-Reply-To: <47173C62.5080302@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Thu, 18 Oct 2007 12:58:42 +0200
> Patrick McHardy wrote:
> > Andrew Morton wrote:
> >> On Wed, 17 Oct 2007 07:36:16 -0700 (PDT)
> >> bugme-daemon@bugzilla.kernel.org wrote:
> >>
> >>> http://bugzilla.kernel.org/show_bug.cgi?id=9174
> >>>
> >>> Summary: linux-2.6.23-git11 kernel panic
> > >>
> >
> >>> EIP is at packet_rcv_0x1a2/0x360
> >
> >
> > Please find out on which device the packet socket is opened by
> > looking at /proc/net/packet and comparing the Iface shown there
> > to the ifindexes listed in "ip link list".
>
>
> Well, he replied in private mail, the device in question is
> an IPv6-over-IPv4 tunnel, which doesn't have any header_ops,
> so the crash happens in dev_parse_header when dereferencing
> them.
>
> Signed-off-by: Patrick McHardy <kaber@trash.net>
Applied, thanks Patrick!
^ permalink raw reply
* Re: [PATCH 2/3] Lost locking in fl6_sock_lookup
From: Pavel Emelyanov @ 2007-10-18 12:11 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / 吉藤英明; +Cc: davem, netdev, devel
In-Reply-To: <20071018.210043.51908349.yoshfuji@linux-ipv6.org>
YOSHIFUJI Hideaki wrote:
> In article <47174950.6060409@openvz.org> (at Thu, 18 Oct 2007 15:53:52 +0400), Pavel Emelyanov <xemul@openvz.org> says:
>
>> This routine scans the ipv6_fl_list whose update is
>> protected with the socket lock and the ip6_sk_fl_lock.
>
>> struct ip6_flowlabel *fl = sfl->fl;
>> if (fl->label == label) {
>> + read_unlock_bh(&ip6_sk_fl_lock);
>> fl->lastuse = jiffies;
>> atomic_inc(&fl->users);
>> return fl;
>
> We should increment fl->users within the critical section, shouldn't we?
Not necessary. The users is more than zero (because it is
linked in the sock's list) so garbage collector won't catch
it in any way.
Thanks,
Pavel
> --yoshfuji
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 2/3] Lost locking in fl6_sock_lookup
From: David Miller @ 2007-10-18 12:14 UTC (permalink / raw)
To: xemul; +Cc: yoshfuji, netdev, devel
In-Reply-To: <47174D8E.2050200@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Thu, 18 Oct 2007 16:11:58 +0400
> YOSHIFUJI Hideaki wrote:
> > In article <47174950.6060409@openvz.org> (at Thu, 18 Oct 2007 15:53:52 +0400), Pavel Emelyanov <xemul@openvz.org> says:
> >
> >> This routine scans the ipv6_fl_list whose update is
> >> protected with the socket lock and the ip6_sk_fl_lock.
> >
> >> struct ip6_flowlabel *fl = sfl->fl;
> >> if (fl->label == label) {
> >> + read_unlock_bh(&ip6_sk_fl_lock);
> >> fl->lastuse = jiffies;
> >> atomic_inc(&fl->users);
> >> return fl;
> >
> > We should increment fl->users within the critical section, shouldn't we?
>
> Not necessary. The users is more than zero (because it is
> linked in the sock's list) so garbage collector won't catch
> it in any way.
Right, we're grabbing an "extra" reference here and only
someone who gets the socket lock (which we have) can unlink
it and thus potentially drop the count to zero.
^ permalink raw reply
* Re: [PATCH 1/3] Lost locking when inserting a flowlabel in ipv6_fl_list
From: David Miller @ 2007-10-18 12:15 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <471748CD.2030808@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Thu, 18 Oct 2007 15:51:41 +0400
> The new flowlabels should be inserted into the sock list
> under the ip6_sk_fl_lock. This was lost in one place.
>
> This list is naturally protected with the socket lock, but
> the fl6_sock_lookup() is called without it, so another
> protection is required.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] Lost locking in fl6_sock_lookup
From: David Miller @ 2007-10-18 12:16 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47174950.6060409@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Thu, 18 Oct 2007 15:53:52 +0400
> This routine scans the ipv6_fl_list whose update is
> protected with the socket lock and the ip6_sk_fl_lock.
>
> Since the socket lock is not taken in the lookup, use
> the other one.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
But I notice that I was wrong in my email, we don't
hold the socket lock here.
What prevents an unlink from the socket's list
and thus a reference count of zero occurring for
a brief moment?
^ permalink raw reply
* Re: [PATCH 3/3] Fix race in ipv6_flowlabel_opt() when inserting two labels
From: David Miller @ 2007-10-18 12:19 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47174A92.4090701@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Thu, 18 Oct 2007 15:59:14 +0400
> In the IPV6_FL_A_GET case the hash is checked for flowlabels
> with the given label. If it is not found, the lock, protecting
> the hash, is dropped to be re-get for writing. After this a
> newly allocated entry is inserted, but no checks are performed
> to catch a classical SMP race, when the conflicting label may
> be inserted on another cpu.
>
> Use the (currently unused) return value from fl_intern() to
> return the conflicting entry (if found) and re-check, whether
> we can reuse it (IPV6_FL_F_EXCL) or return -EEXISTS.
>
> Also add the comment, about why not re-lookup the current
> sock for conflicting flowlabel entry.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] Lost locking in fl6_sock_lookup
From: Pavel Emelyanov @ 2007-10-18 12:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev, devel
In-Reply-To: <20071018.051647.23015283.davem@davemloft.net>
David Miller wrote:
> From: Pavel Emelyanov <xemul@openvz.org>
> Date: Thu, 18 Oct 2007 15:53:52 +0400
>
>> This routine scans the ipv6_fl_list whose update is
>> protected with the socket lock and the ip6_sk_fl_lock.
>>
>> Since the socket lock is not taken in the lookup, use
>> the other one.
>>
>> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
>
> Applied.
>
> But I notice that I was wrong in my email, we don't
> hold the socket lock here.
>
> What prevents an unlink from the socket's list
> and thus a reference count of zero occurring for
> a brief moment?
Oops. You're right here :( I looked at the ip6_fl_lock
and messed it with the ip6_sk_fl_lock.
Should I resend the whole patch, or just make an
incremental one?
Thanks,
Pavel
^ permalink raw reply
* Re: [PATCH 2/3] Lost locking in fl6_sock_lookup
From: David Miller @ 2007-10-18 12:33 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel
In-Reply-To: <47175019.4090004@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Thu, 18 Oct 2007 16:22:49 +0400
> Oops. You're right here :( I looked at the ip6_fl_lock
> and messed it with the ip6_sk_fl_lock.
>
> Should I resend the whole patch, or just make an
> incremental one?
Please make an incremental one.
And hurry, I'm trying to go to bed :-)))
^ permalink raw reply
* [PATCH] Fix again the fl6_sock_lookup() fixed locking
From: Pavel Emelyanov @ 2007-10-18 12:36 UTC (permalink / raw)
To: David Miller; +Cc: Linux Netdev List, devel, YOSHIFUJI Hideaki
YOSHIFUJI fairly pointed out, that the users increment should
be done under the ip6_sk_fl_lock not to give IPV6_FL_A_PUT a
chance to put this count to zero and release the flowlabel.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
---
diff --git a/net/ipv6/ip6_flowlabel.c b/net/ipv6/ip6_flowlabel.c
index e55ae1a..b12cc22 100644
--- a/net/ipv6/ip6_flowlabel.c
+++ b/net/ipv6/ip6_flowlabel.c
@@ -210,9 +210,9 @@ struct ip6_flowlabel * fl6_sock_lookup(struct sock *sk, __be32 label)
for (sfl=np->ipv6_fl_list; sfl; sfl = sfl->next) {
struct ip6_flowlabel *fl = sfl->fl;
if (fl->label == label) {
- read_unlock_bh(&ip6_sk_fl_lock);
fl->lastuse = jiffies;
atomic_inc(&fl->users);
+ read_unlock_bh(&ip6_sk_fl_lock);
return fl;
}
}
^ permalink raw reply related
* Re: [PATCH] Fix again the fl6_sock_lookup() fixed locking
From: David Miller @ 2007-10-18 12:38 UTC (permalink / raw)
To: xemul; +Cc: netdev, devel, yoshfuji
In-Reply-To: <4717536A.2080400@openvz.org>
From: Pavel Emelyanov <xemul@openvz.org>
Date: Thu, 18 Oct 2007 16:36:58 +0400
> YOSHIFUJI fairly pointed out, that the users increment should
> be done under the ip6_sk_fl_lock not to give IPV6_FL_A_PUT a
> chance to put this count to zero and release the flowlabel.
>
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
> Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Applied, thank you very much Pavel.
^ permalink raw reply
* about multiple network interface
From: wit @ 2007-10-18 13:06 UTC (permalink / raw)
To: netdev
Hi all,
Sorry, I don't know if this is the right mail list. I got the
following question:
I have a e100 card and a e1000 card. Whenever I boot the system, I
found the eth0 matches the e1000 card, and the eth2 matches the other.
How can I force the eth0 to match the e100 card and the eth2 to match
e1000?
^ permalink raw reply
* Re: BUG: unable to handle kernel NULL pointer dereference at virtual address 000000b0
From: Krzysztof Oledzki @ 2007-10-18 13:15 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Eric Dumazet, netdev
In-Reply-To: <4717477E.8000003@trash.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 406 bytes --]
On Thu, 18 Oct 2007, Patrick McHardy wrote:
> Krzysztof Oledzki wrote:
>>> Hum, you are using IPT_TPROXY thing, which is not in linux-2.6.22.9
>>
>> It is only compiled in, not used at the moment.
>
> But at least the previous version (before those patches posted a week
> ago) touches the routing code in exactly that function.
Right. Thank you.
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Re: about multiple network interface
From: Evgeniy Polyakov @ 2007-10-18 13:28 UTC (permalink / raw)
To: wit; +Cc: netdev
In-Reply-To: <105610bf0710180606w6a687642r35414d2b66b6d3af@mail.gmail.com>
On Thu, Oct 18, 2007 at 09:06:40PM +0800, wit (is01kzh@gmail.com) wrote:
> Hi all,
>
> Sorry, I don't know if this is the right mail list. I got the
> following question:
> I have a e100 card and a e1000 card. Whenever I boot the system, I
> found the eth0 matches the e1000 card, and the eth2 matches the other.
> How can I force the eth0 to match the e100 card and the eth2 to match
> e1000?
Hi.
Check your /etc/modprobe.conf and put there
alias eth0 e100
alias eth2 e1000
--
Evgeniy Polyakov
^ permalink raw reply
* Re: [PATCH v3 0/4] FEC - fast ethernet controller for mpc52xx
From: Grant Likely @ 2007-10-18 14:15 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Domen Puncer, galak, linuxppc-dev, tnt, netdev
In-Reply-To: <4713BA1C.2050604@pobox.com>
On 10/15/07, Jeff Garzik <jgarzik@pobox.com> wrote:
> Domen Puncer wrote:
> > Hello!
> >
> > If there are no objections, I would like to get this merged
> > when bestcomm goes in (any time now?).
> >
> > It's split into four parts:
> > 1 - device tree
> > 2 - small bestcomm change
> > 3 - the actual driver
> > 4 - phy part of the driver
>
> patches #3 and #4 need to be combined together.
>
> Are the arch people OK with patches #1 and #2?
Jeff,
The bestcomm patches and patch 1 & 2 from this series are now in
Linus' tree. That clears the way for the FEC driver when Domen
reposts it. (In other words; there is nothing left in arch land
blocking this driver)
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: [PATCH] Fix ethernet multicast for ucc_geth.
From: Li Yang-r58472 @ 2007-10-18 14:24 UTC (permalink / raw)
To: joakim.tjernlund, Netdev, linuxppc-dev
In-Reply-To: <1192611942.7848.19.camel@gentoo-jocke.transmode.se>
> -----Original Message-----
> From: Joakim Tjernlund [mailto:joakim.tjernlund@transmode.se]
> Sent: Wednesday, October 17, 2007 5:06 PM
> To: Netdev; Li Yang-r58472
> Subject: [PATCH] Fix ethernet multicast for ucc_geth.
>
> >From 5761a9e5924b34615c748fba2dcb977ed04c1243 Mon Sep 17
> 00:00:00 2001
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: Wed, 17 Oct 2007 11:01:44 +0200
> Subject: [PATCH] Fix ethernet multicast for ucc_geth.
> hw_add_addr_in_hash() already swaps byte order, don't do it
> in ucc_geth_set_multi() too.
>
>
> Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Acked-by: Li Yang <leoli@freescale.com>
^ permalink raw reply
* [PATCH] ip: justification for local port range robustness
From: Anton Arapov @ 2007-10-18 14:27 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Stephen Hemminger, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 5108 bytes --]
Hi!
There is a justifying patch for Stephen's patches. Stephen's patches
disallows using a port range of one single port and brakes the meaning
of the 'remaining' variable, in some places it has different meaning.
My patch gives back the sense of 'remaining' variable. It should mean how
many ports are remaining and nothing else. Also my patch allows using
a single port.
I sure we must be able to use mentioned port range, this does not
restricted by documentation and does not brake current behavior.
usefull links:
Patches posted by Stephen Hemminger
http://marc.info/?l=linux-netdev&m=119206106218187&w=2
http://marc.info/?l=linux-netdev&m=119206109918235&w=2
Andrew Morton's comment
http://marc.info/?l=linux-kernel&m=119248225007737&w=2
== Patch:
Justification of the Stephen Hemminger's patches, commit numbers
06393009000779b00a558fd2f280882cc7dc2008
227b60f5102cda4e4ab792b526a59c8cb20cd9f8
1. Allows using a port range of one single port.
2. Gives back sense of 'remaining' variable.
Signed-off-by: Anton Arapov <aarapov@redhat.com>
---
drivers/infiniband/core/cma.c | 5 +++--
net/ipv4/inet_connection_sock.c | 2 +-
net/ipv4/inet_hashtables.c | 2 +-
net/ipv4/sysctl_net_ipv4.c | 4 ++--
net/ipv4/udp.c | 5 +++--
net/ipv6/inet6_hashtables.c | 2 +-
6 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index 93644f8..d08fb30 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -2797,11 +2797,12 @@ static void cma_remove_one(struct ib_device *device)
static int cma_init(void)
{
- int ret, low, high;
+ int ret, low, high, remaining;
get_random_bytes(&next_port, sizeof next_port);
inet_get_local_port_range(&low, &high);
- next_port = ((unsigned int) next_port % (high - low)) + low;
+ remaining = (high - low) + 1;
+ next_port = ((unsigned int) next_port % remaining) + low;
cma_wq = create_singlethread_workqueue("rdma_cm");
if (!cma_wq)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 3cef128..8fb6ca2 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -93,7 +93,7 @@ int inet_csk_get_port(struct inet_hashinfo *hashinfo,
int remaining, rover, low, high;
inet_get_local_port_range(&low, &high);
- remaining = high - low;
+ remaining = (high - low) + 1;
rover = net_random() % remaining + low;
do {
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index fac6398..16eecc7 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -286,7 +286,7 @@ int inet_hash_connect(struct inet_timewait_death_row *death_row,
struct inet_timewait_sock *tw = NULL;
inet_get_local_port_range(&low, &high);
- remaining = high - low;
+ remaining = (high - low) + 1;
local_bh_disable();
for (i = 1; i <= remaining; i++) {
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index c98ef16..ec353cf 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -122,7 +122,7 @@ static int ipv4_local_port_range(ctl_table *table, int write, struct file *filp,
ret = proc_dointvec_minmax(&tmp, write, filp, buffer, lenp, ppos);
if (write && ret == 0) {
- if (range[1] <= range[0])
+ if (range[1] < range[0])
ret = -EINVAL;
else
set_local_port_range(range);
@@ -150,7 +150,7 @@ static int ipv4_sysctl_local_port_range(ctl_table *table, int __user *name,
ret = sysctl_intvec(&tmp, name, nlen, oldval, oldlenp, newval, newlen);
if (ret == 0 && newval && newlen) {
- if (range[1] <= range[0])
+ if (range[1] < range[0])
ret = -EINVAL;
else
set_local_port_range(range);
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index cb9fc58..35d2b0e 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -147,13 +147,14 @@ int __udp_lib_get_port(struct sock *sk, unsigned short snum,
write_lock_bh(&udp_hash_lock);
if (!snum) {
- int i, low, high;
+ int i, low, high, remaining;
unsigned rover, best, best_size_so_far;
inet_get_local_port_range(&low, &high);
+ remaining = (high - low) + 1;
best_size_so_far = UINT_MAX;
- best = rover = net_random() % (high - low) + low;
+ best = rover = net_random() % remaining + low;
/* 1st pass: look for empty (or shortest) hash chain */
for (i = 0; i < UDP_HTABLE_SIZE; i++) {
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index 1c2c276..d6f1026 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -261,7 +261,7 @@ int inet6_hash_connect(struct inet_timewait_death_row *death_row,
struct inet_timewait_sock *tw = NULL;
inet_get_local_port_range(&low, &high);
- remaining = high - low;
+ remaining = (high - low) + 1;
local_bh_disable();
for (i = 1; i <= remaining; i++) {
--
Anton Arapov, <aarapov@redhat.com>
GPG Key ID: 0x6FA8C812
[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]
^ 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