Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH 3/3] qlcnic: change module parameter permissions
From: David Miller @ 2011-01-10 21:35 UTC (permalink / raw)
  To: amit.salecha; +Cc: netdev, ameen.rahman, anirban.chakraborty
In-Reply-To: <1294654523-3085-4-git-send-email-amit.salecha@qlogic.com>

From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 10 Jan 2011 02:15:23 -0800

> o Updating module parameter after driver load is not supported
>   except auto_fw_reset parameter. Changing these parameter after
>   driver load, can have weird result.
> 
> o Update driver version to 5.0.15.
> 
> Signed-off-by: Amit Kumar Salecha <amit.salecha@qlogic.com>

Applied.

^ permalink raw reply

* Re: [PATCH 2/3] net/dummy: add device group parameter
From: David Miller @ 2011-01-10 21:37 UTC (permalink / raw)
  To: ddvlad; +Cc: netdev, hadi, opurdila
In-Reply-To: <1294659524-22509-3-git-send-email-ddvlad@rosedu.org>

From: Vlad Dogaru <ddvlad@rosedu.org>
Date: Mon, 10 Jan 2011 13:38:43 +0200

> When inserting the dummy module, the user can specify the group of the
> dummy devices. This avoids manually moving the newly created pseudo
> devices to a different group.
> 
> Signed-off-by: Vlad Dogaru <ddvlad@rosedu.org>

The amount of hacks people wish to add to the dummy driver is one step
away from amazing.

Just use the standard APIs to add dummy devices to the group you want,
instead of these ad-hoc device specific module parameters.

Thanks.

^ permalink raw reply

* [PATCH net-26] cxgb4vf: fix mailbox data/control coherency domain race
From: Casey Leedom @ 2011-01-10 21:51 UTC (permalink / raw)
  To: netdev; +Cc: davem, Casey Leedom

For the VFs, the Mailbox Data "registers" are actually backed by
T4's "MA" interface rather than PL Registers (as is the case for
the PFs).  Because these are in different coherency domains, the
write to the VF's PL-register-backed Mailbox Control can race in
front of the writes to the MA-backed VF Mailbox Data "registers".
So we need to do a read-back on at least one byte of the VF Mailbox
Data registers before doing the write to the VF Mailbox Control
register.

Signed-off-by: Casey Leedom <leedom@chelsio.com>
---
 drivers/net/cxgb4vf/t4vf_hw.c |   11 +++++++++++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/net/cxgb4vf/t4vf_hw.c b/drivers/net/cxgb4vf/t4vf_hw.c
index e4bec78..0f51c80 100644
--- a/drivers/net/cxgb4vf/t4vf_hw.c
+++ b/drivers/net/cxgb4vf/t4vf_hw.c
@@ -147,9 +147,20 @@ int t4vf_wr_mbox_core(struct adapter *adapter, const void *cmd, int size,
 	/*
 	 * Write the command array into the Mailbox Data register array and
 	 * transfer ownership of the mailbox to the firmware.
+	 *
+	 * For the VFs, the Mailbox Data "registers" are actually backed by
+	 * T4's "MA" interface rather than PL Registers (as is the case for
+	 * the PFs).  Because these are in different coherency domains, the
+	 * write to the VF's PL-register-backed Mailbox Control can race in
+	 * front of the writes to the MA-backed VF Mailbox Data "registers".
+	 * So we need to do a read-back on at least one byte of the VF Mailbox
+	 * Data registers before doing the write to the VF Mailbox Control
+	 * register.
 	 */
 	for (i = 0, p = cmd; i < size; i += 8)
 		t4_write_reg64(adapter, mbox_data + i, be64_to_cpu(*p++));
+	t4_read_reg(adapter, mbox_data);         /* flush write */
+
 	t4_write_reg(adapter, mbox_ctl,
 		     MBMSGVALID | MBOWNER(MBOX_OWNER_FW));
 	t4_read_reg(adapter, mbox_ctl);          /* flush write */
-- 
1.7.0.4


^ permalink raw reply related

* Re: [PATCH net-26] cxgb4vf: fix mailbox data/control coherency domain race
From: David Miller @ 2011-01-10 21:56 UTC (permalink / raw)
  To: leedom; +Cc: netdev
In-Reply-To: <1294696261-21209-1-git-send-email-leedom@chelsio.com>

From: Casey Leedom <leedom@chelsio.com>
Date: Mon, 10 Jan 2011 13:51:01 -0800

> For the VFs, the Mailbox Data "registers" are actually backed by
> T4's "MA" interface rather than PL Registers (as is the case for
> the PFs).  Because these are in different coherency domains, the
> write to the VF's PL-register-backed Mailbox Control can race in
> front of the writes to the MA-backed VF Mailbox Data "registers".
> So we need to do a read-back on at least one byte of the VF Mailbox
> Data registers before doing the write to the VF Mailbox Control
> register.
> 
> Signed-off-by: Casey Leedom <leedom@chelsio.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] UDPCP Communication Protocol
From: Hagen Paul Pfeifer @ 2011-01-10 22:28 UTC (permalink / raw)
  To: Stefani Seibold; +Cc: Eric Dumazet, linux-kernel, akpm, davem, netdev
In-Reply-To: <1293918016.28646.3.camel@wall-e>

* Stefani Seibold | 2011-01-01 22:40:16 [+0100]:

>> > I cannot fix it, because the information is still lost, and i need it. 
>> > 
>> 
>> You can fix it. Really. If not, you can pay me and I'll fix it for you.
>> 
>
>I am a poor girl, so i did it by me self. Hope you like the new
>approach.

Stefani, Eric try to support your effort and helps you the whole time. You
should trust him and align your effort more on his tips and the way the
kernel is developed.

^ permalink raw reply

* Re: [PATCH] UDPCP Communication Protocol
From: Jesper Juhl @ 2011-01-10 22:53 UTC (permalink / raw)
  To: stefani; +Cc: linux-kernel, akpm, davem, netdev
In-Reply-To: <1293787785-3834-1-git-send-email-stefani@seibold.net>


stefani@seibold.net wrote:
+static int udpcp_xmit(struct sock *sk, struct udpcp_dest *dest)
+{
+       struct udpcp_sock *usk = udpcp_sk(sk);
+       int ret;
+
+       ret = _udpcp_xmit(sk, dest);
+
+       if (dest->xmit_wait) {
+               dest->tx_time = jiffies;
+
+               if (!timer_pending(&usk->timer))
+                       udpcp_timer(sk, dest->tx_time + usk->tx_timeout);
+       }
+       return ret;
+}

Wouldn't this be slightly nicer as 

static int udpcp_xmit(struct sock *sk, struct udpcp_dest *dest)
{
       int ret = _udpcp_xmit(sk, dest);

       if (dest->xmit_wait) {
               struct udpcp_sock *usk = udpcp_sk(sk);
               dest->tx_time = jiffies;
               if (!timer_pending(&usk->timer))
                       udpcp_timer(sk, dest->tx_time + usk->tx_timeout);
       }
       return ret;
}

??

-- 
Jesper Juhl <jj@chaosbits.net>            http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.


^ permalink raw reply

* RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3
From: Dave, Tushar N @ 2011-01-10 23:11 UTC (permalink / raw)
  To: Chris Rankin, e1000-devel@lists.sourceforge.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <913138.52057.qm@web121710.mail.ne1.yahoo.com>

Chris,
Sorry to hear that you have the issue. 
Does the issue appears only when you add a bridge?

Thanks.

-Tushar

-----Original Message-----
From: Chris Rankin [mailto:rankincj@yahoo.com] 
Sent: Saturday, January 08, 2011 4:54 AM
To: e1000-devel@lists.sourceforge.net
Cc: netdev@vger.kernel.org
Subject: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

Hi,

I've just booted 2.6.36.3 on my old router box (which contains one single e100 card, and one dual-port e100 card), and have discovered this rather scary message in the dmesg log:

e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
e100 0000:00:0f.0: PME# disabled
e100 0000:00:0f.0: eth0: addr 0xffbeb000, irq 10, MAC addr 00:90:27:76:d0:ec
e100 0000:01:04.0: PME# disabled
e100 0000:01:04.0: eth1: addr 0xff0fe000, irq 11, MAC addr 00:03:47:3b:29:5c
e100 0000:01:05.0: PME# disabled
e100 0000:01:05.0: eth2: addr 0xff0ff000, irq 10, MAC addr 00:03:47:3b:29:5d
...
device eth1 entered promiscuous mode
ADDRCONF(NETDEV_UP): eth1: link is not ready
e100 0000:01:04.0: eth1: NIC Link is Up 100 Mbps Full Duplex
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
device eth2 entered promiscuous mode
ADDRCONF(NETDEV_UP): eth2: link is not ready
br0: port 1(eth1) entering learning state
br0: port 1(eth1) entering learning state
ifconfig: page allocation failure. order:6, mode:0x8020
Pid: 3716, comm: ifconfig Not tainted 2.6.36.3 #1
Call Trace:
 [<c104b2a9>] ? __alloc_pages_nodemask+0x477/0x4a6
 [<c106177d>] ? __slab_alloc+0x1eb/0x396
 [<c1004ca6>] ? dma_generic_alloc_coherent+0x4e/0xac
 [<c105fb5c>] ? dma_pool_alloc+0xe5/0x1d9
 [<c1004c58>] ? dma_generic_alloc_coherent+0x0/0xac
 [<c58f97f3>] ? e100_rx_alloc_skb+0x87/0x122 [e100]
 [<c58f9883>] ? e100_rx_alloc_skb+0x117/0x122 [e100]
 [<c58f98dc>] ? e100_alloc_cbs+0x4e/0xfa [e100]
 [<c58fb370>] ? e100_up+0x1b/0xf1 [e100]
 [<c58fb45d>] ? e100_open+0x17/0x3b [e100]
 [<c1121630>] ? __dev_open+0x7c/0xa0
 [<c11217ed>] ? __dev_change_flags+0x8b/0x100
 [<c11218c3>] ? dev_change_flags+0x10/0x3b
 [<c1159880>] ? devinet_ioctl+0x25a/0x532
 [<c11146d2>] ? sock_ioctl+0x1a8/0x1ca
 [<c111452a>] ? sock_ioctl+0x0/0x1ca
 [<c106e061>] ? do_vfs_ioctl+0x464/0x4a2
 [<c1014ce0>] ? do_page_fault+0x2d2/0x2ea
 [<c1014cc8>] ? do_page_fault+0x2ba/0x2ea
 [<c10636f6>] ? sys_faccessat+0x144/0x151
 [<c106e0cc>] ? sys_ioctl+0x2d/0x49
 [<c1177dd5>] ? syscall_call+0x7/0xb
Mem-Info:
DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
Normal per-cpu:
CPU    0: hi:    6, btch:   1 usd:   0
active_anon:280 inactive_anon:808 isolated_anon:0
 active_file:1384 inactive_file:9672 isolated_file:0
 unevictable:0 dirty:77 writeback:0 unstable:0
 free:753 slab_reclaimable:499 slab_unreclaimable:1393
 mapped:375 shmem:643 pagetables:59 bounce:0
DMA free:1492kB min:248kB low:308kB high:372kB active_anon:0kB inactive_anon:12kB active_file:288kB inactive_file:12548kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15864kB mlocked:0kB dirty:48kB writeback:0kB mapped:28kB shmem:0kB slab_reclaimable:312kB slab_unreclaimable:884kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 47 47
Normal free:1520kB min:764kB low:952kB high:1144kB active_anon:1120kB inactive_anon:3220kB active_file:5248kB inactive_file:26140kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:48768kB mlocked:0kB dirty:260kB writeback:0kB mapped:1472kB shmem:2572kB slab_reclaimable:1684kB slab_unreclaimable:4688kB kernel_stack:176kB pagetables:236kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 51*4kB 23*8kB 3*16kB 3*32kB 7*64kB 4*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1492kB
Normal: 260*4kB 26*8kB 1*16kB 0*32kB 0*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1520kB
11715 total pagecache pages
16 pages in swap cache
Swap cache stats: add 44, delete 28, find 72/72
Free swap  = 2179532kB
Total swap = 2179596kB
16383 pages RAM
826 pages reserved
10736 pages shared
5361 pages non-shared
ADDRCONF(NETDEV_UP): eth0: link is not ready
e100 0000:00:0f.0: eth0: NIC Link is Up 100 Mbps Full Duplex
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
br0: port 1(eth1) entering forwarding state

Should I be concerned, please? All three e100 devices still appear to be working, but something nasty seems to have happened anyway.

The lspci output for these devices is:
00:0f.0 0200: 8086:1229 (rev 08)
	Subsystem: 8086:000c
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 72 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at ffbeb000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at ef00 [size=64]
	Region 2: Memory at fef00000 (32-bit, non-prefetchable) [size=1M]
	[virtual] Expansion ROM at 04000000 [disabled] [size=1M]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=2 PME-
	Kernel driver in use: e100
	Kernel modules: e100

01:04.0 0200: 8086:1229 (rev 05)
	Subsystem: 8086:10f0
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 72 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at ff0fe000 (32-bit, prefetchable) [size=4K]
	Region 1: I/O ports at fcc0 [size=32]
	Region 2: Memory at ff700000 (32-bit, non-prefetchable) [size=1M]
	[virtual] Expansion ROM at ff100000 [disabled] [size=1M]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: e100
	Kernel modules: e100

