Netdev List
 help / color / mirror / Atom feed
* Re: Bridge stays down until a port is added
From: Sven-Haegar Koch @ 2011-08-12 12:22 UTC (permalink / raw)
  To: Marc Haber; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20110811205429.GB21307@torres.zugschlus.de>

On Thu, 11 Aug 2011, Marc Haber wrote:

> On Thu, Aug 11, 2011 at 08:17:06AM -0700, Stephen Hemminger wrote:
> > On Thu, 11 Aug 2011 09:06:59 +0200
> > Marc Haber <mh+netdev@zugschlus.de> wrote:
> > > Is that a feature? If so, why does the interface stay pingable after
> > > removing the dummy0 interface from the bridge?
> > 
> > Yes, there are no links to send a packet so it seems logical
> > that there would be no carrier.
> 
> Yes, but if I can configure an IP address to the bridge I would expect
> it to be reachable even if there are no interfaces in the bridge.
> "Older" kernels used to behave like that.

For me (using kernel 3.0.0) it seems to work as I expect it:

aurora:~# brctl addbr br0
aurora:~# ifconfig br0 192.168.254.1 netmask 255.255.255.0 up
aurora:~# ping 192.168.254.1
PING 192.168.254.1 (192.168.254.1) 56(84) bytes of data.
64 bytes from 192.168.254.1: icmp_req=1 ttl=64 time=0.087 ms

aurora:~# ifconfig br0
br0       Link encap:Ethernet  HWaddr 96:e1:ba:9f:91:f9  
          inet addr:192.168.254.1  Bcast:192.168.254.255  Mask:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

The br0 interface has no carrier / is not "running", exactly like an 
ethernet port without a cable.

c'ya
sven-haegar

-- 
Three may keep a secret, if two of them are dead.
- Ben F.

^ permalink raw reply

* Re: [PATCH] Fix RCU warning in rt_cache_seq_show
From: Paul E. McKenney @ 2011-08-12 12:49 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Mark Rutland, netdev, David S. Miller, Gergely Kalman
In-Reply-To: <1313133830.2669.34.camel@edumazet-laptop>

On Fri, Aug 12, 2011 at 09:23:50AM +0200, Eric Dumazet wrote:
> Le jeudi 11 août 2011 à 19:32 -0700, Paul E. McKenney a écrit :
> > On Thu, Aug 11, 2011 at 06:58:21PM +0200, Eric Dumazet wrote:
> > > Le mercredi 10 août 2011 à 10:28 +0100, Mark Rutland a écrit :
> > > > > -----Original Message-----
> > > > > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > > > > Sent: 09 August 2011 18:19
> > > > > To: Mark Rutland; Paul E. McKenney
> > > > > Cc: netdev@vger.kernel.org; David S. Miller; Gergely Kalman
> > > > > Subject: Re: [PATCH] Fix RCU warning in rt_cache_seq_show
> > > > > 
> > > > > Le mardi 09 août 2011 à 18:02 +0100, Mark Rutland a écrit :
> > > > > > Commit f2c31e32 ("net: fix NULL dereferences in check_peer_redir()")
> > > > > > added rcu protection to dst neighbour, and updated callsites for
> > > > > > dst_{get,set}_neighbour. Unfortunately, it missed rt_cache_seq_show.
> > > > > >
> > > > > > This produces a warning on v3.1-rc1 (on a preemptible kernel, on an
> > > > > > ARM Vexpress A9x4):
> > > > > >
> > > > > > ===================================================
> > > > > > [ INFO: suspicious rcu_dereference_check() usage. ]
> > > > > > ---------------------------------------------------
> > > > > > include/net/dst.h:91 invoked rcu_dereference_check() without
> > > > > protection!
> > > > > >
> > > > > > other info that might help us debug this:
> > > > > >
> > > > > > rcu_scheduler_active = 1, debug_locks = 0
> > > > > > 2 locks held by proc01/32159:
> > > > > >
> > > > > > stack backtrace:
> > > > > > [<80014880>] (unwind_backtrace+0x0/0xf8) from [<802e5c78>]
> > > > > (rt_cache_seq_show+0x18c/0x1c4)
> > > > > > [<802e5c78>] (rt_cache_seq_show+0x18c/0x1c4) from [<800e0c5c>]
> > > > > (seq_read+0x324/0x4a4)
> > > > > > [<800e0c5c>] (seq_read+0x324/0x4a4) from [<8010786c>]
> > > > > (proc_reg_read+0x70/0x94)
> > > > > > [<8010786c>] (proc_reg_read+0x70/0x94) from [<800c0ba8>]
> > > > > (vfs_read+0xb0/0x144)
> > > > > > [<800c0ba8>] (vfs_read+0xb0/0x144) from [<800c0ea8>]
> > > > > (sys_read+0x40/0x70)
> > > > > > [<800c0ea8>] (sys_read+0x40/0x70) from [<8000e0c0>]
> > > > > (ret_fast_syscall+0x0/0x3c)
> > > > > >
> > > > > > This patch adds calls to rcu_read_{lock,unlock} in rt_cache_seq_show,
> > > > > > protecting the dereferenced variable, and clearing the warning.
> > > > > >
> > > > > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > > > > Cc: David S. Miller <davem@davemloft.net>
> > > > > > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > > > > > Cc: Gergely Kalman <synapse@hippy.csoma.elte.hu>
> > > > > > ---
> > > > > >  net/ipv4/route.c |    2 ++
> > > > > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > > > >
> > > > > > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > > > > > index e3dec1c..6699ef7 100644
> > > > > > --- a/net/ipv4/route.c
> > > > > > +++ b/net/ipv4/route.c
> > > > > > @@ -419,6 +419,7 @@ static int rt_cache_seq_show(struct seq_file
> > > > > *seq, void *v)
> > > > > >  		struct neighbour *n;
> > > > > >  		int len;
> > > > > >
> > > > > > +		rcu_read_lock();
> > > > > >  		n = dst_get_neighbour(&r->dst);
> > > > > >  		seq_printf(seq, "%s\t%08X\t%08X\t%8X\t%d\t%u\t%d\t"
> > > > > >  			      "%08X\t%d\t%u\t%u\t%02X\t%d\t%1d\t%08X%n",
> > > > > > @@ -435,6 +436,7 @@ static int rt_cache_seq_show(struct seq_file
> > > > > *seq, void *v)
> > > > > >  			-1,
> > > > > >  			(n && (n->nud_state & NUD_CONNECTED)) ? 1 : 0,
> > > > > >  			r->rt_spec_dst, &len);
> > > > > > +		rcu_read_unlock();
> > > > > >
> > > > > >  		seq_printf(seq, "%*s\n", 127 - len, "");
> > > > > >  	}
> > > > > 
> > > > > 
> > > > > Hmm, I though rcu_read_lock_bh() (done by caller of this function) was
> > > > > protecting us here.
> > > > 
> > > > Aha. Being a bit trigger-happy, I'd had a quick look at the functions
> > > > mentioned in the backtrace, and not looked at any possible inlining.
> > > > 
> > > > This being my first real exposure to RCU, I wasn't aware of the *_bh
> > > > variants. Looking at the documentation (Documentation/RCU/checklist.txt),
> > > > I think the real problem is that we should be using rcu_dereference_bh in
> > > > this case:
> > > > 
> > > >   > read-side critical sections are delimited by rcu_read_lock()
> > > >   > and rcu_read_unlock(), or by similar primitives such as
> > > >   > rcu_read_lock_bh() and rcu_read_unlock_bh(), in which case
> > > >   > the matching rcu_dereference() primitive must be used in order
> > > >   > to keep lockdep happy, in this case, rcu_dereference_bh().
> > > 
> > > Hmm.
> > > 
> > > I do think dst_get_neighbour() should use rcu_dereference(), because
> > > dst->_neighbour are freed by call_rcu().
> > > 
> > > The question is : Is following construct [A] safe or not ?
> > > 
> > > {
> > > rcu_read_lock_bh();
> > > 	/* BH are now disabled, and we are not allowed to sleep */
> > > 	...
> > > 
> > > 	ptr = rcu_dereference();
> > 
> > This should be:
> > 
> > 	ptr = rcu_dereference_bh();
> > 
> > As you say below.  Never mind!  ;-)
> > 
> > > 	...
> > > rcu_read_unlock_bh();
> > > }
> > > 
> > > 
> > > I dont really understand why lockdep wants [B] instead :
> > > 
> > > {
> > > rcu_read_lock_bh();
> > > 	...
> > > 
> > > 	{
> > > 	rcu_read_lock();
> > > 	ptr = rcu_dereference();
> > 
> > Here you are protected by both RCU and RCU-bh, so you should be able
> > to use either rcu_dereference() or rcu_dereference_bh().  A bit
> > strange to use rcu_dereference_bh(), though.  Except perhaps if a
> > pointer to a function was passed in from the outer RCU-bh read-side
> > critical section or something.
> > 
> > > 	rcu_read_unlock();
> > > 	}
> > > 	...
> > > rcu_read_unlock_bh();
> > > }
> > > 
> > > 
> > > 
> > > However, I can understand the other way [C], this is really needed :
> > > 
> > > {
> > > rcu_read_lock();
> > > 	...
> > > 
> > > 	{
> > > 	rcu_read_lock_bh();
> > > 	ptr = rcu_dereference_bh();
> > > 	rcu_read_unlock_bh();
> > > 	}
> > > 	...
> > > rcu_read_unlock();
> > > }
> > > 
> > > I believe [A] should be allowed by lockdep.
> > 
> > OK, I'll bite.  Why?
> > 
> 
> Oh well, I assumed local_bh_disable() disables preemption.
> 
> It does since day-0
> add_preempt_count(SOFTIRQ_DISABLE_OFFSET);
> 
> So following should be safe :
> 
> local_bh_disable();
> {
> ptr = rcu_dereference(...);
> use(ptr);
> }
> local_bh_enable();
> 
> Maybe they are longterm plans to break this assumption, I dont know.

It would be safe for TINY_RCU and TREE_RCU, but not for either
TINY_PREEMPT_RCU or TREE_PREEMPT_RCU.  These last two do not
recognize a preempt-disable region as an RCU read-side critical
section.

						Thanx, Paul

^ permalink raw reply

* Re: [net-next RFC PATCH 4/7] tuntap: multiqueue support
From: Eric Dumazet @ 2011-08-12 14:29 UTC (permalink / raw)
  To: Jason Wang
  Cc: krkumar2, kvm, mst, qemu-devel, netdev, rusty, linux-kernel,
	virtualization, mirq-linux, davem
In-Reply-To: <20110812015520.31613.99890.stgit@intel-e5620-16-2.englab.nay.redhat.com>

Le vendredi 12 août 2011 à 09:55 +0800, Jason Wang a écrit :

>+       rxq = skb_get_rxhash(skb);
>+       if (rxq) {
>+               tfile = rcu_dereference(tun->tfiles[rxq % numqueues]);
>+               if (tfile)
>+                       goto out;
>+       }

You can avoid an expensive divide with following trick :

u32 idx = ((u64)rxq * numqueues) >> 32;



> -static struct tun_struct *tun_get(struct file *file)
> +static void tun_detach_all(struct net_device *dev)
>  {
> -	return __tun_get(file->private_data);
> +	struct tun_struct *tun = netdev_priv(dev);
> +	struct tun_file *tfile, *tfile_list[MAX_TAP_QUEUES];
> +	int i, j = 0;
> +
> +	spin_lock(&tun_lock);
> +
> +	for (i = 0; i < MAX_TAP_QUEUES && tun->numqueues; i++) {
> +		tfile = rcu_dereference_protected(tun->tfiles[i],
> +						lockdep_is_held(&tun_lock));
> +		if (tfile) {
> +			wake_up_all(&tfile->wq.wait);
> +			tfile_list[i++] = tfile;

	typo here, you want tfile_list[j++] = tfile;

> +			rcu_assign_pointer(tun->tfiles[i], NULL);
> +			rcu_assign_pointer(tfile->tun, NULL);
> +			--tun->numqueues;
> +		}
> +	}
> +	BUG_ON(tun->numqueues != 0);
> +	spin_unlock(&tun_lock);
> +
> +	synchronize_rcu();
> +	for(--j; j >= 0; j--)
> +		sock_put(&tfile_list[j]->sk);
>  }
>  

Could you take a look at net/packet/af_packet.c, to check how David did
the whole fanout thing ?

__fanout_unlink() 

Trick is to not leave NULL entries in the tun->tfiles[] array.

It makes things easier in hot path.

^ permalink raw reply

* [PATCH] bnx2x: suppress repeated error messages about Max BW
From: Michal Schmidt @ 2011-08-12 14:33 UTC (permalink / raw)
  To: netdev; +Cc: dmitry, vladz

When a VN is configured with invalid Max BW, the error does not have to
be logged repeatedly and fill the logs.
Warn only once when the bad configuration is detected on boot, or when
the configuration changes dynamically from good to bad.

Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
---

 drivers/net/ethernet/broadcom/bnx2x/bnx2x.h      |    1 +
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c  |    5 ++---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h  |   21 +++++++++++----------
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c |    2 +-
 4 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
