* Re: [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: Felipe Balbi @ 2012-07-16 10:14 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, wimax-BPSAo7wm5JOHVYUYWc+uSQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H,
linux-s390-u79uwXL29TY76Z2rM5mHXA, Johannes Berg,
uclinux-dist-devel-ZG0+EudsQA8dtHy/vicBwGD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-c6x-dev-jPsnJVOj+W6hPH1hqNUYSQ,
linux-mips-6z/3iImG2C8G8FEW9MqTrA,
user-mode-linux-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
user-mode-linux-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
e1000-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <cover.1342157022.git.joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3693 bytes --]
On Thu, Jul 12, 2012 at 10:33:04PM -0700, Joe Perches wrote:
> net-next commit ad7eee98be ("etherdevice: introduce eth_broadcast_addr")
> added a new style API. Rename random_ether_addr to eth_random_addr to
> create some API symmetry.
>
> Joe Perches (8):
> etherdevice: Rename random_ether_addr to eth_random_addr
if you're really renaming the function, then this patch alone will break
all of the below users. That should all be a single patch, I'm afraid.
> ethernet: Use eth_random_addr
> net: usb: Use eth_random_addr
> wireless: Use eth_random_addr
> drivers/net: Use eth_random_addr
> s390: Use eth_random_addr
> usb: Use eth_random_addr
> arch: Use eth_random_addr
>
> arch/blackfin/mach-bf537/boards/stamp.c | 2 +-
> arch/c6x/kernel/soc.c | 2 +-
> arch/mips/ar7/platform.c | 4 ++--
> arch/mips/powertv/powertv_setup.c | 6 +++---
> arch/um/drivers/net_kern.c | 2 +-
> drivers/net/ethernet/atheros/atl1c/atl1c_hw.c | 2 +-
> drivers/net/ethernet/atheros/atlx/atl1.c | 2 +-
> drivers/net/ethernet/atheros/atlx/atl2.c | 2 +-
> drivers/net/ethernet/ethoc.c | 2 +-
> drivers/net/ethernet/intel/igb/igb_main.c | 4 ++--
> drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 2 +-
> drivers/net/ethernet/lantiq_etop.c | 2 +-
> drivers/net/ethernet/micrel/ks8851.c | 2 +-
> drivers/net/ethernet/micrel/ks8851_mll.c | 2 +-
> drivers/net/ethernet/smsc/smsc911x.c | 2 +-
> drivers/net/ethernet/ti/cpsw.c | 2 +-
> drivers/net/ethernet/tile/tilegx.c | 2 +-
> drivers/net/ethernet/wiznet/w5100.c | 2 +-
> drivers/net/ethernet/wiznet/w5300.c | 2 +-
> drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2 +-
> drivers/net/tun.c | 2 +-
> drivers/net/usb/smsc75xx.c | 2 +-
> drivers/net/usb/smsc95xx.c | 2 +-
> drivers/net/usb/usbnet.c | 2 +-
> drivers/net/wimax/i2400m/driver.c | 2 +-
> drivers/net/wireless/adm8211.c | 2 +-
> drivers/net/wireless/p54/eeprom.c | 2 +-
> drivers/net/wireless/rt2x00/rt2400pci.c | 2 +-
> drivers/net/wireless/rt2x00/rt2500pci.c | 2 +-
> drivers/net/wireless/rt2x00/rt2500usb.c | 2 +-
> drivers/net/wireless/rt2x00/rt2800lib.c | 2 +-
> drivers/net/wireless/rt2x00/rt61pci.c | 2 +-
> drivers/net/wireless/rt2x00/rt73usb.c | 2 +-
> drivers/net/wireless/rtl818x/rtl8180/dev.c | 2 +-
> drivers/net/wireless/rtl818x/rtl8187/dev.c | 2 +-
> drivers/s390/net/qeth_l2_main.c | 2 +-
> drivers/s390/net/qeth_l3_main.c | 2 +-
> drivers/usb/atm/xusbatm.c | 4 ++--
> drivers/usb/gadget/u_ether.c | 2 +-
> include/linux/etherdevice.h | 14 ++++++++------
> 40 files changed, 52 insertions(+), 50 deletions(-)
>
> --
> 1.7.8.111.gad25c.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: iptables CLAMP MSS to PMTU not working?
From: Steffen Klassert @ 2012-07-16 10:08 UTC (permalink / raw)
To: Timo Teras; +Cc: David S. Miller, netdev
In-Reply-To: <20120716105546.14a6490d@vostro>
On Mon, Jul 16, 2012 at 10:55:46AM +0300, Timo Teras wrote:
> On Mon, 16 Jul 2012 09:23:05 +0200 Steffen Klassert
> <steffen.klassert@secunet.com> wrote:
> >
> > I did this patch to avoid to propagate learned PMTU informations.
> > It restores the behaviour we had before we moved the PMTU informations
> > to the inetpeer. Unfortunately CLAMPMSS really wants to have the PMTU
> > informations of an input route, which is not possible any more after
> > this patch.
> >
> > Anyway, this patch seems to be obsolete in the net-next tree, as
> > the cached pmtu informations are back in the route. So we should
> > remove the check for an output route from ipv4_mtu() in the net-next
> > tree. This should bring CLAMPMSS back to work, at least for upcoming
> > kernel versions.
>
> Right, saw those commits. But before net-next hits release, I'd really
> need a fix for 3.3/3.4/3.5. Non-working fragmentation with IPsec, and
> this CLAMPMSS thingy are an upgrade stopper for me.
>
> Would it be safe to just revert this commit, with the side-effect of
> exposing cached pmtu too agressively?
The router that can't send the packet to the next hop network has to
send the ICMP Destination Unreachable message. We never propagated
learned PMTU informations and I would not like to change this, in
particular not in a stable kernel.
Maybe we could fix this for already released kernels within the
netfilter module. Perhaps we could add a function
static unsigned int tcpmss_mtu(const struct dst_entry *dst)
{
unsigned int mtu = dst_metric_raw(dst, RTAX_MTU);
return mtu ? : dst_mtu(dst->path);
}
and use this instead of dst_mtu().
>
> Or would it be better to try to backport the relevant changes of moving
> pmtu back to route table?
A backport is probaply too invasive for a stable kernel.
^ permalink raw reply
* Re: [PATCH] lpc_eth: remove duplicated include
From: David Miller @ 2012-07-16 9:58 UTC (permalink / raw)
To: djduanjiong; +Cc: netdev
In-Reply-To: <5003E362.4060604@gmail.com>
Without a proper signoff, I will not apply your patch.
^ permalink raw reply
* Re: [PATCH] ipv6: fix incorrect route 'expires' value passed to userspace.
From: David Miller @ 2012-07-16 9:56 UTC (permalink / raw)
To: lw; +Cc: netdev, shemminger
In-Reply-To: <5003CC41.9080204@cn.fujitsu.com>
Without a proper signoff, I won't apply your patch.
^ permalink raw reply
* [PATCH] lpc_eth: remove duplicated include
From: Duan Jiong @ 2012-07-16 9:48 UTC (permalink / raw)
To: davem; +Cc: netdev
---
drivers/net/ethernet/nxp/lpc_eth.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index 083d671..a1fe179 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -44,7 +44,6 @@
#include <linux/of_net.h>
#include <linux/types.h>
-#include <linux/delay.h>
#include <linux/io.h>
#include <mach/board.h>
#include <mach/platform.h>
--
1.7.9.5
^ permalink raw reply related
* [PATCH] lpc_eth: remove duplicated include
From: Duan Jiong @ 2012-07-16 9:27 UTC (permalink / raw)
To: davem; +Cc: netdev
>From a63c538ff8ad0c53feec630744ebcc9b7eec67b4 Mon Sep 17 00:00:00 2001
From: Duan Jiong <djduanjiong@gmail.com>
Date: Mon, 16 Jul 2012 17:09:49 +0800
Subject: [PATCH] lpc_eth: remove duplicated include
---
drivers/net/ethernet/nxp/lpc_eth.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/nxp/lpc_eth.c b/drivers/net/ethernet/nxp/lpc_eth.c
index 083d671..a1fe179 100644
--- a/drivers/net/ethernet/nxp/lpc_eth.c
+++ b/drivers/net/ethernet/nxp/lpc_eth.c
@@ -44,7 +44,6 @@
#include <linux/of_net.h>
#include <linux/types.h>
-#include <linux/delay.h>
#include <linux/io.h>
#include <mach/board.h>
#include <mach/platform.h>
--
1.7.9.5
^ permalink raw reply related
* Re: New commands to configure IOV features
From: Yuval Mintz @ 2012-07-16 9:19 UTC (permalink / raw)
To: davem@davemloft.net
Cc: Chris Friesen, Ben Hutchings, Greg Rose, netdev@vger.kernel.org,
linux-pci
In-Reply-To: <4FFB4985.3040507@genband.com>
>>>> If I want to pick the RFCs and add support for configuring the number
>>>> of VFs - do you think ethtool's the right place for such added
>>>> support?
>>>>
>>> I think a PCI utility tool would be better, SR-IOV is not limited to
>>> network devices. That's one of the reasons I dropped the RFC. I
>>> haven't gotten back to the idea since then due to my day job keeping me
>>> pretty busy.
>>
>> For what it's worth, I agree with this.
>
> From my perspective it would be ideal if this could be exported via /sys or something
>
Well, obviously unless there was a sudden change in our stance regarding
sysfs we will not head that way.
This thread got no replies from the pci community, and I'm unfamiliar
with such a tool.
Dave, What's your stance in the matter - do you wish us to continue pursuing
some pci tool (which might or might not exist), or instead work on
a networking solution to this issue?
Do you happen to know such a tool?
Thanks,
Yuval
^ permalink raw reply
* RE: Is TCP vulneribility patch (as in RFC 5961) done in linux?
From: Eric Dumazet @ 2012-07-16 8:35 UTC (permalink / raw)
To: Kiran (Kiran Kumar) Kella; +Cc: netdev@vger.kernel.org
In-Reply-To: <1342427617.4812.0.camel@edumazet-glaptop>
On Mon, 2012-07-16 at 10:33 +0200, Eric Dumazet wrote:
> On Mon, 2012-07-16 at 07:06 +0000, Kiran (Kiran Kumar) Kella wrote:
> > Looking into the file tcp_input.c in the latest stable linux release 3.4.4 source, I understand the fix for this recommendation is not implemented in Linux.
> > Any reason why it was not addressed?
>
> Nobody cared ?
>
> Are you planning to send a patch ?
>
By the way, if the attacker replaces the RST bit by FIN bit, how
are we going to deal with the problem ?
Also many middleboxes will drop the challenge ACK...
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the infiniband tree
From: Jack Morgenstein @ 2012-07-16 8:34 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Hadar Hen Zion,
Or Gerlitz, Roland Dreier, linux-rdma
In-Reply-To: <20120712121307.a482863a98848e3813690ef2@canb.auug.org.au>
On Thursday 12 July 2012 05:13, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> include/linux/mlx4/device.h between commit 396f2feb05d7 ("mlx4_core:
> Implement mechanism for reserved Q_Keys") from the infiniband tree and
> commit 0ff1fb654bec ("{NET, IB}/mlx4: Add device managed flow steering
> firmware API") from the net-next tree.
>
> Just context changes. I fixed it up (see below) and can carry the fix
> as necessary.
Thanks, Stephen!
Your merge looks fine. Ack.
-Jack
^ permalink raw reply
* RE: Is TCP vulneribility patch (as in RFC 5961) done in linux?
From: Eric Dumazet @ 2012-07-16 8:33 UTC (permalink / raw)
To: Kiran (Kiran Kumar) Kella; +Cc: netdev@vger.kernel.org
In-Reply-To: <68700EDA775E5E47B5EBA9FF8AC0F15C077FF3@SJEXCHMB09.corp.ad.broadcom.com>
On Mon, 2012-07-16 at 07:06 +0000, Kiran (Kiran Kumar) Kella wrote:
> Looking into the file tcp_input.c in the latest stable linux release 3.4.4 source, I understand the fix for this recommendation is not implemented in Linux.
> Any reason why it was not addressed?
Nobody cared ?
Are you planning to send a patch ?
^ permalink raw reply
* Re: linux-next: manual merge of the net-next tree with the infiniband tree
From: Jack Morgenstein @ 2012-07-16 8:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev, linux-next, linux-kernel, Roland Dreier,
linux-rdma, Hadar Hen Zion, Or Gerlitz
In-Reply-To: <20120712120950.223be053857381046b7d5db6@canb.auug.org.au>
On Thursday 12 July 2012 05:09, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in
> drivers/net/ethernet/mellanox/mlx4/main.c between commit 6634961c14d3
> ("mlx4: Put physical GID and P_Key table sizes in mlx4_phys_caps struct
> and paravirtualize them") from the infiniband tree and commit
> 0ff1fb654bec ("{NET, IB}/mlx4: Add device managed flow steering firmware
> API") from the net-next tree.
>
> Just context changes (I think). I have fixed it up (see below) and can
> carry the fix as necessary.
Thanks, Stephen!
Ack for IB side.
-Jack
^ permalink raw reply
* [PATCH] ipv6: fix incorrect route 'expires' value passed to userspace.
From: Li Wei @ 2012-07-16 8:09 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Stephen Hemminger
When userspace use RTM_GETROUTE to dump route table, with a already
expired route entry, we always got an 'expires' value(2147157)
calculated base on INT_MAX.
The reason of this problem is in the following satement:
rt->dst.expires - jiffies < INT_MAX
gcc promoted the type of both sides of '<' to unsigned long, thus
a small negative value would be considered greater than INT_MAX.
This patch fix this by cast the result of subtraction to an 'int'
which I think is large enough for the expires.
Also we should do some fix in rtnl_put_cacheinfo() which use
jiffies_to_clock_t(which take an unsigned log as parameter) to
convert jiffies to clock_t to handle the negative expires.
---
net/core/rtnetlink.c | 3 ++-
net/ipv6/route.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 21318d1..f92f3d8 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -641,7 +641,8 @@ int rtnl_put_cacheinfo(struct sk_buff *skb, struct dst_entry *dst, u32 id,
};
if (expires)
- ci.rta_expires = jiffies_to_clock_t(expires);
+ ci.rta_expires = expires > 0 ? jiffies_to_clock_t(expires)
+ : -jiffies_to_clock_t(-expires);
return nla_put(skb, RTA_CACHEINFO, sizeof(ci), &ci);
}
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index becb048..a7fec9d 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -2516,7 +2516,7 @@ static int rt6_fill_node(struct net *net,
goto nla_put_failure;
if (!(rt->rt6i_flags & RTF_EXPIRES))
expires = 0;
- else if (rt->dst.expires - jiffies < INT_MAX)
+ else if ((int)(rt->dst.expires - jiffies) < INT_MAX)
expires = rt->dst.expires - jiffies;
else
expires = INT_MAX;
--
1.7.1
^ permalink raw reply related
* Re: iptables CLAMP MSS to PMTU not working?
From: Timo Teras @ 2012-07-16 7:55 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David S. Miller, netdev
In-Reply-To: <20120716072305.GJ1869@secunet.com>
On Mon, 16 Jul 2012 09:23:05 +0200 Steffen Klassert
<steffen.klassert@secunet.com> wrote:
> On Mon, Jul 16, 2012 at 09:20:58AM +0300, Timo Teras wrote:
> > On Mon, 16 Jul 2012 08:49:46 +0300 Timo Teras <timo.teras@iki.fi>
> > wrote:
> >
> > > Looking at the changelog, this would likely be side effect of:
> > >
> > > commit 261663b0ee2ee8e3947f4c11c1a08be18cd2cea1
> > > Author: Steffen Klassert <steffen.klassert@secunet.com>
> > > Date: Wed Nov 23 02:14:50 2011 +0000
> > >
> > > ipv4: Don't use the cached pmtu informations for input routes
> > >
> > > At least from performance side, it would be better if CLAMPMSS to
> > > PMTU would clamp to the learned, cached mtu.
> >
> > Actually, this is worse. Since XFRM is ignored - it breaks
> > fragmentation for IPsec targets.
> >
> > Could this be reverted?
>
> I did this patch to avoid to propagate learned PMTU informations.
> It restores the behaviour we had before we moved the PMTU informations
> to the inetpeer. Unfortunately CLAMPMSS really wants to have the PMTU
> informations of an input route, which is not possible any more after
> this patch.
>
> Anyway, this patch seems to be obsolete in the net-next tree, as
> the cached pmtu informations are back in the route. So we should
> remove the check for an output route from ipv4_mtu() in the net-next
> tree. This should bring CLAMPMSS back to work, at least for upcoming
> kernel versions.
Right, saw those commits. But before net-next hits release, I'd really
need a fix for 3.3/3.4/3.5. Non-working fragmentation with IPsec, and
this CLAMPMSS thingy are an upgrade stopper for me.
Would it be safe to just revert this commit, with the side-effect of
exposing cached pmtu too agressively?
Or would it be better to try to backport the relevant changes of moving
pmtu back to route table?
^ permalink raw reply
* Re: [PATCH 2/6] drivers/net/can/softing/softing_main.c: ensure a consistent return value in error case
From: Marc Kleine-Budde @ 2012-07-16 7:34 UTC (permalink / raw)
To: Julia Lawall
Cc: Wolfgang Grandegger, kernel-janitors, linux-can, netdev,
linux-kernel
In-Reply-To: <1342284188-19176-3-git-send-email-Julia.Lawall@lip6.fr>
[-- Attachment #1: Type: text/plain, Size: 2284 bytes --]
On 07/14/2012 06:43 PM, Julia Lawall wrote:
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Typically, the return value desired for the failure of a function with an
> integer return value is a negative integer. In these cases, the return
> value is sometimes a negative integer and sometimes 0, due to a subsequent
> initialization of the return variable within the loop.
>
> A simplified version of the semantic match that finds this problem is:
> (http://coccinelle.lip6.fr/)
>
> //<smpl>
> @r exists@
> identifier ret;
> position p;
> constant C;
> expression e1,e3,e4;
> statement S;
> @@
>
> ret = -C
> ... when != ret = e3
> when any
> if@p (...) S
> ... when any
> if (\(ret != 0\|ret < 0\|ret > 0\) || ...) { ... return ...; }
> ... when != ret = e3
> when any
> *if@p (...)
> {
> ... when != ret = e4
> return ret;
> }
> //</smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Thanks, applied to can-next
Marc
>
> ---
> drivers/net/can/softing/softing_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/softing/softing_main.c b/drivers/net/can/softing/softing_main.c
> index a7c77c7..f2a221e 100644
> --- a/drivers/net/can/softing/softing_main.c
> +++ b/drivers/net/can/softing/softing_main.c
> @@ -826,12 +826,12 @@ static __devinit int softing_pdev_probe(struct platform_device *pdev)
> goto sysfs_failed;
> }
>
> - ret = -ENOMEM;
> for (j = 0; j < ARRAY_SIZE(card->net); ++j) {
> card->net[j] = netdev =
> softing_netdev_create(card, card->id.chip[j]);
> if (!netdev) {
> dev_alert(&pdev->dev, "failed to make can[%i]", j);
> + ret = -ENOMEM;
> goto netdev_failed;
> }
> priv = netdev_priv(card->net[j]);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-can" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: iptables CLAMP MSS to PMTU not working?
From: Steffen Klassert @ 2012-07-16 7:23 UTC (permalink / raw)
To: Timo Teras; +Cc: David S. Miller, netdev
In-Reply-To: <20120716092058.270f6008@vostro>
On Mon, Jul 16, 2012 at 09:20:58AM +0300, Timo Teras wrote:
> On Mon, 16 Jul 2012 08:49:46 +0300 Timo Teras <timo.teras@iki.fi> wrote:
>
> > Looking at the changelog, this would likely be side effect of:
> >
> > commit 261663b0ee2ee8e3947f4c11c1a08be18cd2cea1
> > Author: Steffen Klassert <steffen.klassert@secunet.com>
> > Date: Wed Nov 23 02:14:50 2011 +0000
> >
> > ipv4: Don't use the cached pmtu informations for input routes
> >
> > At least from performance side, it would be better if CLAMPMSS to PMTU
> > would clamp to the learned, cached mtu.
>
> Actually, this is worse. Since XFRM is ignored - it breaks
> fragmentation for IPsec targets.
>
> Could this be reverted?
I did this patch to avoid to propagate learned PMTU informations.
It restores the behaviour we had before we moved the PMTU informations
to the inetpeer. Unfortunately CLAMPMSS really wants to have the PMTU
informations of an input route, which is not possible any more after
this patch.
Anyway, this patch seems to be obsolete in the net-next tree, as
the cached pmtu informations are back in the route. So we should remove
the check for an output route from ipv4_mtu() in the net-next tree.
This should bring CLAMPMSS back to work, at least for upcoming
kernel versions.
^ permalink raw reply
* RE: Is TCP vulneribility patch (as in RFC 5961) done in linux?
From: Kiran (Kiran Kumar) Kella @ 2012-07-16 7:06 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <68700EDA775E5E47B5EBA9FF8AC0F15C076B03@SJEXCHMB09.corp.ad.broadcom.com>
Looking into the file tcp_input.c in the latest stable linux release 3.4.4 source, I understand the fix for this recommendation is not implemented in Linux.
Any reason why it was not addressed?
Regards,
Kiran
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Kiran (Kiran Kumar) Kella
Sent: Friday, July 13, 2012 11:48 AM
To: netdev@vger.kernel.org
Subject: Is TCP vulneribility patch (as in RFC 5961) done in linux?
Hi,
I just now checked in the kernel archives if the patch in section 3.2 mentioned in RFC 5961 for RST attacks with predictable sequence numbers.
I see some discussion happened in 2004 timeframe.
I was just wondering if in the latest linux source, the patch is made available.
Appreciate your quick response in this regard.
Thanks,
Kiran
^ permalink raw reply
* Re: iptables CLAMP MSS to PMTU not working?
From: Timo Teras @ 2012-07-16 6:20 UTC (permalink / raw)
To: David S. Miller, Steffen Klassert; +Cc: netdev
In-Reply-To: <20120716084946.67b91a69@vostro>
On Mon, 16 Jul 2012 08:49:46 +0300 Timo Teras <timo.teras@iki.fi> wrote:
> On Thu, 12 Jul 2012 13:24:19 +0300 Timo Teras <timo.teras@iki.fi>
> wrote:
>
> > On Thu, 12 Jul 2012 12:00:21 +0300 Timo Teras <timo.teras@iki.fi>
> > wrote:
> >
> > > We recently noticed that CLAMPMSS to path MTU does not seem to be
> > > working properly. Most recently tested version is linux-3.3.6
> > > which does not work. linux-2.6.35 works for sure, but I suspect
> > > it to have broken somewhere around 3.0'ish with the inetpeer
> > > changes.
> > >
> > > In my case, the destination is on gre tunnel (that gets routed to
> > > Internet over IPsec transport mode).
> > >
> > > 'ip route' command verifies that in both boxes the path-MTU is
> > > detected properly. That, is on both cases the static route MTU is
> > > higher. And after large packets sent, ICMP frag-needed is received
> > > and the cache route is updated properly.
> > >
> > > On the new kernel, I get info like:
> > > # ip route get 10.x.x.x
> > > 10.x.x.x via 172.16.y.y dev gre1 src 172.16.z.z
> > > cache expires 68sec ipid 0x3153 mtu 1422
> >
> > CLAMP MSS sets MSS to 1432. Which implies MTU 1472. This matches the
> > gre1 interface MTU:
> >
> > 14: gre1: <UP,LOWER_UP> mtu 1472 qdisc noqueue state UNKNOWN
> >
> > So apparently CLAMPMSS is honoring the static route for gre1,
> > instead of the cached pmtu route.
> >
> > > And the older kernel:
> > > # ip route get 10.x.x.x
> > > 10.x.x.x via 172.16.y.y dev gre1 src 172.16.z.z
> > > cache expires 595sec ipid 0xd241 mtu 1422 advmss 1432
> > > hoplimit 64
> > >
> > > For some reason, iptables CLAMPMSS seems to set incorrect MSS for
> > > this route (or maybe it's using the static route instead?).
> >
> > And in this case MSS is set to 1382. That is, it's properly
> > calculated from the path MTU (1422-40=1382). I would expect the
> > advmss of the cached route to get updated on the TCP connects on
> > the older kernels (the above paste is after pinging with large
> > packets and no TCP connection done for the cached entry).
>
> Looking at the changelog, this would likely be side effect of:
>
> commit 261663b0ee2ee8e3947f4c11c1a08be18cd2cea1
> Author: Steffen Klassert <steffen.klassert@secunet.com>
> Date: Wed Nov 23 02:14:50 2011 +0000
>
> ipv4: Don't use the cached pmtu informations for input routes
>
> At least from performance side, it would be better if CLAMPMSS to PMTU
> would clamp to the learned, cached mtu.
Actually, this is worse. Since XFRM is ignored - it breaks
fragmentation for IPsec targets.
Could this be reverted?
^ permalink raw reply
* Re: 3.4.4/amd64 full interrupt hangs under big nfs copies
From: Eric Dumazet @ 2012-07-16 6:18 UTC (permalink / raw)
To: Marc MERLIN
Cc: David Miller, Larry.Finger, bhutchings, linux-wireless, netdev
In-Reply-To: <20120715215935.GF24420@merlins.org>
On Sun, 2012-07-15 at 14:59 -0700, Marc MERLIN wrote:
> On Tue, Apr 10, 2012 at 10:27:33PM -0700, Marc MERLIN wrote:
> > On Tue, Apr 10, 2012 at 08:11:03AM +0200, Eric Dumazet wrote:
> > > Please try following patch, as it solved the problem for me (no more
> > > order-1 allocations in tx path)
> >
> > I applied our patch to 3.3.1 and cannot reproduce the problem anymore.
> >
> > I'll leave a big wireless copy running overnight just in case, but I think
> > you fixed it.
>
> Mmmh, so I'm running 3.4.4 and I had another full machine hang while copying
> big files (gigabytes) over wireless via NFS.
> The laptop self recovered after 5mn or so (mouse cursor would not even
> move) and I was able to kill -9 the process (midnight commander).
> mc did not actually stop for another 4mn or so (i.e. it took that long for
> the process to come out of kernel hung state), but the machine was usable
> during that time.
> Note that copying the same data with scp works fine.
> NFS mount looks like this:
> gargamel:/mnt/dshelf2/ /net/gargamel/mnt/dshelf2 nfs4 rw,nosuid,nodev,relatime,vers=4.0,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.205.7,local_lock=none,addr=192.168.205.3 0 0
>
> I didn't have anything like last time in the kernel logs, and more
> annoyingly, ps -elf does not show anything for any process in WCHAN,
> making pointing the finger a bit harder (procps-ng 3.3.3 does not show
> anything other than '-' in WCHAN for any process with 3.4.4).
>
> My understanding is that user space calling drivers that shut off all
> interrupts for extended periods of time (as least I think so since my mouse
> cursor would not move), is still a kernel bug.
>
> For what it's worth, copying 1GB of data in lots of small files does not
> cause problems, it seems that it's big files that cause a problem since they
> likely fill a buffer somewhere while interrupts are disabled.
>
> Do you have an idea of how I can find out where my mc process is stuck in
> the kernel?
> Should I reproduce with specific sysrq output?
Just to clarify, you get this freeze when transferring a big file from a
remote NFS server to your PC, (aka a download), not the reverse way ?
If so, you might hit OOM condition because iwlwifi uses big/fat RX
buffers, I never understood why...
(amsdu_size_8K = 1)
Storing an MTU=1500 frams in 8KB of memory sounds really bad.
diff --git a/drivers/net/wireless/iwlwifi/iwl-drv.c b/drivers/net/wireless/iwlwifi/iwl-drv.c
index cc41cfa..434b924 100644
--- a/drivers/net/wireless/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/iwlwifi/iwl-drv.c
@@ -1006,7 +1006,7 @@ void iwl_drv_stop(struct iwl_drv *drv)
/* shared module parameters */
struct iwl_mod_params iwlwifi_mod_params = {
- .amsdu_size_8K = 1,
+ .amsdu_size_8K = 0,
.restart_fw = 1,
.plcp_check = true,
.bt_coex_active = true,
^ permalink raw reply related
* (unknown)
From: Tess Bradley @ 2012-07-16 6:14 UTC (permalink / raw)
Need urgent Loan? email me for more info.
^ permalink raw reply
* Re: [PATCH net-next] bonding: Support for multi function NIC devices
From: Anirban Chakraborty @ 2012-07-16 6:10 UTC (permalink / raw)
To: Jay Vosburgh
Cc: John Fastabend, David Miller, netdev, Dept-NX Linux NIC Driver
In-Reply-To: <22437.1342417803@death.nxdomain>
On 7/15/12 10:50 PM, "Jay Vosburgh" <fubar@us.ibm.com> wrote:
>Anirban Chakraborty <anirban.chakraborty@qlogic.com> wrote:
>>On 7/15/12 9:39 PM, "John Fastabend" <john.r.fastabend@intel.com> wrote:
>[...]
>>>Also I'm not sure we need to explicitly block this. It is clear from
>>>looking at 'ip' output what the topology is. And in the SR-IOV
>>>case would this still work if the functions are direct assigned? How
>>>about if I try to bond two stacked devices that are on the same
>>>physical link. In both case iirc the bus info wont match up.
>>>
>>>Seems easier to just call this a configuration error or not if for
>>>some reason this is really what someone intended.
>>>
>>>.John
>>
>>I agree that for SR-IOV case with VFs assigned directly to the guest, bus
>>info won't
>>match up. However, I was thinking from the point of view of NIC
>>partitioned mode (NPAR),
>>and for the use case of SR-IOV VFs assigned to the hypervisor. It would
>>be
>>nice to
>>prevent the user from getting into misconfiguration.
>
> If I'm understanding correctly, to hit the case you're worried
>about here would require assigning multiple VFs from one PF to the same
>linux instance as the PF itself, and then bonding those VFs together.
>
> Heck, there might be some arcane reason that somebody wants to
>do that on purpose, or the test may inadvertently prohibit legal
>configurations that happen to match the criteria.
>
> Has this been a real problem in practice? I'm not seeing a
>compelling argument for doing this.
>
> -J
The real problem that we have faced so far is the case of NPAR, where
multiple
physical functions are assigned to the linux host and the customer tried
to create
a bond of interfaces from the same physical port. In this case, linux host
was running
without any guest OS and the NICs are used for carrying host traffic only.
-Anirban
^ permalink raw reply
* Re: [PATCH net-next] bonding: Support for multi function NIC devices
From: Jay Vosburgh @ 2012-07-16 5:50 UTC (permalink / raw)
To: Anirban Chakraborty
Cc: John Fastabend, David Miller, netdev, Dept-NX Linux NIC Driver
In-Reply-To: <CC28EE8B.36B53%anirban.chakraborty@qlogic.com>
Anirban Chakraborty <anirban.chakraborty@qlogic.com> wrote:
>On 7/15/12 9:39 PM, "John Fastabend" <john.r.fastabend@intel.com> wrote:
[...]
>>Also I'm not sure we need to explicitly block this. It is clear from
>>looking at 'ip' output what the topology is. And in the SR-IOV
>>case would this still work if the functions are direct assigned? How
>>about if I try to bond two stacked devices that are on the same
>>physical link. In both case iirc the bus info wont match up.
>>
>>Seems easier to just call this a configuration error or not if for
>>some reason this is really what someone intended.
>>
>>.John
>
>I agree that for SR-IOV case with VFs assigned directly to the guest, bus
>info won't
>match up. However, I was thinking from the point of view of NIC
>partitioned mode (NPAR),
>and for the use case of SR-IOV VFs assigned to the hypervisor. It would be
>nice to
>prevent the user from getting into misconfiguration.
If I'm understanding correctly, to hit the case you're worried
about here would require assigning multiple VFs from one PF to the same
linux instance as the PF itself, and then bonding those VFs together.
Heck, there might be some arcane reason that somebody wants to
do that on purpose, or the test may inadvertently prohibit legal
configurations that happen to match the criteria.
Has this been a real problem in practice? I'm not seeing a
compelling argument for doing this.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: iptables CLAMP MSS to PMTU not working?
From: Timo Teras @ 2012-07-16 5:49 UTC (permalink / raw)
To: Steffen Klassert; +Cc: netdev
In-Reply-To: <20120712132419.50b4acaf@vostro>
On Thu, 12 Jul 2012 13:24:19 +0300 Timo Teras <timo.teras@iki.fi> wrote:
> On Thu, 12 Jul 2012 12:00:21 +0300 Timo Teras <timo.teras@iki.fi>
> wrote:
>
> > We recently noticed that CLAMPMSS to path MTU does not seem to be
> > working properly. Most recently tested version is linux-3.3.6 which
> > does not work. linux-2.6.35 works for sure, but I suspect it to have
> > broken somewhere around 3.0'ish with the inetpeer changes.
> >
> > In my case, the destination is on gre tunnel (that gets routed to
> > Internet over IPsec transport mode).
> >
> > 'ip route' command verifies that in both boxes the path-MTU is
> > detected properly. That, is on both cases the static route MTU is
> > higher. And after large packets sent, ICMP frag-needed is received
> > and the cache route is updated properly.
> >
> > On the new kernel, I get info like:
> > # ip route get 10.x.x.x
> > 10.x.x.x via 172.16.y.y dev gre1 src 172.16.z.z
> > cache expires 68sec ipid 0x3153 mtu 1422
>
> CLAMP MSS sets MSS to 1432. Which implies MTU 1472. This matches the
> gre1 interface MTU:
>
> 14: gre1: <UP,LOWER_UP> mtu 1472 qdisc noqueue state UNKNOWN
>
> So apparently CLAMPMSS is honoring the static route for gre1, instead
> of the cached pmtu route.
>
> > And the older kernel:
> > # ip route get 10.x.x.x
> > 10.x.x.x via 172.16.y.y dev gre1 src 172.16.z.z
> > cache expires 595sec ipid 0xd241 mtu 1422 advmss 1432 hoplimit
> > 64
> >
> > For some reason, iptables CLAMPMSS seems to set incorrect MSS for
> > this route (or maybe it's using the static route instead?).
>
> And in this case MSS is set to 1382. That is, it's properly calculated
> from the path MTU (1422-40=1382). I would expect the advmss of the
> cached route to get updated on the TCP connects on the older kernels
> (the above paste is after pinging with large packets and no TCP
> connection done for the cached entry).
Looking at the changelog, this would likely be side effect of:
commit 261663b0ee2ee8e3947f4c11c1a08be18cd2cea1
Author: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed Nov 23 02:14:50 2011 +0000
ipv4: Don't use the cached pmtu informations for input routes
At least from performance side, it would be better if CLAMPMSS to PMTU
would clamp to the learned, cached mtu.
^ permalink raw reply
* Re: [PATCH net-next] bonding: Support for multi function NIC devices
From: Anirban Chakraborty @ 2012-07-16 5:12 UTC (permalink / raw)
To: John Fastabend, Jay Vosburgh
Cc: David Miller, netdev, Dept-NX Linux NIC Driver
In-Reply-To: <50039B11.1010006@intel.com>
On 7/15/12 9:39 PM, "John Fastabend" <john.r.fastabend@intel.com> wrote:
>On 7/15/2012 6:40 PM, Jay Vosburgh wrote:
>> Anirban Chakraborty <anirban.chakraborty@qlogic.com> wrote:
>>
>>> From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
>>>
>>> Add support to disable bonding of interfaces belonging to the same
>>>physical port. In
>>> case of SRIOV or NIC partition mode, a single port of the adapter can
>>>have multiple
>>> NIC functions. While bonding such interfaces, it is ensured that the
>>>NIC functions
>>> belonging to the same physical port are not bonded together.
>>>
>>> Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
>>> ---
>>> Documentation/networking/ifenslave.c | 208
>>>+++++++++++++++++++++++++++++++++-
>>> 1 files changed, 207 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/Documentation/networking/ifenslave.c
>>>b/Documentation/networking/ifenslave.c
>>> index ac5debb..a0bdab9 100644
>>> --- a/Documentation/networking/ifenslave.c
>>> +++ b/Documentation/networking/ifenslave.c
>>> @@ -92,9 +92,14 @@
>>> * - 2003/12/01 - Shmulik Hen <shmulik.hen at intel dot com>
>>> * - Code cleanup and style changes
>>> * set version to 1.1.0
>>> + *
>>> + * - 2012/07/15 - Anirban Chakraborty <anirban.chakraborty at
>>>qlogic dot com>
>>> + * - Added support to disable bonding interfaces belonging to the
>>> + * same physical port.
>>> + * set version to 1.1.1
>>
>> This patch is all implemented within the ifenslave user space
>> program, which, to my knowledge, is not currently used by any major
>> distro to configure bonding.
>>
>> The configuration for bonding is typically performed by packages
>> such as initscripts or sysconfig, and this functionality would likely
>> need to go there.
>>
>> The only real use for ifenslave.c is on kernels without sysfs
>> compiled in.
>>
>> -J
>>
>
>Also I'm not sure we need to explicitly block this. It is clear from
>looking at 'ip' output what the topology is. And in the SR-IOV
>case would this still work if the functions are direct assigned? How
>about if I try to bond two stacked devices that are on the same
>physical link. In both case iirc the bus info wont match up.
>
>Seems easier to just call this a configuration error or not if for
>some reason this is really what someone intended.
>
>.John
I agree that for SR-IOV case with VFs assigned directly to the guest, bus
info won't
match up. However, I was thinking from the point of view of NIC
partitioned mode (NPAR),
and for the use case of SR-IOV VFs assigned to the hypervisor. It would be
nice to
prevent the user from getting into misconfiguration.
-Anirban
^ permalink raw reply
* Re: [PATCH net-next] bonding: Support for multi function NIC devices
From: John Fastabend @ 2012-07-16 4:39 UTC (permalink / raw)
To: Jay Vosburgh, Anirban Chakraborty; +Cc: davem, netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <20657.1342402819@death.nxdomain>
On 7/15/2012 6:40 PM, Jay Vosburgh wrote:
> Anirban Chakraborty <anirban.chakraborty@qlogic.com> wrote:
>
>> From: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
>>
>> Add support to disable bonding of interfaces belonging to the same physical port. In
>> case of SRIOV or NIC partition mode, a single port of the adapter can have multiple
>> NIC functions. While bonding such interfaces, it is ensured that the NIC functions
>> belonging to the same physical port are not bonded together.
>>
>> Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
>> ---
>> Documentation/networking/ifenslave.c | 208 +++++++++++++++++++++++++++++++++-
>> 1 files changed, 207 insertions(+), 1 deletions(-)
>>
>> diff --git a/Documentation/networking/ifenslave.c b/Documentation/networking/ifenslave.c
>> index ac5debb..a0bdab9 100644
>> --- a/Documentation/networking/ifenslave.c
>> +++ b/Documentation/networking/ifenslave.c
>> @@ -92,9 +92,14 @@
>> * - 2003/12/01 - Shmulik Hen <shmulik.hen at intel dot com>
>> * - Code cleanup and style changes
>> * set version to 1.1.0
>> + *
>> + * - 2012/07/15 - Anirban Chakraborty <anirban.chakraborty at qlogic dot com>
>> + * - Added support to disable bonding interfaces belonging to the
>> + * same physical port.
>> + * set version to 1.1.1
>
> This patch is all implemented within the ifenslave user space
> program, which, to my knowledge, is not currently used by any major
> distro to configure bonding.
>
> The configuration for bonding is typically performed by packages
> such as initscripts or sysconfig, and this functionality would likely
> need to go there.
>
> The only real use for ifenslave.c is on kernels without sysfs
> compiled in.
>
> -J
>
Also I'm not sure we need to explicitly block this. It is clear from
looking at 'ip' output what the topology is. And in the SR-IOV
case would this still work if the functions are direct assigned? How
about if I try to bond two stacked devices that are on the same
physical link. In both case iirc the bus info wont match up.
Seems easier to just call this a configuration error or not if for
some reason this is really what someone intended.
.John
^ permalink raw reply
* Re: [PATCH net] caif: Fix access to freed pernet memory
From: Eric W. Biederman @ 2012-07-16 1:43 UTC (permalink / raw)
To: sjur.brandeland; +Cc: davem, netdev, sjurbren, Dmitry Tarnyagin
In-Reply-To: <1342383014-5525-1-git-send-email-sjur.brandeland@stericsson.com>
sjur.brandeland@stericsson.com writes:
> From: Sjur Brændeland <sjur.brandeland@stericsson.com>
>
> unregister_netdevice_notifier() must be called before
> unregister_pernet_subsys() to avoid accessing already freed
> pernet memory. This fixes the following oops when doing rmmod:
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
The patch looks good to me.
You might want to look at error handling during caif_device_init
as well, as it looks like the same ordering issue is present.
Although unlikely to bite anyone at that point.
Eric
>
> Call Trace:
> [<ffffffffa0f802bd>] caif_device_notify+0x4d/0x5a0 [caif]
> [<ffffffff81552ba9>] unregister_netdevice_notifier+0xb9/0x100
> [<ffffffffa0f86dcc>] caif_device_exit+0x1c/0x250 [caif]
> [<ffffffff810e7734>] sys_delete_module+0x1a4/0x300
> [<ffffffff810da82d>] ? trace_hardirqs_on_caller+0x15d/0x1e0
> [<ffffffff813517de>] ? trace_hardirqs_on_thunk+0x3a/0x3
> [<ffffffff81696bad>] system_call_fastpath+0x1a/0x1f
>
> RIP
> [<ffffffffa0f7f561>] caif_get+0x51/0xb0 [caif]
>
> Signed-off-by: Sjur Brændeland <sjur.brandeland@stericsson.com>
> ---
>
> Hi Dave,
>
> Can you please queue up this bugfix as appropriate for -net and -stable?
>
> I guess this bug has been around since introduction of network
> name spaces in CAIF, but it became visible after 3.4 and the commit:
> "net: In unregister_netdevice_notifier unregister the netdevices."
>
> Thanks,
> Sjur
>
> net/caif/caif_dev.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/caif/caif_dev.c b/net/caif/caif_dev.c
> index 554b312..8c83c17 100644
> --- a/net/caif/caif_dev.c
> +++ b/net/caif/caif_dev.c
> @@ -561,9 +561,9 @@ static int __init caif_device_init(void)
>
> static void __exit caif_device_exit(void)
> {
> - unregister_pernet_subsys(&caif_net_ops);
> unregister_netdevice_notifier(&caif_device_notifier);
> dev_remove_pack(&caif_packet_type);
> + unregister_pernet_subsys(&caif_net_ops);
> }
>
> module_init(caif_device_init);
^ 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