01:05.0 0200: 8086:1229 (rev 05)
	Subsystem: 8086:10f0
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 72 (2000ns min, 14000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 10
	Region 0: Memory at ff0ff000 (32-bit, prefetchable) [size=4K]
	Region 1: I/O ports at fce0 [size=32]
	Region 2: Memory at ff900000 (32-bit, non-prefetchable) [size=1M]
	[virtual] Expansion ROM at ff200000 [disabled] [size=1M]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Kernel driver in use: e100
	Kernel modules: e100

Thanks,
Chris


      

------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

^ permalink raw reply

* [PATCH] cxgb3i: fixed connection problem with iscsi private ip
From: kxie @ 2011-01-10 23:15 UTC (permalink / raw)
  To: netdev, linux-scsi, open-iscsi; +Cc: kxie, davem, James.Bottomley, michaelc

[PATCH] cxgb3i: fixed connection problem with iscsi private ip

From: Karen Xie <kxie@chelsio.com>

fixed the connection problem when the private iscsi ipv4 address is provisioned on the interface.

Signed-off-by: Karen Xie <kxie@chelsio.com>
---
 drivers/scsi/cxgbi/cxgb3i/cxgb3i.h |   18 ++++++++++++++----
 1 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
index 5f5e339..bed14db 100644
--- a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
+++ b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
@@ -24,10 +24,20 @@
 
 extern cxgb3_cpl_handler_func cxgb3i_cpl_handlers[NUM_CPL_CMDS];
 
-#define cxgb3i_get_private_ipv4addr(ndev) \
-	(((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr)
-#define cxgb3i_set_private_ipv4addr(ndev, addr) \
-	(((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr) = addr
+static inline unsigned int cxgb3i_get_private_ipv4addr(struct net_device *ndev)
+{
+	return ((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr;
+}
+
+static inline void cxgb3i_set_private_ipv4addr(struct net_device *ndev,
+					unsigned int addr)
+{
+	struct port_info *pi =  (struct port_info *)netdev_priv(ndev);
+
+	pi->iscsic.flags = addr ? 1 : 0;
+	pi->iscsi_ipv4addr = addr;
+	if (addr)
+		memcpy(pi->iscsic.mac_addr, ndev->dev_addr, ETH_ALEN);
+}
 
 struct cpl_iscsi_hdr_norss {
 	union opcode_tid ot;

^ permalink raw reply related

* [PATCH] caif: don't set connection request param size before copying data
From: Dan Rosenberg @ 2011-01-10 23:36 UTC (permalink / raw)
  To: Sjur Braendeland, David S. Miller; +Cc: netdev

The size field should not be set until after the data is successfully
copied in.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
---
 net/caif/caif_socket.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/caif/caif_socket.c b/net/caif/caif_socket.c
index 1bf0cf5..8184c03 100644
--- a/net/caif/caif_socket.c
+++ b/net/caif/caif_socket.c
@@ -740,12 +740,12 @@ static int setsockopt(struct socket *sock,
 		if (cf_sk->sk.sk_protocol != CAIFPROTO_UTIL)
 			return -ENOPROTOOPT;
 		lock_sock(&(cf_sk->sk));
-		cf_sk->conn_req.param.size = ol;
 		if (ol > sizeof(cf_sk->conn_req.param.data) ||
 			copy_from_user(&cf_sk->conn_req.param.data, ov, ol)) {
 			release_sock(&cf_sk->sk);
 			return -EINVAL;
 		}
+		cf_sk->conn_req.param.size = ol;
 		release_sock(&cf_sk->sk);
 		return 0;
 



^ permalink raw reply related

* RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3
From: Chris Rankin @ 2011-01-10 23:41 UTC (permalink / raw)
  To: e1000-devel@lists.sourceforge.net, Tushar NDave; +Cc: netdev@vger.kernel.org
In-Reply-To: <F675EE07F28A0A4E933E5F9DD28672FB01197E08E2@orsmsx508.amr.corp.intel.com>

--- On Mon, 10/1/11, Dave, Tushar N <tushar.n.dave@intel.com> wrote:
> Does the issue appears only when you add a bridge?

Tushar,

I'm not sure what you mean by "add a bridge". I've been using this box ever since the late 1990s, and have had the 3 e100 port since the early 2000s, so I can't say that I "do" anything with it apart from use it. 

The PCI configuration remains as it always has, and the box get rebooted only to receive stable kernel updates. Looking back through old dmesg logs, it looks like this issue also happened in 2.6.33.6 too without me ever realising. Hence I am suspecting that this problem has been happening intermittently for ages...

Is there anything else I can tell you about this ropey old P200 MMX PC before Indiana Jones finds it and tries putting it in his museum ;-)?

Cheers,
Chris


      

^ permalink raw reply

* [RFC] sched: CHOKe packet scheduler (v0.4)
From: Stephen Hemminger @ 2011-01-10 23:44 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1294667210.3491.7.camel@edumazet-laptop>

This implements the CHOKe packet scheduler based on the existing
Linux RED scheduler based on the algorithm described in the paper.

The core idea is:
  For every packet arrival:
  	Calculate Qave
	if (Qave < minth) 
	     Queue the new packet
	else 
	     Select randomly a packet from the queue 
	     if (both packets from same flow)
	     then Drop both the packets
	     else if (Qave > maxth)
	          Drop packet
	     else
	       	  Admit packet with proability p (same as RED)

See also:
  Rong Pan, Balaji Prabhakar, Konstantinos Psounis, "CHOKe: a stateless active
   queue management scheme for approximating fair bandwidth allocation", 
  Proceeding of INFOCOM'2000, March 2000. 

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

---
0.3 version from Eric uses table for queue.
0.4 allows classification with TC filters
    fixes crash when peek_random() finds a hole

 net/sched/Kconfig     |   11 +
 net/sched/Makefile    |    1 
 net/sched/sch_choke.c |  527 ++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 539 insertions(+)

--- a/net/sched/Kconfig	2011-01-10 09:17:25.328637817 -0800
+++ b/net/sched/Kconfig	2011-01-10 12:11:40.489701227 -0800
@@ -205,6 +205,17 @@ config NET_SCH_DRR
 
 	  If unsure, say N.
 
+config NET_SCH_CHOKE
+	tristate "CHOose and Keep responsive flow scheduler (CHOKE)"
+	help
+	  Say Y here if you want to use the CHOKe packet scheduler (CHOose
+	  and Keep for responsive flows, CHOose and Kill for unresponsive
+	  flows). This is a variation of RED which trys to penalize flows
+	  that monopolize the queue.
+
+	  To compile this code as a module, choose M here: the
+	  module will be called sch_choke.
+
 config NET_SCH_INGRESS
 	tristate "Ingress Qdisc"
 	depends on NET_CLS_ACT
--- a/net/sched/Makefile	2011-01-10 09:17:25.336639744 -0800
+++ b/net/sched/Makefile	2011-01-10 12:11:40.489701227 -0800
@@ -32,6 +32,7 @@ obj-$(CONFIG_NET_SCH_MULTIQ)	+= sch_mult
 obj-$(CONFIG_NET_SCH_ATM)	+= sch_atm.o
 obj-$(CONFIG_NET_SCH_NETEM)	+= sch_netem.o
 obj-$(CONFIG_NET_SCH_DRR)	+= sch_drr.o
+obj-$(CONFIG_NET_SCH_CHOKE)	+= sch_choke.o
 obj-$(CONFIG_NET_CLS_U32)	+= cls_u32.o
 obj-$(CONFIG_NET_CLS_ROUTE4)	+= cls_route.o
 obj-$(CONFIG_NET_CLS_FW)	+= cls_fw.o
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ b/net/sched/sch_choke.c	2011-01-10 12:40:32.802282618 -0800
@@ -0,0 +1,527 @@
+/*
+ * net/sched/sch_choke.c	CHOKE scheduler
+ *
+ * Copyright (c) 2011 Stephen Hemminger <shemminger@vyatta.com>
+ * Copyright (c) 2011 Eric Dumazet <eric.dumazet@gmail.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/skbuff.h>
+#include <linux/reciprocal_div.h>
+#include <net/pkt_sched.h>
+#include <net/inet_ecn.h>
+#include <net/red.h>
+
+/*	CHOKe stateless AQM for fair bandwidth allocation
+        =================================================
+
+   CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for
+   unresponsive flows) is a variant of RED that penalizes misbehaving flows but
+   maintains no flow state. The difference from RED is an additional step
+   during the enqueuing process. If average queue size is over the
+   low threshold (qmin), a packet is chosen at random from the queue.
+   If both the new and chosen packet are from the same flow, both
+   are dropped. Unlike RED, CHOKe is not really a "classful" qdisc because it
+   needs to access packets in queue randomly. It has a minimal class
+   interface to allow overriding the builtin flow classifier with
+   filters.
+
+   Source:
+   R. Pan, B. Prabhakar, and K. Psounis, "CHOKe, A Stateless
+   Active Queue Management Scheme for Approximating Fair Bandwidth Allocation",
+   IEEE INFOCOM, 2000.
+
+   A. Tang, J. Wang, S. Low, "Understanding CHOKe: Throughput and Spatial
+   Characteristics", IEEE/ACM Transactions on Networking, 2004
+
+ */
+
+struct choke_sched_data {
+/* Parameters */
+	u32		 limit;
+	unsigned char	 flags;
+
+	struct red_parms parms;
+	struct red_stats stats;
+
+/* Variables */
+	struct tcf_proto *filter_list;
+	unsigned int	 head;
+	unsigned int	 tail;
+	unsigned int	 holes;
+	unsigned int	 tab_mask; /* size - 1 */
+
+	struct sk_buff **tab;
+};
+
+static inline unsigned int choke_len(const struct choke_sched_data *q)
+{
+	return (q->tail - q->head) & q->tab_mask;
+}
+
+/* deliver a random number between 0 and N - 1 */
+static inline u32 random_N(unsigned int N)
+{
+	return reciprocal_divide(random32(), N);
+}
+
+
+/* Select a packet at random from the queue in O(1) and handle holes */
+static struct sk_buff *choke_peek_random(struct choke_sched_data *q,
+					 unsigned int *pidx)
+{
+	struct sk_buff *skb;
+	int retrys = 3;
+
+	do {
+		*pidx = (q->head + random_N(choke_len(q))) & q->tab_mask;
+		skb = q->tab[*pidx];
+		if (skb)
+			return skb;
+	} while (--retrys > 0);
+
+	/* queue is has lots of holes use the head which is known to exist */
+	return q->tab[*pidx = q->head];
+}
+
+/* Is ECN parameter configured */
+static inline int use_ecn(const struct choke_sched_data *q)
+{
+	return q->flags & TC_RED_ECN;
+}
+
+/* Should packets over max just be dropped (versus marked) */
+static inline int use_harddrop(const struct choke_sched_data *q)
+{
+	return q->flags & TC_RED_HARDDROP;
+}
+
+/* Move head pointer forward to skip over holes */
+static void choke_zap_head_holes(struct choke_sched_data *q)
+{
+	while (q->holes && q->tab[q->head] == NULL) {
+		q->head = (q->head + 1) & q->tab_mask;
+		q->holes--;
+	}
+}
+
+/* Move tail pointer backwards to reuse holes */
+static void choke_zap_tail_holes(struct choke_sched_data *q)
+{
+	while (q->holes && q->tab[q->tail - 1] == NULL) {
+		q->tail = (q->tail - 1) & q->tab_mask;
+		q->holes--;
+	}
+}
+
+/* Drop packet from queue array by creating a "hole" */
+static void choke_drop_by_idx(struct choke_sched_data *q, unsigned int idx)
+{
+	q->tab[idx] = NULL;
+	q->holes++;
+
+	if (idx == q->head)
+		choke_zap_head_holes(q);
+	if (idx == q->tail)
+		choke_zap_tail_holes(q);
+}
+
+/* Classify flow using either:
+   1. pre-existing classification result in skb
+   2. fast internal classification
+   3. use TC filter based classification
+*/
+static inline unsigned int choke_classify(struct sk_buff *skb,
+					  struct Qdisc *sch, int *qerr)
+
+{
+	struct choke_sched_data *q = qdisc_priv(sch);
+	struct tcf_result res;
+	int result;
+
+	*qerr = NET_XMIT_SUCCESS | __NET_XMIT_BYPASS;
+
+	if (TC_H_MAJ(skb->priority) == sch->handle &&
+	    TC_H_MIN(skb->priority) > 0)
+		return TC_H_MIN(skb->priority);
+
+	if (!q->filter_list)
+		return skb_get_rxhash(skb);
+
+	result = tc_classify(skb, q->filter_list, &res);
+	if (result >= 0) {
+#ifdef CONFIG_NET_CLS_ACT
+		switch (result) {
+		case TC_ACT_STOLEN:
+		case TC_ACT_QUEUED:
+			*qerr = NET_XMIT_SUCCESS | __NET_XMIT_STOLEN;
+		case TC_ACT_SHOT:
+			return 0;
+		}
+#endif
+		return TC_H_MIN(res.classid);
+	}
+
+	return 0;
+}
+
+static int choke_enqueue(struct sk_buff *skb, struct Qdisc *sch)
+{
+	struct choke_sched_data *q = qdisc_priv(sch);
+	struct red_parms *p = &q->parms;
+	unsigned int hash;
+	int uninitialized_var(ret);
+
+	hash = choke_classify(skb, sch, &ret);
+	if (unlikely(!hash)) {
+		if (ret & __NET_XMIT_BYPASS)
+			sch->qstats.drops++;
+		kfree_skb(skb);
+		return ret;
+	}
+
+	/* XXX add hash to qdisc_skb_cb? */
+	*(unsigned int *)(qdisc_skb_cb(skb)->data) = hash;
+
+	/* Compute average queue usage (see RED) */
+	p->qavg = red_calc_qavg(p, choke_len(q) - q->holes);
+	if (red_is_idling(p))
+		red_end_of_idle_period(p);
+
+	/* Is queue small? */
+	if (p->qavg <= p->qth_min)
+		p->qcount = -1;
+	else {
+		struct sk_buff *oskb;
+		unsigned int idx;
+
+		/* Draw a packet at random from queue */
+		oskb = choke_peek_random(q, &idx);
+
+		/* Both packets from same flow ? */
+		if (*(unsigned int *)(qdisc_skb_cb(oskb)->data) == hash) {
+			/* Drop both packets */
+			choke_drop_by_idx(q, idx);
+			qdisc_drop(oskb, sch);
+			goto congestion_drop;
+		}
+
+		if (p->qavg > p->qth_max) {
+			p->qcount = -1;
+
+			sch->qstats.overlimits++;
+			if (use_harddrop(q) || !use_ecn(q) ||
+			    !INET_ECN_set_ce(skb)) {
+				q->stats.forced_drop++;
+				goto congestion_drop;
+			}
+
+			q->stats.forced_mark++;
+		}
+
+		if (++p->qcount) {
+			if (red_mark_probability(p, p->qavg)) {
+				p->qcount = 0;
+				p->qR = red_random(p);
+
+				sch->qstats.overlimits++;
+				if (!use_ecn(q) || !INET_ECN_set_ce(skb)) {
+					q->stats.prob_drop++;
+					goto congestion_drop;
+				}
+
+				q->stats.prob_mark++;
+			}
+		} else
+			p->qR = red_random(p);
+	}
+
+	/* Admit new packet */
+	if (likely(choke_len(q) < q->limit)) {
+		q->tab[q->tail] = skb;
+		q->tail = (q->tail + 1) & q->tab_mask;
+
+		sch->qstats.backlog += qdisc_pkt_len(skb);
+		__qdisc_update_bstats(sch, qdisc_pkt_len(skb));
+		return NET_XMIT_SUCCESS;
+	}
+
+	q->stats.pdrop++;
+	sch->qstats.drops++;
+	kfree_skb(skb);
+	return NET_XMIT_DROP;
+
+ congestion_drop:
+	qdisc_drop(skb, sch);
+	return NET_XMIT_CN;
+}
+
+static struct sk_buff *choke_dequeue(struct Qdisc *sch)
+{
+	struct choke_sched_data *q = qdisc_priv(sch);
+	struct sk_buff *skb;
+
+	if (q->head == q->tail) {
+		if (!red_is_idling(&q->parms))
+			red_start_of_idle_period(&q->parms);
+		return NULL;
+	}
+	skb = q->tab[q->head];
+	q->tab[q->head] = NULL; /* not really needed */
+	q->head = (q->head + 1) & q->tab_mask;
+	choke_zap_head_holes(q);
+	sch->qstats.backlog -= qdisc_pkt_len(skb);
+
+	return skb;
+}
+
+static unsigned int choke_drop(struct Qdisc *sch)
+{
+	struct choke_sched_data *q = qdisc_priv(sch);
+	unsigned int len;
+
+	len = qdisc_queue_drop(sch);
+
+	if (len > 0)
+		q->stats.other++;
+	else {
+		if (!red_is_idling(&q->parms))
+			red_start_of_idle_period(&q->parms);
+	}
+
+	return len;
+}
+
+static void choke_reset(struct Qdisc* sch)
+{
+	struct choke_sched_data *q = qdisc_priv(sch);
+
+	red_restart(&q->parms);
+}
+
+static const struct nla_policy choke_policy[TCA_RED_MAX + 1] = {
+	[TCA_RED_PARMS]	= { .len = sizeof(struct tc_red_qopt) },
+	[TCA_RED_STAB]	= { .len = RED_STAB_SIZE },
+};
+
+
+static void choke_free(void *addr)
+{
+	if (addr) {
+		if (is_vmalloc_addr(addr))
+			vfree(addr);
+		else
+			kfree(addr);
+	}
+}
+
+static int choke_change(struct Qdisc *sch, struct nlattr *opt)
+{
+	struct choke_sched_data *q = qdisc_priv(sch);
+	struct nlattr *tb[TCA_RED_MAX + 1];
+	struct tc_red_qopt *ctl;
+	int err;
+	struct sk_buff **old = NULL;
+	unsigned int mask;
+
+	if (opt == NULL)
+		return -EINVAL;
+
+	err = nla_parse_nested(tb, TCA_RED_MAX, opt, choke_policy);
+	if (err < 0)
+		return err;
+
+	if (tb[TCA_RED_PARMS] == NULL ||
+	    tb[TCA_RED_STAB] == NULL)
+		return -EINVAL;
+
+	ctl = nla_data(tb[TCA_RED_PARMS]);
+
+	mask = roundup_pow_of_two(ctl->limit + 1) - 1;
+	if (mask != q->tab_mask) {
+		struct sk_buff **ntab = kcalloc(mask + 1, sizeof(struct sk_buff *),
+						GFP_KERNEL);
+		if (!ntab)
+			ntab = vzalloc((mask + 1) * sizeof(struct sk_buff *));
+		if (!ntab)
+			return -ENOMEM;
+		sch_tree_lock(sch);
+		old = q->tab;
+		if (old) {
+			unsigned int tail = 0;
+
+			while (q->head != q->tail) {
+				ntab[tail++] = q->tab[q->head];
+				q->head = (q->head + 1) & q->tab_mask;
+			}
+			q->head = 0;
+			q->tail = tail;
+		}
+		q->tab_mask = mask;
+		q->holes = 0;
+	} else
+		sch_tree_lock(sch);
+	q->flags = ctl->flags;
+	q->limit = ctl->limit;
+
+	red_set_parms(&q->parms, ctl->qth_min, ctl->qth_max, ctl->Wlog,
+		      ctl->Plog, ctl->Scell_log,
+		      nla_data(tb[TCA_RED_STAB]));
+
+	if (q->head == q->tail)
+		red_end_of_idle_period(&q->parms);
+
+	sch_tree_unlock(sch);
+	choke_free(old);
+	return 0;
+}
+
+static int choke_init(struct Qdisc* sch, struct nlattr *opt)
+{
+	return choke_change(sch, opt);
+}
+
+static int choke_dump(struct Qdisc *sch, struct sk_buff *skb)
+{
+	struct choke_sched_data *q = qdisc_priv(sch);
+	struct nlattr *opts = NULL;
+	struct tc_red_qopt opt = {
+		.limit		= q->limit,
+		.flags		= q->flags,
+		.qth_min	= q->parms.qth_min >> q->parms.Wlog,
+		.qth_max	= q->parms.qth_max >> q->parms.Wlog,
+		.Wlog		= q->parms.Wlog,
+		.Plog		= q->parms.Plog,
+		.Scell_log	= q->parms.Scell_log,
+	};
+
+	sch->q.qlen = choke_len(q) - q->holes;
+	opts = nla_nest_start(skb, TCA_OPTIONS);
+	if (opts == NULL)
+		goto nla_put_failure;
+
+	NLA_PUT(skb, TCA_RED_PARMS, sizeof(opt), &opt);
+	return nla_nest_end(skb, opts);
+
+nla_put_failure:
+	nla_nest_cancel(skb, opts);
+	return -EMSGSIZE;
+}
+
+static int choke_dump_stats(struct Qdisc *sch, struct gnet_dump *d)
+{
+	struct choke_sched_data *q = qdisc_priv(sch);
+	struct tc_red_xstats st = {
+		.early	= q->stats.prob_drop + q->stats.forced_drop,
+		.pdrop	= q->stats.pdrop,
+		.other	= q->stats.other,
+		.marked	= q->stats.prob_mark + q->stats.forced_mark,
+	};
+
+	return gnet_stats_copy_app(d, &st, sizeof(st));
+}
+
+static void choke_destroy(struct Qdisc *sch)
+{
+	struct choke_sched_data *q = qdisc_priv(sch);
+
+	tcf_destroy_chain(&q->filter_list);
+	choke_free(q->tab);
+}
+
+static struct Qdisc *choke_leaf(struct Qdisc *sch, unsigned long arg)
+{
+	return NULL;
+}
+
+static unsigned long choke_get(struct Qdisc *sch, u32 classid)
+{
+	return 0;
+}
+
+static void choke_put(struct Qdisc *q, unsigned long cl)
+{
+}
+
+static unsigned long choke_bind(struct Qdisc *sch, unsigned long parent,
+				u32 classid)
+{
+	return 0;
+}
+
+static struct tcf_proto **choke_find_tcf(struct Qdisc *sch, unsigned long cl)
+{
+	struct choke_sched_data *q = qdisc_priv(sch);
+
+	if (cl)
+		return NULL;
+	return &q->filter_list;
+}
+
+static int choke_dump_class(struct Qdisc *sch, unsigned long cl,
+			  struct sk_buff *skb, struct tcmsg *tcm)
+{
+	tcm->tcm_handle |= TC_H_MIN(cl);
+	return 0;
+}
+
+static void choke_walk(struct Qdisc *sch, struct qdisc_walker *arg)
+{
+	if (!arg->stop) {
+		if (arg->fn(sch, 1, arg) < 0) {
+			arg->stop = 1;
+			return;
+		}
+		arg->count++;
+	}
+}
+
+static const struct Qdisc_class_ops choke_class_ops = {
+	.leaf		=	choke_leaf,
+	.get		=	choke_get,
+	.put		=	choke_put,
+	.tcf_chain	=	choke_find_tcf,
+	.bind_tcf	=	choke_bind,
+	.unbind_tcf	=	choke_put,
+	.dump		=	choke_dump_class,
+	.walk		=	choke_walk,
+};
+
+static struct Qdisc_ops choke_qdisc_ops __read_mostly = {
+	.id		=	"choke",
+	.priv_size	=	sizeof(struct choke_sched_data),
+
+	.enqueue	=	choke_enqueue,
+	.dequeue	=	choke_dequeue,
+	.peek		=	qdisc_peek_head,
+	.drop		=	choke_drop,
+	.init		=	choke_init,
+	.destroy	=	choke_destroy,
+	.reset		=	choke_reset,
+	.change		=	choke_change,
+	.dump		=	choke_dump,
+	.dump_stats	=	choke_dump_stats,
+	.owner		=	THIS_MODULE,
+};
+
+static int __init choke_module_init(void)
+{
+	return register_qdisc(&choke_qdisc_ops);
+}
+
+static void __exit choke_module_exit(void)
+{
+	unregister_qdisc(&choke_qdisc_ops);
+}
+
+module_init(choke_module_init)
+module_exit(choke_module_exit)
+
+MODULE_LICENSE("GPL");

^ permalink raw reply

* [PATCH] rt2x00: Don't leak mem in error path of rt2x00lib_request_firmware()
From: Jesper Juhl @ 2011-01-10 23:47 UTC (permalink / raw)
  To: linux-wireless
  Cc: users, linux-kernel, netdev, Gertjan van Wingerde,
	John W. Linville, Ivo van Doorn

We need to release_firmware() in order not to leak memory.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
 rt2x00firmware.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/rt2x00/rt2x00firmware.c b/drivers/net/wireless/rt2x00/rt2x00firmware.c
index f0e1eb7..be0ff78 100644
--- a/drivers/net/wireless/rt2x00/rt2x00firmware.c
+++ b/drivers/net/wireless/rt2x00/rt2x00firmware.c
@@ -58,6 +58,7 @@ static int rt2x00lib_request_firmware(struct rt2x00_dev *rt2x00dev)
 
 	if (!fw || !fw->size || !fw->data) {
 		ERROR(rt2x00dev, "Failed to read Firmware.\n");
+		release_firmware(fw);
 		return -ENOENT;
 	}
 


-- 
Jesper Juhl <jj@chaosbits.net>            http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.

^ permalink raw reply related

* Re: [PATCH] caif: don't set connection request param size before copying data
From: David Miller @ 2011-01-11  0:01 UTC (permalink / raw)
  To: drosenberg; +Cc: sjur.brandeland, netdev
In-Reply-To: <1294702597.2125.74.camel@dan>

From: Dan Rosenberg <drosenberg@vsecurity.com>
Date: Mon, 10 Jan 2011 18:36:37 -0500

> The size field should not be set until after the data is successfully
> copied in.
> 
> Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>

Applied, thanks.

^ permalink raw reply

* Re: [RFC] sched: CHOKe packet scheduler (v0.4)
From: Eric Dumazet @ 2011-01-11  0:00 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <20110110154414.53f33916@nehalam>

Le lundi 10 janvier 2011 à 15:44 -0800, Stephen Hemminger a écrit :
> This implements the CHOKe packet scheduler based on the existing
> Linux RED scheduler based on the algorithm described in the paper.
> 
> The core idea is:
>   For every packet arrival:
>   	Calculate Qave
> 	if (Qave < minth) 
> 	     Queue the new packet
> 	else 
> 	     Select randomly a packet from the queue 
> 	     if (both packets from same flow)
> 	     then Drop both the packets
> 	     else if (Qave > maxth)
> 	          Drop packet
> 	     else
> 	       	  Admit packet with proability p (same as RED)
> 
> See also:
>   Rong Pan, Balaji Prabhakar, Konstantinos Psounis, "CHOKe: a stateless active
>    queue management scheme for approximating fair bandwidth allocation", 
>   Proceeding of INFOCOM'2000, March 2000. 
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> 

You beat me, I found the bug I had  in _change()


> +
> +static int choke_change(struct Qdisc *sch, struct nlattr *opt)
> +{
> +	struct choke_sched_data *q = qdisc_priv(sch);
> +	struct nlattr *tb[TCA_RED_MAX + 1];
> +	struct tc_red_qopt *ctl;
> +	int err;
> +	struct sk_buff **old = NULL;
> +	unsigned int mask;
> +
> +	if (opt == NULL)
> +		return -EINVAL;
> +
> +	err = nla_parse_nested(tb, TCA_RED_MAX, opt, choke_policy);
> +	if (err < 0)
> +		return err;
> +
> +	if (tb[TCA_RED_PARMS] == NULL ||
> +	    tb[TCA_RED_STAB] == NULL)
> +		return -EINVAL;
> +
> +	ctl = nla_data(tb[TCA_RED_PARMS]);
> +
> +	mask = roundup_pow_of_two(ctl->limit + 1) - 1;
> +	if (mask != q->tab_mask) {
> +		struct sk_buff **ntab = kcalloc(mask + 1, sizeof(struct sk_buff *),
> +						GFP_KERNEL);
> +		if (!ntab)
> +			ntab = vzalloc((mask + 1) * sizeof(struct sk_buff *));
> +		if (!ntab)
> +			return -ENOMEM;
> +		sch_tree_lock(sch);
> +		old = q->tab;
> +		if (old) {
> +			unsigned int tail = 0;
> +
> +			while (q->head != q->tail) {
> +				ntab[tail++] = q->tab[q->head];
> +				q->head = (q->head + 1) & q->tab_mask;
> +			}
> +			q->head = 0;
> +			q->tail = tail;
> +		}
> +		q->tab_mask = mask;

Here we missed :

		q->tab = ntab;

> +		q->holes = 0;
> +	} else
> +		sch_tree_lock(sch);
> +	q->flags = ctl->flags;
> +	q->limit = ctl->limit;
> +
> +	red_set_parms(&q->parms, ctl->qth_min, ctl->qth_max, ctl->Wlog,
> +		      ctl->Plog, ctl->Scell_log,
> +		      nla_data(tb[TCA_RED_STAB]));
> +
> +	if (q->head == q->tail)
> +		red_end_of_idle_period(&q->parms);
> +
> +	sch_tree_unlock(sch);
> +	choke_free(old);
> +	return 0;
> +}
> +



^ permalink raw reply

* Re: [patch v2] phonet: some signedness bugs
From: David Miller @ 2011-01-11  0:06 UTC (permalink / raw)
  To: error27; +Cc: remi.denis-courmont, netdev, kernel-janitors, dan.j.rosenberg
In-Reply-To: <20110110140658.GB2721@bicker>

From: Dan Carpenter <error27@gmail.com>
Date: Mon, 10 Jan 2011 17:06:58 +0300

> Dan Rosenberg pointed out that there were some signed comparison bugs
> in the phonet protocol.
> 
> http://marc.info/?l=full-disclosure&m=129424528425330&w=2
> 
> The problem is that we check for array overflows but "protocol" is
> signed and we don't check for array underflows.  If you have already
> have CAP_SYS_ADMIN then you could use the bugs to get root, or someone
> could cause an oops by mistake.
> 
> Signed-off-by: Dan Carpenter <error27@gmail.com>

Applied.

^ permalink raw reply

* Re: [PATCH 0/2] net: Allow allocating different number RX and TX mqs
From: David Miller @ 2011-01-11  0:06 UTC (permalink / raw)
  To: therbert; +Cc: netdev
In-Reply-To: <alpine.DEB.2.00.1101092123340.3137@pokey.mtv.corp.google.com>

From: Tom Herbert <therbert@google.com>
Date: Sun, 9 Jan 2011 21:36:25 -0800 (PST)

> Add functions so that a different number of TX and RX queues can be
> allocated in a netdevice.  Second patch modifies mlx4 driver to call
> this function which is an example of a driver that allocates different
> numbers for TX and RX queues.

Both applied, thanks Tom.

^ permalink raw reply

* Re: [PATCH] net_sched: factorize qdisc stats handling
From: David Miller @ 2011-01-11  0:08 UTC (permalink / raw)
  To: eric.dumazet; +Cc: shemminger, jarkao2, xiaosuo, fabio, netdev, rizzo
In-Reply-To: <1294597854.2709.850.camel@edumazet-laptop>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 09 Jan 2011 19:30:54 +0100

> [PATCH v2] net_sched: factorize qdisc stats handling
> 
> HTB takes into account skb is segmented in stats updates.
> Generalize this to all schedulers.
> 
> They should use qdisc_bstats_update() helper instead of manipulating
> bstats.bytes and bstats.packets
> 
> Add bstats_update() helper too for classes that use
> gnet_stats_basic_packed fields.
> 
> Note : Right now, TCQ_F_CAN_BYPASS shortcurt can be taken only if no
> stab is setup on qdisc.
> 
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> v2: constify some methods, and make sure qdisc_skb_cb(skb)->pkt_len is
> set in the TCQ_F_CAN_BYPASS shortcut in __dev_xmit_skb()

Applied, thanks Eric.

^ permalink raw reply

* Re: [PATCH 3/5] NET: IPV4: ARP: allow to invalidate specific ARP entries
From: David Miller @ 2011-01-11  0:11 UTC (permalink / raw)
  To: maximlevitsky
  Cc: eric.dumazet, linux1394-devel, stefanr, netdev, kuznet, jmorris,
	kaber
In-Reply-To: <1294531032.25396.11.camel@maxim-laptop>

From: Maxim Levitsky <maximlevitsky@gmail.com>
Date: Sun, 09 Jan 2011 01:57:12 +0200

>     NET: IPV4: ARP: allow to invalidate specific ARP entries
>     
>     IPv4 over firewire needs to be able to remove ARP entries
>     from the ARP cache that belong to nodes that are removed, because
>     IPv4 over firewire uses ARP packets for private information
>     about nodes.
>     
>     This information becomes invalid as soon as node drops
>     off the bus and when it reconnects, its only possible
>     to start takling to is after it responded to an ARP packet.
>     But ARP cache prevents such packets from being sent.
>     
>     Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH] CAIF: Fix IPv6 support in receive path for GPRS/3G
From: David Miller @ 2011-01-11  0:12 UTC (permalink / raw)
  To: sjurbren; +Cc: netdev, kumar.sanghvi, sjur.brandeland
In-Reply-To: <1294401428-2085-1-git-send-email-sjurbren@stericsson.com>

From: Sjur Brændeland <sjurbren@stericsson.com>
Date: Fri, 07 Jan 2011 12:57:08 +0100

> From: Kumar Sanghvi <kumar.sanghvi@stericsson.com>
> 
> Checks version field of IP in the receive path for GPRS/3G data
> and appropriately sets the value of skb->protocol.
> 
> Signed-off-by: Sjur Braendeland <sjur.brandeland@stericsson.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH v2] net/r8169: Update the function of parsing firmware
From: David Miller @ 2011-01-11  0:14 UTC (permalink / raw)
  To: hayeswang; +Cc: romieu, netdev, linux-kernel
In-Reply-To: <1294661245-2191-1-git-send-email-hayeswang@realtek.com>

From: Hayes Wang <hayeswang@realtek.com>
Date: Mon, 10 Jan 2011 20:07:25 +0800

> Update rtl_phy_write_fw function. The new function could
> parse the complex firmware which is used by RTL8111E and later.
> The new firmware may read data and do some operations, not just
> do writing only.
> 
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>

Applied, thank you.

^ permalink raw reply

* Re: [PATCH v2] net: ppp: use {get,put}_unaligned_be{16,32}
From: David Miller @ 2011-01-11  0:13 UTC (permalink / raw)
  To: xiaosuo; +Cc: paulus, harvey.harrison, linux-ppp, netdev
In-Reply-To: <1294357056-25889-1-git-send-email-xiaosuo@gmail.com>

From: Changli Gao <xiaosuo@gmail.com>
Date: Fri,  7 Jan 2011 07:37:36 +0800

> Signed-off-by: Changli Gao <xiaosuo@gmail.com>

Applied.

^ permalink raw reply

* Re: [PATCH 0/2] net: Allow allocating different number RX and TX mqs
From: Tom Herbert @ 2011-01-11  0:28 UTC (permalink / raw)
  To: David Miller; +Cc: netdev
In-Reply-To: <20110110.160642.146350621.davem@davemloft.net>

On Mon, Jan 10, 2011 at 4:06 PM, David Miller <davem@davemloft.net> wrote:
> From: Tom Herbert <therbert@google.com>
> Date: Sun, 9 Jan 2011 21:36:25 -0800 (PST)
>
>> Add functions so that a different number of TX and RX queues can be
>> allocated in a netdevice.  Second patch modifies mlx4 driver to call
>> this function which is an example of a driver that allocates different
>> numbers for TX and RX queues.
>
> Both applied, thanks Tom.
>

Thanks.  By the way I didn't see a maintainer for the mlx drivers in
the MAINTAINERS files.  Who maintains these?

^ permalink raw reply

* Re: [e100] Page allocation failure warning(?) in 2.6.36.3
From: Dave, Tushar N @ 2011-01-11  0:37 UTC (permalink / raw)
  To: Chris Rankin, e1000-devel@lists.sourceforge.net; +Cc: netdev@vger.kernel.org
In-Reply-To: <688142.89079.qm@web121707.mail.ne1.yahoo.com>

Chris,
The reason I asked you about bridge is because I have noticed "br0: port 1(eth1) entering learning state" in the dmesg log you sent.
I am trying to figure out exactly what sequence of commands you run that produce this message " br0: port 1(eth1) entering learning state" in log.
Also if you let me know output of 
#cat /etc/network/interface
#ifconfig -a

Thanks.


-Tushar

-----Original Message-----
From: Chris Rankin [mailto:rankincj@yahoo.com] 
Sent: Monday, January 10, 2011 3:42 PM
To: e1000-devel@lists.sourceforge.net; Dave, Tushar N
Cc: netdev@vger.kernel.org
Subject: RE: [E1000-devel] [e100] Page allocation failure warning(?) in 2.6.36.3

--- On Mon, 10/1/11, Dave, Tushar N <tushar.n.dave@intel.com> wrote:
> Does the issue appears only when you add a bridge?

Tushar,

I'm not sure what you mean by "add a bridge". I've been using this box ever since the late 1990s, and have had the 3 e100 port since the early 2000s, so I can't say that I "do" anything with it apart from use it. 

The PCI configuration remains as it always has, and the box get rebooted only to receive stable kernel updates. Looking back through old dmesg logs, it looks like this issue also happened in 2.6.33.6 too without me ever realising. Hence I am suspecting that this problem has been happening intermittently for ages...

Is there anything else I can tell you about this ropey old P200 MMX PC before Indiana Jones finds it and tries putting it in his museum ;-)?

Cheers,
Chris


      
------------------------------------------------------------------------------
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web.   Learn how to 
best implement a security strategy that keeps consumers' information secure 
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl 
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel&#174; Ethernet, visit http://communities.intel.com/community/wired

^ permalink raw reply

* [PATCH v2] cxgb3i: fixed connection problem with iscsi private ip
From: kxie @ 2011-01-11  0:45 UTC (permalink / raw)
  To: netdev, linux-scsi, open-iscsi; +Cc: kxie, davem, James.Bottomley, michaelc

[PATCH v2] cxgb3i: fixed connection problem with iscsi private ip

From: Karen Xie <kxie@chelsio.com>

The last one seems to have some formatting problem. Regenerated the patch.

fixed the connection problem when the private iscsi ipv4 address is provisioned on the interface.

Signed-off-by: Karen Xie <kxie@chelsio.com>
---
 drivers/scsi/cxgbi/cxgb3i/cxgb3i.h |   19 +++++++++++++++----
 1 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
index 5f5e339..20593fd 100644
--- a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
+++ b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
@@ -24,10 +24,21 @@
 
 extern cxgb3_cpl_handler_func cxgb3i_cpl_handlers[NUM_CPL_CMDS];
 
-#define cxgb3i_get_private_ipv4addr(ndev) \
-	(((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr)
-#define cxgb3i_set_private_ipv4addr(ndev, addr) \
-	(((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr) = addr
+static inline unsigned int cxgb3i_get_private_ipv4addr(struct net_device *ndev)
+{
+	return ((struct port_info *)(netdev_priv(ndev)))->iscsi_ipv4addr;
+}
+
+static inline void cxgb3i_set_private_ipv4addr(struct net_device *ndev,
+						unsigned int addr)
+{
+	struct port_info *pi =  (struct port_info *)netdev_priv(ndev);
+
+	pi->iscsic.flags = addr ? 1 : 0;
+	pi->iscsi_ipv4addr = addr;
+	if (addr)
+		memcpy(pi->iscsic.mac_addr, ndev->dev_addr, ETH_ALEN);
+}
 
 struct cpl_iscsi_hdr_norss {
 	union opcode_tid ot;

^ permalink raw reply related

* Re: [PATCH] UDPCP Communication Protocol
From: Hagen Paul Pfeifer @ 2011-01-11  0:49 UTC (permalink / raw)
  To: stefani; +Cc: linux-kernel, akpm, davem, netdev
In-Reply-To: <1293787785-3834-1-git-send-email-stefani@seibold.net>

find_dest() via new_dest() may return NULL

* stefani@seibold.net | 2010-12-31 10:29:45 [+0100]:

>+static int udpcp_sendmsg(struct kiocb *iocb, struct sock *sk,
>+			 struct msghdr *msg, size_t len)
>+{
>+	struct inet_sock *inet = inet_sk(sk);
>+	struct udpcp_sock *usk = udpcp_sk(sk);
>+	struct ipcm_cookie *ipc;
>+	struct rtable *rt = NULL;
>+	int free = 0;
>+	int connected = 0;
>+	__be32 daddr, faddr, saddr;
>+	__be16 dport;
>+	u8 tos;
>+	int err = 0;
>+	int corkreq = usk->udpsock.corkflag || msg->msg_flags & MSG_MORE;
>+	int (*getfrag) (void *, char *, int, int, int, struct sk_buff *);
>+	struct udpcp_dest *dest;
>+
>+	if (len > UDPCP_MAX_MSGSIZE)
>+		return -EMSGSIZE;
>+
>+	/*
>+	 * Check the flags.
>+	 */
>+	if (msg->msg_flags & MSG_OOB)
>+		return -EOPNOTSUPP;
>+
>+	/*
>+	 * check if socket is binded to a port
>+	 */
>+	if (!(sk->sk_userlocks & SOCK_BINDPORT_LOCK) || !inet->inet_num)
>+		return -ENOTCONN;
>+
>+	/*
>+	 * Get and verify the address.
>+	 */
>+	if (msg->msg_name) {
>+		struct sockaddr_in *usin = (struct sockaddr_in *)msg->msg_name;
>+		if (msg->msg_namelen < sizeof(*usin))
>+			return -EINVAL;
>+		if (usin->sin_family != AF_INET) {
>+			if (usin->sin_family != AF_UNSPEC)
>+				return -EAFNOSUPPORT;
>+		}
>+
>+		daddr = usin->sin_addr.s_addr;
>+		dport = usin->sin_port;
>+	} else {
>+		if (sk->sk_state != TCP_ESTABLISHED)
>+			return -EDESTADDRREQ;
>+		daddr = inet->inet_daddr;
>+		dport = inet->inet_dport;
>+		/* Open fast path for connected socket.
>+		   Route will not be used, if at least one option is set.
>+		 */
>+		connected = 1;
>+	}
>+
>+	if (dport == 0)
>+		return -EINVAL;
>+
>+	dest = find_dest(sk, daddr, dport);
    if (!dest)
			return -ENOBUFS;

^ permalink raw reply


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