* Re: [PATCH 2.6.32-rc1] net: VMware virtual Ethernet NIC driver: vmxnet3
From: David Miller @ 2009-10-01 22:23 UTC (permalink / raw)
To: sbhatewara
Cc: linux-kernel, netdev, shemminger, jgarzik, anthony, chrisw, greg,
akpm, virtualization, pv-drivers
In-Reply-To: <alpine.LRH.2.00.0909301432410.8073@localhost.localdomain>
From: Shreyas Bhatewara <sbhatewara@vmware.com>
Date: Wed, 30 Sep 2009 14:34:57 -0700 (PDT)
> +{
> + struct vmxnet3_adapter *adapter = netdev_priv(netdev);
> + u8 *base;
> + int i;
> +
> + VMXNET3_WRITE_BAR1_REG(adapter, VMXNET3_REG_CMD,
> VMXNET3_CMD_GET_STATS);
> +
> + /* this does assume each counter is 64-bit wide */
> +
> + base = (u8 *)&adapter->tqd_start->stats;
> + for (i = 0; i < ARRAY_SIZE(vmxnet3_tq_dev_stats); i++)
> + *buf++ = *(u64 *)(base + vmxnet3_tq_dev_stats[i].offset);
> +
> + base = (u8 *)&adapter->tx_queue.stats;
> + for (i = 0; i < ARRAY_SIZE(vmxnet3_tq_driver_stats); i++)
> + *buf++ = *(u64 *)(base + vmxnet3_tq_driver_stats[i].offset);
> +
> + base = (u8 *)&adapter->rqd_start->stats;
There's a lot of code like this that isn't indented properly. Either
that or your email client has corrupted the patch by breaking up long
lines or similar.
Another example:
> +static int
> +vmxnet3_set_rx_csum(struct net_device *netdev, u32 val)
> +{
> + struct vmxnet3_adapter *adapter = netdev_priv(netdev);
> +
> + if (adapter->rxcsum != val) {
> + adapter->rxcsum = val;
> + if (netif_running(netdev)) {
> + if (val)
> + adapter->shared->devRead.misc.uptFeatures |=
> + UPT1_F_RXCSUM;
> + else
> + adapter->shared->devRead.misc.uptFeatures &=
> + ~UPT1_F_RXCSUM;
> +
> + VMXNET3_WRITE_BAR1_REG(adapter, VMXNET3_REG_CMD,
> + VMXNET3_CMD_UPDATE_FEATURE);
> + }
> + }
> + return 0;
> +}
Yikes! :-)
^ permalink raw reply
* Re: SPLICE_F_NONBLOCK semantics...
From: Linus Torvalds @ 2009-10-01 22:24 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, jgunthorpe, vl, opurdila, netdev,
Linux Kernel Mailing List, Jens Axboe
In-Reply-To: <alpine.LFD.2.01.0910011516390.6996@localhost.localdomain>
On Thu, 1 Oct 2009, Linus Torvalds wrote:
>
> Ack. The original intent was for the flag to affect the buffering, not the
> end points.
Side note, in case it wasn't clear: I added Jens to the cc, because in the
end my "original intent" probably doesn't matter all that much. I may have
set up the basic ideas and so on, but I never wrote any apps that use it,
and Jens has done most of the actual fixes since.
So give "my original intent" the weight (or rather, lack there-of) that it
deserves.
Linus
^ permalink raw reply
* Re: SPLICE_F_NONBLOCK semantics...
From: David Miller @ 2009-10-01 22:27 UTC (permalink / raw)
To: torvalds
Cc: eric.dumazet, jgunthorpe, vl, opurdila, netdev, linux-kernel,
jens.axboe
In-Reply-To: <alpine.LFD.2.01.0910011516390.6996@localhost.localdomain>
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu, 1 Oct 2009 15:21:44 -0700 (PDT)
> On Thu, 1 Oct 2009, David Miller wrote:
>>
>> It depends upon our interpretation of how you intended the
>> SPLICE_F_NONBLOCK flag to work when you added it way back
>> when.
>>
>> Linus introduced SPLICE_F_NONBLOCK in commit 29e350944fdc2dfca102500790d8ad6d6ff4f69d
>> (splice: add SPLICE_F_NONBLOCK flag )
>>
>> It doesn't make the splice itself necessarily nonblocking (because the
>> actual file descriptors that are spliced from/to may block unless they
>> have the O_NONBLOCK flag set), but it makes the splice pipe operations
>> nonblocking.
>>
>> Linus intention was clear : let SPLICE_F_NONBLOCK control the splice pipe mode only
>
> Ack. The original intent was for the flag to affect the buffering, not the
> end points.
Great, thanks for reviewing.
> Although the more I think about it, the more I suspect that the
> whole NONBLOCK thing should probably have been two bits, and simply
> been about "nonblocking input" vs "nonblocking output" (so that you
> could control both sides on a call-by-call basis).
I think we could still extend things in this way if we wanted to.
So if you specify the explicit input and/or output nonblock flag,
it takes precedence over the SPLICE_F_NONBLOCK thing.
Anyways, just an idea.
^ permalink raw reply
* [PATCH] pasemi_mac: ethtool get settings fix
From: Valentine Barshak @ 2009-10-01 22:27 UTC (permalink / raw)
To: linuxppc-dev; +Cc: netdev
Not all pasemi mac interfaces can have a phy attached.
For example, XAUI has no phy and phydev is NULL for it.
In this case ethtool get settings causes kernel crash.
Fix it by returning -EOPNOTSUPP if there's no PHY attached.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
drivers/net/pasemi_mac_ethtool.c | 2 ++
1 file changed, 2 insertions(+)
--- linux-2.6.21.orig/drivers/net/pasemi_mac_ethtool.c 2008-11-06 18:10:38.000000000 +0300
+++ linux-2.6.21/drivers/net/pasemi_mac_ethtool.c 2008-11-19 19:24:28.000000000 +0300
@@ -71,6 +71,8 @@ pasemi_mac_ethtool_get_settings(struct n
struct pasemi_mac *mac = netdev_priv(netdev);
struct phy_device *phydev = mac->phydev;
+ if (!phydev)
+ return -EOPNOTSUPP;
return phy_ethtool_gset(phydev, cmd);
}
^ permalink raw reply
* Re: [PATCH] connector: Fix regression introduced by sid connector
From: Oleg Nesterov @ 2009-10-01 22:29 UTC (permalink / raw)
To: Andrew Morton
Cc: Christian Borntraeger, scott, zbr, linux-kernel, matthltc, davem,
netdev
In-Reply-To: <20091001141426.2c1a0139.akpm@linux-foundation.org>
On 10/01, Andrew Morton wrote:
>
> On Wed, 30 Sep 2009 08:43:11 +0200
> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
>
> > --- linux-2.6.orig/kernel/sys.c
> > +++ linux-2.6/kernel/sys.c
> > @@ -1110,6 +1110,8 @@ SYSCALL_DEFINE0(setsid)
> > err = session;
> > out:
> > write_unlock_irq(&tasklist_lock);
> > + if (err > 0)
> > + proc_sid_connector(sid);
> > return err;
> > }
>
> kernel/sys.c: In function 'sys_setsid':
> kernel/sys.c:1114: warning: passing argument 1 of 'proc_sid_connector' from incompatible pointer type
>
> Pass a `struct pid*' into a function expecting a `struct task_struct*'.
> Surely it will crash??
Oh, indeed, it should be
proc_sid_connector(group_leader);
Oleg.
^ permalink raw reply
* Re: Network hangs with 2.6.30.5
From: David Miller @ 2009-10-01 22:49 UTC (permalink / raw)
To: jarkao2; +Cc: holger.hoffstaette, netdev, eric.dumazet, ilpo.jarvinen
In-Reply-To: <20090907072143.GA5966@ff.dom.local>
From: Jarek Poplawski <jarkao2@gmail.com>
Date: Mon, 7 Sep 2009 07:21:43 +0000
> While Eric is analyzing your data, I guess you could try reverting
> some stuff around this tcp_tw_recycle, and my tcp ignorance would
> point these commits for the beginning:
>
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=commitdiff;h=fc1ad92dfc4e363a055053746552cdb445ba5c57
> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=commitdiff;h=c887e6d2d9aee56ee7c9f2af4cec3a5efdcc4c72
Ilpo's cleanup (the second commit listed) looks most likely to
be a possibility.
But I surely cannot find any bugs in it, even after studying it
a few times.
Ilpo could you audit it one more time for us just in case?
I also looked through all the TCP commits in 2.6.29 to 2.6.30
and I could not find anything else that might cause stalls with
time-wait recycled connections.
^ permalink raw reply
* Re: 2.6.32-rc1-git2: Reported regressions from 2.6.31
From: James Bottomley @ 2009-10-01 22:48 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Linux Kernel Mailing List, Adrian Bunk, Andrew Morton,
Linus Torvalds, Natalie Protasevich, Kernel Testers List,
Network Development, Linux ACPI, Linux PM List, Linux SCSI List,
Linux Wireless List, DRI
In-Reply-To: <9UCePxij8cB.A.VCG.-3SxKB@chimera>
On Thu, 2009-10-01 at 21:26 +0200, Rafael J. Wysocki wrote:
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14214
> Subject : BUG at drivers/scsi/scsi_lib.c:1108!
> Submitter : Plamen Petrov <pvp-lsts-Xdw7EbNJKi3354cJYj5R/Q@public.gmane.org>
> Date : 2009-09-23 11:13 (9 days old)
This one is fixed (as confirmed by the bug report).
James
^ permalink raw reply
* [patch 8/9] netfilter: bridge: refcount fix
From: Greg KH @ 2009-10-01 23:16 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, netdev, netfilter-devel,
Patrick McHardy, davem, Eric Dumazet
In-Reply-To: <20091001231938.GA29593@kroah.com>
[-- Attachment #1: netfilter-bridge-refcount-fix.patch --]
[-- Type: text/plain, Size: 1100 bytes --]
2.6.27-stable review patch. If anyone has any objections, please let us know.
------------------
From: Patrick McHardy <kaber@trash.net>
netfilter: bridge: refcount fix
Upstream commit f3abc9b9:
commit f216f082b2b37c4943f1e7c393e2786648d48f6f
([NETFILTER]: bridge netfilter: deal with martians correctly)
added a refcount leak on in_dev.
Instead of using in_dev_get(), we can use __in_dev_get_rcu(),
as netfilter hooks are running under rcu_read_lock(), as pointed
by Patrick.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/bridge/br_netfilter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -358,7 +358,7 @@ static int br_nf_pre_routing_finish(stru
},
.proto = 0,
};
- struct in_device *in_dev = in_dev_get(dev);
+ struct in_device *in_dev = __in_dev_get_rcu(dev);
/* If err equals -EHOSTUNREACH the error is due to a
* martian destination or due to the fact that
^ permalink raw reply
* [patch 21/30] netfilter: bridge: refcount fix
From: Greg KH @ 2009-10-01 23:31 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, netdev, netfilter-devel,
Patrick McHardy, davem, Eric Dumazet
In-Reply-To: <20091001233504.GA17709@kroah.com>
[-- Attachment #1: netfilter-bridge-refcount-fix.patch --]
[-- Type: text/plain, Size: 1097 bytes --]
2.6.30-stable review patch. If anyone has any objections, please let us know.
------------------
From: Patrick McHardy <kaber@trash.net>
netfilter: bridge: refcount fix
Upstream commit f3abc9b9:
commit f216f082b2b37c4943f1e7c393e2786648d48f6f
([NETFILTER]: bridge netfilter: deal with martians correctly)
added a refcount leak on in_dev.
Instead of using in_dev_get(), we can use __in_dev_get_rcu(),
as netfilter hooks are running under rcu_read_lock(), as pointed
by Patrick.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/bridge/br_netfilter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -357,7 +357,7 @@ static int br_nf_pre_routing_finish(stru
},
.proto = 0,
};
- struct in_device *in_dev = in_dev_get(dev);
+ struct in_device *in_dev = __in_dev_get_rcu(dev);
/* If err equals -EHOSTUNREACH the error is due to a
* martian destination or due to the fact that
^ permalink raw reply
* [patch 22/30] netfilter: ebt_ulog: fix checkentry return value
From: Greg KH @ 2009-10-01 23:31 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, netdev, netfilter-devel,
Patrick McHardy, davem
In-Reply-To: <20091001233504.GA17709@kroah.com>
[-- Attachment #1: netfilter-ebt_ulog-fix-checkentry-return-value.patch --]
[-- Type: text/plain, Size: 900 bytes --]
2.6.30-stable review patch. If anyone has any objections, please let us know.
------------------
From: Patrick McHardy <kaber@trash.net>
netfilter: ebt_ulog: fix checkentry return value
Upstream commit 8a56df0a:
Commit 19eda87 (netfilter: change return types of check functions for
Ebtables extensions) broke the ebtables ulog module by missing a return
value conversion.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/bridge/netfilter/ebt_ulog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/bridge/netfilter/ebt_ulog.c
+++ b/net/bridge/netfilter/ebt_ulog.c
@@ -266,7 +266,7 @@ static bool ebt_ulog_tg_check(const stru
if (uloginfo->qthreshold > EBT_ULOG_MAX_QLEN)
uloginfo->qthreshold = EBT_ULOG_MAX_QLEN;
- return 0;
+ return true;
}
static struct xt_target ebt_ulog_tg_reg __read_mostly = {
^ permalink raw reply
* [patch 23/30] netfilter: nf_nat: fix inverted logic for persistent NAT mappings
From: Greg KH @ 2009-10-01 23:31 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, netdev, netfilter-devel,
Patrick McHardy, davem, Maximilian Engelhardt
In-Reply-To: <20091001233504.GA17709@kroah.com>
[-- Attachment #1: netfilter-nf_nat-fix-inverted-logic-for-persistent-nat-mappings.patch --]
[-- Type: text/plain, Size: 1554 bytes --]
2.6.30-stable review patch. If anyone has any objections, please let us know.
------------------
From: Patrick McHardy <kaber@trash.net>
netfilter: nf_nat: fix inverted logic for persistent NAT mappings
Upstream commit cce5a5c3:
Kernel 2.6.30 introduced a patch [1] for the persistent option in the
netfilter SNAT target. This is exactly what we need here so I had a quick look
at the code and noticed that the patch is wrong. The logic is simply inverted.
The patch below fixes this.
Also note that because of this the default behavior of the SNAT target has
changed since kernel 2.6.30 as it now ignores the destination IP in choosing
the source IP for nating (which should only be the case if the persistent
option is set).
[1] http://git.eu.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98d500d66cb7940747b424b245fc6a51ecfbf005
Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/ipv4/netfilter/nf_nat_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/netfilter/nf_nat_core.c
+++ b/net/ipv4/netfilter/nf_nat_core.c
@@ -212,7 +212,7 @@ find_best_ips_proto(struct nf_conntrack_
maxip = ntohl(range->max_ip);
j = jhash_2words((__force u32)tuple->src.u3.ip,
range->flags & IP_NAT_RANGE_PERSISTENT ?
- (__force u32)tuple->dst.u3.ip : 0, 0);
+ 0 : (__force u32)tuple->dst.u3.ip, 0);
j = ((u64)j * (maxip - minip + 1)) >> 32;
*var_ipp = htonl(minip + j);
}
^ permalink raw reply
* [082/136] netfilter: nf_conntrack: netns fix re reliable conntrack event delivery
From: Greg KH @ 2009-10-02 1:17 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, netdev, netfilter-devel,
Patrick McHardy, davem, Alexey Dobriyan, Pablo Neira Ayuso
In-Reply-To: <20091002012911.GA18542@kroah.com>
[-- Attachment #1: netfilter-nf_conntrack-netns-fix-re-reliable-conntrack-event-delivery.patch --]
[-- Type: text/plain, Size: 1572 bytes --]
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Patrick McHardy <kaber@trash.net>
netfilter: nf_conntrack: netns fix re reliable conntrack event delivery
Upstream commit ee254fa4:
Conntracks in netns other than init_net dying list were never killed.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/netfilter/nf_conntrack_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1089,14 +1089,14 @@ void nf_conntrack_flush_report(struct ne
}
EXPORT_SYMBOL_GPL(nf_conntrack_flush_report);
-static void nf_ct_release_dying_list(void)
+static void nf_ct_release_dying_list(struct net *net)
{
struct nf_conntrack_tuple_hash *h;
struct nf_conn *ct;
struct hlist_nulls_node *n;
spin_lock_bh(&nf_conntrack_lock);
- hlist_nulls_for_each_entry(h, n, &init_net.ct.dying, hnnode) {
+ hlist_nulls_for_each_entry(h, n, &net->ct.dying, hnnode) {
ct = nf_ct_tuplehash_to_ctrack(h);
/* never fails to remove them, no listeners at this point */
nf_ct_kill(ct);
@@ -1115,7 +1115,7 @@ static void nf_conntrack_cleanup_net(str
{
i_see_dead_people:
nf_ct_iterate_cleanup(net, kill_all, NULL);
- nf_ct_release_dying_list();
+ nf_ct_release_dying_list(net);
if (atomic_read(&net->ct.count) != 0) {
schedule();
goto i_see_dead_people;
^ permalink raw reply
* [083/136] netfilter: bridge: refcount fix
From: Greg KH @ 2009-10-02 1:17 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, netdev, netfilter-devel,
Patrick McHardy, davem, Eric Dumazet
In-Reply-To: <20091002012911.GA18542@kroah.com>
[-- Attachment #1: netfilter-bridge-refcount-fix.patch --]
[-- Type: text/plain, Size: 1097 bytes --]
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Patrick McHardy <kaber@trash.net>
netfilter: bridge: refcount fix
Upstream commit f3abc9b9:
commit f216f082b2b37c4943f1e7c393e2786648d48f6f
([NETFILTER]: bridge netfilter: deal with martians correctly)
added a refcount leak on in_dev.
Instead of using in_dev_get(), we can use __in_dev_get_rcu(),
as netfilter hooks are running under rcu_read_lock(), as pointed
by Patrick.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/bridge/br_netfilter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -359,7 +359,7 @@ static int br_nf_pre_routing_finish(stru
},
.proto = 0,
};
- struct in_device *in_dev = in_dev_get(dev);
+ struct in_device *in_dev = __in_dev_get_rcu(dev);
/* If err equals -EHOSTUNREACH the error is due to a
* martian destination or due to the fact that
^ permalink raw reply
* [084/136] netfilter: ebt_ulog: fix checkentry return value
From: Greg KH @ 2009-10-02 1:17 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, netdev, netfilter-devel,
Patrick McHardy, davem
In-Reply-To: <20091002012911.GA18542@kroah.com>
[-- Attachment #1: netfilter-ebt_ulog-fix-checkentry-return-value.patch --]
[-- Type: text/plain, Size: 900 bytes --]
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Patrick McHardy <kaber@trash.net>
netfilter: ebt_ulog: fix checkentry return value
Upstream commit 8a56df0a:
Commit 19eda87 (netfilter: change return types of check functions for
Ebtables extensions) broke the ebtables ulog module by missing a return
value conversion.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/bridge/netfilter/ebt_ulog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/bridge/netfilter/ebt_ulog.c
+++ b/net/bridge/netfilter/ebt_ulog.c
@@ -266,7 +266,7 @@ static bool ebt_ulog_tg_check(const stru
if (uloginfo->qthreshold > EBT_ULOG_MAX_QLEN)
uloginfo->qthreshold = EBT_ULOG_MAX_QLEN;
- return 0;
+ return true;
}
static struct xt_target ebt_ulog_tg_reg __read_mostly = {
^ permalink raw reply
* [081/136] netfilter: nf_nat: fix inverted logic for persistent NAT mappings
From: Greg KH @ 2009-10-02 1:17 UTC (permalink / raw)
To: linux-kernel, stable
Cc: stable-review, torvalds, akpm, alan, netdev, netfilter-devel,
Patrick McHardy, davem, Maximilian Engelhardt
In-Reply-To: <20091002012911.GA18542@kroah.com>
[-- Attachment #1: netfilter-nf_nat-fix-inverted-logic-for-persistent-nat-mappings.patch --]
[-- Type: text/plain, Size: 1554 bytes --]
2.6.31-stable review patch. If anyone has any objections, please let us know.
------------------
From: Patrick McHardy <kaber@trash.net>
netfilter: nf_nat: fix inverted logic for persistent NAT mappings
Upstream commit cce5a5c3:
Kernel 2.6.30 introduced a patch [1] for the persistent option in the
netfilter SNAT target. This is exactly what we need here so I had a quick look
at the code and noticed that the patch is wrong. The logic is simply inverted.
The patch below fixes this.
Also note that because of this the default behavior of the SNAT target has
changed since kernel 2.6.30 as it now ignores the destination IP in choosing
the source IP for nating (which should only be the case if the persistent
option is set).
[1] http://git.eu.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=98d500d66cb7940747b424b245fc6a51ecfbf005
Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
net/ipv4/netfilter/nf_nat_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/netfilter/nf_nat_core.c
+++ b/net/ipv4/netfilter/nf_nat_core.c
@@ -212,7 +212,7 @@ find_best_ips_proto(struct nf_conntrack_
maxip = ntohl(range->max_ip);
j = jhash_2words((__force u32)tuple->src.u3.ip,
range->flags & IP_NAT_RANGE_PERSISTENT ?
- (__force u32)tuple->dst.u3.ip : 0, 0);
+ 0 : (__force u32)tuple->dst.u3.ip, 0);
j = ((u64)j * (maxip - minip + 1)) >> 32;
*var_ipp = htonl(minip + j);
}
^ permalink raw reply
* Re: [PATCH 1/7] mlx4: Added interrupts test support
From: Roland Dreier @ 2009-10-02 3:32 UTC (permalink / raw)
To: Yevgeny Petrilin; +Cc: davem, netdev
In-Reply-To: <4AC4BD9A.2050101@mellanox.co.il>
This feels like a pretty risky thing to do while the device might be
handling all sorts of other traffic at the same time. Are you sure
there are no races you expose here? Have you actually seen cases where
the interrupt test during initialization works but then this test
catches a problem? (My experience has been that if any MSI-X interrupts
work from a device, then they'll all work)
> +/* A test that verifies that we can accept interrupts on all
> + * the irq vectors of the device.
> + * Interrupts are checked using the NOP command.
> + */
> +int mlx4_test_interrupts(struct mlx4_dev *dev)
> +{
> + struct mlx4_priv *priv = mlx4_priv(dev);
> + int i;
> + int err;
> +
> + err = mlx4_NOP(dev);
> + /* When not in MSI_X, there is only one irq to check */
> + if (!(dev->flags & MLX4_FLAG_MSI_X))
> + return err;
> +
> + /* A loop over all completion vectors, for each vector we will check
> + * whether it works by mapping command completions to that vector
> + * and performing a NOP command
> + */
> + for (i = 0; !err && (i < dev->caps.num_comp_vectors); ++i) {
> + /* Temporary use polling for command completions */
you want the adverb form here: "Temporarily"
> + mlx4_cmd_use_polling(dev);
> +
> + /* Map the new eq to handle all asyncronous events */
"asynchronous"
> + err = mlx4_MAP_EQ(dev, MLX4_ASYNC_EVENT_MASK, 0,
> + priv->eq_table.eq[i].eqn);
> + if (err) {
> + mlx4_warn(dev, "Failed mapping eq for interrupt test\n");
> + mlx4_cmd_use_events(dev);
> + break;
> + }
> +
> + /* Go back to using events */
> + mlx4_cmd_use_events(dev);
> + err = mlx4_NOP(dev);
You could simplify the code a bit by moving the mlx4_cmd_use_events() to
before where you test err, ie:
err = mlx4_MAP_EQ(...);
mlx4_cmd_user_events(dev);
if (err)
mlx4_warn(dev, ...)
else
err = mlx4_NOP(dev);
> + }
> +
> + /* Return to default */
> + mlx4_MAP_EQ(dev, MLX4_ASYNC_EVENT_MASK, 0,
> + priv->eq_table.eq[dev->caps.num_comp_vectors].eqn);
> + return err;
> +}
^ permalink raw reply
* query: adding a sysctl
From: William Allen Simpson @ 2009-10-02 4:00 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 403 bytes --]
[My first post here, hopefully not a FAQ, as I've googled it, but cannot find
the definitive answer.]
I've been trying to add a sysctl, and I've noticed this message:
sysctl table check failed: /net/ipv4/tcp_cookie_size .3.5.126 Unknown sysctl binary path
I modeled the code on sysctl_tcp_syncookies, and apparently I'm missing some
additional magic? Or does something need to be done other than C?
[-- Attachment #2: sysctl_tcp_cookie_size.txt --]
[-- Type: text/plain, Size: 1993 bytes --]
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index e76d3b2..8c74bec 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -435,6 +435,7 @@ enum
NET_TCP_ALLOWED_CONG_CONTROL=123,
NET_TCP_MAX_SSTHRESH=124,
NET_TCP_FRTO_RESPONSE=125,
+ NET_TCP_COOKIE_SIZE=126,
};
enum {
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 4710d21..e6174c9 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -340,6 +340,16 @@ static struct ctl_table ipv4_table[] = {
.proc_handler = proc_dointvec_jiffies,
.strategy = sysctl_jiffies
},
+#ifdef CONFIG_TCP_OPT_COOKIE_EXTENSION
+ {
+ .ctl_name = NET_TCP_COOKIE_SIZE,
+ .procname = "tcp_cookie_size",
+ .data = &sysctl_tcp_cookie_size,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
+#endif
#ifdef CONFIG_SYN_COOKIES
{
.ctl_name = NET_TCP_SYNCOOKIES,
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 56b7602..a53b2a8 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -208,6 +214,7 @@ extern int sysctl_tcp_synack_retries;
extern int sysctl_tcp_retries1;
extern int sysctl_tcp_retries2;
extern int sysctl_tcp_orphan_retries;
+extern int sysctl_tcp_cookie_size;
extern int sysctl_tcp_syncookies;
extern int sysctl_tcp_retrans_collapse;
extern int sysctl_tcp_stdurg;
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 5200aab..afbdc30 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -59,6 +59,14 @@ int sysctl_tcp_base_mss __read_mostly = 512;
/* By default, RFC2861 behavior. */
int sysctl_tcp_slow_start_after_idle __read_mostly = 1;
+#ifdef CONFIG_SYSCTL
+/* By default, let the user enable it. */
+int sysctl_tcp_cookie_size __read_mostly = 0;
+#else
+int sysctl_tcp_cookie_size __read_mostly = TCP_COOKIE_MAX;
+#endif
+
+
/* Account for new data that has been sent to the network. */
static void tcp_event_new_data_sent(struct sock *sk, struct sk_buff *skb)
{
^ permalink raw reply related
* Re: [PATCH] tg3: Remove prev_vlan_tag from struct tx_ring_info
From: Eric Dumazet @ 2009-10-02 4:16 UTC (permalink / raw)
To: David Miller; +Cc: mcarlson, netdev, mchan
In-Reply-To: <20091001.143859.53379358.davem@davemloft.net>
David Miller a écrit :
>
> Applied, thanks.
>
> Eric, I had to apply this by hand because:
>
>>> @@ -2412,7 +2412,6 @@ struct ring_info {
>>>
>>> struct tx_ring_info {
>>> struct sk_buff *skb;
>>> - u32 prev_vlan_tag;
>>> };
>
> Your email client changed tabs into spaces.
Oops, I'm sorry Dave, I did a copy/paste and forgot about tabs.
Thanks
^ permalink raw reply
* Re: [PATCH 04/31] mm: tag reseve pages
From: Neil Brown @ 2009-10-02 4:43 UTC (permalink / raw)
To: David Rientjes
Cc: Suresh Jayaraman, Linus Torvalds, Andrew Morton, linux-kernel,
linux-mm, netdev, Miklos Szeredi, Wouter Verhelst, Peter Zijlstra,
trond.myklebust
In-Reply-To: <alpine.DEB.1.00.0910011407390.32006@chino.kir.corp.google.com>
On Thursday October 1, rientjes@google.com wrote:
> On Thu, 1 Oct 2009, Suresh Jayaraman wrote:
>
> > Index: mmotm/mm/page_alloc.c
> > ===================================================================
> > --- mmotm.orig/mm/page_alloc.c
> > +++ mmotm/mm/page_alloc.c
> > @@ -1501,8 +1501,10 @@ zonelist_scan:
> > try_this_zone:
> > page = buffered_rmqueue(preferred_zone, zone, order,
> > gfp_mask, migratetype);
> > - if (page)
> > + if (page) {
> > + page->reserve = !!(alloc_flags & ALLOC_NO_WATERMARKS);
> > break;
> > + }
> > this_zone_full:
> > if (NUMA_BUILD)
> > zlc_mark_zone_full(zonelist, z);
>
> page->reserve won't necessary indicate that access to reserves was
> _necessary_ for the allocation to succeed, though. This will mark any
> page being allocated under PF_MEMALLOC as reserve when all zones may be
> well above their min watermarks.
Normally if zones are above their watermarks, page->reserve will not
be set.
This is because __alloc_page_nodemask (which seems to be the main
non-inline entrypoint) first calls get_page_from_freelist with
alloc_flags set to ALLOC_WMARK_LOW|ALLOC_CPUSET.
Only if this fails does __alloc_page_nodemask call
__alloc_pages_slowpath which potentially sets ALLOC_NO_WATERMARKS in
alloc_flags.
So page->reserved being set actually tells us:
PF_MEMALLOC or GFP_MEMALLOC were used, and
a WMARK_LOW allocation attempt failed very recently
which is close enough to "the emergency reserves were used" I think.
Thanks,
NeilBrown
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 30/31] Fix use of uninitialized variable in cache_grow()
From: Neil Brown @ 2009-10-02 4:54 UTC (permalink / raw)
To: David Rientjes
Cc: Suresh Jayaraman, Linus Torvalds, Andrew Morton, linux-kernel,
linux-mm, netdev, Miklos Szeredi, Wouter Verhelst, Peter Zijlstra,
trond.myklebust
In-Reply-To: <alpine.DEB.1.00.0910011341280.27559@chino.kir.corp.google.com>
On Thursday October 1, rientjes@google.com wrote:
> On Thu, 1 Oct 2009, Suresh Jayaraman wrote:
>
> > From: Miklos Szeredi <mszeredi@suse.cz>
> >
> > This fixes a bug in reserve-slub.patch.
> >
> > If cache_grow() was called with objp != NULL then the 'reserve' local
> > variable wasn't initialized. This resulted in ac->reserve being set to
> > a rubbish value. Due to this in some circumstances huge amounts of
> > slab pages were allocated (due to slab_force_alloc() returning true),
> > which caused atomic page allocation failures and slowdown of the
> > system.
> >
> > Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
> > Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
> > ---
> > mm/slab.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > Index: mmotm/mm/slab.c
> > ===================================================================
> > --- mmotm.orig/mm/slab.c
> > +++ mmotm/mm/slab.c
> > @@ -2760,7 +2760,7 @@ static int cache_grow(struct kmem_cache
> > size_t offset;
> > gfp_t local_flags;
> > struct kmem_list3 *l3;
> > - int reserve;
> > + int reserve = -1;
> >
> > /*
> > * Be lazy and only check for valid flags here, keeping it out of the
> > @@ -2816,7 +2816,8 @@ static int cache_grow(struct kmem_cache
> > if (local_flags & __GFP_WAIT)
> > local_irq_disable();
> > check_irq_off();
> > - slab_set_reserve(cachep, reserve);
> > + if (reserve != -1)
> > + slab_set_reserve(cachep, reserve);
> > spin_lock(&l3->list_lock);
> >
> > /* Make slab active. */
>
> Given the patch description, shouldn't this be a test for objp != NULL
> instead, then?
In between those to patch hunks, cache_grow contains the code:
if (!objp)
objp = kmem_getpages(cachep, local_flags, nodeid, &reserve);
if (!objp)
goto failed;
We can no longer test if objp was NULL on entry to the function.
We could take a copy of objp on entry to the function, and test it
here. But initialising 'reserve' to an invalid value is easier.
>
> If so, it doesn't make sense because reserve will only be initialized when
> objp == NULL in the call to kmem_getpages() from cache_grow().
>
>
> The title of the patch suggests this is just dealing with an uninitialized
> auto variable so the anticipated change would be from "int reserve" to
> "int uninitialized_var(result)".
That change is only appropriate when the compiler is issuing a
warning that the variable is used before it is initialised, but we
know that not to be the case.
In this situation, we know it *is* being used before it is
initialised, and so we need to initialise it to something.
Thanks,
NeilBrown
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 03/31] mm: expose gfp_to_alloc_flags()
From: Neil Brown @ 2009-10-02 5:04 UTC (permalink / raw)
To: David Rientjes
Cc: Suresh Jayaraman, Linus Torvalds, Andrew Morton, linux-kernel,
linux-mm, netdev, Miklos Szeredi, Wouter Verhelst, Peter Zijlstra,
trond.myklebust
In-Reply-To: <alpine.DEB.1.00.0910011355230.32006@chino.kir.corp.google.com>
On Thursday October 1, rientjes@google.com wrote:
> On Thu, 1 Oct 2009, Suresh Jayaraman wrote:
>
> > From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> >
> > Expose the gfp to alloc_flags mapping, so we can use it in other parts
> > of the vm.
> >
> > Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Signed-off-by: Suresh Jayaraman <sjayaraman@suse.de>
>
> Nack, these flags are internal to the page allocator and exporting them to
> generic VM code is unnecessary.
>
> The only bit you actually use in your patchset is ALLOC_NO_WATERMARKS to
> determine whether a particular allocation can use memory reserves. I'd
> suggest adding a bool function that returns whether the current context is
> given access to reserves including your new __GFP_MEMALLOC flag and
> exporting that instead.
That sounds like a very appropriate suggestion, thanks.
So something like this?
Then change every occurrence of
+ if (!(gfp_to_alloc_flags(gfpflags) & ALLOC_NO_WATERMARKS))
to
+ if (!(gfp_has_no_watermarks(gfpflags)))
??
Thanks,
NeilBrown
diff --git a/mm/internal.h b/mm/internal.h
index 22ec8d2..7ff78d6 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -195,6 +195,8 @@ static inline struct page *mem_map_next(struct page *iter,
#define __paginginit __init
#endif
+int gfp_has_no_watermarks(gfp_t gfp_mask);
+
/* Memory initialisation debug and verification */
enum mminit_level {
MMINIT_WARNING,
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index bf72055..4b4292a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1782,6 +1782,11 @@ gfp_to_alloc_flags(gfp_t gfp_mask)
return alloc_flags;
}
+int gfp_has_no_watermarks(gfp_t gfp_mask)
+{
+ return (gfp_to_alloc_flags(gfp_mask) & ALLOC_NO_WATERMARKS);
+}
+
static inline struct page *
__alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
struct zonelist *zonelist, enum zone_type high_zoneidx,
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* Re: [PATCH] Use sk_mark for routing lookup in more places
From: Eric Dumazet @ 2009-10-02 5:14 UTC (permalink / raw)
To: David Miller; +Cc: atis, panther, netdev
In-Reply-To: <20091001.151823.263194343.davem@davemloft.net>
Here is a followup on this area, thanks.
[RFC] af_packet: fill skb->mark at xmit
skb->mark may be used by classifiers, so fill it in case user
set a SO_MARK option on socket.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/packet/af_packet.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index d7ecca0..610f150 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -490,6 +490,7 @@ static int packet_sendmsg_spkt(struct kiocb *iocb, struct socket *sock,
skb->protocol = proto;
skb->dev = dev;
skb->priority = sk->sk_priority;
+ skb->mark = sk->sk_mark;
if (err)
goto out_free;
@@ -856,6 +857,7 @@ static int tpacket_fill_skb(struct packet_sock *po, struct sk_buff *skb,
skb->protocol = proto;
skb->dev = dev;
skb->priority = po->sk.sk_priority;
+ skb->mark = po->sk.sk_mark;
skb_shinfo(skb)->destructor_arg = ph.raw;
switch (po->tp_version) {
@@ -1125,6 +1127,7 @@ static int packet_snd(struct socket *sock,
skb->protocol = proto;
skb->dev = dev;
skb->priority = sk->sk_priority;
+ skb->mark = sk->sk_mark;
/*
* Now send it
^ permalink raw reply related
* Re: [PATCH 01/31] mm: serialize access to min_free_kbytes
From: Neil Brown @ 2009-10-02 5:20 UTC (permalink / raw)
To: David Rientjes
Cc: Suresh Jayaraman, Linus Torvalds, Andrew Morton, linux-kernel,
linux-mm, netdev, Miklos Szeredi, Wouter Verhelst, Peter Zijlstra,
trond.myklebust
In-Reply-To: <alpine.DEB.1.00.0910011330430.27559@chino.kir.corp.google.com>
On Thursday October 1, rientjes@google.com wrote:
> On Thu, 1 Oct 2009, Suresh Jayaraman wrote:
>
> > From: Peter Zijlstra <a.p.zijlstra@chello.nl>
> >
> > There is a small race between the procfs caller and the memory hotplug caller
> > of setup_per_zone_wmarks(). Not a big deal, but the next patch will add yet
> > another caller. Time to close the gap.
> >
>
> By "next patch," you mean "mm: emegency pool" (patch 08/31)?
:-) It is always safer to say "a subsequent patch", isn't it....
>
> If so, can't you eliminate var_free_mutex entirely from that patch and
> take min_free_lock in adjust_memalloc_reserve() instead?
adjust_memalloc_reserve does a test alloc/free cycle under a lock.
That cannot be done under a spin-lock, it must be a mutex.
So I don't think you can eliminate var_free_mutex.
Thanks,
NeilBrown
>
> [ __adjust_memalloc_reserve() would call __setup_per_zone_wmarks()
> under lock instead, now. ]
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 1/7] mlx4: Added interrupts test support
From: David Miller @ 2009-10-02 5:27 UTC (permalink / raw)
To: rdreier; +Cc: yevgenyp, netdev
In-Reply-To: <adaeipmqxmv.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Thu, 01 Oct 2009 20:32:08 -0700
> This feels like a pretty risky thing to do while the device might be
> handling all sorts of other traffic at the same time. Are you sure
> there are no races you expose here? Have you actually seen cases where
> the interrupt test during initialization works but then this test
> catches a problem? (My experience has been that if any MSI-X interrupts
> work from a device, then they'll all work)
I would suggest only allowing the test while the interface is down.
That way the test has exclusive control of the IRQ.
^ permalink raw reply
* Re: [PATCH 2/5] Implement loss counting on TFRC-SP receiver
From: Gerrit Renker @ 2009-10-01 20:40 UTC (permalink / raw)
To: Ivo Calado; +Cc: dccp, netdev
In-Reply-To: <cb00fa210909231843q7f13b2c3i32672e883a017b7b@mail.gmail.com>
| >> The following code would be correct then?
| >>
| >> if ((len <= 0) ||
| >> (!tfrc_lh_closed_check(cur, cong_evt->tfrchrx_ccval)))
| > {
| >> + cur->li_losses += rh->num_losses;
| >> + rh->num_losses = 0;
| >> return false;
| >> With this change I suppose the could be fixed. With that, the
| >> rh->num_losses couldn't added twice. Am I correct?
| >>
| >>
| > The function tfrc_lh_interval_add() is called when
| > * __two_after_loss() returns true (a new loss is detected) or
| > * a data packet is ECN-CE marked.
| >
| > I am still not sure about the 'len <= 0' case; this would be true
| > if an ECN-marked packet arrives whose sequence number is 'before'
| > the start of the current loss interval, or if a loss is detected
| > which is older than the start of the current loss interval.
| >
| > The other case (tfrc_lh_closed_check) returns 1 if the current loss
| > interval is 'closed' according to RFC 4342, 10.2.
| >
| > Intuitively, in the first case it refers to the preceding loss
| > interval (i.e. not cur->...), in the second case it seems correct.
| >
| > Doing the first case is complicated due to going back in history.
| > The simplest solution I can think of at the moment is to ignore
| > the exception-case of reordered packets and do something like
| >
| > if (len <= 0) {
| > /* FIXME: this belongs into the previous loss interval */
| > tfrc_pr_debug("Warning: ignoring loss due to reordering");
| > return false;
| > }
| > if (!tfrc_lh_closed_check(...)) {
| > // your code from above
| > }
|
| Okay, i'll add your sugestion. But i don't know how this would be fixed at all.
|
If it doesn't we will just do another iteration and fix it.
| > So it is necessary to decide whether to go the full way, which means
| > * support Loss Intervals and Dropped Packets alike
| > * modify TFRC library (it will be a redesign)
| > * modify receiver code
| > * modify sender code,
| > or to use the present approach where
| > * the receiver computes the Loss Rate and
| > * a Mandatory Send Loss Event Rate feature is present during feature
| > negotiation, to avoid problems with incompatible senders
| > (there is a comment explaining this, in net/dccp/feat.c).
| >
| > Thoughts?
|
<snip>
| I believe that the first way is better (to "support Loss Intervals and
| Dropped Packets alike..."), because RFC requires loss intervals option
| to be sent. And so, proceed and implement dropped packets option for
| TFRC-SP. You are right, this would need a redesign and rewrite of
| sender and receiver code.
|
Agree, then let's do that. It requires some coordination on how to arrange
the patches, but we can simplify the process by using the test tree to
store all intermediate results (i.e. use a separate tree for the rewrite
until it is sufficiently stable/useful).
^ 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