Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH net-next] neigh: RCU conversion of struct neighbour
From: David Miller @ 2010-10-07  0:49 UTC (permalink / raw)
  To: eric.dumazet; +Cc: netdev
In-Reply-To: <1286380456.9417.40.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 06 Oct 2010 17:54:16 +0200

> This is the second step for neighbour RCU conversion.
> 
> (first was commit d6bf7817 : RCU conversion of neigh hash table)
> 
> neigh_lookup() becomes lockless, but still take a reference on found
> neighbour. (no more read_lock()/read_unlock() on tbl->lock)
> 
> struct neighbour gets an additional rcu_head field and is freed after an
> RCU grace period.
> 
> Future work would need to eventually not take a reference on neighbour
> for temporary dst (DST_NOCACHE), but this would need dst->_neighbour to
> use a noref bit like we did for skb->_dst.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied, thanks Eric.

^ permalink raw reply

* Re: Linux 2.6.36-rc7
From: Stephen Rothwell @ 2010-10-07  0:49 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Linux Kernel Mailing List, Russell King, James Bottomley,
	David Miller, netdev, John W. Linville, Michal Marek,
	Dmitry Torokhov
In-Reply-To: <AANLkTi=LsBNU+O2hqZUcM2nYM_ze6qPq3thwSZBMtY_v@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2788 bytes --]

Hi Linus,

On Wed, 6 Oct 2010 14:45:13 -0700 Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> This should be the last -rc, I'm not seeing any reason to keep
> delaying a real release. There was still more changes to
> drivers/gpu/drm than I really would have hoped for, but they all look
> harmless and good. Famous last words.