index c423504..648e165 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
@@ -1220,6 +1220,7 @@ struct bnx2x {
 	struct cmng_struct_per_port cmng;
 	u32			vn_weight_sum;
 	u32			mf_config[E1HVN_MAX];
+	bool			prev_max_cfg_invalid[E1HVN_MAX];
 	u32			mf2_config[E2_FUNC_MAX];
 	u32			path_has_ovlan; /* E3 */
 	u16			mf_ov;
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index d724a18..a5216a9 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -841,8 +841,7 @@ u16 bnx2x_get_mf_speed(struct bnx2x *bp)
 {
 	u16 line_speed = bp->link_vars.line_speed;
 	if (IS_MF(bp)) {
-		u16 maxCfg = bnx2x_extract_max_cfg(bp,
-						   bp->mf_config[BP_VN(bp)]);
+		u16 maxCfg = bnx2x_extract_max_cfg(bp, BP_VN(bp));
 
 		/* Calculate the current MAX line speed limit for the MF
 		 * devices
@@ -1153,7 +1152,7 @@ void bnx2x_update_max_mf_config(struct bnx2x *bp, u32 value)
 	/* load old values */
 	u32 mf_cfg = bp->mf_config[BP_VN(bp)];
 
-	if (value != bnx2x_extract_max_cfg(bp, mf_cfg)) {
+	if (value != bnx2x_extract_max_cfg(bp, BP_VN(bp))) {
 		/* leave all but MAX value */
 		mf_cfg &= ~FUNC_MF_CFG_MAX_BW_MASK;
 
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
index 223bfee..6e75c42 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.h
@@ -1473,19 +1473,20 @@ void bnx2x_release_phy_lock(struct bnx2x *bp);
  * bnx2x_extract_max_cfg - extract MAX BW part from MF configuration.
  *
  * @bp:		driver handle
- * @mf_cfg:	MF configuration
+ * @vn:		vnic index
  *
  */
-static inline u16 bnx2x_extract_max_cfg(struct bnx2x *bp, u32 mf_cfg)
+static inline u16 bnx2x_extract_max_cfg(struct bnx2x *bp, int vn)
 {
-	u16 max_cfg = (mf_cfg & FUNC_MF_CFG_MAX_BW_MASK) >>
-			      FUNC_MF_CFG_MAX_BW_SHIFT;
-	if (!max_cfg) {
-		BNX2X_ERR("Illegal configuration detected for Max BW - "
-			  "using 100 instead\n");
-		max_cfg = 100;
-	}
-	return max_cfg;
+	u16 max_cfg = (bp->mf_config[vn] & FUNC_MF_CFG_MAX_BW_MASK) >>
+					 FUNC_MF_CFG_MAX_BW_SHIFT;
+
+	if (!max_cfg && !bp->prev_max_cfg_invalid[vn])
+		BNX2X_ERR("Illegal configuration detected for Max BW "
+			  "on vn %d - using 100 instead\n", vn);
+	bp->prev_max_cfg_invalid[vn] = !max_cfg;
+
+	return max_cfg ?: 100;
 }
 
 #endif /* BNX2X_CMN_H */
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 1507091..a952f84 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -2335,7 +2335,7 @@ static void bnx2x_init_vn_minmax(struct bnx2x *bp, int vn)
 		vn_max_rate = 0;
 
 	} else {
-		u32 maxCfg = bnx2x_extract_max_cfg(bp, vn_cfg);
+		u32 maxCfg = bnx2x_extract_max_cfg(bp, vn);
 
 		vn_min_rate = ((vn_cfg & FUNC_MF_CFG_MIN_BW_MASK) >>
 				FUNC_MF_CFG_MIN_BW_SHIFT) * 100;


^ permalink raw reply related

* Re: [PATCH v4] usbnet/cdc_ncm: Don't use stack variables for DMA
From: Josh Boyer @ 2011-08-12 15:07 UTC (permalink / raw)
  To: Oliver Neukum, Alexey ORISHKO; +Cc: gregkh, linux-usb, linux-kernel, netdev
In-Reply-To: <20110808123406.GA2526@zod.bos.redhat.com>

On Mon, Aug 08, 2011 at 08:34:06AM -0400, Josh Boyer wrote:
> The cdc_ncm driver still has a few places where stack variables are
> passed to the cdc_ncm_do_request function.  This triggers a stack trace in
> lib/dma-debug.c if the CONFIG_DEBUG_DMA_API option is set.
> 
> Adjust these calls to pass parameters that have been allocated with
> kzalloc.
> 
> Signed-off-by: Josh Boyer <jwboyer@redhat.com>
> ---
> v4: Rebase against 3.1-rc1
> v3: Fix checkpatch errors
> v2: Fix leak in error path
> 
>  drivers/net/usb/cdc_ncm.c |   47 ++++++++++++++++++++++++++++++++++++--------
>  1 files changed, 38 insertions(+), 9 deletions(-)

Just curious, but which tree would this be pulled into?  usb or net or?

josh

^ permalink raw reply

* TCP port firewall incl. description and english variable names
From: Tonda @ 2011-08-12 15:10 UTC (permalink / raw)
  To: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
  Cc: Antoine Steinhauser

Module that is used to open, close or filter specified TCP port by sending certain sequence of UDP packets to predefined UDP ports (password-like firewall). One sequence of UDP ports is the opening key and sending packets successively to them opens the TCP port and the second sequence of UDP ports is the closing key and sending packets successively to them closes the TCP port. If between two UDP packets in the sequence comes more than 16 another UDP packets, the sequence (either opening or closing) is aborted. The configuration and view of affected TCP port, opening and closing key and other firewall parameters is made throw use of sysfs.

Signed-off-by: Antoine Steinhauser <as@strmilov.cz>

diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -624,3 +624,7 @@
 	  on the Internet.
 
 	  If unsure, say N.
+
+config TCPFIREWALL
+	tristate "TCP Firewall controlled by UDP queries"
+	depends on m
diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
--- a/net/ipv4/Makefile
+++ b/net/ipv4/Makefile
@@ -51,3 +51,4 @@
 
 obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
 		      xfrm4_output.o
+obj-$(CONFIG_TCPFIREWALL) += tcpfirewall/
diff --git a/net/ipv4/tcpfirewall/Makefile b/net/ipv4/tcpfirewall/Makefile
--- a/net/ipv4/tcpfirewall/Makefile
+++ b/net/ipv4/tcpfirewall/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_TCPFIREWALL) += tcpfirewall.o
diff --git a/net/ipv4/tcpfirewall/tcpfirewall.c b/net/ipv4/tcpfirewall/tcpfirewall.c
--- a/net/ipv4/tcpfirewall/tcpfirewall.c
+++ b/net/ipv4/tcpfirewall/tcpfirewall.c
@@ -0,0 +1,451 @@
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/skbuff.h>
+#include <linux/in.h>
+#include <linux/if_packet.h>
+#include <linux/tcp.h>
+#include <linux/udp.h>
+#include <net/tcp.h>
+#include <net/udp.h>
+
+struct net_protocol {
+	int (*handler)(struct sk_buff *skb);
+	void (*err_handler)(struct sk_buff *skb, u32 info);
+	int (*gso_send_check)(struct sk_buff *skb);
+	struct sk_buff *(*gso_segment)(struct sk_buff *skb,
+		u32 features);
+	struct sk_buff **(*gro_receive)(struct sk_buff **head,
+		struct sk_buff *skb);
+	int (*gro_complete)(struct sk_buff *skb);
+	unsigned int no_policy:1,
+		netns_ok:1;
+};
+
+MODULE_LICENSE("GPL");
+
+static unsigned long inet_protos = 0x01234567;
+
+struct net_protocol **_inet_protos;
+
+module_param(inet_protos, ulong, 0);
+
+static int *openkeys;
+static int *closekeys;
+
+static int openkeyscount;
+static int closekeyscount;
+static int fastate;
+static int packetcounter;
+static int tcpport;
+static int open;
+static int firewall;
+
+int (*tcpv4recv) (struct sk_buff *skb);
+int (*udprecv) (struct sk_buff *skb);
+
+int udpcontroller(struct sk_buff *skb)
+{
+	const struct udphdr *uh;
+
+	if (skb->pkt_type != PACKET_HOST) {
+		kfree_skb(skb);
+		return 0;
+	}
+
+	if (!pskb_may_pull(skb, sizeof(struct tcphdr))) {
+		kfree_skb(skb);
+		return 0;
+	}
+
+	uh = udp_hdr(skb);
+
+	if (openkeyscount == 0)
+		return udprecv(skb);
+
+	if (!open) {
+		if (uh->dest == openkeys[fastate]) {
+			++fastate;
+			packetcounter = 0;
+
+			if (fastate == openkeyscount) {
+				open = 1;
+				fastate = 0;
+			}
+		} else {
+			if (packetcounter <= 16) {
+				++packetcounter;
+				if (packetcounter > 16)
+					fastate = 0;
+			}
+		}
+	} else {
+		if (uh->dest == closekeys[fastate]) {
+			++fastate;
+			packetcounter = 0;
+
+			if (fastate == closekeyscount) {
+				open = 0;
+				fastate = 0;
+			}
+		} else {
+			if (packetcounter <= 16) {
+				++packetcounter;
+				if (packetcounter > 16)
+					fastate = 0;
+			}
+		}
+	}
+
+
+	return udprecv(skb);
+}
+
+int tcpfirewall(struct sk_buff *skb)
+{
+	const struct tcphdr *th;
+
+	if (skb->pkt_type != PACKET_HOST) {
+		kfree_skb(skb);
+		return 0;
+	}
+
+	if (!pskb_may_pull(skb, sizeof(struct tcphdr))) {
+		kfree_skb(skb);
+		return 0;
+	}
+
+	th = tcp_hdr(skb);
+
+	if (th->dest == tcpport) {
+		if (firewall == 1 && !open) {
+			/*tcpv4sendreset(NULL, skb);*/
+			kfree_skb(skb);
+			return 0;
+		}
+	}
+
+	return tcpv4recv(skb);
+}
+
+static struct net_protocol *backuptcp;
+static struct net_protocol *backupudp;
+static struct net_protocol mytcp;
+static struct net_protocol myudp;
+
+static ssize_t show(struct kobject *kobj, struct attribute *attr, char *buffer)
+{
+	if (!strcmp(attr->name, "firewall")) {
+		if (firewall)
+			buffer[0] = '1';
+		else
+			buffer[0] = '0';
+
+		buffer[1] = '\n';
+		return 2;
+	}
+
+	if (!strcmp(attr->name, "tcpport")) {
+		sprintf(buffer, "%d\n", ntohs(tcpport));
+		return strlen(buffer)+1;
+	}
+
+	if (!strcmp(attr->name, "openers")) {
+		int i;
+		char *znak;
+		if (openkeyscount == 0)
+			return 0;
+		buffer[0] = '\0';
+		znak = kmalloc(10, GFP_KERNEL);
+		for (i = 0; i < openkeyscount; ++i) {
+			sprintf(znak, "%d ", ntohs(openkeys[i]));
+			strcat(buffer, znak);
+		}
+		kfree(znak);
+		buffer[strlen(buffer)-1] = '\n';
+		return strlen(buffer);
+	}
+
+	if (!strcmp(attr->name, "closers")) {
+		int i;
+		char *znak;
+		if (closekeyscount == 0)
+			return 0;
+		buffer[0] = '\0';
+		znak = kmalloc(10, GFP_KERNEL);
+		for (i = 0; i < closekeyscount; ++i) {
+			sprintf(znak, "%d ", ntohs(closekeys[i]));
+			strcat(buffer, znak);
+		}
+		kfree(znak);
+		buffer[strlen(buffer)-1] = '\n';
+		return strlen(buffer);
+	}
+
+	if (!strcmp(attr->name, "open")) {
+		if (open)
+			buffer[0] = '1';
+		else
+			buffer[0] = '0';
+
+		buffer[1] = '\n';
+		return 2;
+	}
+
+	if (!strcmp(attr->name, "state")) {
+		sprintf(buffer, "%d\n", fastate);
+		return strlen(buffer)+1;
+	}
+
+	if (!strcmp(attr->name, "counter")) {
+		sprintf(buffer, "%d\n", packetcounter);
+		return strlen(buffer)+1;
+	}
+
+	return 0;
+}
+
+static ssize_t store(struct kobject *kobj, struct attribute *attr,
+	const char *buffer, size_t size)
+{
+	int i;
+	char *cislo;
+	if (!strcmp(attr->name, "firewall")) {
+		if (size > 0 && buffer[0] == '1')
+			firewall = 1;
+		else
+			firewall = 0;
+		fastate = 0;
+		return size;
+	}
+
+	if (!strcmp(attr->name, "tcpport")) {
+		cislo = kmalloc(size+1, GFP_KERNEL);
+		for (i = 0; i < size; ++i)
+			cislo[i] = buffer[i];
+		cislo[size] = '\0';
+		if (kstrtoint(cislo, 10, &i) < 0)
+			i = -1;
+		if (i > 0 && i < 65536)
+			tcpport = htons(i);
+		kfree(cislo);
+		fastate = 0;
+		return size;
+	}
+
+	if (!strcmp(attr->name, "openers")) {
+		int udpport, i;
+		int *noveopenkeys;
+		int *stareopenkeys;
+		cislo = kmalloc(size+1, GFP_KERNEL);
+		for (i = 0; i < size; ++i)
+			cislo[i] = buffer[i];
+		cislo[size] = '\0';
+
+		if (!strcmp(cislo, "reset") || !strcmp(cislo, "reset\n")) {
+			if (openkeyscount)
+				kfree(openkeys);
+			openkeyscount = 0;
+		}
+
+		if (kstrtoint(cislo, 10, &i) < 0)
+			i = -1;
+		kfree(cislo);
+
+		if (i > 0 && i < 65536 && (openkeyscount == 0 ||
+			openkeys[openkeyscount-1] != i))
+				udpport = htons(i);
+		else
+			return size;
+
+		if (openkeyscount < 10) {
+			noveopenkeys = kmalloc((openkeyscount+1)*sizeof(int),
+				GFP_KERNEL);
+
+			for (i = 0; i < openkeyscount; ++i)
+				noveopenkeys[i] = openkeys[i];
+
+			noveopenkeys[openkeyscount] = udpport;
+			stareopenkeys = openkeys;
+			openkeys = noveopenkeys;
+			if (openkeyscount)
+				kfree(stareopenkeys);
+
+			++openkeyscount;
+		}
+		fastate = 0;
+		return size;
+	}
+
+	if (!strcmp(attr->name, "closers")) {
+		int udpport, i;
+		int *noveclosekeys;
+		int *stareclosekeys;
+		cislo = kmalloc(size+1, GFP_KERNEL);
+		for (i = 0; i < size; ++i)
+			cislo[i] = buffer[i];
+		cislo[size] = '\0';
+
+		if (!strcmp(cislo, "reset") || !strcmp(cislo, "reset\n")) {
+			if (closekeyscount)
+				kfree(closekeys);
+			closekeyscount = 0;
+		}
+
+		if (kstrtoint(cislo, 10, &i) < 0)
+			i = -1;
+		kfree(cislo);
+
+		if (i > 0 && i < 65536 && (closekeyscount == 0 ||
+			closekeys[closekeyscount-1] != i))
+				udpport = htons(i);
+		else
+			return size;
+
+		if (closekeyscount < 10) {
+			noveclosekeys = kmalloc((closekeyscount+1)*sizeof(int),
+				GFP_KERNEL);
+
+			for (i = 0; i < closekeyscount; ++i)
+				noveclosekeys[i] = closekeys[i];
+
+			noveclosekeys[closekeyscount] = udpport;
+			stareclosekeys = closekeys;
+			closekeys = noveclosekeys;
+			if (closekeyscount)
+				kfree(stareclosekeys);
+
+			++closekeyscount;
+		}
+		fastate = 0;
+		return size;
+	}
+
+	if (!strcmp(attr->name, "open")) {
+		if (size > 0 && buffer[0] == '1')
+			open = 1;
+		else
+			open = 0;
+
+		fastate = 0;
+		return size;
+	}
+
+	return 0;
+}
+
+static const struct sysfs_ops so = {
+	.show = show,
+	.store = store,
+};
+
+static struct kobj_type khid = {
+	.sysfs_ops = &so,
+};
+
+static struct kobject kobj;
+
+static const struct attribute fw = {
+	.name = "firewall",
+	.mode = S_IRWXU,
+};
+
+static const struct attribute opn = {
+	.name = "open",
+	.mode = S_IRWXU,
+};
+
+static const struct attribute tcpp = {
+	.name = "tcpport",
+	.mode = S_IRWXU,
+};
+
+static const struct attribute openers = {
+	.name = "openers",
+	.mode = S_IRWXU,
+};
+
+static const struct attribute closers = {
+	.name = "closers",
+	.mode = S_IRWXU,
+};
+
+static const struct attribute stat = {
+	.name = "state",
+	.mode = S_IRUSR,
+};
+
+static const struct attribute counte = {
+	.name = "counter",
+	.mode = S_IRUSR,
+};
+
+static int __init start(void)
+{
+	if (inet_protos == 0x01234567) {
+		printk(KERN_WARNING "inet_protos parameter was not");
+		printk(KERN_WARNING " specified!\nread its value from");
+		printk(KERN_WARNING " System_map file file, and insert");
+		printk(KERN_WARNING " the module again!\n");
+		return -1;
+	}
+
+	openkeyscount = 0;
+	closekeyscount = 0;
+	fastate = -1;
+	packetcounter = 0;
+	tcpport = 0;
+	open = 1;
+	firewall = 0;
+
+	memset(&kobj, 0, sizeof(struct kobject));
+
+	_inet_protos = (struct net_protocol **)inet_protos;
+
+	kobject_init(&kobj, &khid);
+	if (kobject_add(&kobj, NULL, "tcpfirewall") < 0)
+		printk(KERN_ERR "kobject_add failed");
+
+	if (sysfs_create_file(&kobj, &fw) < 0)
+		printk(KERN_ERR "sysfs_create_file failed");
+	if (sysfs_create_file(&kobj, &opn) < 0)
+		printk(KERN_ERR "sysfs_create_file failed");
+	if (sysfs_create_file(&kobj, &tcpp) < 0)
+		printk(KERN_ERR "sysfs_create_file failed");
+	if (sysfs_create_file(&kobj, &openers) < 0)
+		printk(KERN_ERR "sysfs_create_file failed");
+	if (sysfs_create_file(&kobj, &closers) < 0)
+		printk(KERN_ERR "sysfs_create_file failed");
+	if (sysfs_create_file(&kobj, &stat) < 0)
+		printk(KERN_ERR "sysfs_create_file failed");
+	if (sysfs_create_file(&kobj, &counte) < 0)
+		printk(KERN_ERR "sysfs_create_file failed");
+
+	backuptcp = _inet_protos[IPPROTO_TCP];
+	backupudp = _inet_protos[IPPROTO_UDP];
+	mytcp = *backuptcp;
+	myudp = *backupudp;
+	tcpv4recv = mytcp.handler;
+	udprecv = myudp.handler;
+	mytcp.handler = tcpfirewall;
+	myudp.handler = udpcontroller;
+	_inet_protos[IPPROTO_TCP] = &mytcp;
+	_inet_protos[IPPROTO_UDP] = &myudp;
+	return 0;
+}
+
+static void konec(void)
+{
+	_inet_protos[IPPROTO_TCP] = backuptcp;
+	_inet_protos[IPPROTO_UDP] = backupudp;
+
+	if (openkeyscount)
+		kfree(openkeys);
+	if (closekeyscount)
+		kfree(closekeys);
+
+	kobject_del(&kobj);
+}
+
+module_init(start);
+module_exit(konec);

^ permalink raw reply

* Re: [PATCH v4] usbnet/cdc_ncm: Don't use stack variables for DMA
From: David Miller @ 2011-08-12 15:11 UTC (permalink / raw)
  To: jwboyer; +Cc: oliver, alexey.orishko, gregkh, linux-usb, linux-kernel, netdev
In-Reply-To: <20110812150715.GD3014@zod.bos.redhat.com>

From: Josh Boyer <jwboyer@redhat.com>
Date: Fri, 12 Aug 2011 11:07:16 -0400

> On Mon, Aug 08, 2011 at 08:34:06AM -0400, Josh Boyer wrote:
>> The cdc_ncm driver still has a few places where stack variables are
>> passed to the cdc_ncm_do_request function.  This triggers a stack trace in
>> lib/dma-debug.c if the CONFIG_DEBUG_DMA_API option is set.
>> 
>> Adjust these calls to pass parameters that have been allocated with
>> kzalloc.
>> 
>> Signed-off-by: Josh Boyer <jwboyer@redhat.com>
>> ---
>> v4: Rebase against 3.1-rc1
>> v3: Fix checkpatch errors
>> v2: Fix leak in error path
>> 
>>  drivers/net/usb/cdc_ncm.c |   47 ++++++++++++++++++++++++++++++++++++--------
>>  1 files changed, 38 insertions(+), 9 deletions(-)
> 
> Just curious, but which tree would this be pulled into?  usb or net or?

Probably net.

^ permalink raw reply

* Re: TCP port firewall incl. description and english variable names
From: Randy Dunlap @ 2011-08-12 15:13 UTC (permalink / raw)
  To: Tonda; +Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1313161843-18226-1-git-send-email-as@strmilov.cz>

On Fri, 12 Aug 2011 17:10:43 +0200 Tonda wrote:

> Module that is used to open, close or filter specified TCP port by sending certain sequence of UDP packets to predefined UDP ports (password-like firewall). One sequence of UDP ports is the opening key and sending packets successively to them opens the TCP port and the second sequence of UDP ports is the closing key and sending packets successively to them closes the TCP port. If between two UDP packets in the sequence comes more than 16 another UDP packets, the sequence (either opening or closing) is aborted. The configuration and view of affected TCP port, opening and closing key and other firewall parameters is made throw use of sysfs.

> Signed-off-by: Antoine Steinhauser <as@strmilov.cz>
> 
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -624,3 +624,7 @@
>  	  on the Internet.
>  
>  	  If unsure, say N.
> +
> +config TCPFIREWALL
> +	tristate "TCP Firewall controlled by UDP queries"
> +	depends on m

I have the same comments as yesterday, which for some reason were
unanswered.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

^ permalink raw reply

* Re: TCP port firewall incl. description and english variable names
From: Eric Dumazet @ 2011-08-12 15:34 UTC (permalink / raw)
  To: Tonda; +Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1313161843-18226-1-git-send-email-as@strmilov.cz>

Le vendredi 12 août 2011 à 17:10 +0200, Tonda a écrit :
> Module that is used to open, close or filter specified TCP port by
> sending certain sequence of UDP packets to predefined UDP ports
> (password-like firewall). One sequence of UDP ports is the opening key
> and sending packets successively to them opens the TCP port and the
> second sequence of UDP ports is the closing key and sending packets
> successively to them closes the TCP port. If between two UDP packets
> in the sequence comes more than 16 another UDP packets, the sequence
> (either opening or closing) is aborted. The configuration and view of
> affected TCP port, opening and closing key and other firewall
> parameters is made throw use of sysfs.
> 
> Signed-off-by: Antoine Steinhauser <as@strmilov.cz>

Antoine

There is no chance this can be added in official linux kernel, its
really too ugly, and can be implemented using standard iptables rules,
and userland controller, adding encryption and other high level stuff if
needed.




^ permalink raw reply

* Re: TCP port firewall controlled by UDP packets
From: Antonin Steinhauser @ 2011-08-12 15:35 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <20110811171317.271be88b.rdunlap@xenotime.net>

Dne 12.8.2011 02:13, Randy Dunlap napsal(a):
> On Fri, 12 Aug 2011 01:56:09 +0200 Tonda wrote:
>
> Need more patch description&  justification here, as well as
> Signed-off-by:<your name&  email address>
>
>
>    
>> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
>> --- a/net/ipv4/Kconfig
>> +++ b/net/ipv4/Kconfig
>> @@ -624,3 +624,7 @@
>>   	  on the Internet.
>>
>>   	  If unsure, say N.
>> +
>> +config TCPFIREWALL
>> +	tristate "TCP Firewall controlled by UDP queries"
>> +	depends on m
>>      
> Why buildable only as a loadable module?
>
>    
Because it needs parameter - address of inet_protos table from 
/boot/System_map
>    
>> diff --git a/net/ipv4/Makefile b/net/ipv4/Makefile
>> --- a/net/ipv4/Makefile
>> +++ b/net/ipv4/Makefile
>> @@ -51,3 +51,4 @@
>>
>>   obj-$(CONFIG_XFRM) += xfrm4_policy.o xfrm4_state.o xfrm4_input.o \
>>   		      xfrm4_output.o
>> +obj-$(CONFIG_TCPFIREWALL) += tcpfirewall/
>> diff --git a/net/ipv4/tcpfirewall/Makefile b/net/ipv4/tcpfirewall/Makefile
>> --- a/net/ipv4/tcpfirewall/Makefile
>> +++ b/net/ipv4/tcpfirewall/Makefile
>> @@ -0,0 +1 @@
>> +obj-$(CONFIG_TCPFIREWALL) += tcpfirewall.o
>> diff --git a/net/ipv4/tcpfirewall/tcpfirewall.c b/net/ipv4/tcpfirewall/tcpfirewall.c
>> --- a/net/ipv4/tcpfirewall/tcpfirewall.c
>> +++ b/net/ipv4/tcpfirewall/tcpfirewall.c
>> @@ -0,0 +1,451 @@
>> +#include<linux/module.h>
>> +#include<linux/kernel.h>
>> +#include<linux/init.h>
>> +#include<linux/skbuff.h>
>> +#include<linux/in.h>
>> +#include<linux/if_packet.h>
>> +#include<linux/tcp.h>
>> +#include<linux/udp.h>
>> +#include<net/tcp.h>
>> +#include<net/udp.h>
>> +
>> +struct net_protocol {
>> +	int (*handler)(struct sk_buff *skb);
>> +	void (*err_handler)(struct sk_buff *skb, u32 info);
>> +	int (*gso_send_check)(struct sk_buff *skb);
>> +	struct sk_buff *(*gso_segment)(struct sk_buff *skb,
>> +		u32 features);
>> +	struct sk_buff **(*gro_receive)(struct sk_buff **head,
>> +		struct sk_buff *skb);
>> +	int (*gro_complete)(struct sk_buff *skb);
>> +	unsigned int no_policy:1,
>> +		netns_ok:1;
>> +};
>> +
>> +MODULE_LICENSE("GPL");
>> +
>> +static unsigned long inet_protos = 0x01234567;
>> +
>> +struct net_protocol **_inet_protos;
>> +
>> +module_param(inet_protos, ulong, 0);
>> +
>> +static int *otviraky;
>> +static int *zaviraky;
>> +
>> +static int pocetotviraku;
>> +static int pocetzaviraku;
>> +static int stav;
>> +static int packetcounter;
>> +static int tcpport;
>> +static int open;
>> +static int firewall;
>> +
>> +int (*tcpv4recv) (struct sk_buff *skb);
>> +int (*udprecv) (struct sk_buff *skb);
>> +
>> +int udpcontroller(struct sk_buff *skb)
>>      
> can be static?
>
>    
Yes
>> +{
>> +	const struct udphdr *uh;
>> +
>> +	if (skb->pkt_type != PACKET_HOST) {
>> +		kfree_skb(skb);
>> +		return 0;
>> +	}
>> +
>> +	if (!pskb_may_pull(skb, sizeof(struct tcphdr))) {
>> +		kfree_skb(skb);
>> +		return 0;
>> +	}
>> +
>> +	uh = udp_hdr(skb);
>> +
>> +	if (pocetotviraku == 0)
>> +		return udprecv(skb);
>> +
>> +	if (!open) {
>> +		if (uh->dest == otviraky[stav]) {
>> +			++stav;
>> +			packetcounter = 0;
>> +
>> +			if (stav == pocetotviraku) {
>> +				open = 1;
>> +				stav = 0;
>> +			}
>> +		} else {
>> +			if (packetcounter<= 16) {
>> +				++packetcounter;
>> +				if (packetcounter>  16)
>> +					stav = 0;
>> +			}
>> +		}
>> +	} else {
>> +		if (uh->dest == zaviraky[stav]) {
>> +			++stav;
>> +			packetcounter = 0;
>> +
>> +			if (stav == pocetzaviraku) {
>> +				open = 0;
>> +				stav = 0;
>> +			}
>> +		} else {
>> +			if (packetcounter<= 16) {
>> +				++packetcounter;
>> +				if (packetcounter>  16)
>> +					stav = 0;
>> +			}
>> +		}
>> +	}
>> +
>> +
>> +	return udprecv(skb);
>> +}
>> +
>> +int tcpfirewall(struct sk_buff *skb)
>>      
> can be static?
>
>    
Yes
>> +{
>> +	const struct tcphdr *th;
>> +
>> +	if (skb->pkt_type != PACKET_HOST) {
>> +		kfree_skb(skb);
>> +		return 0;
>> +	}
>> +
>> +	if (!pskb_may_pull(skb, sizeof(struct tcphdr))) {
>> +		kfree_skb(skb);
>> +		return 0;
>> +	}
>> +
>> +	th = tcp_hdr(skb);
>> +
>> +	if (th->dest == tcpport) {
>> +		if (firewall == 1&&  !open) {
>> +			/*tcpv4sendreset(NULL, skb);*/
>> +			kfree_skb(skb);
>> +			return 0;
>> +		}
>> +	}
>> +
>> +	return tcpv4recv(skb);
>> +}
>>      
> [snip]
>
>    
>> +static int __init start(void)
>> +{
>> +	if (inet_protos == 0x01234567) {
>> +		printk(KERN_WARNING "inet_protos parameter was not");
>> +		printk(KERN_WARNING " specified!\nread its value from");
>> +		printk(KERN_WARNING " System_map file file, and insert");
>> +		printk(KERN_WARNING " the module again!\n");
>>      
> Break the printk() calls at newlines, please.
>
>    
OK
>> +		return -1;
>> +	}
>> +
>> +	pocetotviraku = 0;
>> +	pocetzaviraku = 0;
>> +	stav = -1;
>> +	packetcounter = 0;
>> +	tcpport = 0;
>> +	open = 1;
>> +	firewall = 0;
>> +
>> +	memset(&kobj, 0, sizeof(struct kobject));
>> +
>> +	_inet_protos = (struct net_protocol **)inet_protos;
>> +
>> +	kobject_init(&kobj,&khid);
>> +	if (kobject_add(&kobj, NULL, "tcpfirewall")<  0)
>> +		printk(KERN_ERR "kobject_add failed");
>> +
>>      
> All of these kobject_add() and sysfs_create_file() failures are not
> fatal errors?
>
>    
I do not know, whether collision of kobject names is fatal or not.
>> +	if (sysfs_create_file(&kobj,&fw)<  0)
>> +		printk(KERN_ERR "sysfs_create_file failed");
>> +	if (sysfs_create_file(&kobj,&opn)<  0)
>> +		printk(KERN_ERR "sysfs_create_file failed");
>> +	if (sysfs_create_file(&kobj,&tcpp)<  0)
>> +		printk(KERN_ERR "sysfs_create_file failed");
>> +	if (sysfs_create_file(&kobj,&openers)<  0)
>> +		printk(KERN_ERR "sysfs_create_file failed");
>> +	if (sysfs_create_file(&kobj,&closers)<  0)
>> +		printk(KERN_ERR "sysfs_create_file failed");
>> +	if (sysfs_create_file(&kobj,&stat)<  0)
>> +		printk(KERN_ERR "sysfs_create_file failed");
>> +	if (sysfs_create_file(&kobj,&counte)<  0)
>> +		printk(KERN_ERR "sysfs_create_file failed");
>> +
>> +	zalohatcp = _inet_protos[IPPROTO_TCP];
>> +	zalohaudp = _inet_protos[IPPROTO_UDP];
>> +	mytcp = *zalohatcp;
>> +	myudp = *zalohaudp;
>> +	tcpv4recv = mytcp.handler;
>> +	udprecv = myudp.handler;
>> +	mytcp.handler = tcpfirewall;
>> +	myudp.handler = udpcontroller;
>> +	_inet_protos[IPPROTO_TCP] =&mytcp;
>> +	_inet_protos[IPPROTO_UDP] =&myudp;
>> +	return 0;
>> +}
>> +
>> +static void konec(void)
>> +{
>> +	_inet_protos[IPPROTO_TCP] = zalohatcp;
>> +	_inet_protos[IPPROTO_UDP] = zalohaudp;
>> +
>> +	if (pocetotviraku)
>> +		kfree(otviraky);
>> +	if (pocetzaviraku)
>> +		kfree(zaviraky);
>> +
>> +	kobject_del(&kobj);
>> +}
>> +
>> +module_init(start);
>> +module_exit(konec);
>> --
>>      
> Some of the function&  variable names confuse me.
>
>
>    
I renamed them in the second version.
Should I resend the corrected patch again?
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
>
>    

^ permalink raw reply

* Re: TCP port firewall incl. description and english variable names
From: Patrick McHardy @ 2011-08-12 15:38 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: Tonda, davem, kuznet, jmorris, yoshfuji, netdev, linux-kernel
In-Reply-To: <1313163276.2354.32.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>

On 12.08.2011 17:34, Eric Dumazet wrote:
> Le vendredi 12 août 2011 à 17:10 +0200, Tonda a écrit :
>> Module that is used to open, close or filter specified TCP port by
>> sending certain sequence of UDP packets to predefined UDP ports
>> (password-like firewall). One sequence of UDP ports is the opening key
>> and sending packets successively to them opens the TCP port and the
>> second sequence of UDP ports is the closing key and sending packets
>> successively to them closes the TCP port. If between two UDP packets
>> in the sequence comes more than 16 another UDP packets, the sequence
>> (either opening or closing) is aborted. The configuration and view of
>> affected TCP port, opening and closing key and other firewall
>> parameters is made throw use of sysfs.
>>
>> Signed-off-by: Antoine Steinhauser <as@strmilov.cz>
> 
> Antoine
> 
> There is no chance this can be added in official linux kernel, its
> really too ugly, and can be implemented using standard iptables rules,
> and userland controller, adding encryption and other high level stuff if
> needed.

Fully agreed. There are also standarized protocols for this.

^ permalink raw reply

* Re: TCP port firewall incl. description and english variable names
From: Antonin Steinhauser @ 2011-08-12 15:37 UTC (permalink / raw)
  To: Eric Dumazet
  Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1313163276.2354.32.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>

OK
Dne 12.8.2011 17:34, Eric Dumazet napsal(a):
> Le vendredi 12 août 2011 à 17:10 +0200, Tonda a écrit :
>    
>> Module that is used to open, close or filter specified TCP port by
>> sending certain sequence of UDP packets to predefined UDP ports
>> (password-like firewall). One sequence of UDP ports is the opening key
>> and sending packets successively to them opens the TCP port and the
>> second sequence of UDP ports is the closing key and sending packets
>> successively to them closes the TCP port. If between two UDP packets
>> in the sequence comes more than 16 another UDP packets, the sequence
>> (either opening or closing) is aborted. The configuration and view of
>> affected TCP port, opening and closing key and other firewall
>> parameters is made throw use of sysfs.
>>
>> Signed-off-by: Antoine Steinhauser<as@strmilov.cz>
>>      
> Antoine
>
> There is no chance this can be added in official linux kernel, its
> really too ugly, and can be implemented using standard iptables rules,
> and userland controller, adding encryption and other high level stuff if
> needed.
>
>
>
>
>    


^ permalink raw reply

* Re: iproute2: make arpd daemon write pid file on fork
From: Stephen Hemminger @ 2011-08-12 16:15 UTC (permalink / raw)
  To: Alex Dubov; +Cc: netdev
In-Reply-To: <201108121623.24984.oakad@yahoo.com>

On Fri, 12 Aug 2011 16:23:24 +1000
Alex Dubov <oakad@yahoo.com> wrote:

> Current version of arpd included with iproute2-2.6.37 will fork 
> unconditionally on start-up (using daemon() library call). This causes 
> problems with distro start-up scripts, as PID of the started daemon can not be 
> reliably obtained, hampering orderly daemon shutdown process.
> 
> The included patch makes arpd write it's own pid file after fork, in a common 
> LSB fashion, so as to better inter-operate with start up scripts. Removal of 
> stale pid files is handled elsewhere.

I already checked in a version which has the -p pidfile option.

^ permalink raw reply

* Re: Request for Redhat
From: Chris Wright @ 2011-08-12 16:18 UTC (permalink / raw)
  To: Jun.Kondo
  Cc: linux-kernel, omega-g1@ctc-g.co.jp, notsuki, Kozaki, Motokazu,
	Hajime Taira, netdev
In-Reply-To: <4E450C8F.4030009@ctc-g.co.jp>

Hi Jun,

* Jun.Kondo (jun.kondo@ctc-g.co.jp) wrote:
> CTC had the following demand;
> 
> 1. to ensure high throughput from the beginning of
> tcp connection at normal times by acquiring large
> default transmission buffer value
> 
> 2. to limit the block time of the write in order to
> prevent the timeout of upper layer applications
> even when the connection has low throughput, such
> as low rate streaming

Make sure you include network developers (netdev@vger.kernel.org Cc'd)
on networking related patches.

You'll find some helpful information regarding the email format for
submitting patches here:
  http://www.kernel.org/doc/Documentation/SubmittingPatches

Improving your Subject: and fixing the patch level for your diff come
to mind immediately.

> --- sock.h 2011-04-14 14:58:03.000000000 +0900
> +++ sock.h.mod 2011-04-21 15:30:07.000000000 +0900
> @@ -434,9 +434,12 @@
> /*
> * Compute minimal free write space needed to queue new packets.
> */
> +
> +extern int sysctl_tcp_lowat;
> +
> static inline int sk_stream_min_wspace(struct sock *sk)
> {
> - return sk->sk_wmem_queued / 2;
> + return sk->sk_wmem_queued >> sysctl_tcp_lowat;
> }

Also, this patch appears to be against an old tree (I assume the RHEL
5 tree).  To be considered upstream, you need to generate a diff against
the upstream tree.  And considering all that's changed since 2.6.18, it
would be useful to verify you still have the issue in a current upstream
Linux tree.

Alternatively, you may consider using Red Hat's Bugzilla to contact RH
engineers for help and guidance.

Good luck.

thanks,
-chris

^ permalink raw reply

* Re: bridge: accept bridge own MAC address as local
From: Stephen Hemminger @ 2011-08-12 16:19 UTC (permalink / raw)
  To: Ulrich Weber; +Cc: davem, netdev
In-Reply-To: <20110812113024.GA8900@babylon>

On Fri, 12 Aug 2011 13:30:24 +0200
Ulrich Weber <ulrich.weber@sophos.com> wrote:

> bridge: accept bridge own MAC address as local
> if MAC address of bridge is manually set (BR_SET_MAC_ADDR). Otherwise
> only MAC addresses of bridge members will work if manually set.
> 
> Signed-off-by: Ulrich Weber <ulrich.weber@sophos.com>
> ---
>  net/bridge/br_input.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> index f06ee39..3adabe3 100644
> --- a/net/bridge/br_input.c
> +++ b/net/bridge/br_input.c
> @@ -93,7 +93,9 @@ int br_handle_frame_finish(struct sk_buff *skb)
>  			skb2 = skb;
>  
>  		br->dev->stats.multicast++;
> -	} else if ((dst = __br_fdb_get(br, dest)) && dst->is_local) {
> +	} else if ((br->flags & BR_SET_MAC_ADDR &&
> +		    !compare_ether_addr(br->bridge_id.addr, dest)) ||
> +		   ((dst = __br_fdb_get(br, dest)) && dst->is_local)) {
>  		skb2 = skb;
>  		/* Do not forward the packet since it's local. */
>  		skb = NULL;

A cleaner way to do this would be better to put a local entry
in the forwarding database when mac address is manually set.
Then there would not be special case code.

^ permalink raw reply

* Re: TCP port firewall controlled by UDP packets
From: Valdis.Kletnieks @ 2011-08-12 16:40 UTC (permalink / raw)
  To: Tonda; +Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
In-Reply-To: <1313106969-18733-1-git-send-email-as@strmilov.cz>

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

On Fri, 12 Aug 2011 01:56:09 +0200, Tonda said:
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -624,3 +624,7 @@
>  	  on the Internet.
>  
>  	  If unsure, say N.
> +
> +config TCPFIREWALL
> +	tristate "TCP Firewall controlled by UDP queries"
> +	depends on m

I don't suppose it would be asking too much to support UPNP here, would it?
https://secure.wikimedia.org/wikipedia/en/wiki/Internet_Gateway_Device_Protocol

(If this in fact *does* do the UPNP thing, then this *really* needs better docs).


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

^ permalink raw reply

* Re: bridge: accept bridge own MAC address as local
From: Ulrich Weber @ 2011-08-12 16:36 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: davem, netdev
In-Reply-To: <20110812091909.712fa36e@nehalam.ftrdhcpuser.net>

On 08/12/2011 06:19 PM, Stephen Hemminger wrote:
> A cleaner way to do this would be better to put a local entry
> in the forwarding database when mac address is manually set.
> Then there would not be special case code.

I agree, would be nicer to have it in the forwarding db.

However to which bridge port should i attach this entry?
Seems to be wrong for me to have it attached to a not
related port...

The intention of this patch is to set the bridge MAC to any
address, not related to an bridge port interface.

Cheers
 Ulrich

-- 
Ulrich Weber | ulrich.weber@sophos.com | Senior Software Engineer
Astaro - a Sophos company | Amalienbadstr 41 | 76227 Karlsruhe | Germany
Phone +49-721-25516-0 | Fax –200 | www.astaro.com

^ permalink raw reply

* igb transmit queue timed out, rcu_sched_state detected stall
From: Peter Neal @ 2011-08-12 16:42 UTC (permalink / raw)
  To: netdev

Hi,

I have a machine with 25 interfaces, a mixture of igb and e1000e dual
and quad port NICs. It is used to PXE install and test 24 network
appliances at the same time. During a test run, the interfaces often
go up and down, and are frequently reconfigured (ipv4 and ipv6, all
done through iproute2). I recently changed some of the scripting that
controls the network setup, and now the box has started to hang about
4 hours into the test. I set up a serial console, and the text below
was spat out when the box hung - my shell on the serial terminal
responds when I press return, but any command hangs.

The issue is reproducible on two machines, a dell R900 (below) and an
R910 in a very similar setup, both running a 64bit kernel. I initially
found the issue on a debian packaged 2.6.32-5-amd64, and upgraded to
3.0.1 - this shows the same behaviour, and provided the information
below.

Please copy me on any replies as I'm not subscribed.

Thanks,


Pete Neal


[10179.824031] ------------[ cut here ]------------
[10179.879205] WARNING: at net/sched/sch_generic.c:255 dev_watchdog+0xea/0x17e()
[10179.964506] Hardware name: PowerEdge R900
[10180.012375] NETDEV WATCHDOG: eth0 (igb): transmit queue 0 timed out
[10180.087284] Modules linked in: ipmi_si ipmi_devintf ipmi_msghandler
8021q garp stp loop tpm_tis snd_pcm snd_timer snd shpchp soundcore
rng_core dcdbas snd_page_alloc i7300_idle psmouse pcspkr processor tpm
tpm_bios ioatdma evdev thermal_sys serio_raw pci_hotplug button ext3
jbd mbcache sg sr_mod cdrom sd_mod ses crc_t10dif enclosure
ata_generic usbhid hid uhci_hcd ata_piix ehci_hcd libata e1000e
usbcore bnx2 megaraid_sas scsi_mod igb dca [last unloaded:
scsi_wait_scan]
[10180.585411] Pid: 0, comm: swapper Not tainted 3.0.1 #1
[10180.646793] Call Trace:
[10180.675937]  <IRQ>  [<ffffffff810450af>] ? warn_slowpath_common+0x78/0x8c
[10180.757115]  [<ffffffff81045162>] ? warn_slowpath_fmt+0x45/0x4a
[10180.827869]  [<ffffffff81281560>] ? netif_tx_lock+0x43/0x74
[10180.894465]  [<ffffffff810625a9>] ? hrtimer_interrupt+0x114/0x1a6
[10180.967301]  [<ffffffff8128167b>] ? dev_watchdog+0xea/0x17e
[10181.033890]  [<ffffffff810662aa>] ? ktime_get+0x50/0x88
[10181.096319]  [<ffffffff81051dbb>] ? run_timer_softirq+0x1c3/0x290
[10181.169149]  [<ffffffff81281591>] ? netif_tx_lock+0x74/0x74
[10181.235734]  [<ffffffff8104a737>] ? __do_softirq+0xc4/0x1a0
[10181.302324]  [<ffffffff81090afa>] ? handle_irq_event_percpu+0x166/0x184
[10181.381402]  [<ffffffff8132af5c>] ? call_softirq+0x1c/0x30
[10181.446950]  [<ffffffff8100aa3f>] ? do_softirq+0x3f/0x79
[10181.510420]  [<ffffffff8104a507>] ? irq_exit+0x44/0xb5
[10181.571809]  [<ffffffff8100a38a>] ? do_IRQ+0x94/0xaa
[10181.631121]  [<ffffffff81323cd3>] ? common_interrupt+0x13/0x13
[10181.700827]  <EOI>  [<ffffffffa031816e>] ?
acpi_idle_enter_simple+0xc7/0xfc [processor]
[10181.796569]  [<ffffffffa031816a>] ?
acpi_idle_enter_simple+0xc3/0xfc [processor]
[10181.885006]  [<ffffffff81252d9f>] ? cpuidle_idle_call+0x123/0x1d4
[10181.957836]  [<ffffffff81008dc7>] ? cpu_idle+0xab/0xe1
[10182.019225]  [<ffffffff81692c17>] ? start_kernel+0x3b4/0x3bf
[10182.086857]  [<ffffffff816923c8>] ? x86_64_start_kernel+0x102/0x10f
[10182.161766] ---[ end trace 74b13b200a4ea2df ]---
[10182.217111] igb 0000:10:00.0: eth0: Reset adapter
[10202.300005] INFO: rcu_sched_state detected stall on CPU 10 (t=15000 jiffies)
[10202.304005] INFO: rcu_sched_state detected stall on CPU 4 (t=15000 jiffies)

root@worker-1b.bigrig.dom:~# [10321.876088] INFO: task kworker/3:1:62
blocked for more than 120 seconds.
[10321.956203] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[10322.049830] kworker/3:1     D ffff88042ee03d50     0    62      2 0x00000000
[10322.134133]  ffff88042ee03d50 0000000000000046 0000000000000000
ffff88042ece8000
[10322.222595]  0000000000012680 ffff88042e87bfd8 ffff88042e87bfd8
0000000000012680
[10322.311059]  ffff88042ee03d50 ffff88042e87a010 ffff88042ee03d50
000000013f272680
[10322.399536] Call Trace:
[10322.428684]  [<ffffffff813229aa>] ? schedule_timeout+0x2d/0xd7
[10322.498392]  [<ffffffff81037e3b>] ? update_rq_clock+0x15/0x2f
[10322.567055]  [<ffffffff81094019>] ? rcu_batches_completed+0x8/0x8
[10322.639874]  [<ffffffff8132281e>] ? wait_for_common+0xd1/0x14e
[10322.709583]  [<ffffffff810419a7>] ? try_to_wake_up+0x18d/0x18d
[10322.779288]  [<ffffffff81094019>] ? rcu_batches_completed+0x8/0x8
[10322.852115]  [<ffffffff81086eb6>] ? __stop_cpus+0xc4/0xe1
[10322.916616]  [<ffffffff81086f0c>] ? try_stop_cpus+0x39/0x51
[10322.983199]  [<ffffffff81094019>] ? rcu_batches_completed+0x8/0x8
[10323.056025]  [<ffffffff81095561>] ? synchronize_sched_expedited+0x99/0xc8
[10323.137181]  [<ffffffff812818a9>] ? dev_deactivate_many+0xf4/0x186
[10323.211046]  [<ffffffff81277b4d>] ? __linkwatch_run_queue+0x1a5/0x1a5
[10323.288030]  [<ffffffff81281968>] ? dev_deactivate+0x2d/0x42
[10323.355658]  [<ffffffff812777c8>] ? linkwatch_do_dev+0x9c/0xb2
[10323.425361]  [<ffffffff81277b06>] ? __linkwatch_run_queue+0x15e/0x1a5
[10323.502346]  [<ffffffff81277b6d>] ? linkwatch_event+0x20/0x26
[10323.571015]  [<ffffffff8105b7c8>] ? process_one_work+0x1cc/0x2ea
[10323.642795]  [<ffffffff8105ba13>] ? worker_thread+0x12d/0x247
[10323.711456]  [<ffffffff8105b8e6>] ? process_one_work+0x2ea/0x2ea
[10323.783243]  [<ffffffff8105b8e6>] ? process_one_work+0x2ea/0x2ea
[10323.855034]  [<ffffffff8105ec89>] ? kthread+0x7a/0x82
[10323.915382]  [<ffffffff8132ae64>] ? kernel_thread_helper+0x4/0x10
[10323.988199]  [<ffffffff8105ec0f>] ? kthread_worker_fn+0x147/0x147
[10324.061025]  [<ffffffff8132ae60>] ? gs_change+0x13/0x13
[10324.123455] INFO: task irqbalance:1793 blocked for more than 120 seconds.
[10324.204596] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[10324.298223] irqbalance      D ffff88042d99a8e0     0  1793      1 0x00000000
[10324.382521]  ffff88042d99a8e0 0000000000000082 ffff880400000000
ffff88042ec6df60
[10324.470993]  0000000000012680 ffff88042a8f5fd8 ffff88042a8f5fd8
0000000000012680
[10324.559457]  ffff88042d99a8e0 ffff88042a8f4010 ffff88042a8f5cc8
000000012d91d000
[10324.647926] Call Trace:
[10324.677066]  [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[10324.751974]  [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[10324.815444]  [<ffffffff81269ca6>] ? dev_load+0x9/0x70
[10324.875792]  [<ffffffff8126b017>] ? dev_ioctl+0x4ad/0x62e
[10324.940302]  [<ffffffff810eb735>] ? get_partial_node+0x15/0x7b
[10325.010005]  [<ffffffff8125844c>] ? sock_do_ioctl+0x2f/0x36
[10325.076582]  [<ffffffff81258853>] ? sock_ioctl+0x205/0x212
[10325.142126]  [<ffffffff810f3d2d>] ? get_empty_filp+0x9c/0x12b
[10325.210790]  [<ffffffff810ff9bb>] ? do_vfs_ioctl+0x467/0x4b4
[10325.278414]  [<ffffffff81259ed4>] ? sock_alloc_file+0xae/0x10c
[10325.348117]  [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[10325.411574]  [<ffffffff810ffa53>] ? sys_ioctl+0x4b/0x70
[10325.473999]  [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[10325.547865] INFO: task snmpd:1820 blocked for more than 120 seconds.
[10325.623803] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[10325.717436] snmpd           D ffff88042b412fb0     0  1820      1 0x00000000
[10325.801728]  ffff88042b412fb0 0000000000000086 ffffffff00000000
ffff88042edb0000
[10325.890194]  0000000000012680 ffff88042e961fd8 ffff88042e961fd8
0000000000012680
[10325.978657]  ffff88042b412fb0 ffff88042e960010 ffff8804127346c0
000000018113e49b
[10326.067122] Call Trace:
[10326.096260]  [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[10326.171167]  [<ffffffff810fa4b3>] ? dget+0x12/0x1e
[10326.228388]  [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[10326.291853]  [<ffffffff8126aba4>] ? dev_ioctl+0x3a/0x62e
[10326.355315]  [<ffffffff81103734>] ? dput+0x29/0xe9
[10326.412538]  [<ffffffff810eb735>] ? get_partial_node+0x15/0x7b
[10326.482242]  [<ffffffff810ec082>] ? kmem_cache_alloc+0x2a/0xe1
[10326.551952]  [<ffffffff8125844c>] ? sock_do_ioctl+0x2f/0x36
[10326.618530]  [<ffffffff81258853>] ? sock_ioctl+0x205/0x212
[10326.684084]  [<ffffffff810f3d2d>] ? get_empty_filp+0x9c/0x12b
[10326.752746]  [<ffffffff810ff9bb>] ? do_vfs_ioctl+0x467/0x4b4
[10326.820372]  [<ffffffff81259ed4>] ? sock_alloc_file+0xae/0x10c
[10326.890072]  [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[10326.953533]  [<ffffffff810ffa53>] ? sys_ioctl+0x4b/0x70
[10327.015958]  [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[10327.089837] INFO: task tcpdump:12446 blocked for more than 120 seconds.
[10327.168898] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[10327.262522] tcpdump         D ffff88042e9ae630     0 12446  10117 0x00000000
[10327.346820]  ffff88042e9ae630 0000000000000086 0000003100000000
ffff88042ed44420
[10327.435286]  0000000000012680 ffff8803e6533fd8 ffff8803e6533fd8
0000000000012680
[10327.523751]  ffff88042e9ae630 ffff8803e6532010 ffff8803e6533d38
000000013fffbe00
[10327.612231] Call Trace:
[10327.641369]  [<ffffffff813229aa>] ? schedule_timeout+0x2d/0xd7
[10327.711072]  [<ffffffff810e5028>] ? alloc_pages_vma+0x101/0x11d
[10327.781816]  [<ffffffff8132281e>] ? wait_for_common+0xd1/0x14e
[10327.851522]  [<ffffffff810419a7>] ? try_to_wake_up+0x18d/0x18d
[10327.921231]  [<ffffffff8119d912>] ? hweight_long+0x5/0x6
[10327.984692]  [<ffffffff8119d94b>] ? __bitmap_weight+0x38/0x78
[10328.053357]  [<ffffffff810954c2>] ? synchronize_sched+0x4c/0x52
[10328.124101]  [<ffffffff8105c988>] ? alloc_pid+0x368/0x368
[10328.188599]  [<ffffffff813078f9>] ? packet_set_ring+0x226/0x3ac
[10328.259341]  [<ffffffff81307d3c>] ? packet_setsockopt+0x2bd/0x518
[10328.332166]  [<ffffffff813076a8>] ? packet_getsockopt+0x1c5/0x1f0
[10328.404990]  [<ffffffff81259b6c>] ? sys_setsockopt+0x7d/0x9c
[10328.472613]  [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[10328.546481] INFO: task sshd:12447 blocked for more than 120 seconds.
[10328.622420] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[10328.716055] sshd            D ffff88042e9ac420     0 12447   1828 0x00000004
[10328.800362]  ffff88042e9ac420 0000000000000086 0000093a00000000
ffff88042edb0000
[10328.888838]  0000000000012680 ffff8803f37b3fd8 ffff8803f37b3fd8
0000000000012680
[10328.977309]  ffff88042e9ac420 ffff8803f37b2010 0000000000000001
00000001f37b3b88
[10329.065787] Call Trace:
[10329.094923]  [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[10329.169827]  [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[10329.233289]  [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[10329.298836]  [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[10329.368538]  [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[10329.439282]  [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[10329.513145]  [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[10329.578695]  [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[10329.641113]  [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[10329.708736]  [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[10329.781560]  [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[10329.846073]  [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[10329.909533]  [<ffffffff81259f56>] ? sock_map_fd+0x24/0x2d
[10329.974037]  [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[10330.047905] INFO: task sshd:12450 blocked for more than 120 seconds.
[10330.123851] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[10330.217469] sshd            D ffff88042a845890     0 12450   1828 0x00000000
[10330.301759]  ffff88042a845890 0000000000000086 000280da00000000
ffff88042edb51c0
[10330.390234]  0000000000012680 ffff8803e417ffd8 ffff8803e417ffd8
0000000000012680
[10330.478698]  ffff88042a845890 ffff8803e417e010 ffff8803e417fb88
000000018110028a
[10330.567162] Call Trace:
[10330.596301]  [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[10330.671207]  [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[10330.734668]  [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[10330.800222]  [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[10330.869929]  [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[10330.940668]  [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[10331.014530]  [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[10331.080084]  [<ffffffff810378ce>] ? __wake_up+0x35/0x46
[10331.142504]  [<ffffffff8125838d>] ? copy_from_user+0x18/0x30
[10331.210128]  [<ffffffff81258e23>] ? move_addr_to_kernel+0x2c/0x4c
[10331.282952]  [<ffffffff812595fc>] ? sys_sendto+0xf7/0x137
[10331.347455]  [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[10331.410918]  [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[10382.420003] INFO: rcu_sched_state detected stall on CPU 10 (t=60030 jiffies)
[10382.423999] INFO: rcu_sched_state detected stall on CPU 4 (t=60030 jiffies)
[10451.484093] INFO: task kworker/3:1:62 blocked for more than 120 seconds.
[10451.564192] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[10451.657811] kworker/3:1     D ffff88042ee03d50     0    62      2 0x00000000
[10451.742095]  ffff88042ee03d50 0000000000000046 0000000000000000
ffff88042ece8000
[10451.830553]  0000000000012680 ffff88042e87bfd8 ffff88042e87bfd8
0000000000012680
[10451.919018]  ffff88042ee03d50 ffff88042e87a010 ffff88042ee03d50
000000013f272680
[10452.007482] Call Trace:
[10452.036621]  [<ffffffff813229aa>] ? schedule_timeout+0x2d/0xd7
[10452.106321]  [<ffffffff81037e3b>] ? update_rq_clock+0x15/0x2f
[10452.174984]  [<ffffffff81094019>] ? rcu_batches_completed+0x8/0x8
[10452.247808]  [<ffffffff8132281e>] ? wait_for_common+0xd1/0x14e
[10452.317506]  [<ffffffff810419a7>] ? try_to_wake_up+0x18d/0x18d
[10452.387207]  [<ffffffff81094019>] ? rcu_batches_completed+0x8/0x8
[10452.460049]  [<ffffffff81086eb6>] ? __stop_cpus+0xc4/0xe1
[10452.524548]  [<ffffffff81086f0c>] ? try_stop_cpus+0x39/0x51
[10452.591126]  [<ffffffff81094019>] ? rcu_batches_completed+0x8/0x8
[10452.663944]  [<ffffffff81095561>] ? synchronize_sched_expedited+0x99/0xc8
[10452.745082]  [<ffffffff812818a9>] ? dev_deactivate_many+0xf4/0x186
[10452.818945]  [<ffffffff81277b4d>] ? __linkwatch_run_queue+0x1a5/0x1a5
[10452.895927]  [<ffffffff81281968>] ? dev_deactivate+0x2d/0x42
[10452.963546]  [<ffffffff812777c8>] ? linkwatch_do_dev+0x9c/0xb2
[10453.033244]  [<ffffffff81277b06>] ? __linkwatch_run_queue+0x15e/0x1a5
[10453.110223]  [<ffffffff81277b6d>] ? linkwatch_event+0x20/0x26
[10453.178887]  [<ffffffff8105b7c8>] ? process_one_work+0x1cc/0x2ea
[10453.250669]  [<ffffffff8105ba13>] ? worker_thread+0x12d/0x247
[10453.319326]  [<ffffffff8105b8e6>] ? process_one_work+0x2ea/0x2ea
[10453.391105]  [<ffffffff8105b8e6>] ? process_one_work+0x2ea/0x2ea
[10453.462889]  [<ffffffff8105ec89>] ? kthread+0x7a/0x82
[10453.523231]  [<ffffffff8132ae64>] ? kernel_thread_helper+0x4/0x10
[10453.596054]  [<ffffffff8105ec0f>] ? kthread_worker_fn+0x147/0x147
[10453.668880]  [<ffffffff8132ae60>] ? gs_change+0x13/0x13
[10453.731306] INFO: task irqbalance:1793 blocked for more than 120 seconds.
[10453.812448] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[10453.906070] irqbalance      D ffff88042d99a8e0     0  1793      1 0x00000000
[10453.990357]  ffff88042d99a8e0 0000000000000082 ffff880400000000
ffff88042ec6df60
[10454.078814]  0000000000012680 ffff88042a8f5fd8 ffff88042a8f5fd8
0000000000012680
[10454.167280]  ffff88042d99a8e0 ffff88042a8f4010 ffff88042a8f5cc8
000000012d91d000
[10454.255744] Call Trace:
[10454.284883]  [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[10454.359780]  [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[10454.423237]  [<ffffffff81269ca6>] ? dev_load+0x9/0x70
[10454.483576]  [<ffffffff8126b017>] ? dev_ioctl+0x4ad/0x62e
[10454.548088]  [<ffffffff810eb735>] ? get_partial_node+0x15/0x7b
[10454.617789]  [<ffffffff8125844c>] ? sock_do_ioctl+0x2f/0x36
[10454.684365]  [<ffffffff81258853>] ? sock_ioctl+0x205/0x212
[10454.749906]  [<ffffffff810f3d2d>] ? get_empty_filp+0x9c/0x12b
[10454.818572]  [<ffffffff810ff9bb>] ? do_vfs_ioctl+0x467/0x4b4
[10454.886192]  [<ffffffff81259ed4>] ? sock_alloc_file+0xae/0x10c
[10454.955894]  [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[10455.019351]  [<ffffffff810ffa53>] ? sys_ioctl+0x4b/0x70
[10455.081769]  [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[10455.155632] INFO: task ntpd:1808 blocked for more than 120 seconds.
[10455.230529] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[10455.324148] ntpd            D ffff88042bf96630     0  1808      1 0x00000004
[10455.408430]  ffff88042bf96630 0000000000000082 ffff880400000000
ffff88042eceed00
[10455.496902]  0000000000012680 ffff88042a8affd8 ffff88042a8affd8
0000000000012680
[10455.585370]  ffff88042bf96630 ffff88042a8ae010 0000000700200200
000000010000ea00
[10455.673841] Call Trace:
[10455.702978]  [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[10455.777876]  [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[10455.841336]  [<ffffffff8126aba4>] ? dev_ioctl+0x3a/0x62e
[10455.904797]  [<ffffffff81053d92>] ? __set_task_blocked+0x5a/0x61
[10455.976575]  [<ffffffff810ec082>] ? kmem_cache_alloc+0x2a/0xe1
[10456.046279]  [<ffffffff8125844c>] ? sock_do_ioctl+0x2f/0x36
[10456.112861]  [<ffffffff81258853>] ? sock_ioctl+0x205/0x212
[10456.178400]  [<ffffffff810f3d2d>] ? get_empty_filp+0x9c/0x12b
[10456.247062]  [<ffffffff810ff9bb>] ? do_vfs_ioctl+0x467/0x4b4
[10456.314679]  [<ffffffff81259ed4>] ? sock_alloc_file+0xae/0x10c
[10456.384377]  [<ffffffff810f0dc5>] ? fd_install+0x27/0x4e
[10456.447833]  [<ffffffff810ffa53>] ? sys_ioctl+0x4b/0x70
[10456.510251]  [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[10456.584106] INFO: task zebra:1815 blocked for more than 120 seconds.
[10456.660054] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[10456.753680] zebra           D ffff88042bfecaf0     0  1815      1 0x00000000
[10456.837969]  ffff88042bfecaf0 0000000000000082 ffff880400000000
ffff88042edb1b40
[10456.926427]  0000000000012680 ffff88042ba69fd8 ffff88042ba69fd8
0000000000012680
[10457.014891]  ffff88042bfecaf0 ffff88042ba68010 ffff88042ba69d48
0000000181289426
[10457.103356] Call Trace:
[10457.132494]  [<ffffffff81322df5>] ? __mutex_lock_common+0x10c/0x172
[10457.207392]  [<ffffffff81322f21>] ? mutex_lock+0x1a/0x2c
[10457.270850]  [<ffffffff81100218>] ? __pollwait+0xd0/0xd0
[10457.334306]  [<ffffffff81275f2e>] ? rtnetlink_rcv+0xe/0x28
[10457.399842]  [<ffffffff8128951f>] ? netlink_unicast+0xea/0x152
[10457.469540]  [<ffffffff81289c74>] ? netlink_sendmsg+0x246/0x266
[10457.540280]  [<ffffffff8125809a>] ? __sock_sendmsg_nosec+0x25/0x5d
[10457.614142]  [<ffffffff812590dc>] ? sock_sendmsg+0x83/0x9b
[10457.679679]  [<ffffffff812580fb>] ? __sock_recvmsg_nosec+0x29/0x69
[10457.753538]  [<ffffffff81262a9c>] ? copy_from_user+0x18/0x30
[10457.821166]  [<ffffffff81262de0>] ? verify_iovec+0x46/0x98
[10457.886703]  [<ffffffff81259811>] ? __sys_sendmsg+0x1c4/0x23b
[10457.955361]  [<ffffffff810f2687>] ? do_sync_read+0xb1/0xea
[10458.020900]  [<ffffffff8103cbdb>] ? thread_group_times+0x32/0x8e
[10458.092683]  [<ffffffff81053c57>] ? __lock_task_sighand+0x4a/0x72
[10458.165506]  [<ffffffff810431f2>] ? mmput+0x9/0xde
[10458.222724]  [<ffffffff81057e16>] ? getrusage+0x34b/0x365
[10458.287227]  [<ffffffff810ec082>] ? kmem_cache_alloc+0x2a/0xe1
[10458.356924]  [<ffffffff812599e6>] ? sys_sendmsg+0x39/0x58
[10458.421420]  [<ffffffff81329d52>] ? system_call_fastpath+0x16/0x1b
[10562.540002] INFO: rcu_sched_state detected stall on CPU 10 (t=105060 jiffies)
[10562.543993] INFO: rcu_sched_state detected stall on CPU 4 (t=105060 jiffies)

^ permalink raw reply

* RE: [net-next 02/10] cirrus: Move the Cirrus network driver
From: H Hartley Sweeten @ 2011-08-12 17:29 UTC (permalink / raw)
  To: Jeff Kirsher, davem@davemloft.net
  Cc: netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com
In-Reply-To: <1313146371-6562-3-git-send-email-jeffrey.t.kirsher@intel.com>

On Friday, August 12, 2011 3:53 AM, Jeff Kirsher wrote:
>
> Move the Cirrus Ethernet driver into drivers/net/ethernet/cirrus/
> and make the necessary Kconfig and Makefile changes
>
> CC: Hartley Sweeten <hsweeten@visionengravers.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
>  MAINTAINERS                                       |    2 +-
>  drivers/net/arm/Kconfig                           |    8 ------
>  drivers/net/arm/Makefile                          |    1 -
>  drivers/net/ethernet/Kconfig                      |    1 +
>  drivers/net/ethernet/Makefile                     |    1 +
>  drivers/net/ethernet/cirrus/Kconfig               |   28 +++++++++++++++++++++
>  drivers/net/ethernet/cirrus/Makefile              |    5 +++
>  drivers/net/{arm => ethernet/cirrus}/ep93xx_eth.c |    0
>  8 files changed, 36 insertions(+), 10 deletions(-)
>  create mode 100644 drivers/net/ethernet/cirrus/Kconfig
>  create mode 100644 drivers/net/ethernet/cirrus/Makefile
>  rename drivers/net/{arm => ethernet/cirrus}/ep93xx_eth.c (100%)

Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>

Will the Kconfig change require an update to ep93xx_defconfig in order to
have CONFIG_EP93XX_ETH selected?

Currently it has these relevant selections:

CONFIG_NET=y
CONFIG_NETDEVICES=y
CONFIG_NET_ETHERNET=y
CONFIG_EP93XX_ETH=y

Will CONFIG_NET_VENDOR_CIRRUS need to be added or will kconfig figure out
the dependency automatically?

Regards,
Hartley

^ permalink raw reply

* Re: [RFC PATCH v2 0/9] bql: Byte Queue Limits
From: Stephen Hemminger @ 2011-08-12 18:20 UTC (permalink / raw)
  To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1108072129010.13386@pokey.mtv.corp.google.com>

On Sun, 7 Aug 2011 21:43:13 -0700 (PDT)
Tom Herbert <therbert@google.com> wrote:

> Changes from last version:
> - Simplified and generalized driver interface.  Drivers need to
>   implement two functions:
>     netdev_tx_completed_queue: Called at end of transmit completion
>       to inform stack of number of bytes and packets processed.
>     netdev_tx_sent_queue: Called to inform stack when packets are
>       queued.
> 
>     netdev_tx_reset_queue: is optional to reset state in the stack
> 
> - Added new per queue flags that allow stack to stop a queue
>   separately from driver doing this.  Driver continue using the
>   same functions to stop queues, but there are two functions that
>   the stack calls (to check if queue has been stopped by driver or
>   stack:
> 
>   netif_xmit_stopped,netif_xmit_frozen_or_stopped
> 
> - Added example support for bnx2x and sfc (demonstrates operation over
>   multi-queue)
> 
> - Removed BQL being under CONFIG_RPS (didn't add CONFIG_BQL)
> 
> - Still needs some more testing, including ishowing benfits to high
>   priority packets in QoS.
> ----
> 
> This patch series implements byte queue limits (bql) for NIC TX queues.
> 
> Byte queue limits are a mechanism to limit the size of the transmit
> hardware queue on a NIC by number of bytes. The goal of these byte
> limits is too reduce latency caused by excessive queuing in hardware
> without sacrificing throughput.
> 
> Hardware queuing limits are typically specified in terms of a number
> hardware descriptors, each of which has a variable size. The variability
> of the size of individual queued items can have a very wide range. For
> instance with the e1000 NIC the size could range from 64 bytes to 4K
> (with TSO enabled). This variability makes it next to impossible to
> choose a single queue limit that prevents starvation and provides lowest
> possible latency.
> 
> The objective of byte queue limits is to set the limit to be the
> minimum needed to prevent starvation between successive transmissions to
> the hardware. The latency between two transmissions can be variable in a
> system. It is dependent on interrupt frequency, NAPI polling latencies,
> scheduling of the queuing discipline, lock contention, etc. Therefore we
> propose that byte queue limits should be dynamic and change in
> iaccordance with networking stack latencies a system encounters.

A couple of other related points:

1. Need a way to configure the values.  My preference would be new
   netlink attribute and via 'ip link set' ...

2. Does this need to know the speed of the link (autonegotiation) or
   is it self clocking?



^ permalink raw reply

* Re: TCP port firewall controlled by UDP packets
From: Valdis.Kletnieks @ 2011-08-12 19:25 UTC (permalink / raw)
  To: Antonin Steinhauser
  Cc: Randy Dunlap, davem, kuznet, jmorris, yoshfuji, kaber, netdev,
	linux-kernel
In-Reply-To: <4E45482B.7080207@strmilov.cz>

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

On Fri, 12 Aug 2011 17:35:07 +0200, Antonin Steinhauser said:
> Dne 12.8.2011 02:13, Randy Dunlap napsal(a):
> > On Fri, 12 Aug 2011 01:56:09 +0200 Tonda wrote:
> >> +config TCPFIREWALL
> >> +	tristate "TCP Firewall controlled by UDP queries"
> >> +	depends on m
> >>
> > Why buildable only as a loadable module?
> >
> >
> Because it needs parameter - address of inet_protos table from
> /boot/System_map

That's probably a very good indication that you're doing it the wrong way, and
need to redesign what you're doing....


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

^ permalink raw reply

* [net-next 00/10] drivers/net organize Ethernet drivers (6th series)
From: Jeff Kirsher @ 2011-08-12 19:45 UTC (permalink / raw)
  To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann

This is the sixth of seven 10 patch series to move the Ethernet
drivers into drivers/net/ethernet/
  
The following are changes since commit b13ad8f498793dc582b7f42f27b8f44490bd608d:
  xilinx/ll_temac: Move the Xilinx drivers
and are available in the git repository at:
  master.kernel.org:/pub/scm/linux/kernel/git/jkirsher/next-organize master

Jeff Kirsher (10):
  ipg: Move the IC Plus driver
  korina: Move the IDT driver
  mipsnet: Move the MIPS driver
  lantiq: Move the Lantiq SoC driver
  bfin_mac: Move the Analog Devices Inc driver
  macb: Move the Atmel driver
  r6040: Move the RDC driver
  fealnx: Move the Myson driver
  forcedeth: Move the NVIDIA nForce driver
  starfire: Move the Adaptec driver

 MAINTAINERS                                        |   10 +-
 drivers/net/Kconfig                                |  140 --------------------
 drivers/net/Makefile                               |   12 --
 drivers/net/arm/Kconfig                            |   12 --
 drivers/net/arm/Makefile                           |    6 -
 drivers/net/ethernet/Kconfig                       |   38 ++++++
 drivers/net/ethernet/Makefile                      |   10 ++
 drivers/net/ethernet/adaptec/Kconfig               |   34 +++++
 drivers/net/ethernet/adaptec/Makefile              |    5 +
 drivers/net/{ => ethernet/adaptec}/starfire.c      |    0
 drivers/net/ethernet/adi/Kconfig                   |   68 ++++++++++
 drivers/net/ethernet/adi/Makefile                  |    5 +
 drivers/net/{ => ethernet/adi}/bfin_mac.c          |    0
 drivers/net/{ => ethernet/adi}/bfin_mac.h          |    0
 drivers/net/ethernet/cadence/Kconfig               |   44 ++++++
 drivers/net/ethernet/cadence/Makefile              |    6 +
 drivers/net/{arm => ethernet/cadence}/at91_ether.c |    0
 drivers/net/{arm => ethernet/cadence}/at91_ether.h |    0
 drivers/net/{ => ethernet/cadence}/macb.c          |    0
 drivers/net/{ => ethernet/cadence}/macb.h          |    0
 drivers/net/{ => ethernet}/fealnx.c                |    0
 drivers/net/ethernet/icplus/Kconfig                |   13 ++
 drivers/net/ethernet/icplus/Makefile               |    5 +
 drivers/net/{ => ethernet/icplus}/ipg.c            |    0
 drivers/net/{ => ethernet/icplus}/ipg.h            |    0
 drivers/net/{ => ethernet}/korina.c                |    0
 drivers/net/{ => ethernet}/lantiq_etop.c           |    0
 drivers/net/{ => ethernet}/mipsnet.c               |    0
 drivers/net/ethernet/nvidia/Kconfig                |   31 +++++
 drivers/net/ethernet/nvidia/Makefile               |    5 +
 drivers/net/{ => ethernet/nvidia}/forcedeth.c      |    0
 drivers/net/ethernet/rdc/Kconfig                   |   33 +++++
 drivers/net/ethernet/rdc/Makefile                  |    5 +
 drivers/net/{ => ethernet/rdc}/r6040.c             |    0
 34 files changed, 307 insertions(+), 175 deletions(-)
 delete mode 100644 drivers/net/arm/Kconfig
 delete mode 100644 drivers/net/arm/Makefile
 create mode 100644 drivers/net/ethernet/adaptec/Kconfig
 create mode 100644 drivers/net/ethernet/adaptec/Makefile
 rename drivers/net/{ => ethernet/adaptec}/starfire.c (100%)
 create mode 100644 drivers/net/ethernet/adi/Kconfig
 create mode 100644 drivers/net/ethernet/adi/Makefile
 rename drivers/net/{ => ethernet/adi}/bfin_mac.c (100%)
 rename drivers/net/{ => ethernet/adi}/bfin_mac.h (100%)
 create mode 100644 drivers/net/ethernet/cadence/Kconfig
 create mode 100644 drivers/net/ethernet/cadence/Makefile
 rename drivers/net/{arm => ethernet/cadence}/at91_ether.c (100%)
 rename drivers/net/{arm => ethernet/cadence}/at91_ether.h (100%)
 rename drivers/net/{ => ethernet/cadence}/macb.c (100%)
 rename drivers/net/{ => ethernet/cadence}/macb.h (100%)
 rename drivers/net/{ => ethernet}/fealnx.c (100%)
 create mode 100644 drivers/net/ethernet/icplus/Kconfig
 create mode 100644 drivers/net/ethernet/icplus/Makefile
 rename drivers/net/{ => ethernet/icplus}/ipg.c (100%)
 rename drivers/net/{ => ethernet/icplus}/ipg.h (100%)
 rename drivers/net/{ => ethernet}/korina.c (100%)
 rename drivers/net/{ => ethernet}/lantiq_etop.c (100%)
 rename drivers/net/{ => ethernet}/mipsnet.c (100%)
 create mode 100644 drivers/net/ethernet/nvidia/Kconfig
 create mode 100644 drivers/net/ethernet/nvidia/Makefile
 rename drivers/net/{ => ethernet/nvidia}/forcedeth.c (100%)
 create mode 100644 drivers/net/ethernet/rdc/Kconfig
 create mode 100644 drivers/net/ethernet/rdc/Makefile
 rename drivers/net/{ => ethernet/rdc}/r6040.c (100%)

-- 
1.7.6


^ permalink raw reply

* [net-next 01/10] ipg: Move the IC Plus driver
From: Jeff Kirsher @ 2011-08-12 19:45 UTC (permalink / raw)
  To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann, craig_rich, sorbica, jesse
In-Reply-To: <1313178344-8168-1-git-send-email-jeffrey.t.kirsher@intel.com>

Move the IC Plus driver into drivers/net/ethernet/icplus/ and
make the necessary Kconfig and Makefile changes.

CC: <craig_rich@sundanceti.com>
CC: <sorbica@icplus.com.tw>
CC: <jesse@icplus.com.tw>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 MAINTAINERS                             |    2 +-
 drivers/net/Kconfig                     |   10 ----------
 drivers/net/Makefile                    |    1 -
 drivers/net/ethernet/Kconfig            |    1 +
 drivers/net/ethernet/Makefile           |    1 +
 drivers/net/ethernet/icplus/Kconfig     |   13 +++++++++++++
 drivers/net/ethernet/icplus/Makefile    |    5 +++++
 drivers/net/{ => ethernet/icplus}/ipg.c |    0
 drivers/net/{ => ethernet/icplus}/ipg.h |    0
 9 files changed, 21 insertions(+), 12 deletions(-)
 create mode 100644 drivers/net/ethernet/icplus/Kconfig
 create mode 100644 drivers/net/ethernet/icplus/Makefile
 rename drivers/net/{ => ethernet/icplus}/ipg.c (100%)
 rename drivers/net/{ => ethernet/icplus}/ipg.h (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 37cbe14..879c17e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3443,7 +3443,7 @@ M:	Francois Romieu <romieu@fr.zoreil.com>
 M:	Sorbica Shieh <sorbica@icplus.com.tw>
 L:	netdev@vger.kernel.org
 S:	Maintained
-F:	drivers/net/ipg.*
+F:	drivers/net/ethernet/icplus/ipg.*
 
 IPATH DRIVER
 M:	Mike Marciniszyn <infinipath@qlogic.com>
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 2607a44..bcf7368 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -522,16 +522,6 @@ menuconfig NETDEV_1000
 
 if NETDEV_1000
 
-config IP1000
-	tristate "IP1000 Gigabit Ethernet support"
-	depends on PCI && EXPERIMENTAL
-	select MII
-	---help---
-	  This driver supports IP1000 gigabit Ethernet cards.
-
-	  To compile this driver as a module, choose M here: the module
-	  will be called ipg.  This is recommended.
-
 endif # NETDEV_1000
 
 #
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 4c7af02..2fb039b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -5,7 +5,6 @@
 obj-$(CONFIG_MII) += mii.o
 obj-$(CONFIG_MDIO) += mdio.o
 obj-$(CONFIG_PHYLIB) += phy/
-obj-$(CONFIG_IP1000) += ipg.o
 obj-$(CONFIG_CAN) += can/
 obj-$(CONFIG_BONDING) += bonding/
 obj-$(CONFIG_VMXNET3) += vmxnet3/
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 922f4d1..72d0f5e 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -31,6 +31,7 @@ source "drivers/net/ethernet/ibm/Kconfig"
 source "drivers/net/ethernet/intel/Kconfig"
 source "drivers/net/ethernet/i825xx/Kconfig"
 source "drivers/net/ethernet/xscale/Kconfig"
+source "drivers/net/ethernet/icplus/Kconfig"
 
 config JME
 	tristate "JMicron(R) PCI-Express Gigabit Ethernet support"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index fcecd5f..a8d8913 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_NET_VENDOR_IBM) += ibm/
 obj-$(CONFIG_NET_VENDOR_INTEL) += intel/
 obj-$(CONFIG_NET_VENDOR_I825XX) += i825xx/
 obj-$(CONFIG_NET_VENDOR_XSCALE) += xscale/
+obj-$(CONFIG_IP1000) += icplus/
 obj-$(CONFIG_JME) += jme.o
 obj-$(CONFIG_NET_VENDOR_MARVELL) += marvell/
 obj-$(CONFIG_NET_VENDOR_MELLANOX) += mellanox/
diff --git a/drivers/net/ethernet/icplus/Kconfig b/drivers/net/ethernet/icplus/Kconfig
new file mode 100644
index 0000000..e888222
--- /dev/null
+++ b/drivers/net/ethernet/icplus/Kconfig
@@ -0,0 +1,13 @@
+#
+# IC Plus device configuration
+#
+
+config IP1000
+	tristate "IP1000 Gigabit Ethernet support"
+	depends on PCI && EXPERIMENTAL
+	select MII
+	---help---
+	  This driver supports IP1000 gigabit Ethernet cards.
+
+	  To compile this driver as a module, choose M here: the module
+	  will be called ipg.  This is recommended.
diff --git a/drivers/net/ethernet/icplus/Makefile b/drivers/net/ethernet/icplus/Makefile
new file mode 100644
index 0000000..5bc87c1
--- /dev/null
+++ b/drivers/net/ethernet/icplus/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for the IC Plus device drivers
+#
+
+obj-$(CONFIG_IP1000) += ipg.o
diff --git a/drivers/net/ipg.c b/drivers/net/ethernet/icplus/ipg.c
similarity index 100%
rename from drivers/net/ipg.c
rename to drivers/net/ethernet/icplus/ipg.c
diff --git a/drivers/net/ipg.h b/drivers/net/ethernet/icplus/ipg.h
similarity index 100%
rename from drivers/net/ipg.h
rename to drivers/net/ethernet/icplus/ipg.h
-- 
1.7.6


^ permalink raw reply related

* [net-next 02/10] korina: Move the IDT driver
From: Jeff Kirsher @ 2011-08-12 19:45 UTC (permalink / raw)
  To: davem
  Cc: Jeff Kirsher, netdev, gospo, sassmann, IDT Inc., Felix Fietkau,
	Florian Fainelli
In-Reply-To: <1313178344-8168-1-git-send-email-jeffrey.t.kirsher@intel.com>

Move the IDT driver into drivers/net/ethernet/ and make the
necessary Kconfig and Makefile changes

CC: "IDT Inc." <rischelp@idt.com>
CC: Felix Fietkau <nbd@openwrt.org>
CC: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/Kconfig                 |    7 -------
 drivers/net/Makefile                |    1 -
 drivers/net/ethernet/Kconfig        |    7 +++++++
 drivers/net/ethernet/Makefile       |    1 +
 drivers/net/{ => ethernet}/korina.c |    0
 5 files changed, 8 insertions(+), 8 deletions(-)
 rename drivers/net/{ => ethernet}/korina.c (100%)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index bcf7368..d9b3cb5 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -237,13 +237,6 @@ config MACB
 
 source "drivers/net/arm/Kconfig"
 
-config KORINA
-	tristate "Korina (IDT RC32434) Ethernet support"
-	depends on NET_ETHERNET && MIKROTIK_RB532
-	help
-	  If you have a Mikrotik RouterBoard 500 or IDT RC32434
-	  based system say Y. Otherwise say N.
-
 config MIPS_SIM_NET
 	tristate "MIPS simulator Network device"
 	depends on MIPS_SIM
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 2fb039b..6c17cb6 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -54,7 +54,6 @@ obj-$(CONFIG_MACVLAN) += macvlan.o
 obj-$(CONFIG_MACVTAP) += macvtap.o
 obj-$(CONFIG_DEFXX) += defxx.o
 obj-$(CONFIG_EQUALIZER) += eql.o
-obj-$(CONFIG_KORINA) += korina.o
 obj-$(CONFIG_MIPS_SIM_NET) += mipsnet.o
 obj-$(CONFIG_TUN) += tun.o
 obj-$(CONFIG_VETH) += veth.o
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index 72d0f5e..dae10a3 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -45,6 +45,13 @@ config JME
 	  To compile this driver as a module, choose M here. The module
 	  will be called jme.
 
+config KORINA
+	tristate "Korina (IDT RC32434) Ethernet support"
+	depends on MIKROTIK_RB532
+	---help---
+	  If you have a Mikrotik RouterBoard 500 or IDT RC32434
+	  based system say Y. Otherwise say N.
+
 source "drivers/net/ethernet/marvell/Kconfig"
 source "drivers/net/ethernet/mellanox/Kconfig"
 source "drivers/net/ethernet/micrel/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index a8d8913..ddf097d 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_NET_VENDOR_I825XX) += i825xx/
 obj-$(CONFIG_NET_VENDOR_XSCALE) += xscale/
 obj-$(CONFIG_IP1000) += icplus/
 obj-$(CONFIG_JME) += jme.o
+obj-$(CONFIG_KORINA) += korina.o
 obj-$(CONFIG_NET_VENDOR_MARVELL) += marvell/
 obj-$(CONFIG_NET_VENDOR_MELLANOX) += mellanox/
 obj-$(CONFIG_NET_VENDOR_MICREL) += micrel/
diff --git a/drivers/net/korina.c b/drivers/net/ethernet/korina.c
similarity index 100%
rename from drivers/net/korina.c
rename to drivers/net/ethernet/korina.c
-- 
1.7.6


^ permalink raw reply related

* [net-next 03/10] mipsnet: Move the MIPS driver
From: Jeff Kirsher @ 2011-08-12 19:45 UTC (permalink / raw)
  To: davem; +Cc: Jeff Kirsher, netdev, gospo, sassmann
In-Reply-To: <1313178344-8168-1-git-send-email-jeffrey.t.kirsher@intel.com>

Move the MIPS drivers into drivers/net/ethernet/ and
make the necessary Kconfig and Makefile changes.

Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
 drivers/net/Kconfig                  |    8 --------
 drivers/net/Makefile                 |    1 -
 drivers/net/ethernet/Kconfig         |    9 +++++++++
 drivers/net/ethernet/Makefile        |    1 +
 drivers/net/{ => ethernet}/mipsnet.c |    0
 5 files changed, 10 insertions(+), 9 deletions(-)
 rename drivers/net/{ => ethernet}/mipsnet.c (100%)

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index d9b3cb5..d38cad2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -237,14 +237,6 @@ config MACB
 
 source "drivers/net/arm/Kconfig"
 
-config MIPS_SIM_NET
-	tristate "MIPS simulator Network device"
-	depends on MIPS_SIM
-	help
-	  The MIPSNET device is a simple Ethernet network device which is
-	  emulated by the MIPS Simulator.
-	  If you are not using a MIPSsim or are unsure, say N.
-
 config SH_ETH
 	tristate "Renesas SuperH Ethernet support"
 	depends on SUPERH && \
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 6c17cb6..389c268 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -54,7 +54,6 @@ obj-$(CONFIG_MACVLAN) += macvlan.o
 obj-$(CONFIG_MACVTAP) += macvtap.o
 obj-$(CONFIG_DEFXX) += defxx.o
 obj-$(CONFIG_EQUALIZER) += eql.o
-obj-$(CONFIG_MIPS_SIM_NET) += mipsnet.o
 obj-$(CONFIG_TUN) += tun.o
 obj-$(CONFIG_VETH) += veth.o
 obj-$(CONFIG_NET_NETX) += netx-eth.o
diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig
index dae10a3..f1509a5 100644
--- a/drivers/net/ethernet/Kconfig
+++ b/drivers/net/ethernet/Kconfig
@@ -55,6 +55,15 @@ config KORINA
 source "drivers/net/ethernet/marvell/Kconfig"
 source "drivers/net/ethernet/mellanox/Kconfig"
 source "drivers/net/ethernet/micrel/Kconfig"
+
+config MIPS_SIM_NET
+	tristate "MIPS simulator Network device"
+	depends on MIPS_SIM
+	---help---
+	  The MIPSNET device is a simple Ethernet network device which is
+	  emulated by the MIPS Simulator.
+	  If you are not using a MIPSsim or are unsure, say N.
+
 source "drivers/net/ethernet/myricom/Kconfig"
 source "drivers/net/ethernet/natsemi/Kconfig"
 source "drivers/net/ethernet/8390/Kconfig"
diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile
index ddf097d..50fc50a 100644
--- a/drivers/net/ethernet/Makefile
+++ b/drivers/net/ethernet/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_KORINA) += korina.o
 obj-$(CONFIG_NET_VENDOR_MARVELL) += marvell/
 obj-$(CONFIG_NET_VENDOR_MELLANOX) += mellanox/
 obj-$(CONFIG_NET_VENDOR_MICREL) += micrel/
+obj-$(CONFIG_MIPS_SIM_NET) += mipsnet.o
 obj-$(CONFIG_NET_VENDOR_MYRI) += myricom/
 obj-$(CONFIG_NET_VENDOR_NATSEMI) += natsemi/
 obj-$(CONFIG_NET_VENDOR_NUVOTON) += nuvoton/
diff --git a/drivers/net/mipsnet.c b/drivers/net/ethernet/mipsnet.c
similarity index 100%
rename from drivers/net/mipsnet.c
rename to drivers/net/ethernet/mipsnet.c
-- 
1.7.6


^ 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