* 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
* 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: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: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: 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
* [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
* [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
* 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
* 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: 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 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: [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: David Miller @ 2012-07-16 10:29 UTC (permalink / raw)
To: balbi
Cc: linux-s390, linux-c6x-dev, wimax, linux-mips,
user-mode-linux-user, netdev, linux-usb, linux-wireless, users,
linux-kernel, e1000-devel, user-mode-linux-devel, joe,
uclinux-dist-devel, johannes
In-Reply-To: <20120716101437.GC22638@arwen.pp.htv.fi>
From: Felipe Balbi <balbi@ti.com>
Date: Mon, 16 Jul 2012 13:14:38 +0300
> 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.
It would help if you actually read his patches before saying what they
might or might not do.
He provides a macro in the first patch that provides the old name,
and this will get removed at the end.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: iptables CLAMP MSS to PMTU not working?
From: Timo Teras @ 2012-07-16 10:53 UTC (permalink / raw)
To: Steffen Klassert; +Cc: David S. Miller, netdev
In-Reply-To: <20120716100844.GK1869@secunet.com>
On Mon, 16 Jul 2012 12:08:44 +0200 Steffen Klassert
<steffen.klassert@secunet.com> wrote:
> 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.
Ah, now I understand what you mean with "propagation". Leaking out the
PMTU of locally originating traffic to the forward path.
Makes sense. I'll probably just revert the change locally, as for my
use this should not be a problem.
> 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().
Yes, of course this fixes TCPMSS; but not IPsec fragmentation which is
even more critical.
On forward path, if I send large IP-packets (e.g. ping -s 1500) with
DF-bit not set to a destination that is XFRMed, I get now blackholed.
This is because the large packet is fragmented according to the forward
route MTU which now does not account the XFRM headers and the fragments
are too large to be sent out. This causes the packets to get dropped
to floor; and since DF was not set, there's no ICMP error sent out.
With fragmentation the originator is not and does not want to be aware
of the PMTU.
Basically the MTU needs to be accurate for fragmentation to work.
Just using the "device MTU" or "route MTU" is not enough. This is
because XFRMed target MTU is currently learned dynamically. The
per-packet overhead can depend on destination IP (e.g. per-IP SA can
have different hash or encapsulation which affects the header size and
thus the overall MTU).
I guess it would be better if the XFRMed MTUs were calculated properly.
This would avoid one lost packet -- the one that gets sent out using
the device/route MTU, then triggers route pmtu to get updated, and
dropped. Then further packets get fragmented according to the cached
pmtu properly. Would be nice if this "learning" packet was not needed.
^ permalink raw reply
* MY ASSISTANCE TO PAY YOUR ACCRUED INTEREST AMOUNT. PLEASE OPEN THE FILE FOR MORE DETAILS
From: MR. CHRIS @ 2012-07-16 10:36 UTC (permalink / raw)
To: Recipients
[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: FROM MR. CHRIS.rtf --]
[-- Type: application/octet-stream, Size: 5642 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: Felipe Balbi @ 2012-07-16 11:12 UTC (permalink / raw)
To: David Miller
Cc: balbi, joe, netdev, linux-usb, wimax, linux-wireless, users,
linux-s390, johannes, uclinux-dist-devel, linux-kernel,
linux-c6x-dev, linux-mips, user-mode-linux-devel,
user-mode-linux-user, e1000-devel
In-Reply-To: <20120716.032901.1657058688119342783.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 788 bytes --]
Hi,
On Mon, Jul 16, 2012 at 03:29:01AM -0700, David Miller wrote:
> From: Felipe Balbi <balbi@ti.com>
> Date: Mon, 16 Jul 2012 13:14:38 +0300
>
> > 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.
>
> It would help if you actually read his patches before saying what they
> might or might not do.
>
> He provides a macro in the first patch that provides the old name,
> and this will get removed at the end.
that's why I put an "if" there. The subject was misleading and I really
couldn't bother going search for the patch on the mail archives.
Anyway, if nothing will be broken then for drivers/usb/gadget/:
Acked-by: Felipe Balbi <balbi@ti.com>
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] net: respect GFP_DMA in __netdev_alloc_skb()
From: Eric Dumazet @ 2012-07-16 11:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Few drivers use GFP_DMA allocations, and netdev_alloc_frag()
doesn't allocate pages in DMA zone.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/skbuff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 46a3d23..d124306 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -353,7 +353,7 @@ struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
unsigned int fragsz = SKB_DATA_ALIGN(length + NET_SKB_PAD) +
SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
- if (fragsz <= PAGE_SIZE && !(gfp_mask & __GFP_WAIT)) {
+ if (fragsz <= PAGE_SIZE && !(gfp_mask & (__GFP_WAIT | GFP_DMA))) {
void *data = netdev_alloc_frag(fragsz);
if (likely(data)) {
^ permalink raw reply related
* Re: [PATCH net-next 0/8] etherdevice: Rename random_ether_addr to eth_random_addr
From: David Miller @ 2012-07-16 11:17 UTC (permalink / raw)
To: balbi-l0cyMroinI0
Cc: joe-6d6DIl74uiNBDgjK7y7TUQ, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, wimax-BPSAo7wm5JOHVYUYWc+uSQ,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
users-poMEt7QlJxcwIE2E9O76wjtx2kNaKg5H,
linux-s390-u79uwXL29TY76Z2rM5mHXA,
johannes-cdvu00un1VgdHxzADdlk8Q,
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: <20120716111218.GA4913-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
From: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
Date: Mon, 16 Jul 2012 14:12:19 +0300
> Acked-by: Felipe Balbi <balbi-l0cyMroinI0@public.gmane.org>
You need to provide this in a reply to the patch you actually want
to ACK, so that the patch tracking system attaches your ACK to
the proper patch.
Thank you.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] net: respect GFP_DMA in __netdev_alloc_skb()
From: David Miller @ 2012-07-16 11:18 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1342437352.23494.8.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 16 Jul 2012 13:15:52 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Few drivers use GFP_DMA allocations, and netdev_alloc_frag()
> doesn't allocate pages in DMA zone.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: resurrecting tcphealth
From: Piotr Sawuk @ 2012-07-16 11:33 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
In-Reply-To: <20120713165544.6767ea8f@nehalam.linuxnetplumber.net>
On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
> I am not sure if the is really necessary since the most
> of the stats are available elsewhere.
if by "most" you mean address and port then you're right.
but even the rtt reported by "ss -i" seems to differ from tcphealth.
however, if instead by "elsewhere" you mean "on the server"...
>
>>+ seq_printf(seq,
>>+ "TCP Health Monitoring (established connections only)\n"
>>+ " -Duplicate ACKs indicate lost or reordered packets on the
>>connection.\n"
>>+ " -Duplicate Packets Received signal a slow and badly inefficient
>>connection.\n"
>>+ " -RttEst estimates how long future packets will take on a round trip
>>over the connection.\n"
>>+ "id Local Address Remote Address RttEst(ms) AcksSent "
>
> Header seems excessive, just put one line of header please.
I guess the header was sort of documentation for this patch.
I've put it into Kconfig instead.
>
>
>>+ "DupAcksSent PktsRecv DupPktsRecv\n");
>>+ goto out;
>>+ }
>>+
>>+ /* Loop through established TCP connections */
>>+ st = seq->private;
>>+
>>+
>>+ if (st->state == TCP_SEQ_STATE_ESTABLISHED)
>>+ {
>>+/* ; //insert read-lock here */
>
> Don't think you need read-lock
you mean I wont get segfault reading a tcp_sock that's gone?
>
> Kernel has %pI4 to print IP addresses.
thanks, I didn't know.
>
>>+ seq_printf(seq, "%*s\n", LINESZ - 1 - len, "");
>
> This padding of line is bogus, just print variable length line.
> Are you trying to make it fixed length record file?
I guess so, /proc/net/tcp is doing the same.
wont question the authors of that user-interface.
OK, new version, this time with Kconfig changed:
diff -rub A/include/linux/tcp.h B/include/linux/tcp.h
--- A/include/linux/tcp.h 2012-07-08 02:23:56.000000000 +0200
+++ B/include/linux/tcp.h 2012-07-16 09:04:54.000000000 +0200
@@ -492,6 +492,17 @@
* contains related tcp_cookie_transactions fields.
*/
struct tcp_cookie_values *cookie_values;
+
+#ifdef CONFIG_TCPHEALTH
+ /*
+ * TCP health monitoring counters.
+ */
+ __u32 dup_acks_sent;
+ __u32 dup_pkts_recv;
+ __u32 acks_sent;
+ __u32 pkts_recv;
+ __u32 last_ack_sent; /* Sequence number of the last ack we sent. */
+#endif
};
static inline struct tcp_sock *tcp_sk(const struct sock *sk)
Only in B/include/linux: tcp.h.orig
diff -rub A/net/ipv4/Kconfig B/net/ipv4/Kconfig
--- A/net/ipv4/Kconfig 2012-07-08 02:23:56.000000000 +0200
+++ B/net/ipv4/Kconfig 2012-07-16 11:56:15.000000000 +0200
@@ -619,6 +619,28 @@
default "reno" if DEFAULT_RENO
default "cubic"
+config TCPHEALTH
+ bool "TCP: client-side health-statistics (/proc/net/tcphealth)"
+ default n
+ ---help---
+ IPv4 TCP Health Monitoring (established connections only):
+ -Duplicate ACKs indicate there could be lost or reordered packets
+ on the connection.
+ -Duplicate Packets Received signal a slow and badly inefficient
+ connection.
+ -RttEst estimates how long future packets will take on a round trip
+ over the connection.
+
+ Additionally you get total amount of sent ACKs and received Packets.
+ All these values are displayed seperately for each connection.
+ If you are running a dedicated server you wont need this.
+ Duplicate ACKs refers only to those sent upon receiving a Packet.
+ A server most likely doesn't receive much Packets to count.
+ Hence for a server these statistics wont be meaningful.
+ especially since they are split into individual connections.
+
+ If you plan to investigate why some download is slow, say Y.
+
config TCP_MD5SIG
bool "TCP: MD5 Signature Option support (RFC2385) (EXPERIMENTAL)"
depends on EXPERIMENTAL
Only in B/net/ipv4: Kconfig~
diff -rub A/net/ipv4/tcp_input.c B/net/ipv4/tcp_input.c
--- A/net/ipv4/tcp_input.c 2012-07-08 02:23:56.000000000 +0200
+++ B/net/ipv4/tcp_input.c 2012-07-16 09:28:23.000000000 +0200
@@ -4492,6 +4492,11 @@
}
if (!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt)) {
+#ifdef CONFIG_TCPHEALTH
+ /* Course Timeout caused retransmit inefficiency-
+ * this packet has been received twice. */
+ tp->dup_pkts_recv++;
+#endif
SOCK_DEBUG(sk, "ofo packet was already received\n");
__skb_unlink(skb, &tp->out_of_order_queue);
__kfree_skb(skb);
@@ -4824,6 +4829,12 @@
return;
}
+#ifdef CONFIG_TCPHEALTH
+ /* A packet is a "duplicate" if it contains bytes we have already
received. */
+ if (before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt))
+ tp->dup_pkts_recv++;
+#endif
+
if (!after(TCP_SKB_CB(skb)->end_seq, tp->rcv_nxt)) {
/* A retransmit, 2nd most common case. Force an immediate ack. */
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_DELAYEDACKLOST);
@@ -5535,6 +5546,12 @@
tp->rx_opt.saw_tstamp = 0;
+#ifdef CONFIG_TCPHEALTH
+ /*
+ * total per-connection packet arrivals.
+ */
+ tp->pkts_recv++;
+#endif
/* pred_flags is 0xS?10 << 16 + snd_wnd
* if header_prediction is to be made
* 'S' will always be tp->tcp_header_len >> 2
diff -rub A/net/ipv4/tcp_ipv4.c B/net/ipv4/tcp_ipv4.c
--- A/net/ipv4/tcp_ipv4.c 2012-07-08 02:23:56.000000000 +0200
+++ B/net/ipv4/tcp_ipv4.c 2012-07-16 10:12:48.000000000 +0200
@@ -2500,6 +2500,57 @@
return 0;
}
+#ifdef CONFIG_TCPHEALTH
+/*
+ * Output /proc/net/tcphealth
+ */
+#define LINESZ 128
+
+int tcp_health_seq_show(struct seq_file *seq, void *v)
+{
+ int len, num;
+ struct tcp_iter_state *st;
+
+ if (v == SEQ_START_TOKEN) {
+ seq_printf(seq,
+ "id Local Address Remote Address RttEst(ms) AcksSent "
+ "DupAcksSent PktsRecv DupPktsRecv\n");
+ goto out;
+ }
+
+ /* Loop through established TCP connections */
+ st = seq->private;
+
+
+ if (st->state == TCP_SEQ_STATE_ESTABLISHED)
+ {
+ const struct tcp_sock *tp = tcp_sk(v);
+ const struct inet_sock *inet = inet_sk(v);
+
+ seq_printf(seq, "%d: %-21pI4:%u %-21pI4:%u "
+ "%8lu %8lu %8lu %8lu %8lu%n",
+ st->num,
+ inet->inet_rcv_saddr,
+ ntohs(inet->inet_sport),
+ inet->inet_daddr,
+ ntohs(inet->inet_dport),
+ tp->srtt >> 3,
+ tp->acks_sent,
+ tp->dup_acks_sent,
+ tp->pkts_recv,
+ tp->dup_pkts_recv,
+
+ &len
+ );
+
+ seq_printf(seq, "%*s\n", LINESZ - 1 - len, "");
+ }
+
+out:
+ return 0;
+}
+#endif /* CONFIG_TCPHEALTH */
+
static const struct file_operations tcp_afinfo_seq_fops = {
.owner = THIS_MODULE,
.open = tcp_seq_open,
@@ -2508,6 +2559,17 @@
.release = seq_release_net
};
+#ifdef CONFIG_TCPHEALTH
+static struct tcp_seq_afinfo tcphealth_seq_afinfo = {
+ .name = "tcphealth",
+ .family = AF_INET,
+ .seq_fops = &tcp_afinfo_seq_fops,
+ .seq_ops = {
+ .show = tcp_health_seq_show,
+ },
+};
+#endif
+
static struct tcp_seq_afinfo tcp4_seq_afinfo = {
.name = "tcp",
.family = AF_INET,
@@ -2519,12 +2581,20 @@
static int __net_init tcp4_proc_init_net(struct net *net)
{
- return tcp_proc_register(net, &tcp4_seq_afinfo);
+ int ret = tcp_proc_register(net, &tcp4_seq_afinfo);
+#ifdef CONFIG_TCPHEALTH
+ if(ret == 0)
+ ret = tcp_proc_register(net, &tcphealth_seq_afinfo);
+#endif
+ return ret;
}
static void __net_exit tcp4_proc_exit_net(struct net *net)
{
tcp_proc_unregister(net, &tcp4_seq_afinfo);
+#ifdef CONFIG_TCPHEALTH
+ tcp_proc_unregister(net, &tcphealth_seq_afinfo);
+#endif
}
static struct pernet_operations tcp4_net_ops = {
Only in B/net/ipv4: tcp_ipv4.c~
Only in B/net/ipv4: tcp_ipv4.c.orig
diff -rub A/net/ipv4/tcp_output.c B/net/ipv4/tcp_output.c
--- A/net/ipv4/tcp_output.c 2012-07-08 02:23:56.000000000 +0200
+++ B/net/ipv4/tcp_output.c 2012-07-16 09:44:02.000000000 +0200
@@ -2772,8 +2772,19 @@
skb_reserve(buff, MAX_TCP_HEADER);
tcp_init_nondata_skb(buff, tcp_acceptable_seq(sk), TCPHDR_ACK);
+#ifdef CONFIG_TCPHEALTH
+ /* If the rcv_nxt has not advanced since sending our last ACK, this is a
duplicate. */
+ if (tcp_sk(sk)->rcv_nxt == tcp_sk(sk)->last_ack_sent)
+ tcp_sk(sk)->dup_acks_sent++;
+ /* Record the total number of acks sent on this connection. */
+ tcp_sk(sk)->acks_sent++;
+#endif
+
/* Send it off, this clears delayed acks for us. */
TCP_SKB_CB(buff)->when = tcp_time_stamp;
+#ifdef CONFIG_TCPHEALTH
+ tcp_sk(sk)->last_ack_sent = tcp_sk(sk)->rcv_nxt;
+#endif
tcp_transmit_skb(sk, buff, 0, GFP_ATOMIC);
}
^ permalink raw reply
* [PATCH net-next] tcp: add OFO snmp counters
From: Eric Dumazet @ 2012-07-16 11:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
Add three SNMP TCP counters, to better track TCP behavior
at global stage (netstat -s), when packets are received
Out Of Order (OFO)
TCPOFOQueue : Number of packets queued in OFO queue
TCPOFODrop : Number of packets meant to be queued in OFO
but dropped because socket rcvbuf limit hit.
TCPOFOMerge : Number of packets in OFO that were merged with
other packets.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/linux/snmp.h | 5 ++++-
net/ipv4/proc.c | 3 +++
net/ipv4/tcp_input.c | 7 +++++--
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/include/linux/snmp.h b/include/linux/snmp.h
index 2e68f5b..6e4c511 100644
--- a/include/linux/snmp.h
+++ b/include/linux/snmp.h
@@ -233,7 +233,10 @@ enum
LINUX_MIB_TCPREQQFULLDOCOOKIES, /* TCPReqQFullDoCookies */
LINUX_MIB_TCPREQQFULLDROP, /* TCPReqQFullDrop */
LINUX_MIB_TCPRETRANSFAIL, /* TCPRetransFail */
- LINUX_MIB_TCPRCVCOALESCE, /* TCPRcvCoalesce */
+ LINUX_MIB_TCPRCVCOALESCE, /* TCPRcvCoalesce */
+ LINUX_MIB_TCPOFOQUEUE, /* TCPOFOQueue */
+ LINUX_MIB_TCPOFODROP, /* TCPOFODrop */
+ LINUX_MIB_TCPOFOMERGE, /* TCPOFOMerge */
__LINUX_MIB_MAX
};
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 8af0d44..dae25e76 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -258,6 +258,9 @@ static const struct snmp_mib snmp4_net_list[] = {
SNMP_MIB_ITEM("TCPReqQFullDrop", LINUX_MIB_TCPREQQFULLDROP),
SNMP_MIB_ITEM("TCPRetransFail", LINUX_MIB_TCPRETRANSFAIL),
SNMP_MIB_ITEM("TCPRcvCoalesce", LINUX_MIB_TCPRCVCOALESCE),
+ SNMP_MIB_ITEM("TCPOFOQueue", LINUX_MIB_TCPOFOQUEUE),
+ SNMP_MIB_ITEM("TCPOFODrop", LINUX_MIB_TCPOFODROP),
+ SNMP_MIB_ITEM("TCPOFOMerge", LINUX_MIB_TCPOFOMERGE),
SNMP_MIB_SENTINEL
};
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 055ac49..cc4e12f 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -4397,8 +4397,8 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
TCP_ECN_check_ce(tp, skb);
- if (tcp_try_rmem_schedule(sk, skb->truesize)) {
- /* TODO: should increment a counter */
+ if (unlikely(tcp_try_rmem_schedule(sk, skb->truesize))) {
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFODROP);
__kfree_skb(skb);
return;
}
@@ -4407,6 +4407,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
tp->pred_flags = 0;
inet_csk_schedule_ack(sk);
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFOQUEUE);
SOCK_DEBUG(sk, "out of order segment: rcv_next %X seq %X - %X\n",
tp->rcv_nxt, TCP_SKB_CB(skb)->seq, TCP_SKB_CB(skb)->end_seq);
@@ -4460,6 +4461,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
if (skb1 && before(seq, TCP_SKB_CB(skb1)->end_seq)) {
if (!after(end_seq, TCP_SKB_CB(skb1)->end_seq)) {
/* All the bits are present. Drop. */
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFOMERGE);
__kfree_skb(skb);
skb = NULL;
tcp_dsack_set(sk, seq, end_seq);
@@ -4498,6 +4500,7 @@ static void tcp_data_queue_ofo(struct sock *sk, struct sk_buff *skb)
__skb_unlink(skb1, &tp->out_of_order_queue);
tcp_dsack_extend(sk, TCP_SKB_CB(skb1)->seq,
TCP_SKB_CB(skb1)->end_seq);
+ NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_TCPOFOMERGE);
__kfree_skb(skb1);
}
^ permalink raw reply related
* Re: resurrecting tcphealth
From: Eric Dumazet @ 2012-07-16 11:46 UTC (permalink / raw)
To: Piotr Sawuk; +Cc: netdev, linux-kernel
In-Reply-To: <87741204cd72d363d54dadf9a94bb6fe.squirrel@webmail.univie.ac.at>
On Mon, 2012-07-16 at 13:33 +0200, Piotr Sawuk wrote:
> On Sa, 14.07.2012, 01:55, Stephen Hemminger wrote:
> > I am not sure if the is really necessary since the most
> > of the stats are available elsewhere.
>
> if by "most" you mean address and port then you're right.
> but even the rtt reported by "ss -i" seems to differ from tcphealth.
Thats because tcphealth is wrong, it assumes HZ=1000 ?
tp->srtt unit is jiffies, not ms.
tcphealth is a gross hack.
^ permalink raw reply
* [PATCH] net-next: make sock diag per-namespace
From: Andrew Vagin @ 2012-07-16 12:14 UTC (permalink / raw)
To: David S. Miller
Cc: Andrew Vagin, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Pavel Emelyanov, linux-kernel,
netdev
Before this patch sock_diag works for init_net only and dumps
information about sockets from all namespaces.
This patch expands sock_diag for all name-spaces.
It creates a netlink kernel socket for each netns and filters
data during dumping.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Pavel Emelyanov <xemul@parallels.com>
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Andrew Vagin <avagin@openvz.org>
---
include/linux/sock_diag.h | 1 -
include/net/net_namespace.h | 1 +
net/core/sock_diag.c | 28 ++++++++++++++++++++++------
net/ipv4/inet_diag.c | 13 ++++++++++---
net/ipv4/udp_diag.c | 3 ++-
net/unix/diag.c | 9 +++++++--
6 files changed, 42 insertions(+), 13 deletions(-)
diff --git a/include/linux/sock_diag.h b/include/linux/sock_diag.h
index 6793fac..e3e395a 100644
--- a/include/linux/sock_diag.h
+++ b/include/linux/sock_diag.h
@@ -44,6 +44,5 @@ void sock_diag_save_cookie(void *sk, __u32 *cookie);
int sock_diag_put_meminfo(struct sock *sk, struct sk_buff *skb, int attr);
-extern struct sock *sock_diag_nlsk;
#endif /* KERNEL */
#endif
diff --git a/include/net/net_namespace.h b/include/net/net_namespace.h
index ac9195e..ae1cd6c 100644
--- a/include/net/net_namespace.h
+++ b/include/net/net_namespace.h
@@ -101,6 +101,7 @@ struct net {
struct netns_xfrm xfrm;
#endif
struct netns_ipvs *ipvs;
+ struct sock *diag_nlsk;
};
diff --git a/net/core/sock_diag.c b/net/core/sock_diag.c
index 07a29eb..d060251 100644
--- a/net/core/sock_diag.c
+++ b/net/core/sock_diag.c
@@ -166,23 +166,39 @@ static void sock_diag_rcv(struct sk_buff *skb)
mutex_unlock(&sock_diag_mutex);
}
-struct sock *sock_diag_nlsk;
-EXPORT_SYMBOL_GPL(sock_diag_nlsk);
+struct sock *diag_nlsk;
+EXPORT_SYMBOL_GPL(diag_nlsk);
-static int __init sock_diag_init(void)
+static int __net_init diag_net_init(struct net *net)
{
struct netlink_kernel_cfg cfg = {
.input = sock_diag_rcv,
};
- sock_diag_nlsk = netlink_kernel_create(&init_net, NETLINK_SOCK_DIAG,
+ net->diag_nlsk = netlink_kernel_create(net, NETLINK_SOCK_DIAG,
THIS_MODULE, &cfg);
- return sock_diag_nlsk == NULL ? -ENOMEM : 0;
+ return net->diag_nlsk == NULL ? -ENOMEM : 0;
+}
+
+static void __net_exit diag_net_exit(struct net *net)
+{
+ netlink_kernel_release(net->diag_nlsk);
+ net->diag_nlsk = NULL;
+}
+
+static struct pernet_operations diag_net_ops = {
+ .init = diag_net_init,
+ .exit = diag_net_exit,
+};
+
+static int __init sock_diag_init(void)
+{
+ return register_pernet_subsys(&diag_net_ops);
}
static void __exit sock_diag_exit(void)
{
- netlink_kernel_release(sock_diag_nlsk);
+ unregister_pernet_subsys(&diag_net_ops);
}
module_init(sock_diag_init);
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index 38064a2..4703c58 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -272,6 +272,7 @@ int inet_diag_dump_one_icsk(struct inet_hashinfo *hashinfo, struct sk_buff *in_s
int err;
struct sock *sk;
struct sk_buff *rep;
+ struct net *net = sock_net(in_skb->sk);
err = -EINVAL;
if (req->sdiag_family == AF_INET) {
@@ -317,7 +318,7 @@ int inet_diag_dump_one_icsk(struct inet_hashinfo *hashinfo, struct sk_buff *in_s
nlmsg_free(rep);
goto out;
}
- err = netlink_unicast(sock_diag_nlsk, rep, NETLINK_CB(in_skb).pid,
+ err = netlink_unicast(net->diag_nlsk, rep, NETLINK_CB(in_skb).pid,
MSG_DONTWAIT);
if (err > 0)
err = 0;
@@ -724,6 +725,7 @@ void inet_diag_dump_icsk(struct inet_hashinfo *hashinfo, struct sk_buff *skb,
{
int i, num;
int s_i, s_num;
+ struct net *net = sock_net(skb->sk);
s_i = cb->args[1];
s_num = num = cb->args[2];
@@ -743,6 +745,9 @@ void inet_diag_dump_icsk(struct inet_hashinfo *hashinfo, struct sk_buff *skb,
sk_nulls_for_each(sk, node, &ilb->head) {
struct inet_sock *inet = inet_sk(sk);
+ if (!net_eq(sock_net(sk), net))
+ continue;
+
if (num < s_num) {
num++;
continue;
@@ -943,6 +948,7 @@ static int inet_diag_get_exact_compat(struct sk_buff *in_skb,
static int inet_diag_rcv_msg_compat(struct sk_buff *skb, struct nlmsghdr *nlh)
{
int hdrlen = sizeof(struct inet_diag_req);
+ struct net *net = sock_net(skb->sk);
if (nlh->nlmsg_type >= INET_DIAG_GETSOCK_MAX ||
nlmsg_len(nlh) < hdrlen)
@@ -963,7 +969,7 @@ static int inet_diag_rcv_msg_compat(struct sk_buff *skb, struct nlmsghdr *nlh)
struct netlink_dump_control c = {
.dump = inet_diag_dump_compat,
};
- return netlink_dump_start(sock_diag_nlsk, skb, nlh, &c);
+ return netlink_dump_start(net->diag_nlsk, skb, nlh, &c);
}
}
@@ -973,6 +979,7 @@ static int inet_diag_rcv_msg_compat(struct sk_buff *skb, struct nlmsghdr *nlh)
static int inet_diag_handler_dump(struct sk_buff *skb, struct nlmsghdr *h)
{
int hdrlen = sizeof(struct inet_diag_req_v2);
+ struct net *net = sock_net(skb->sk);
if (nlmsg_len(h) < hdrlen)
return -EINVAL;
@@ -991,7 +998,7 @@ static int inet_diag_handler_dump(struct sk_buff *skb, struct nlmsghdr *h)
struct netlink_dump_control c = {
.dump = inet_diag_dump,
};
- return netlink_dump_start(sock_diag_nlsk, skb, h, &c);
+ return netlink_dump_start(net->diag_nlsk, skb, h, &c);
}
}
diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
index a7f86a3..52f42f9 100644
--- a/net/ipv4/udp_diag.c
+++ b/net/ipv4/udp_diag.c
@@ -34,6 +34,7 @@ static int udp_dump_one(struct udp_table *tbl, struct sk_buff *in_skb,
int err = -EINVAL;
struct sock *sk;
struct sk_buff *rep;
+ struct net *net = sock_net(in_skb->sk);
if (req->sdiag_family == AF_INET)
sk = __udp4_lib_lookup(&init_net,
@@ -75,7 +76,7 @@ static int udp_dump_one(struct udp_table *tbl, struct sk_buff *in_skb,
kfree_skb(rep);
goto out;
}
- err = netlink_unicast(sock_diag_nlsk, rep, NETLINK_CB(in_skb).pid,
+ err = netlink_unicast(net->diag_nlsk, rep, NETLINK_CB(in_skb).pid,
MSG_DONTWAIT);
if (err > 0)
err = 0;
diff --git a/net/unix/diag.c b/net/unix/diag.c
index a74864e..750b134 100644
--- a/net/unix/diag.c
+++ b/net/unix/diag.c
@@ -177,6 +177,7 @@ static int unix_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
{
struct unix_diag_req *req;
int num, s_num, slot, s_slot;
+ struct net *net = sock_net(skb->sk);
req = nlmsg_data(cb->nlh);
@@ -192,6 +193,8 @@ static int unix_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
num = 0;
sk_for_each(sk, node, &unix_socket_table[slot]) {
+ if (!net_eq(sock_net(sk), net))
+ continue;
if (num < s_num)
goto next;
if (!(req->udiag_states & (1 << sk->sk_state)))
@@ -243,6 +246,7 @@ static int unix_diag_get_exact(struct sk_buff *in_skb,
struct sock *sk;
struct sk_buff *rep;
unsigned int extra_len;
+ struct net *net = sock_net(in_skb->sk);
if (req->udiag_ino == 0)
goto out_nosk;
@@ -273,7 +277,7 @@ again:
goto again;
}
- err = netlink_unicast(sock_diag_nlsk, rep, NETLINK_CB(in_skb).pid,
+ err = netlink_unicast(net->diag_nlsk, rep, NETLINK_CB(in_skb).pid,
MSG_DONTWAIT);
if (err > 0)
err = 0;
@@ -287,6 +291,7 @@ out_nosk:
static int unix_diag_handler_dump(struct sk_buff *skb, struct nlmsghdr *h)
{
int hdrlen = sizeof(struct unix_diag_req);
+ struct net *net = sock_net(skb->sk);
if (nlmsg_len(h) < hdrlen)
return -EINVAL;
@@ -295,7 +300,7 @@ static int unix_diag_handler_dump(struct sk_buff *skb, struct nlmsghdr *h)
struct netlink_dump_control c = {
.dump = unix_diag_dump,
};
- return netlink_dump_start(sock_diag_nlsk, skb, h, &c);
+ return netlink_dump_start(net->diag_nlsk, skb, h, &c);
} else
return unix_diag_get_exact(skb, h, nlmsg_data(h));
}
--
1.7.1
^ permalink raw reply related
* 2012春季111届广交会买家，群发软件，B2B询盘买家、thomasnet 采购商,海关数据,展会买家 仅300元!
From: 有效果再付款 @ 2012-07-16 12:18 UTC (permalink / raw)
To: neuro, ncarroll, neuwudan, nevanez, neveroverthehill, netdev,
netdeck, netzhj, netzu, neucaijuan
2012春季111届广交会买家，海关数据提单piers版，2008-2012年9届广交会数据。
一共10个包(数据是全行业的，可以按照关键词提取出来的)：
1，2012春季111届广交会买家现场询盘数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，购买后可以免费更新2012秋季广交会买家数据。太超值了。
3，2012最新全球展会现场买家库(与贸发同步),共46万条数据。 (按照行业分类)
4，2011,2010年,2009年,2008年 春季+秋季广交会买家名录，103 104 105 106 107 108,109,110 共六届 共120.6万数据。
5，48.68万条最新买家询盘，都带有Email，最有价值的询盘。
6，2011最新 B2B 英文国际站60万带联络方式询盘 最有价值询盘之一.
7，2010海关提单piers版1000万数据.
8，2011年到香港采购的国外客人名录(香港贸发局提供)，超级重要的买家。
9，2011年新增加的-美国B2B thomasnet 采购商名单。
10，群发软件安装与部署服务。
这些全有，共1280万 数据。
要的抓紧联系QQ: 460122641 或者立即回复邮箱: 460122641@qq.com
要的抓紧联系QQ: 460122641 或者立即回复邮箱: 460122641@qq.com
要的抓紧联系QQ: 460122641 或者立即回复邮箱: 460122641@qq.com
诚信为本，如果不信任本人,可以走淘宝交易,收到数据验证3天后再付款,这是对您最好的保障了。
小技巧：
把500万买家群发以一遍，均会有数千个回复的，这些就是非常高质量的买家。
使用我们送的群发软件，1-2周就可完全发完。
广交会买家按产品类别分类，分为以下几类：
1 办公设备
2 编织及藤铁工艺品
3 玻璃
4 餐厨用具
5 车辆
6 大型机械及设备
7 电子电气
8 电子消费品
9 纺织
10 服装
11 个人护理
12 工程机械
13 工具
14 化工
15 计算机及通讯
16 家居用品
17 家居装饰
18 家具
19 家用电器
20 建筑及装饰材料
21 节日用品
22 礼品及赠品
23 摩托车
24 汽车配件
25 食品
26 陶瓷
27 铁石
28 玩具
29 卫浴
30 五金
31 小型机械
32 鞋
33 休闲用品
34 医疗
35 浴室产品
36 园林
37 照明产品
38 钟表眼镜
39 自行车
40 包
新鲜数据-成单率极高
新鲜数据-成单率极高
新鲜数据-成单率极高
新鲜数据-成单率极高
新鲜数据-成单率极高
^ permalink raw reply
* Re: [PATCH] natsemi: make cable length magic configurable
From: Jean Delvare @ 2012-07-16 12:26 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, Tim Hockin, Olaf Kirch
In-Reply-To: <1322162739.2784.26.camel@bwh-desktop>
Hi Ben,
Thanks for you fast reply and sorry for my very slow one.
Le jeudi 24 novembre 2011 à 19:25 +0000, Ben Hutchings a écrit :
> On Thu, 2011-11-24 at 14:43 +0100, Jean Delvare wrote:
> > From: Olaf Kirch <okir@suse.de>
> >
> > We had a customer report concerning problems with a Natsemi DP83815-D
> > and long cables. With 100m cables, the network would be essentially dead,
> > not a single packet would get through either way. We had to apply the
> > patch below to make it work.
> >
> > The patch adds a module parameter named "no_cable_magic" that does
> > two things:
> >
> > - Unconditionally set the DSPCFG register to the
> > fixed value. Without this change, the chip apparently
> > never completes autonegotiation in the tested configuration.
> >
> > This has been an unconditional assignment for a long time,
> > until this was changed in 2.6.11 (there's an interesting
> > explanation in the ChangeLog, subject is
> > "[PATCH] natsemi long cable fix", bk commit is
> > 5871b81bf2b5cf188deab0d414dce104fcb69ca6, git commit in
> > tglx/history tree is c0d51c67f9c398279a95c5a7df387f2d9a586c98.
> >
> > - Skip the bit banging in {,un}do_cable_magic. It seems that
> > if we write the DSPCFG register as above, a rev D chip will report
> > all cables as "short cables", which do_cable_magic detects, and
> > trying to be helpful it will "fix" the attenuation coefficient.
> >
> > I admit the use of a module parameter is ugly, but I didn't find a sane
> > way to fix this - especially since the magic registers we're changing
> > are undocumented.
> [...]
>
> This could be implemented as an ethtool 'private flag'. However, the
> ethtool utility currently does not provide an interface to them.
> Perhaps you could implement both the private flag and the module
> parameter for now, and then drop the module parameter some time after
> the utility has been updated.
I see that you updated the ethtool utility meanwhile, thanks for doing
that.
> You would need to:
> 1. Number the flags starting from 0. Well, that was easy.
> 2. Implement {get,set}_priv_flags() operations to access all flags as
> a bitmask.
> 3. Expose the flag names as string set ETH_SS_PRIV_FLAGS accessed by
> get_sset_count() and get_strings() operations.
I was looking for an example, but there doesn't seem to be any driver
implementing private flags at the moment?
I am also unsure if a private flag is a suitable solution to the problem
at hand. I am a little worried about the timing, as the non-default
value can't be set before the network device is available, I'm afraid
the network initialization scripts may kick in before one has a chance
to set the flag with ethtool. I suppose this could be problematic, but
then again I don't know much about network device drivers, I don't even
know for sure when method .ndo_open is called...
Furthermore I don't quite get why we can't just go with the module
parameter. As I understand it, this is a crappy driver for crappy, rare
hardware. The driver already has a module parameter to work around a
hardware bug (dspcfg_workaround), I don't quite see why adding a second
one would be a problem. At least it is consistent.
Thanks,
--
Jean Delvare
Suse L3
^ permalink raw reply
* [RESEND] lpc_eth: remove duplicated include
From: Duan Jiong @ 2012-07-16 12:29 UTC (permalink / raw)
To: davem; +Cc: netdev
Remove duplicated #include <linux/delay.h> in
drivers/net/ethernet/nxp/lpc_eth.c
Signed-off-by: Duan Jiong<djduanjiong@gmail.com>
---
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
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