I have no idea how critical any of this stuff is, but linux-next contain
the following in it's "current" trees i.e. stuff that is supposed to go
into 2.6.36.  These are from the arm-current, scsi-rc-fixes, net-current,
wireless-current, kbuild-current, input-current and ide-curent trees
(contacts cc'd).

Arnaud Lacombe (1):
      kconfig: delay symbol direct dependency initialization
[This one produces a lot of new warnings, but also fixes a bug ...]

Ben Hutchings (2):
      Revert "ipv4: Make INET_LRO a bool instead of tristate."
      netdev: Depend on INET before selecting INET_LRO

Dan Carpenter (1):
      cls_u32: signedness bug

Dan Rosenberg (2):
      sctp: prevent reading out-of-bounds memory
      sctp: Fix out-of-bounds reading in sctp_asoc_get_hmac()

David Stevens (1):
      ipv4: correct IGMP behavior on v3 query during v2-compatibility mode

Dmitry Torokhov (1):
      Input: wacom - fix runtime PM related deadlock

Eric Dumazet (1):
      caif: fix two caif_connect() bugs

Felix Fietkau (1):
      ath9k_hw: fix regression in ANI listen time calculation

Henrik Rydberg (1):
      Input: uinput - setup MT usage during device creation

Jeff Kirsher (4):
      ixgbevf.txt: Update ixgbevf documentation
      e1000.txt: Update e1000 documentation
      e1000e.txt: Add e1000e documentation
      MAINTAINERS: update Intel LAN Ethernet info

Johannes Berg (1):
      mac80211: delete AddBA response timer

Kenneth Waters (1):
      Input: joydev - fix JSIOCSAXMAP ioctl

Maciej Żenczykowski (1):
      net: Fix IPv6 PMTU disc. w/ asymmetric routes

Martin K. Petersen (1):
      [SCSI] Fix VPD inquiry page wrapper

Nagendra Tomar (1):
      net: Fix the condition passed to sk_wait_event()

Neil Horman (1):
      bonding: fix WARN_ON when writing to bond_master sysfs file

Santosh Shilimkar (1):
      ARM: 6419/1: mmu: Fix MT_MEMORY and MT_MEMORY_NONCACHED pte flags

Sergei Shtylyov (2):
      hpt366: add debounce delay to cable_detect() method
      hpt366: fix clock turnaround

Stanislaw Gruszka (1):
      skge: add quirk to limit DMA

Will Deacon (2):
      ARM: 6416/1: errata: faulty hazard checking in the Store Buffer may lead to data corruption
      ARM: 6412/1: kprobes-decode: add support for MOVW instruction

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

^ permalink raw reply

* [patch] IPVS: ip_vs_dbg_callid() is only needed for debugging
From: Simon Horman @ 2010-10-07  1:23 UTC (permalink / raw)
  To: lvs-devel, netdev, netfilter-devel
  Cc: Wensong Zhang, Julian Anastasov, Patrick McHardy

ip_vs_dbg_callid() and IP_VS_DEBUG_CALLID() are only needed
it CONFIG_IP_VS_DEBUG is defined.

This resolves the following build warning when CONFIG_IP_VS_DEBUG is
not defined.

net/netfilter/ipvs/ip_vs_pe_sip.c:11: warning: 'ip_vs_dbg_callid' defined but not used

Reported-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Simon Horman <horms@verge.net.au>

Index: nf-next-2.6/net/netfilter/ipvs/ip_vs_pe_sip.c
===================================================================
--- nf-next-2.6.orig/net/netfilter/ipvs/ip_vs_pe_sip.c	2010-10-07 10:17:54.000000000 +0900
+++ nf-next-2.6/net/netfilter/ipvs/ip_vs_pe_sip.c	2010-10-07 10:18:33.000000000 +0900
@@ -8,6 +8,7 @@
 #include <net/netfilter/nf_conntrack.h>
 #include <linux/netfilter/nf_conntrack_sip.h>
 
+#ifdef CONFIG_IP_VS_DEBUG
 static const char *ip_vs_dbg_callid(char *buf, size_t buf_len,
 				    const char *callid, size_t callid_len,
 				    int *idx)
@@ -22,6 +23,7 @@ static const char *ip_vs_dbg_callid(char
 #define IP_VS_DEBUG_CALLID(callid, len)					\
 	ip_vs_dbg_callid(ip_vs_dbg_buf, sizeof(ip_vs_dbg_buf),		\
 			 callid, len, &ip_vs_dbg_idx)
+#endif
 
 static int get_callid(const char *dptr, unsigned int dataoff,
 		      unsigned int datalen,

^ permalink raw reply

* linux-next: manual merge of the net tree with the net-current tree
From: Stephen Rothwell @ 2010-10-07  1:31 UTC (permalink / raw)
  To: David Miller, netdev
  Cc: linux-next, linux-kernel, Eric Dumazet, David Miller, netdev,
	Joe Perches

Hi all,

Today's linux-next merge of the net tree got a conflict in
net/caif/caif_socket.c between commit
79315068f4560f3f7bd6e9790190dcb43059770c ("caif: fix two caif_connect()
bugs") from the net-current tree and commit
b31fa5bad576cd8180a5ad70c648333b44320d44 ("net/caif: Use pr_fmt") from
the net tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc net/caif/caif_socket.c
index 4bf28f2,abcba53..0000000
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@@ -897,23 -888,14 +889,22 @@@ static int caif_connect(struct socket *
  		cf_sk->sk.sk_state = CAIF_DISCONNECTED;
  		goto out;
  	}
 -	dev = dev_get_by_index(sock_net(sk), ifindex);
 +
 +	err = -ENODEV;
 +	rcu_read_lock();
 +	dev = dev_get_by_index_rcu(sock_net(sk), ifindex);
 +	if (!dev) {
 +		rcu_read_unlock();
 +		goto out;
 +	}
  	cf_sk->headroom = LL_RESERVED_SPACE_EXTRA(dev, headroom);
 +	mtu = dev->mtu;
 +	rcu_read_unlock();
 +
  	cf_sk->tailroom = tailroom;
 -	cf_sk->maxframe = dev->mtu - (headroom + tailroom);
 -	dev_put(dev);
 +	cf_sk->maxframe = mtu - (headroom + tailroom);
  	if (cf_sk->maxframe < 1) {
- 		pr_warning("CAIF: %s(): CAIF Interface MTU too small (%u)\n",
- 			   __func__, mtu);
 -		pr_warn("CAIF Interface MTU too small (%d)\n", dev->mtu);
 -		err = -ENODEV;
++		pr_warn("CAIF Interface MTU too small (%d)\n", mtu);
  		goto out;
  	}
  

^ permalink raw reply

* Re: [PATCH] Documentation/networking/ixgbevf.txt: Change file permissions to 644
From: David Miller @ 2010-10-07  1:42 UTC (permalink / raw)
  To: joe; +Cc: jeffrey.t.kirsher, netdev, rdunlap, gregory.v.rose
In-Reply-To: <20101006.173353.179919967.davem@davemloft.net>

From: David Miller <davem@davemloft.net>
Date: Wed, 06 Oct 2010 17:33:53 -0700 (PDT)

> From: Joe Perches <joe@perches.com>
> Date: Wed, 06 Oct 2010 15:09:50 -0700
> 
>> Signed-off-by: Joe Perches <joe@perches.com>
>> ---
>> diff --git a/Documentation/networking/ixgbevf.txt b/Documentation/networking/ixgbevf.txt
>> old mode 100755
>> new mode 100644
> 
> Applied, thanks.

Actually, only net-next-2.6 needs this and this permission issue will
end up getting fixed transparently when I merge net-2.6 into
net-next-2.6

Which I need to do right now to resolve a conflict anyways.

So I won't actually be applying this patch.

^ permalink raw reply

* Re: [net-next-2.6 PATCH 2/3] bonding: add Speed/Duplex information to /proc/net/bonding/bond
From: David Miller @ 2010-10-07  1:44 UTC (permalink / raw)
  To: ole; +Cc: fubar, bonding-devel, netdev
In-Reply-To: <4CACEADA.70009@ans.pl>

From: Krzysztof Olędzki <ole@ans.pl>
Date: Wed, 06 Oct 2010 23:32:10 +0200

> Please note however that this procfs file was recently changed ("Slave
> queue ID" was added) so if this is indeed a problem than we would
> already heard about this.

You make a good argument, therefore I have decided to apply
your patch.

Thanks.


^ permalink raw reply

* Re: [PATCH] Documentation/networking/ixgbevf.txt: Change file permissions to 644
From: Joe Perches @ 2010-10-07  1:52 UTC (permalink / raw)
  To: David Miller; +Cc: jeffrey.t.kirsher, netdev, rdunlap, gregory.v.rose
In-Reply-To: <20101006.184215.35062616.davem@davemloft.net>

On Wed, 2010-10-06 at 18:42 -0700, David Miller wrote:
> So I won't actually be applying this patch.

No worries, happy it's getting resolved.

I sent a patch to checkpatch so these could be avoided
in the future.  Maybe Andy W has a better idea.


^ permalink raw reply

* Re: [PATCH] Documentation/networking/ixgbevf.txt: Change file permissions to 644
From: David Miller @ 2010-10-07  1:59 UTC (permalink / raw)
  To: joe; +Cc: jeffrey.t.kirsher, netdev, rdunlap, gregory.v.rose
In-Reply-To: <1286416346.3292.2.camel@Joe-Laptop>

From: Joe Perches <joe@perches.com>
Date: Wed, 06 Oct 2010 18:52:26 -0700

> On Wed, 2010-10-06 at 18:42 -0700, David Miller wrote:
>> So I won't actually be applying this patch.
> 
> No worries, happy it's getting resolved.
> 
> I sent a patch to checkpatch so these could be avoided
> in the future.  Maybe Andy W has a better idea.

GIT would probably be a better place to detect this, even if
it's not on by default I would enable it in my own personal
.gitconfig

^ permalink raw reply

* Re: linux-next: manual merge of the net tree with the net-current tree
From: David Miller @ 2010-10-07  2:35 UTC (permalink / raw)
  To: sfr; +Cc: netdev, linux-next, linux-kernel, eric.dumazet, joe
In-Reply-To: <20101007123104.bf7a9808.sfr@canb.auug.org.au>

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 7 Oct 2010 12:31:04 +1100

> Hi all,
> 
> Today's linux-next merge of the net tree got a conflict in
> net/caif/caif_socket.c between commit
> 79315068f4560f3f7bd6e9790190dcb43059770c ("caif: fix two caif_connect()
> bugs") from the net-current tree and commit
> b31fa5bad576cd8180a5ad70c648333b44320d44 ("net/caif: Use pr_fmt") from
> the net tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Thanks Stephen, I'm merging net-2.6 into net-next-2.6 right now
to resolve this.

Thanks!

^ permalink raw reply

* [PATCH] TCP: Fix setting of snd_ssthresh in tcp_mtu_probe_success
From: John Heffner @ 2010-10-07  3:41 UTC (permalink / raw)
  To: davem; +Cc: netdev

This looks like a simple typo that has gone unnoticed for some time.  The
impact is relatively low but it's clearly wrong.

Signed-off-by: John Heffner <johnwheffner@gmail.com>
---
 net/ipv4/tcp_input.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index f6fdd72..e4fbdae 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -2874,7 +2874,7 @@ static void tcp_mtup_probe_success(struct sock *sk)
 		       icsk->icsk_mtup.probe_size;
 	tp->snd_cwnd_cnt = 0;
 	tp->snd_cwnd_stamp = tcp_time_stamp;
-	tp->rcv_ssthresh = tcp_current_ssthresh(sk);
+	tp->snd_ssthresh = tcp_current_ssthresh(sk);
 
 	icsk->icsk_mtup.search_low = icsk->icsk_mtup.probe_size;
 	icsk->icsk_mtup.probe_size = 0;
-- 
1.7.0.4


^ permalink raw reply related

* [RFC] net: allow FEC driver to not have attached PHY
From: Greg Ungerer @ 2010-10-07  3:50 UTC (permalink / raw)
  To: netdev; +Cc: gerg


Hi All,

I have a board with a ColdFire SoC on it with the built-in FEC
ethernet module. On this hardware the FEC eth output is directly
attached to a RTL8305 4-port 10/100 switch. There is no conventional
PHY, the FEC output is direct into the uplink port of the switch
chip.

This setup doesn't work after the FEC code was switch to using
phylib. The driver used to have code to bypass phy detection/setup
for this particular board. The phylib probe finds nothing, and of
course sets a no-link condition.

So, what is the cleanest way to support this?

The attached patch adds a config option to do this sort of generically
for the FEC driver. But I am wondering if there isn't a better way?

Regards
Greg


---

[RFC] net: allow FEC driver to not have attached PHY

At least one board using the FEC driver does not have a conventional
PHY attached to it, it is directly connected to a somewhat simple
ethernet switch (the board is the SnapGear/LITE, and the attached
4-port ethernet switch is a RealTek RTL8305). This switch does not
present the usual register interface of a PHY, it presents nothing.
So a PHY scan will find nothing.

After the FEC driver was changed to use phylib for supporting phys
it no longer works on this particular board/switch setup.

Add a config option to allow configuring the FEC driver to not expect
a PHY to be present.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
 drivers/net/Kconfig |    9 +++++++++
 drivers/net/fec.c   |    7 +++++++
 2 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 93494e2..ee44728 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1934,6 +1934,15 @@ config FEC2
 	  Say Y here if you want to use the second built-in 10/100 Fast
 	  ethernet controller on some Motorola ColdFire processors.
 
+config FEC_NOPHY
+	bool "FEC has no attached PHY"
+	depends on FEC
+	help
+	  Some boards using the FEC driver may not have a PHY directly
+	  attached to it. Typically in this scenario the FEC output is
+	  directly connected to the input of an ethernet switch or hub.
+	  Say Y here if your hardware is like this.
+
 config FEC_MPC52xx
 	tristate "MPC52xx FEC driver"
 	depends on PPC_MPC52xx && PPC_BESTCOMM
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 768b840..3637f89 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -910,6 +910,11 @@ fec_enet_open(struct net_device *dev)
 	if (ret)
 		return ret;
 
+#ifdef CONFIG_FEC_NOPHY
+	/* No PHY connected, assume link is always up */
+	fep->link = 1;
+	fec_restart(dev, 0);
+#else
 	/* Probe and connect to PHY when open the interface */
 	ret = fec_enet_mii_probe(dev);
 	if (ret) {
@@ -917,6 +922,8 @@ fec_enet_open(struct net_device *dev)
 		return ret;
 	}
 	phy_start(fep->phy_dev);
+#endif
+
 	netif_start_queue(dev);
 	fep->opened = 1;
 	return 0;

^ permalink raw reply related

* Re: [PATCH] TCP: Fix setting of snd_ssthresh in tcp_mtu_probe_success
From: David Miller @ 2010-10-07  4:18 UTC (permalink / raw)
  To: johnwheffner; +Cc: netdev
In-Reply-To: <1286422913-30034-1-git-send-email-johnwheffner@gmail.com>

From: John Heffner <johnwheffner@gmail.com>
Date: Wed,  6 Oct 2010 23:41:53 -0400

> This looks like a simple typo that has gone unnoticed for some time.  The
> impact is relatively low but it's clearly wrong.
> 
> Signed-off-by: John Heffner <johnwheffner@gmail.com>

Amazing how long something like this can survive :-)

Applied, thanks John.

^ permalink raw reply

* Re: Segmentation fault when using ping6
From: Baruch Siach @ 2010-10-07  5:32 UTC (permalink / raw)
  To: Rogerio Pimentel; +Cc: netdev, linux-arm-kernel
In-Reply-To: <4CACDBB1.9050305@freescale.com>

Hi Rogerio,

On Wed, Oct 06, 2010 at 05:27:29PM -0300, Rogerio Pimentel wrote:
> I'm having a "segmentation fault" problem when using ping6.
> 
> When testing on ARM9 platforms (i.MX25 and i.MX27), it returns the error:
> 
> root@freescale ~$ ping6 ::1
> PING ::1 (::1): 56 data bytes
> Segmentation fault
> 
> When testing on ARM11 and ARM Cortex A8 platforms (i.MX31 and
> i.MX51), it works:
> 
> root@freescale ~$ ping6 ::1
> PING ::1 (::1): 56 data bytes
> 64 bytes from ::1: seq=0 ttl=64 time=0.331 ms
> 64 bytes from ::1: seq=1 ttl=64 time=0.214 ms
> 64 bytes from ::1: seq=2 ttl=64 time=0.176 ms
> 64 bytes from ::1: seq=3 ttl=64 time=0.155 ms
> 
> On all cases, I'm using Linux Kernel 2.6.35 (from Mainline) and
> Busybox 1.15.0
> 
> Does anybody have any idea?

This seems to be a Busybox related issue. I'd suggests you to try the latest 
version of Busybox (1.17.2), and if the problem persists, ask at the Busybox 
mailing list. Don't forget to add strace output to your message.

baruch

-- 
                                                     ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

^ permalink raw reply

* Re: [PATCH -next] sundance: Drop legacy _COMPAT_WITH_OLD_KERNEL includes
From: David Miller @ 2010-10-07  6:11 UTC (permalink / raw)
  To: dkirjanov; +Cc: netdev
In-Reply-To: <20101006135956.GA5556@hera.kernel.org>

From: Denis Kirjanov <dkirjanov@kernel.org>
Date: Wed, 6 Oct 2010 13:59:56 +0000

> Drop legacy includes since 2.4.x
> 
> Signed-off-by: Denis Kirjanov <dkirjanov@kernel.org>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next] dccp:
From: David Miller @ 2010-10-07  6:12 UTC (permalink / raw)
  To: shemminger; +Cc: acme, dccp, netdev
In-Reply-To: <20101005232409.61cb9412@s6510>

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 5 Oct 2010 23:24:09 +0900

> Remove dead code and make some functions static.
> Compile tested only.
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

Looks good, applied, thanks.

^ permalink raw reply

* Re: [net-next-2.6 PATCH] net: netif_set_real_num_rx_queues may cap num_rx_queues at init time
From: Eric Dumazet @ 2010-10-07  6:16 UTC (permalink / raw)
  To: John Fastabend; +Cc: bhutchings, netdev, therbert
In-Reply-To: <20101004220042.3471.92774.stgit@jf-dev1-dcblab>

Le lundi 04 octobre 2010 à 15:00 -0700, John Fastabend a écrit :
> The logic for netif_set_real_num_rx_queues is the following,
> 


...

> Because netif_set_real_num_rx_queues sets num_rx_queues if the
> reg state is not NETREG_REGISTERED we end up with the incorrect
> max number of rx queues. This patch proposes to remove the else
> clause above so this does not occur.  Also just reading the
> function set_real_num it seems a bit unexpected that num_rx_queues
> gets set.
> 
> CC: Ben Hutchings <bhutchings@solarflare.com>
> 
> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
> ---

Acked-by: Eric Dumazet <eric.dumazet@gmail.com>



^ permalink raw reply

* Re: [patch] eicon: make buffer larger
From: David Miller @ 2010-10-07  6:30 UTC (permalink / raw)
  To: error27; +Cc: mac, isdn, netdev, linux-kernel, kernel-janitors
In-Reply-To: <20101004192459.GE5692@bicker>

From: Dan Carpenter <error27@gmail.com>
Date: Mon, 4 Oct 2010 21:24:59 +0200

> In diva_mnt_add_xdi_adapter() we do this:
>   strcpy (clients[id].drvName,     tmp);
>   strcpy (clients[id].Dbg.drvName, tmp);
> 
> The "clients[id].drvName" is a 128 character buffer and
> "clients[id].Dbg.drvName" was originally a 16 character buffer but I've
> changed it to 128 as well.  We don't actually use 128 characters but we
> do use more than 16.
> 
> I've also changed the size of "tmp" to 128 characters instead of 256.
> 
> Signed-off-by: Dan Carpenter <error27@gmail.com>

Applied.

^ permalink raw reply

* Re: [net-next-2.6 PATCH] net: netif_set_real_num_rx_queues may cap num_rx_queues at init time
From: David Miller @ 2010-10-07  6:35 UTC (permalink / raw)
  To: eric.dumazet; +Cc: john.r.fastabend, bhutchings, netdev, therbert
In-Reply-To: <1286432199.9417.47.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 07 Oct 2010 08:16:39 +0200

> Le lundi 04 octobre 2010 à 15:00 -0700, John Fastabend a écrit :
>> The logic for netif_set_real_num_rx_queues is the following,
>> 
> 
> 
> ...
> 
>> Because netif_set_real_num_rx_queues sets num_rx_queues if the
>> reg state is not NETREG_REGISTERED we end up with the incorrect
>> max number of rx queues. This patch proposes to remove the else
>> clause above so this does not occur.  Also just reading the
>> function set_real_num it seems a bit unexpected that num_rx_queues
>> gets set.
>> 
>> CC: Ben Hutchings <bhutchings@solarflare.com>
>> 
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
> 
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>

Applied, thanks everyone.

^ permalink raw reply

* Re: [net-next PATCH] igb: update adapter stats when reading /proc/net/dev.
From: David Miller @ 2010-10-07  6:36 UTC (permalink / raw)
  To: hawk; +Cc: netdev, jeffrey.t.kirsher
In-Reply-To: <20101005141833.20929.10943.stgit@localhost>

From: Jesper Dangaard Brouer <hawk@comx.dk>
Date: Tue, 05 Oct 2010 16:18:33 +0200

> Network driver igb: Improve the accuracy of stats in /proc/net/dev, by
> updating the adapter stats when reading /proc/net/dev.  Currently the
> stats are updated by the watchdog timer every 2 sec, or when getting
> stats via ethtool -S.
> 
> A number of userspace apps read these /proc/net/dev stats every second,
> e.g. ifstat, which then gives a perceived very bursty traffic pattern,
> which is actually false.
> 
> Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>

I assume that the Intel folks will take care of integrating this
now that the locking is fixed.

Thanks.

^ permalink raw reply

* Re: [net-next PATCH] igb: update adapter stats when reading /proc/net/dev.
From: Eric Dumazet @ 2010-10-07  6:44 UTC (permalink / raw)
  To: David Miller; +Cc: hawk, netdev, jeffrey.t.kirsher
In-Reply-To: <20101006.233611.68115178.davem@davemloft.net>

Le mercredi 06 octobre 2010 à 23:36 -0700, David Miller a écrit :
> From: Jesper Dangaard Brouer <hawk@comx.dk>
> Date: Tue, 05 Oct 2010 16:18:33 +0200
> 
> > Network driver igb: Improve the accuracy of stats in /proc/net/dev, by
> > updating the adapter stats when reading /proc/net/dev.  Currently the
> > stats are updated by the watchdog timer every 2 sec, or when getting
> > stats via ethtool -S.
> > 
> > A number of userspace apps read these /proc/net/dev stats every second,
> > e.g. ifstat, which then gives a perceived very bursty traffic pattern,
> > which is actually false.
> > 
> > Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
> 
> I assume that the Intel folks will take care of integrating this
> now that the locking is fixed.
> 

I integrated Jesper patch into my cumulative patch.

BTW, ixgbe has similar locking problem.




^ permalink raw reply

* Re: [net-next PATCH] igb: update adapter stats when reading /proc/net/dev.
From: David Miller @ 2010-10-07  6:46 UTC (permalink / raw)
  To: eric.dumazet; +Cc: hawk, netdev, jeffrey.t.kirsher
In-Reply-To: <1286433848.9417.49.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 07 Oct 2010 08:44:08 +0200

> Le mercredi 06 octobre 2010 à 23:36 -0700, David Miller a écrit :
>> From: Jesper Dangaard Brouer <hawk@comx.dk>
>> Date: Tue, 05 Oct 2010 16:18:33 +0200
>> 
>> > Network driver igb: Improve the accuracy of stats in /proc/net/dev, by
>> > updating the adapter stats when reading /proc/net/dev.  Currently the
>> > stats are updated by the watchdog timer every 2 sec, or when getting
>> > stats via ethtool -S.
>> > 
>> > A number of userspace apps read these /proc/net/dev stats every second,
>> > e.g. ifstat, which then gives a perceived very bursty traffic pattern,
>> > which is actually false.
>> > 
>> > Signed-off-by: Jesper Dangaard Brouer <hawk@comx.dk>
>> 
>> I assume that the Intel folks will take care of integrating this
>> now that the locking is fixed.
>> 
> 
> I integrated Jesper patch into my cumulative patch.

Ok.

^ permalink raw reply

* Re: [net-next-2.6 PATCH] ixgbe: Use affinity_hint when Flow Director is enabled
From: David Miller @ 2010-10-07  6:48 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, gospo, bphilips, peter.p.waskiewicz.jr
In-Reply-To: <20101005112511.23263.64121.stgit@localhost.localdomain>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 05 Oct 2010 04:27:49 -0700

> From: Peter Waskiewicz <peter.p.waskiewicz.jr@intel.com>
> 
> Use the new infrastructure to balance interrupts for flow
> alignment when ATR or Flow Director are enabled.
> 
> Signed-off-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
> Tested-by: Stephen Ko <stephen.s.ko@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>

Applied, thanks.

^ permalink raw reply

* Re: sending VLAN packets via packet_mmap
From: David Miller @ 2010-10-07  6:53 UTC (permalink / raw)
  To: phil; +Cc: netdev, johann.baudy, eric.dumazet
In-Reply-To: <20100930192414.GD26509@orbit.nwl.cc>

From: Phil Sutter <phil@nwl.cc>
Date: Thu, 30 Sep 2010 21:24:14 +0200

> The actual problem in tpacket_snd() is this:
> 
> | reserve = dev->hard_header_len;
> | [...]
> | if (size_max > dev->mtu + reserve)
> | 	size_max = dev->mtu + reserve;
> 
> I guess the check is there to avoid skb overflows on malicious data
> input. Is this correct? Are there other reasons for it's existence?

We can add a special allowance of 4 extra bytes in this size check
_iff_ the device is ethernet and the NETIF_F_VLAN_CHALLENGED netdev
feature bit is not set.


^ permalink raw reply

* Re: ixgbe: normalize frag_list usage
From: David Miller @ 2010-10-07  6:58 UTC (permalink / raw)
  To: alexander.h.duyck
  Cc: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan, netdev
In-Reply-To: <80769D7B14936844A23C0C43D9FBCF0F25B97A24B5@orsmsx501.amr.corp.intel.com>

From: "Duyck, Alexander H" <alexander.h.duyck@intel.com>
Date: Tue, 5 Oct 2010 15:45:32 -0700

> The patch below is kind of what I had in mind for a way to do RSC and maintain
> the pointer scheme you are looking for.  Consider this patch an RFC for now
> since I based this off of Jeff's internal testing tree and so it would need
> some modification to apply cleanly to net-next.

Can you really not remember the head somewhere?

What I wanted is for everyone to build their frag list SKBs from head to tail,
always.  So that I could, as I mentioned in my original posting, do something
like:

struct sk_buff {
	union {
		struct list_head list;
		struct {
			struct sk_buff	*frag_next;
			struct sk_buff	*frag_tail_tracker;
		};
	};
};

The ->frag_tail_tracker is only used in the head SKB to maintain where the
last SKB in the frag list is.

You're tracking the head from the inner SKBs, such that my intended
conventions are not being followed.

^ permalink raw reply

* Re: [PATCH] sysctl: fix min/max handling in __do_proc_doulongvec_minmax()
From: Américo Wang @ 2010-10-07  7:18 UTC (permalink / raw)
  To: Américo Wang
  Cc: Eric Dumazet, Robin Holt, Andrew Morton, linux-kernel,
	Willy Tarreau, David S. Miller, netdev, James Morris,
	Pekka Savola (ipv6), Patrick McHardy, Alexey Kuznetsov, ebiederm
In-Reply-To: <20101005130117.GK5170@cr0.nay.redhat.com>

On Tue, Oct 05, 2010 at 09:01:17PM +0800, Américo Wang wrote:
>On Mon, Oct 04, 2010 at 12:38:21PM +0200, Eric Dumazet wrote:
>>Le lundi 04 octobre 2010 à 18:35 +0800, Américo Wang a écrit :
>>
>>> Your patch does fix the problem, but seems not a good solution,
>>> we should skip all min/max checking if ->extra(1|2) is NULL,
>>> instead of checking it every time within the loop.
>>
>>Please do submit a patch, we'll see if you come to a better solution,
>>with no added code size (this is slow path, I dont care for checking it
>>'every time winthin the loop')
>>
>>
>
>I have one, but just did compile test. :)
>I will test it tomorrow.
>

Here is the final one.

--------------->

Eric D. noticed that we may trigger an OOPS if we leave ->extra{1,2}
to NULL when we use proc_doulongvec_minmax().

Actually, we don't need to store min/max values in a vector,
because all the elements in the vector should share the same min/max
value, like what proc_dointvec_minmax() does.

This also shrinks the binary size a little bit.

   text    data     bss     dec     hex filename
  12419    8744    4016   25179    625b kernel/sysctl.o.BEFORE
  12395    8744    4024   25163    624b kernel/sysctl.o.AFTER

Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Eric W. <ebiederm@xmission.com>
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>

---
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index f88552c..ba5e511 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2448,86 +2448,119 @@ int proc_dointvec_minmax(struct ctl_table *table, int write,
 				do_proc_dointvec_minmax_conv, &param);
 }
 
-static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, int write,
-				     void __user *buffer,
+static int __doulongvec_minmax_read(void *data, void __user *buffer,
 				     size_t *lenp, loff_t *ppos,
 				     unsigned long convmul,
 				     unsigned long convdiv)
 {
-	unsigned long *i, *min, *max;
-	int vleft, first = 1, err = 0;
-	unsigned long page = 0;
-	size_t left;
-	char *kbuf;
+	unsigned long *i = (unsigned long *) data;
+	int err = 0;
+	bool first = true;
+	size_t left = *lenp;
 
-	if (!data || !table->maxlen || !*lenp || (*ppos && !write)) {
-		*lenp = 0;
-		return 0;
+	for (; left; i++, first=false) {
+		unsigned long val;
+
+		val = convdiv * (*i) / convmul;
+		if (!first)
+			err = proc_put_char(&buffer, &left, '\t');
+		err = proc_put_long(&buffer, &left, val, false);
+		if (err)
+			break;
 	}
 
-	i = (unsigned long *) data;
-	min = (unsigned long *) table->extra1;
-	max = (unsigned long *) table->extra2;
-	vleft = table->maxlen / sizeof(unsigned long);
-	left = *lenp;
+	if (!first && left && !err)
+		err = proc_put_char(&buffer, &left, '\n');
 
-	if (write) {
-		if (left > PAGE_SIZE - 1)
-			left = PAGE_SIZE - 1;
-		page = __get_free_page(GFP_TEMPORARY);
-		kbuf = (char *) page;
-		if (!kbuf)
-			return -ENOMEM;
-		if (copy_from_user(kbuf, buffer, left)) {
-			err = -EFAULT;
-			goto free;
-		}
-		kbuf[left] = 0;
+	*lenp -= left;
+	*ppos += *lenp;
+	return err;
+}
+
+static int __doulongvec_minmax_write(void *data, void __user *buffer,
+				     size_t *lenp, loff_t *ppos, int vleft,
+				     unsigned long min, unsigned long max)
+{
+	char *kbuf;
+	size_t left = *lenp;
+	unsigned long page = 0;
+	unsigned long *i = (unsigned long *) data;
+	int err = 0;
+	bool first = true;
+
+	if (left > PAGE_SIZE - 1)
+		left = PAGE_SIZE - 1;
+	page = __get_free_page(GFP_TEMPORARY);
+	kbuf = (char *) page;
+	if (!kbuf)
+		return -ENOMEM;
+	if (copy_from_user(kbuf, buffer, left)) {
+		err = -EFAULT;
+		goto free;
 	}
+	kbuf[left] = 0;
 
-	for (; left && vleft--; i++, min++, max++, first=0) {
+	for (; left && vleft--; i++, first=false) {
 		unsigned long val;
+		bool neg;
 
-		if (write) {
-			bool neg;
-
-			left -= proc_skip_spaces(&kbuf);
+		left -= proc_skip_spaces(&kbuf);
 
-			err = proc_get_long(&kbuf, &left, &val, &neg,
-					     proc_wspace_sep,
-					     sizeof(proc_wspace_sep), NULL);
-			if (err)
-				break;
-			if (neg)
-				continue;
-			if ((min && val < *min) || (max && val > *max))
-				continue;
-			*i = val;
-		} else {
-			val = convdiv * (*i) / convmul;
-			if (!first)
-				err = proc_put_char(&buffer, &left, '\t');
-			err = proc_put_long(&buffer, &left, val, false);
-			if (err)
-				break;
-		}
+		err = proc_get_long(&kbuf, &left, &val, &neg,
+				     proc_wspace_sep,
+				     sizeof(proc_wspace_sep), NULL);
+		if (err)
+			break;
+		if (neg)
+			continue;
+		if (val < min || val > max)
+			continue;
+		*i = val;
 	}
 
-	if (!write && !first && left && !err)
-		err = proc_put_char(&buffer, &left, '\n');
-	if (write && !err)
+	if (!err)
 		left -= proc_skip_spaces(&kbuf);
 free:
-	if (write) {
-		free_page(page);
-		if (first)
-			return err ? : -EINVAL;
-	}
+	free_page(page);
+	if (first)
+		return err ? : -EINVAL;
+
 	*lenp -= left;
 	*ppos += *lenp;
 	return err;
 }
 
+static int __do_proc_doulongvec_minmax(void *data, struct ctl_table *table, int write,
+				     void __user *buffer,
+				     size_t *lenp, loff_t *ppos,
+				     unsigned long convmul,
+				     unsigned long convdiv)
+{
+	if (!data || !table->maxlen || !*lenp || (*ppos && !write)) {
+		*lenp = 0;
+		return 0;
+	}
+
+	if (write) {
+		unsigned long min, max;
+		int vleft;
+
+		vleft = table->maxlen / sizeof(unsigned long);
+		if (table->extra1)
+			min = *(unsigned long *) table->extra1;
+		else
+			min = 0;
+		if (table->extra2)
+			max = *(unsigned long *) table->extra2;
+		else
+			max = ULONG_MAX;
+		return __doulongvec_minmax_write(data, buffer, lenp,
+						  ppos, vleft, min, max);
+	} else
+		return __doulongvec_minmax_read(data, buffer, lenp,
+						 ppos, convmul, convdiv);
+}
+
 static int do_proc_doulongvec_minmax(struct ctl_table *table, int write,
 				     void __user *buffer,
 				     size_t *lenp, loff_t *ppos,

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox