* Re: [net-2.6 PATCH] e1000: Fix DMA mapping error handling on RX
From: David Miller @ 2010-02-23 9:25 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, anton
In-Reply-To: <20100220035423.31265.13034.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 19 Feb 2010 19:54:53 -0800
> From: Anton Blanchard <anton@samba.org>
>
> Check for error return from pci_map_single/pci_map_page and clean up.
>
> With this and the previous patch the driver was able to handle a significant
> percentage of errors (I set the fault injection rate to 10% and could still
> download large files at a reasonable speed).
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: update mv643xx_eth maintenance status
From: David Miller @ 2010-02-23 9:25 UTC (permalink / raw)
To: buytenh; +Cc: netdev
In-Reply-To: <20100223083454.GR1637@mail.wantstofly.org>
From: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Tue, 23 Feb 2010 09:34:54 +0100
> I am no longer with Marvell.
>
> Signed-off-by: Lennert Buytenhek <buytenh@wantstofly.org>
Applied.
^ permalink raw reply
* Re: [PATCH] IPv6: better document max_addresses parameter
From: David Miller @ 2010-02-23 9:25 UTC (permalink / raw)
To: brian.haley; +Cc: nedyalkor, akpm, netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <4B8304C9.1030800@hp.com>
From: Brian Haley <brian.haley@hp.com>
Date: Mon, 22 Feb 2010 17:27:21 -0500
> Andrew Morton wrote:
>>> >From ip-sysctl.txt file in kernel documentation I can see following description
>>> for max_addresses:
>>> max_addresses - INTEGER
>>> Number of maximum addresses per interface. 0 disables limitation.
>>> It is recommended not set too large value (or 0) because it would
>>> be too easy way to crash kernel to allow to create too much of
>>> autoconfigured addresses.
> ^^^^^^^^^^^^^^
>
>>> If this parameter applies only for auto-configured IP addressed, please state
>>> it more clearly in docs or rename the parameter to show that it refers to
>>> auto-configuration.
>
> It did mention autoconfigured in the text, but the below makes it more obvious.
>
>
> More clearly document IPv6 max_addresses parameter.
>
> Signed-off-by: Brian Haley <brian.haley@hp.com>
Applied.
^ permalink raw reply
* Re: [PATCH torvalds-2.6] cdc_ether: new PID for Ericsson C3607w to the whitelist (resubmit)
From: David Miller @ 2010-02-23 9:25 UTC (permalink / raw)
To: torgny.johansson; +Cc: netdev
In-Reply-To: <201002191259.16374.torgny.johansson@gmail.com>
From: Torgny Johansson <torgny.johansson@gmail.com>
Date: Fri, 19 Feb 2010 12:59:15 +0100
> This patch adds a new vid/pid to the cdc_ether whitelist.
>
> Device added:
> - Ericsson Mobile Broadband variant C3607w
>
> Signed-off-by: Torgny Johansson <torgny.johansson@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] tc35815: Remove a wrong netif_wake_queue() call which triggers BUG_ON
From: David Miller @ 2010-02-23 9:25 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <1266592438-10772-1-git-send-email-anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Sat, 20 Feb 2010 00:13:58 +0900
> The netif_wake_queue() is called correctly (i.e. only on !txfull
> condition) from txdone routine. So Unconditional call to the
> netif_wake_queue() here is wrong. This might cause calling of
> start_xmit routine on txfull state and trigger BUG_ON.
>
> This bug does not happen when NAPI disabled. After txdone there
> must be at least one free tx slot. But with NAPI, this is not
> true anymore and the BUG_ON can hits on heavy load.
>
> In this driver NAPI was enabled on 2.6.33-rc1 so this is
> regression from 2.6.32 kernel.
>
> Reported-by: Ralf Roesch <ralf.roesch@rw-gmbh.de>
> Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Patch applied, thanks.
^ permalink raw reply
* Re: [PATCH] tc35815: Remove a wrong netif_wake_queue() call which triggers BUG_ON
From: David Miller @ 2010-02-23 9:26 UTC (permalink / raw)
To: anemo; +Cc: netdev, ralf.roesch
In-Reply-To: <20100220.003122.26280041.anemo@mba.ocn.ne.jp>
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Date: Sat, 20 Feb 2010 00:31:22 +0900 (JST)
> On Sat, 20 Feb 2010 00:13:58 +0900, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
>> @@ -1437,7 +1437,6 @@ static int tc35815_do_interrupt(struct net_device *dev, u32 status, int limit)
>> /* Transmit complete. */
>> lp->lstats.tx_ints++;
>> tc35815_txdone(dev);
>> - netif_wake_queue(dev);
>> if (ret < 0)
>> ret = 0;
>> }
>
> BTY, it looks isa-skelton.c have same problem.
...
> I suppose here is the far origin of the bug :)
Please send a patch for this.
Thank you.
^ permalink raw reply
* Re: pull request: wireless-2.6 2010-02-22
From: David Miller @ 2010-02-23 9:29 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b
In-Reply-To: <20100222182653.GB2988-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Mon, 22 Feb 2010 13:26:53 -0500
> I have a handful of late-breakers for iwlwifi. The one from Dan
> Halperin moves a single line of code and is a fix for an 802.11n
> regression introduced in the 2.6.33 cycle. The other two combine
> to address a problem that causes the wireless LAN connection to
> die without any error message. It has been developed and tested in
> combination between the Intel wireless team and a contributor from
> Red Hat. I hope you will consider including these for 2.6.33 if at
> all possible.
>
> Please let me know if there are problems!
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next-2.6] vhost: Restart tx poll when socket send queue is full
From: Michael S. Tsirkin @ 2010-02-23 10:24 UTC (permalink / raw)
To: Sridhar Samudrala; +Cc: David Miller, netdev
In-Reply-To: <1266526751.15681.71.camel@w-sridhar.beaverton.ibm.com>
On Thu, Feb 18, 2010 at 12:59:11PM -0800, Sridhar Samudrala wrote:
> When running guest to remote host TCP stream test using vhost-net
> via tap/macvtap, i am seeing network transmit hangs. This happens
> when handle_tx() returns because of the socket send queue full
> condition.
> This patch fixes this by restarting tx poll when hitting this
> condition.
>
> Signed-off-by: Sridhar Samudrala <sri@us.ibm.com>
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 91a324c..82d4bbe 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -113,12 +113,16 @@ static void handle_tx(struct vhost_net *net)
> if (!sock)
> return;
>
> - wmem = atomic_read(&sock->sk->sk_wmem_alloc);
> - if (wmem >= sock->sk->sk_sndbuf)
> - return;
> -
> use_mm(net->dev.mm);
> mutex_lock(&vq->mutex);
> +
> + wmem = atomic_read(&sock->sk->sk_wmem_alloc);
> + if (wmem >= sock->sk->sk_sndbuf) {
> + tx_poll_start(net, sock);
> + set_bit(SOCK_ASYNC_NOSPACE, &sock->flags);
> + goto unlock;
> + }
> +
> vhost_disable_notify(vq);
>
> if (wmem < sock->sk->sk_sndbuf * 2)
> @@ -178,6 +182,7 @@ static void handle_tx(struct vhost_net *net)
> }
> }
>
> +unlock:
> mutex_unlock(&vq->mutex);
> unuse_mm(net->dev.mm);
> }
It might be better to avoid use_mm when ring is full.
Does the following fix the tx hang for you?
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 4c89283..f5f6efe 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -113,8 +113,12 @@ static void handle_tx(struct vhost_net *net)
return;
wmem = atomic_read(&sock->sk->sk_wmem_alloc);
- if (wmem >= sock->sk->sk_sndbuf)
- return;
+ if (wmem >= sock->sk->sk_sndbuf) {
+ mutex_lock(&vq->mutex);
+ tx_poll_start(net, sock);
+ mutex_unlock(&vq->mutex);
+ return;
+ }
use_mm(net->dev.mm);
mutex_lock(&vq->mutex);
^ permalink raw reply related
* [PATCH] tg3: receive packets larger than MTU but smaller than 1500 bytes
From: Szilveszter Ordog @ 2010-02-23 11:56 UTC (permalink / raw)
To: Matt Carlson, Michael Chan; +Cc: netdev
This allows for proper ICMP needs fragmentation responses on standard Ethernet
networks.
Signed-off-by: Szilveszter Ördög <slipszi@gmail.com>
---
drivers/net/tg3.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 46a3f86..0c5027b 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -93,6 +93,8 @@
#define TG3_MIN_MTU 60
#define TG3_MAX_MTU(tp) \
((tp->tg3_flags2 & TG3_FLG2_JUMBO_CAPABLE) ? 9000 : 1500)
+#define TG3_MAX_RX_MTU(tp) \
+ max(tp->dev->mtu, (unsigned int)ETH_DATA_LEN)
/* These numbers seem to be hard coded in the NIC firmware somehow.
* You can't change the ring sizes, but you can change where you place
@@ -4532,7 +4534,7 @@ static int tg3_rx(struct tg3 *tp, int budget)
skb->protocol = eth_type_trans(skb, tp->dev);
- if (len > (tp->dev->mtu + ETH_HLEN) &&
+ if (len > (TG3_MAX_RX_MTU(tp) + ETH_HLEN) &&
skb->protocol != htons(ETH_P_8021Q)) {
dev_kfree_skb(skb);
goto next_pkt;
@@ -6979,7 +6981,7 @@ static int tg3_reset_hw(struct tg3 *tp, int reset_phy)
/* MTU + ethernet header + FCS + optional VLAN tag */
tw32(MAC_RX_MTU_SIZE,
- tp->dev->mtu + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN);
+ TG3_MAX_RX_MTU(tp) + ETH_HLEN + ETH_FCS_LEN + VLAN_HLEN);
/* The slot time is changed by tg3_setup_phy if we
* run at gigabit with half duplex.
--
1.6.3.3
^ permalink raw reply related
* Re: BNX2: Kernel crashes with 2.6.31 and 2.6.31.9
From: Bruno Prémont @ 2010-02-23 12:15 UTC (permalink / raw)
To: Benjamin Li; +Cc: NetDEV, Michael Chan, Linux-Kernel
In-Reply-To: <1266609426.2610.36.camel@dhcp-10-12-137-130.broadcom.com>
Hi Benjamin,
On Fri, 19 February 2010 "Benjamin Li" <benli@broadcom.com> wrote:
> >From your logs it looks like the device came up using MSI, but in the
> MSI-X poll routine was being called:
>
> [ 9.836673] bnx2: eth0: using MSI
> ...
>
> [ 134.643459] [<ffffffffa004019e>] bnx2_poll_msix+0x3e/0xd0 [bnx2]
> [ 134.643465] [<ffffffff8135bcd1>] netpoll_poll+0xe1/0x3c0
>
> which is incorrect. If we are in MSI mode, the bnx2_poll() routine
> should be used.
>
> I think what is going on here is that during the bnx2x driver
> initialization the current bnx2 driver adds all possible NAPI
> structures that map to all the hardware vectors (BNX2_MAX_MSIX_VEC=9)
> to the NAPI list in the net_device structure regardless if they are
> used or not (Seen in drivers/net/bnx2.c:bnx2_init_napi()). This can
> cause uninitialized NAPI structures to be placed on the napi_list.
> Because this device is in MSI mode, only 1 vector is initialized.
> Now, the problem is triggered when net/core/netpoll.c:poll_napi() is
> called. This is because this routine will run through the entire
> napi_list calling all the poll routines. In your particular case, it
> is calling the poll routine on an uninitialized vector causing the
> kernel panic.
>
> Please try the patch below to see if it solves your problem. Note,
> this only have been compile tested and tested against basic traffic
> runs. Unfortunately, I could not reproduce the kernel panic with the
> instructions below to verify the patch.
>
> Thanks again for all your help in helping us track this down.
I applied the patch today and tried to reproduce with my showcases.
Seems that it's harder to trigger now but I still end up being able to
crash the box. Don't know if it's the same cause or not (could also
be the tcp-retransmit ghost)...
This time I had to run a few paralell scp's (8Mb/s each) to the box and
'echo t > /proc/sysrq-trigger' multiple times via ssh session for it to
happen. It didn't trigger with by netbomb though I will try some more
and see)
I don't know if it's the same reason or not (hopefully something
reached disk as serial console is dead and pings are not
answered anymore.
It's probably some printk/bug/warn that triggers in network stack and
deadlocks with netconsole.
Regards,
Bruno
^ permalink raw reply
* Re: [PATCH 3/4] gigaset: reduce syslog clutter
From: Tilman Schmidt @ 2010-02-23 12:53 UTC (permalink / raw)
To: Joe Perches
Cc: Karsten Keil, David Miller, Hansjoerg Lipp, Karsten Keil,
isdn4linux, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <1266899531.9265.4.camel@Joe-Laptop.home>
Joe Perches schrieb:
> Perhaps it'd be useful to add a ethtool/netif_msg interface
> and classify the messages as appropriate.
Interesting idea. On first glance, however, I don't see how to map the
Gigaset driver's diverse debugging categories (like USB communication
vs. V.25ter communication vs. ISDN subsystem communication) to the
NETIF_MSG_ flags in a useful way.
What's more, ethtool only seems to allow the setting of a numerical
message "level" enabling all debug flags "below" that level. It cannot
enable, for example, NETIF_MSG_TX_ERR without NETIF_MSG_PROBE. The
Gigaset driver OTOH follows the concept of individually selectable areas
of interest. In fact, I make frequent use of that ability when I help a
user with troubleshooting. For example, a typical first setting for a
user who cannot make an ISDN connection would be the value 0x102020
mentioned in the README.
OTOH, the ability to control the "non-debug" verbosity of the Gigaset
driver (ie. the messages not controlled by the "debug" parameter) with
ethtool/netif_msg might be appreciated. Perhaps that's what you had in mind?
Thanks,
Tilman
^ permalink raw reply
* [iproute2 PATCH 1/3] xfrm: Introduce xfrm by mark
From: jamal @ 2010-02-23 13:15 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Jamal Hadi Salim
In-Reply-To: <xfrm-iproute-mark>
From: Jamal Hadi Salim <hadi@cyberus.ca>
This patch carries basic infrastructure.
You need to make sure that the proper include/linux/xfrm.h is included
for it to compile.
Example:
---
output:
src 192.168.2.100 dst 192.168.1.10
proto esp spi 0x00000301 reqid 0 mode tunnel
replay-window 0
mark 7/0xffffffff
auth hmac(md5) 0x96358c90783bbfa3d7b196ceabe0536b
enc cbc(des3_ede) 0xf6ddb555acfd9d77b03ea3843f2653255afe8eb5573965df
sel src 0.0.0.0/0 dst 0.0.0.0/0
dir fwd ptype main \
tmpl src 192.168.2.100 dst 192.168.1.100 \
proto esp mode tunnel mark 7 mask 0xffffffff
output:
src 172.16.2.0/24 dst 172.16.1.0/24
dir fwd priority 0 ptype main
mark 7/0xffffffff
tmpl src 192.168.2.100 dst 192.168.1.100
proto esp reqid 0 mode tunnel
-----
A mark-configured SAD/SPD entry will use the mark as part of the
lookup key (both in data and control path).
Example:
---
output:
RTNETLINK answers: No such file or directory
output:
src 172.16.2.0/24 dst 172.16.1.0/24
dir fwd priority 0 ptype main
mark 7/0xffffffff
tmpl src 192.168.2.100 dst 192.168.1.100
proto esp reqid 0 mode tunnel
---
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
---
ip/ipxfrm.c | 40 ++++++++++++++++++++++++++++++++++++++++
ip/xfrm.h | 1 +
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/ip/ipxfrm.c b/ip/ipxfrm.c
index 7dc36f3..78e1926 100644
--- a/ip/ipxfrm.c
+++ b/ip/ipxfrm.c
@@ -629,9 +629,48 @@ static void xfrm_tmpl_print(struct xfrm_user_tmpl *tmpls, int len,
}
}
+int xfrm_parse_mark(struct xfrm_mark *mark, int *argcp, char ***argvp)
+{
+ int argc = *argcp;
+ char **argv = *argvp;
+
+ NEXT_ARG();
+ if (get_u32(&mark->v, *argv, 0)) {
+ invarg("Illegal \"mark\" value\n", *argv);
+ }
+ if (argc > 1)
+ NEXT_ARG();
+ else { /* last entry on parse line */
+ mark->m = 0xffffffff;
+ goto done;
+ }
+
+ if (strcmp(*argv, "mask") == 0) {
+ NEXT_ARG();
+ if (get_u32(&mark->m, *argv, 0)) {
+ invarg("Illegal \"mark\" mask\n", *argv);
+ }
+ } else {
+ mark->m = 0xffffffff;
+ PREV_ARG();
+ }
+
+done:
+ *argcp = argc;
+ *argvp = argv;
+
+ return 0;
+}
+
void xfrm_xfrma_print(struct rtattr *tb[], __u16 family,
FILE *fp, const char *prefix)
{
+ if (tb[XFRMA_MARK]) {
+ struct rtattr *rta = tb[XFRMA_MARK];
+ struct xfrm_mark *m = (struct xfrm_mark *) RTA_DATA(rta);
+ fprintf(fp, "\tmark %d/0x%x\n", m->v, m->m);
+ }
+
if (tb[XFRMA_ALG_AUTH]) {
struct rtattr *rta = tb[XFRMA_ALG_AUTH];
xfrm_algo_print((struct xfrm_algo *) RTA_DATA(rta),
@@ -740,6 +779,7 @@ void xfrm_xfrma_print(struct rtattr *tb[], __u16 family,
fprintf(fp, "%s", strxf_time(lastused));
fprintf(fp, "%s", _SL_);
}
+
}
static int xfrm_selector_iszero(struct xfrm_selector *s)
diff --git a/ip/xfrm.h b/ip/xfrm.h
index 104fb20..d3ca5c5 100644
--- a/ip/xfrm.h
+++ b/ip/xfrm.h
@@ -121,6 +121,7 @@ int xfrm_xfrmproto_is_ipsec(__u8 proto);
int xfrm_xfrmproto_is_ro(__u8 proto);
int xfrm_xfrmproto_getbyname(char *name);
int xfrm_algotype_getbyname(char *name);
+int xfrm_parse_mark(struct xfrm_mark *mark, int *argcp, char ***argvp);
const char *strxf_xfrmproto(__u8 proto);
const char *strxf_algotype(int type);
const char *strxf_mask8(__u8 mask);
--
1.6.0.4
^ permalink raw reply related
* [iproute2 PATCH 3/3] xfrm: add support for SA by mark
From: jamal @ 2010-02-23 13:15 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Jamal Hadi Salim
In-Reply-To: <1266930912-14640-2-git-send-email-hadi@cyberus.ca>
From: Jamal Hadi Salim <hadi@cyberus.ca>
Add support for SA manipulation by mark
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
---
ip/xfrm_state.c | 66 +++++++++++++++++++++++++++++++++++++++++++-----------
1 files changed, 52 insertions(+), 14 deletions(-)
diff --git a/ip/xfrm_state.c b/ip/xfrm_state.c
index 32238ab..38d4039 100644
--- a/ip/xfrm_state.c
+++ b/ip/xfrm_state.c
@@ -67,7 +67,7 @@ static void usage(void)
fprintf(stderr, "Usage: ip xfrm state flush [ proto XFRM_PROTO ]\n");
fprintf(stderr, "Usage: ip xfrm state count \n");
- fprintf(stderr, "ID := [ src ADDR ] [ dst ADDR ] [ proto XFRM_PROTO ] [ spi SPI ]\n");
+ fprintf(stderr, "ID := [ src ADDR ] [ dst ADDR ] [ proto XFRM_PROTO ] [ spi SPI ] [mark MARK [mask MASK]]\n");
//fprintf(stderr, "XFRM_PROTO := [ esp | ah | comp ]\n");
fprintf(stderr, "XFRM_PROTO := [ ");
fprintf(stderr, "%s | ", strxf_xfrmproto(IPPROTO_ESP));
@@ -246,6 +246,7 @@ static int xfrm_state_modify(int cmd, unsigned flags, int argc, char **argv)
char *aalgop = NULL;
char *calgop = NULL;
char *coap = NULL;
+ struct xfrm_mark mark = {0, 0};
memset(&req, 0, sizeof(req));
memset(&replay, 0, sizeof(replay));
@@ -264,6 +265,8 @@ static int xfrm_state_modify(int cmd, unsigned flags, int argc, char **argv)
if (strcmp(*argv, "mode") == 0) {
NEXT_ARG();
xfrm_mode_parse(&req.xsinfo.mode, &argc, &argv);
+ } else if (strcmp(*argv, "mark") == 0) {
+ xfrm_parse_mark(&mark, &argc, &argv);
} else if (strcmp(*argv, "reqid") == 0) {
NEXT_ARG();
xfrm_reqid_parse(&req.xsinfo.reqid, &argc, &argv);
@@ -440,6 +443,15 @@ parse_algo:
exit(1);
}
+ if (mark.m & mark.v) {
+ int r = addattr_l(&req.n, sizeof(req.buf), XFRMA_MARK,
+ (void *)&mark, sizeof(mark));
+ if (r < 0) {
+ fprintf(stderr, "XFRMA_MARK failed\n");
+ exit(1);
+ }
+ }
+
switch (req.xsinfo.mode) {
case XFRM_MODE_TRANSPORT:
case XFRM_MODE_TUNNEL:
@@ -519,6 +531,7 @@ static int xfrm_state_allocspi(int argc, char **argv)
char *idp = NULL;
char *minp = NULL;
char *maxp = NULL;
+ struct xfrm_mark mark = {0, 0};
char res_buf[NLMSG_BUF_SIZE];
struct nlmsghdr *res_n = (struct nlmsghdr *)res_buf;
@@ -542,6 +555,8 @@ static int xfrm_state_allocspi(int argc, char **argv)
if (strcmp(*argv, "mode") == 0) {
NEXT_ARG();
xfrm_mode_parse(&req.xspi.info.mode, &argc, &argv);
+ } else if (strcmp(*argv, "mark") == 0) {
+ xfrm_parse_mark(&mark, &argc, &argv);
} else if (strcmp(*argv, "reqid") == 0) {
NEXT_ARG();
xfrm_reqid_parse(&req.xspi.info.reqid, &argc, &argv);
@@ -618,6 +633,15 @@ static int xfrm_state_allocspi(int argc, char **argv)
req.xspi.max = 0xffff;
}
+ if (mark.m & mark.v) {
+ int r = addattr_l(&req.n, sizeof(req.buf), XFRMA_MARK,
+ (void *)&mark, sizeof(mark));
+ if (r < 0) {
+ fprintf(stderr, "XFRMA_MARK failed\n");
+ exit(1);
+ }
+ }
+
if (rtnl_open_byproto(&rth, 0, NETLINK_XFRM) < 0)
exit(1);
@@ -763,6 +787,7 @@ static int xfrm_state_get_or_delete(int argc, char **argv, int delete)
} req;
struct xfrm_id id;
char *idp = NULL;
+ struct xfrm_mark mark = {0, 0};
memset(&req, 0, sizeof(req));
@@ -774,26 +799,39 @@ static int xfrm_state_get_or_delete(int argc, char **argv, int delete)
while (argc > 0) {
xfrm_address_t saddr;
- if (idp)
- invarg("unknown", *argv);
- idp = *argv;
+ if (strcmp(*argv, "mark") == 0) {
+ xfrm_parse_mark(&mark, &argc, &argv);
+ } else {
+ if (idp)
+ invarg("unknown", *argv);
+ idp = *argv;
- /* ID */
- memset(&id, 0, sizeof(id));
- memset(&saddr, 0, sizeof(saddr));
- xfrm_id_parse(&saddr, &id, &req.xsid.family, 0,
- &argc, &argv);
+ /* ID */
+ memset(&id, 0, sizeof(id));
+ memset(&saddr, 0, sizeof(saddr));
+ xfrm_id_parse(&saddr, &id, &req.xsid.family, 0,
+ &argc, &argv);
- memcpy(&req.xsid.daddr, &id.daddr, sizeof(req.xsid.daddr));
- req.xsid.spi = id.spi;
- req.xsid.proto = id.proto;
+ memcpy(&req.xsid.daddr, &id.daddr, sizeof(req.xsid.daddr));
+ req.xsid.spi = id.spi;
+ req.xsid.proto = id.proto;
- addattr_l(&req.n, sizeof(req.buf), XFRMA_SRCADDR,
- (void *)&saddr, sizeof(saddr));
+ addattr_l(&req.n, sizeof(req.buf), XFRMA_SRCADDR,
+ (void *)&saddr, sizeof(saddr));
+ }
argc--; argv++;
}
+ if (mark.m & mark.v) {
+ int r = addattr_l(&req.n, sizeof(req.buf), XFRMA_MARK,
+ (void *)&mark, sizeof(mark));
+ if (r < 0) {
+ fprintf(stderr, "XFRMA_MARK failed\n");
+ exit(1);
+ }
+ }
+
if (rtnl_open_byproto(&rth, 0, NETLINK_XFRM) < 0)
exit(1);
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH 2/4] bas_gigaset: collapse CR/LF at end of AT response
From: Tilman Schmidt @ 2010-02-23 13:19 UTC (permalink / raw)
To: Simon Horman
Cc: Karsten Keil, David Miller, Hansjoerg Lipp, Karsten Keil,
isdn4linux, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20100223063425.GA28744@verge.net.au>
Simon Horman schrieb:
> I am confused about what the value of MAX_RESP_SIZE means.
> Is it a hw restriction?
It's an arbitrary limitation in the driver. The hardware specification
says nothing about the possible length of AT responses from the device,
so we had to draw a line somewhere. 512 bytes have so far proved to be
amply sufficient.
In practice, the limit is only hit with the M10x devices (which transmit
commands and data over the same channel) when the state machine gets out
of sync and tries to interpret received payload data as AT responses.
> It seems that up to MAX_RESP_SIZE of string-data is permitted if the line
> is terminated by CR. But only MAX_RESP_SIZE -1 bytes if the line is
> terminated by LF or CR LF.
Note that when storing the CR in cs->respdata[0] for possible collapsing
with a subsequent LF, the cbytes counter is left at 0, so the CR gets
overwritten by the first character of the next response if there's no
intervening LF.
Thanks for reviewing,
Tilman
^ permalink raw reply
* Re: RFC: netfilter: nf_conntrack: add support for "conntrack zones"
From: jamal @ 2010-02-23 13:27 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Ben Greear, Linux Netdev List,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Netfilter Development Mailinglist
In-Reply-To: <m1wry46es9.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
On Mon, 2010-02-22 at 15:17 -0800, Eric W. Biederman wrote:
> What I am thinking is:
>
> "ip ns <name> route add blah" is:
> fd = open("/var/run/netns/<name>");
> sys_setns(fd); /* Like unshare but takes an existing namespace */
> /* Then the rest of the existing ip command */
The other two below make some sense; For the above:
Does the point after sys_setns(fd) allow me to do io inside
ns <name>? Can i do open() and get a fd from ns <name>?
> "ip ns list" is:
> dfd = open("/var/run/netns", O_DIRECTORY);
> getdents(dfd, buf, count);
>
> "ip ns new <name>" is:
> unshare(CLONE_NEWNS);
> fd = nsfd(NETNS);
> mkdir("/var/run/netns/<name>");
> mount("none", "/var/run/netns/<name>", "ns", 0, fd);
>
> Using unix domain names means that which namespaces you see is under
> control of userspace. Which allows for nested containers (something I
> use today), and ultimately container migration.
The only problem that i see is events are not as nice. I take it i am
going to get something like an inotify when a new namespace is created?
> Using genetlink userspace doesn't result in a nestable implementation
> unless I introduce yet another namespace, ugh.
Is it not just a naming convention that you are dealing with?
Example in your scheme above a nested namespace shows up as:
/var/run/netns/<name>/<nestedname>, no?
cheers,
jamal
^ permalink raw reply
* [iproute2 PATCH 2/3] xfrm: policy by mark
From: jamal @ 2010-02-23 13:15 UTC (permalink / raw)
To: shemminger; +Cc: netdev, Jamal Hadi Salim
In-Reply-To: <1266930912-14640-1-git-send-email-hadi@cyberus.ca>
From: Jamal Hadi Salim <hadi@cyberus.ca>
Add support for SP manipulation by mark
Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
---
ip/xfrm_policy.c | 29 +++++++++++++++++++++++++++--
1 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/ip/xfrm_policy.c b/ip/xfrm_policy.c
index 2788477..121afa1 100644
--- a/ip/xfrm_policy.c
+++ b/ip/xfrm_policy.c
@@ -54,8 +54,8 @@ static void usage(void) __attribute__((noreturn));
static void usage(void)
{
fprintf(stderr, "Usage: ip xfrm policy { add | update } dir DIR SELECTOR [ index INDEX ] [ ptype PTYPE ]\n");
- fprintf(stderr, " [ action ACTION ] [ priority PRIORITY ] [ flag FLAG-LIST ] [ LIMIT-LIST ] [ TMPL-LIST ]\n");
- fprintf(stderr, "Usage: ip xfrm policy { delete | get } dir DIR [ SELECTOR | index INDEX ] [ ptype PTYPE ]\n");
+ fprintf(stderr, " [ action ACTION ] [ priority PRIORITY ] [ flag FLAG-LIST ] [ LIMIT-LIST ] [ TMPL-LIST ] [mark MARK [mask MASK]]\n");
+ fprintf(stderr, "Usage: ip xfrm policy { delete | get } dir DIR [ SELECTOR | index INDEX ] [ ptype PTYPE ] [mark MARK [mask MASK]]\n");
fprintf(stderr, "Usage: ip xfrm policy { deleteall | list } [ dir DIR ] [ SELECTOR ]\n");
fprintf(stderr, " [ index INDEX ] [ action ACTION ] [ priority PRIORITY ] [ flag FLAG-LIST ]\n");
fprintf(stderr, "Usage: ip xfrm policy flush [ ptype PTYPE ]\n");
@@ -235,6 +235,7 @@ static int xfrm_policy_modify(int cmd, unsigned flags, int argc, char **argv)
struct xfrm_userpolicy_type upt;
char tmpls_buf[XFRM_TMPLS_BUF_SIZE];
int tmpls_len = 0;
+ struct xfrm_mark mark = {0, 0};
memset(&req, 0, sizeof(req));
memset(&upt, 0, sizeof(upt));
@@ -258,6 +259,8 @@ static int xfrm_policy_modify(int cmd, unsigned flags, int argc, char **argv)
NEXT_ARG();
xfrm_policy_dir_parse(&req.xpinfo.dir, &argc, &argv);
+ } else if (strcmp(*argv, "mark") == 0) {
+ xfrm_parse_mark(&mark, &argc, &argv);
} else if (strcmp(*argv, "index") == 0) {
NEXT_ARG();
if (get_u32(&req.xpinfo.index, *argv, 0))
@@ -334,6 +337,16 @@ static int xfrm_policy_modify(int cmd, unsigned flags, int argc, char **argv)
(void *)tmpls_buf, tmpls_len);
}
+ if (mark.m & mark.v) {
+ int r = addattr_l(&req.n, sizeof(req.buf), XFRMA_MARK,
+ (void *)&mark, sizeof(mark));
+ if (r < 0) {
+ fprintf(stderr, "%s: XFRMA_MARK failed\n",__func__);
+ exit(1);
+ }
+ }
+
+
if (rtnl_open_byproto(&rth, 0, NETLINK_XFRM) < 0)
exit(1);
@@ -515,6 +528,7 @@ static int xfrm_policy_get_or_delete(int argc, char **argv, int delete,
char *indexp = NULL;
char *ptypep = NULL;
struct xfrm_userpolicy_type upt;
+ struct xfrm_mark mark = {0, 0};
memset(&req, 0, sizeof(req));
memset(&upt, 0, sizeof(upt));
@@ -532,6 +546,8 @@ static int xfrm_policy_get_or_delete(int argc, char **argv, int delete,
NEXT_ARG();
xfrm_policy_dir_parse(&req.xpid.dir, &argc, &argv);
+ } else if (strcmp(*argv, "mark") == 0) {
+ xfrm_parse_mark(&mark, &argc, &argv);
} else if (strcmp(*argv, "index") == 0) {
if (indexp)
duparg("index", *argv);
@@ -584,6 +600,15 @@ static int xfrm_policy_get_or_delete(int argc, char **argv, int delete,
if (req.xpid.sel.family == AF_UNSPEC)
req.xpid.sel.family = AF_INET;
+ if (mark.m & mark.v) {
+ int r = addattr_l(&req.n, sizeof(req.buf), XFRMA_MARK,
+ (void *)&mark, sizeof(mark));
+ if (r < 0) {
+ fprintf(stderr, "%s: XFRMA_MARK failed\n",__func__);
+ exit(1);
+ }
+ }
+
if (rtnl_talk(&rth, &req.n, 0, 0, res_nlbuf, NULL, NULL) < 0)
exit(2);
--
1.6.0.4
^ permalink raw reply related
* Re: RFC: netfilter: nf_conntrack: add support for "conntrack zones"
From: Eric W. Biederman @ 2010-02-23 14:07 UTC (permalink / raw)
To: hadi
Cc: Patrick McHardy, Linux Netdev List, containers,
Netfilter Development Mailinglist, Ben Greear
In-Reply-To: <1266931623.3973.643.camel@bigi>
jamal <hadi@cyberus.ca> writes:
> On Mon, 2010-02-22 at 15:17 -0800, Eric W. Biederman wrote:
>
>> What I am thinking is:
>>
>> "ip ns <name> route add blah" is:
>> fd = open("/var/run/netns/<name>");
>> sys_setns(fd); /* Like unshare but takes an existing namespace */
>> /* Then the rest of the existing ip command */
>
> The other two below make some sense; For the above:
> Does the point after sys_setns(fd) allow me to do io inside
> ns <name>? Can i do open() and get a fd from ns <name>?
Yes. My intention is that current->nsproxy->net_ns be changed.
We can already change it in unshare so this is feasible.
>> "ip ns list" is:
>> dfd = open("/var/run/netns", O_DIRECTORY);
>> getdents(dfd, buf, count);
>>
>> "ip ns new <name>" is:
>> unshare(CLONE_NEWNS);
>> fd = nsfd(NETNS);
>> mkdir("/var/run/netns/<name>");
>> mount("none", "/var/run/netns/<name>", "ns", 0, fd);
>>
>> Using unix domain names means that which namespaces you see is under
>> control of userspace. Which allows for nested containers (something I
>> use today), and ultimately container migration.
>
> The only problem that i see is events are not as nice. I take it i am
> going to get something like an inotify when a new namespace is created?
Yes. Inotify would at the very least see that mkdir. You could also
use poll on /proc/mounts to see the set of mounts change.
>> Using genetlink userspace doesn't result in a nestable implementation
>> unless I introduce yet another namespace, ugh.
>
> Is it not just a naming convention that you are dealing with?
> Example in your scheme above a nested namespace shows up as:
> /var/run/netns/<name>/<nestedname>, no?
No. More like:
For the outer namespace:
/var/run/netns/<name>
For the inner namespace:
/some/random/fs/path/to/a/chroot/var/run/netns/<name>
For a doubly nested scenario:
/some/random/fs/path/to/a/chroot/some/other/random/fs/path/to/another/chroot/var/run/netns/<name>
Since I would be using mount namespaces instead of chroot it is not
strictly required that the fs paths nest at all.
Eric
^ permalink raw reply
* Re: RFC: netfilter: nf_conntrack: add support for "conntrack zones"
From: jamal @ 2010-02-23 14:20 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Daniel Lezcano, Patrick McHardy, Linux Netdev List, containers,
Netfilter Development Mailinglist, Ben Greear
In-Reply-To: <m1iq9ocafv.fsf@fess.ebiederm.org>
Added Daniel to the discussion..
On Tue, 2010-02-23 at 06:07 -0800, Eric W. Biederman wrote:
> jamal <hadi@cyberus.ca> writes:
> > Does the point after sys_setns(fd) allow me to do io inside
> > ns <name>? Can i do open() and get a fd from ns <name>?
>
> Yes. My intention is that current->nsproxy->net_ns be changed.
> We can already change it in unshare so this is feasible.
I like it if it makes it as easy as it sounds;-> With lxc,
i essentially have to create a proxy process inside the
namespace that i use unix domain to open fds inside the ns.
Do i still need that?
> > The only problem that i see is events are not as nice. I take it i am
> > going to get something like an inotify when a new namespace is created?
>
> Yes. Inotify would at the very least see that mkdir. You could also
> use poll on /proc/mounts to see the set of mounts change.
It is not as nice but livable. I suppose attributes of the specific
namespace are retrieved somewhere there as well..
> > Is it not just a naming convention that you are dealing with?
> > Example in your scheme above a nested namespace shows up as:
> > /var/run/netns/<name>/<nestedname>, no?
>
> No. More like:
>
> For the outer namespace:
> /var/run/netns/<name>
>
> For the inner namespace:
> /some/random/fs/path/to/a/chroot/var/run/netns/<name>
>
> For a doubly nested scenario:
> /some/random/fs/path/to/a/chroot/some/other/random/fs/path/to/another/chroot/var/run/netns/<name>
>
> Since I would be using mount namespaces instead of chroot it is not
> strictly required that the fs paths nest at all.
Ok.
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 2/2] can: ti hecc module : add platform specific initialization callback.
From: Wolfgang Grandegger @ 2010-02-23 14:34 UTC (permalink / raw)
To: David Miller
Cc: srk-l0cyMroinI0, socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100222.154741.56894014.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller wrote:
> From: Sriramakrishnan <srk-l0cyMroinI0@public.gmane.org>
> Date: Mon, 22 Feb 2010 19:06:02 +0530
>
>> CAN module on AM3517 requires programming of IO expander as part
>> of init sequence - to enable CAN PHY. Added platform specific
>> init callback to handle this.
>>
>> Signed-off-by: Sriramakrishnan <srk-l0cyMroinI0@public.gmane.org>
>> Acked-by: Anant Gole <anantgole-l0cyMroinI0@public.gmane.org>
>
> Please address Wolfgang's feedback comments.
Yes, as Marc suggested, please follow the at91_can.c example using
transceiver_switch.
Wolfgang.
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: Stephens, Allan @ 2010-02-23 15:02 UTC (permalink / raw)
To: Neil Horman; +Cc: jon.maloy, netdev, tipc-discussion, davem
In-Reply-To: <20100223011116.GA2021@localhost.localdomain>
Neil wrote:
> > 2) The other change you made to defer setting tipc_mode to
> > TIPC_NET_MODE will cause problems if TIPC has to bail out during
> > tipc_net_start() because of problems. Specifically, the
> ensuing call
> > to tipc_net_stop() won't get a chance to clean up any partial
> > initialization that got done prior to the initialization
> problem, which could result in memory leaks.
> >
> > Fortunately, I think there's a relatively easy solution.
> Since TIPC
> > always needs to call tipc_node_select() in order to send an
> off-node
> > message, you should be able to add the necessary error
> checking there.
> > I'm thinking of something along the lines of:
> >
> That seems like it might be a problem in and of itself. If
> the startup/shutdown code relies on the state of the
> implementation, perhaps that worth cleaning up so as to avoid
> a race condition.
I'm afraid I don't understand what you mean here. It sounds like you're
saying that TIPC's code shouldn't rely on the state of its own
implementation.
> > static inline struct tipc_node *tipc_node_select(u32 addr, u32
> > selector) {
> > if (likely(in_own_cluster(addr)))
> > return tipc_local_nodes ?
> > tipc_local_nodes[tipc_node(addr)] : NULL;
> > return tipc_net->zones ? tipc_node_select_next_hop(addr,
> > selector) : NULL;
> > }
> >
> > Please give this a try and let us know how things go.
> >
> I'm happy to give this a try, but I'm a bit concerned by this
> approach. It certainly seems like it will solve the problem
> at hand, but it doesn't seem to address the underlying cause,
> which is that you can execute code paths which the state of
> the implementation doesn't/shouldn't allow. In other words,
> this solve the immediate problem, but it still allows someone
> to try send data via tipc before tipc is ready to send data.
> It would be nice if we could deal with the larger problem.
I don't think you've stated the issue correctly. The problem you
encountered isn't that TIPC is allowing users to send data before TIPC
is ready, it's that TIPC is allowing users to send data *off-node*
before TIPC is ready. TIPC was deliberately designed so that messages
could be sent within the node itself as soon as possible, without having
to wait for full connectivity to the rest of the network, and this it
does quite well. Later, once connectivity to the network is
established, TIPC allows applications to send data to other nodes, and
this also appears to work properly providing the applications use TIPC's
location transparent service naming form of addressing.
What we don't appear to have anticipated is that someone would attempt
to send messages to another node without first receiving an indication
from TIPC that the node could be reached. As far as I can tell, the
only way that the crash you encountered could be generated would be if
your application blindly tries to send to a named service on a specified
node without first waiting for notification that the node exists.
(Please correct me if I'm wrong about this.) While this operation is
certainly legal, including a specific node address in a send operation
kind of defeats the whole location transparent addressing premise on
which TIPC is based and I'm wondering if it's really necessary to do
things this way. Regardless, the fix I've suggested seems to me to be a
reasonable way of blocking premature sends off-node while still
permitting on-node sends to work, and should make everyone happy.
> I'll let you know how the above patch goes.
Thanks,
Al
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
^ permalink raw reply
* [net-next-2.6 PATCH] Multiqueue support for bonding devices
From: "Oleg A. Arkhangelsky" @ 2010-02-23 15:16 UTC (permalink / raw)
To: netdev
Make bonding driver multiqueue aware.
Signed-off-by: Oleg A. Arkhangelsky <sysoleg@yandex.ru>
---
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 1787e3c..f54f590 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4928,8 +4928,9 @@ int bond_create(struct net *net, const char *name)
rtnl_lock();
- bond_dev = alloc_netdev(sizeof(struct bonding), name ? name : "",
- bond_setup);
+ bond_dev = alloc_netdev_mq(sizeof(struct bonding), name ? name : "",
+ bond_setup,
+ min_t(u32, BOND_MAX_TX_QUEUES, num_online_cpus()));
if (!bond_dev) {
pr_err("%s: eek! can't alloc netdev!\n", name);
res = -ENOMEM;
diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
index 257a7a4..eab3239 100644
--- a/drivers/net/bonding/bonding.h
+++ b/drivers/net/bonding/bonding.h
@@ -29,6 +29,7 @@
#define DRV_DESCRIPTION "Ethernet Channel Bonding Driver"
#define BOND_MAX_ARP_TARGETS 16
+#define BOND_MAX_TX_QUEUES 8
#define IS_UP(dev) \
((((dev)->flags & IFF_UP) == IFF_UP) && \
---
--
wbr, Oleg.
^ permalink raw reply related
* [net-next-2.6 PATCH] Preserve queue mapping with bonding and VLAN devices
From: "Oleg A. Arkhangelsky" @ 2010-02-23 15:17 UTC (permalink / raw)
To: netdev
Must be applied with "[net-next-2.6 PATCH] Multiqueue support for bonding devices"
Forwarded packet goes more that once throught dev_queue_xmit() when
using bonding or 802.1q VLAN devices, so we've lost rx-tx queue mapping
index for real devices. This is because initial queue index value (as it recorded
by skb_record_tx_queue()) is overwritten by skb_set_queue_mapping(). We
need to store it somewhere else.
Signed-off-by: Oleg A. Arkhangelsky <sysoleg@yandex.ru>
---
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index ba0f8e3..cbc489d 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -375,7 +375,8 @@ struct sk_buff {
#endif
kmemcheck_bitfield_begin(flags2);
- __u16 queue_mapping:16;
+ __u16 queue_mapping:8,
+ rx_queue_index:8;
#ifdef CONFIG_IPV6_NDISC_NODETYPE
__u8 ndisc_nodetype:2;
#endif
@@ -2011,7 +2012,7 @@ static inline void skb_init_secmark(struct sk_buff *skb)
{ }
#endif
-static inline void skb_set_queue_mapping(struct sk_buff *skb, u16 queue_mapping)
+static inline void skb_set_queue_mapping(struct sk_buff *skb, u8 queue_mapping)
{
skb->queue_mapping = queue_mapping;
}
@@ -2026,22 +2027,27 @@ static inline void skb_copy_queue_mapping(struct sk_buff *to, const struct sk_bu
to->queue_mapping = from->queue_mapping;
}
-static inline void skb_record_rx_queue(struct sk_buff *skb, u16 rx_queue)
+static inline void skb_copy_rx_queue_index(struct sk_buff *to, const struct sk_buff *from)
{
- skb->queue_mapping = rx_queue + 1;
+ to->rx_queue_index = from->rx_queue_index;
+}
+
+static inline void skb_record_rx_queue(struct sk_buff *skb, u8 rx_queue)
+{
+ skb->rx_queue_index = rx_queue + 1;
}
static inline u16 skb_get_rx_queue(const struct sk_buff *skb)
{
- return skb->queue_mapping - 1;
+ return skb->rx_queue_index - 1;
}
static inline bool skb_rx_queue_recorded(const struct sk_buff *skb)
{
- return (skb->queue_mapping != 0);
+ return (skb->rx_queue_index != 0);
}
-extern u16 skb_tx_hash(const struct net_device *dev,
+extern u8 skb_tx_hash(const struct net_device *dev,
const struct sk_buff *skb);
#ifdef CONFIG_XFRM
diff --git a/net/core/dev.c b/net/core/dev.c
index 1968980..0756b79 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1911,7 +1911,7 @@ out_kfree_skb:
static u32 skb_tx_hashrnd;
-u16 skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb)
+u8 skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb)
{
u32 hash;
@@ -1929,7 +1929,7 @@ u16 skb_tx_hash(const struct net_device *dev, const struct sk_buff *skb)
hash = jhash_1word(hash, skb_tx_hashrnd);
- return (u16) (((u64) hash * dev->real_num_tx_queues) >> 32);
+ return (u8) (((u64) hash * dev->real_num_tx_queues) >> 32);
}
EXPORT_SYMBOL(skb_tx_hash);
@@ -1950,7 +1950,7 @@ static inline u16 dev_cap_txqueue(struct net_device *dev, u16 queue_index)
static struct netdev_queue *dev_pick_tx(struct net_device *dev,
struct sk_buff *skb)
{
- u16 queue_index;
+ u8 queue_index;
struct sock *sk = skb->sk;
if (sk_tx_queue_recorded(sk)) {
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 93c4e06..f5ac9ee 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -543,6 +543,7 @@ static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old)
new->pkt_type = old->pkt_type;
new->ip_summed = old->ip_summed;
skb_copy_queue_mapping(new, old);
+ skb_copy_rx_queue_index(new, old);
new->priority = old->priority;
#if defined(CONFIG_IP_VS) || defined(CONFIG_IP_VS_MODULE)
new->ipvs_property = old->ipvs_property;
---
--
wbr, Oleg.
^ permalink raw reply related
* Re: [net-next-2.6 PATCH] Preserve queue mapping with bonding and VLAN devices
From: Ben Hutchings @ 2010-02-23 15:59 UTC (permalink / raw)
To: "Oleg A. Arkhangelsky"; +Cc: netdev
In-Reply-To: <33081266938239@webmail48.yandex.ru>
On Tue, 2010-02-23 at 18:17 +0300, "Oleg A. Arkhangelsky" wrote:
>
> Must be applied with "[net-next-2.6 PATCH] Multiqueue support for bonding devices"
>
> Forwarded packet goes more that once throught dev_queue_xmit() when
> using bonding or 802.1q VLAN devices, so we've lost rx-tx queue mapping
> index for real devices.
[...]
The queue mapping will normally be the same, only no longer biased by 1.
So I think a better solution would be to maintain that bias on TX as
well, or to remove the bias and reserve -1 for unknown RX queue.
We already have hardware that can do RSS across up to 128 RX queues, so
an 8-bit limit is uncomfortably close.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: Neil Horman @ 2010-02-23 16:09 UTC (permalink / raw)
To: Stephens, Allan; +Cc: netdev, jon.maloy, tipc-discussion, davem
In-Reply-To: <29C1DC0826876849BDD9F1C67ABA2943070F0D92@ala-mail09.corp.ad.wrs.com>
On Tue, Feb 23, 2010 at 07:02:16AM -0800, Stephens, Allan wrote:
> Neil wrote:
>
> > > 2) The other change you made to defer setting tipc_mode to
> > > TIPC_NET_MODE will cause problems if TIPC has to bail out during
> > > tipc_net_start() because of problems. Specifically, the
> > ensuing call
> > > to tipc_net_stop() won't get a chance to clean up any partial
> > > initialization that got done prior to the initialization
> > problem, which could result in memory leaks.
> > >
> > > Fortunately, I think there's a relatively easy solution.
> > Since TIPC
> > > always needs to call tipc_node_select() in order to send an
> > off-node
> > > message, you should be able to add the necessary error
> > checking there.
> > > I'm thinking of something along the lines of:
> > >
> > That seems like it might be a problem in and of itself. If
> > the startup/shutdown code relies on the state of the
> > implementation, perhaps that worth cleaning up so as to avoid
> > a race condition.
>
> I'm afraid I don't understand what you mean here. It sounds like you're
> saying that TIPC's code shouldn't rely on the state of its own
> implementation.
>
Not at all, I'm saying quite the opposite, that TIPC should rely on its own
state, but in its current implementation:
1) It doesn't (i.e. theres no check in the send path for messages that the
internal mode is TIPC_NET_MODE if the destination address is not for the local z.c.n
tuple).
2) It couldn't rely on the internal state if it did check (i.e tipc_net_start
sets tipc_mode to TIPC_NET_MODE prior to initalizing the data structures
required to support sending messages off node). So een if we did do a check for
being in NET mode prior to sending a message, it would be useless because theres
a window of time where the implementation says its ok to send, but its really
not (thats what caused the above oops).
>
> > > static inline struct tipc_node *tipc_node_select(u32 addr, u32
> > > selector) {
> > > if (likely(in_own_cluster(addr)))
> > > return tipc_local_nodes ?
> > > tipc_local_nodes[tipc_node(addr)] : NULL;
> > > return tipc_net->zones ? tipc_node_select_next_hop(addr,
> > > selector) : NULL;
> > > }
> > >
> > > Please give this a try and let us know how things go.
> > >
> > I'm happy to give this a try, but I'm a bit concerned by this
> > approach. It certainly seems like it will solve the problem
> > at hand, but it doesn't seem to address the underlying cause,
> > which is that you can execute code paths which the state of
> > the implementation doesn't/shouldn't allow. In other words,
> > this solve the immediate problem, but it still allows someone
> > to try send data via tipc before tipc is ready to send data.
> > It would be nice if we could deal with the larger problem.
>
> I don't think you've stated the issue correctly. The problem you
> encountered isn't that TIPC is allowing users to send data before TIPC
> is ready, it's that TIPC is allowing users to send data *off-node*
> before TIPC is ready. TIPC was deliberately designed so that messages
Well, yes. Sorry for not being clear. We only need to check that we're in net
mode if we're not sending to the local node.
> could be sent within the node itself as soon as possible, without having
> to wait for full connectivity to the rest of the network, and this it
My initial patch checked for this:
+ if ((tipc_mode != TIPC_NET_MODE) &&
+ (dest->addr.name.domain != tipc_own_addr))
+ return -EHOSTUNREACH;
+
If we're not in NET mode but the destination is not tipc_own_addr (initialized
to <0.0.0>) we can still send.
> does quite well. Later, once connectivity to the network is
> established, TIPC allows applications to send data to other nodes, and
> this also appears to work properly providing the applications use TIPC's
> location transparent service naming form of addressing.
>
Yes, it works fine, as long as user space applications all do the right things,
> What we don't appear to have anticipated is that someone would attempt
> to send messages to another node without first receiving an indication
> from TIPC that the node could be reached. As far as I can tell, the
> only way that the crash you encountered could be generated would be if
> your application blindly tries to send to a named service on a specified
> node without first waiting for notification that the node exists.
> (Please correct me if I'm wrong about this.) While this operation is
No, you got that exactly right :).
> certainly legal, including a specific node address in a send operation
> kind of defeats the whole location transparent addressing premise on
> which TIPC is based and I'm wondering if it's really necessary to do
> things this way. Regardless, the fix I've suggested seems to me to be a
As you said, its perfectly legal, and one of the mandates of the kernel is to
prevent unprivlidged user space applications from taking down the entire system
when they do something stupid. I completely agree with you that user space is
doing bad things here, but bad things need to result in errors and broken
applications, not crashed systems.
> reasonable way of blocking premature sends off-node while still
> permitting on-node sends to work, and should make everyone happy.
>
I agree that you patch fixes the exact problem that I reported here, but theres
more to it than that. A quick grep of the tipc stack reveals the following
symbols:
tipc_bearers
media_list
tipc_local_nodes
bcbearer
bclink
tipc_net.zones
All of these symbols:
1) Are allocated dynamically in tipc_net_start, _after_ tipc_mode is set to
TIPC_NET_MODE
2) dereferenced without NULL pointer checks in either the send path or in the
netlink configuration path, both of which are reachable from user space.
So your patch fixes the last item on your list, but what about the others? In
fact, I'll bet I can very quickly change the application to trip over a null
tipc_local_nodes dereference by changing the destination address to be something
within zone 0, cluster 0.
I really think the proper solution needs to be modifying the send and control
paths to gate on the internal state, and modify the init/shutdown code to
change state properly.
I'll let you know what I come up with
Neil
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: Stephens, Allan @ 2010-02-23 16:21 UTC (permalink / raw)
To: Neil Horman; +Cc: jon.maloy, netdev, tipc-discussion, davem
In-Reply-To: <20100223160936.GA16435@hmsreliant.think-freely.org>
Neil wrote:
> I agree that you patch fixes the exact problem that I
> reported here, but theres more to it than that. A quick grep
> of the tipc stack reveals the following
> symbols:
> tipc_bearers
> media_list
> tipc_local_nodes
> bcbearer
> bclink
> tipc_net.zones
>
> All of these symbols:
>
> 1) Are allocated dynamically in tipc_net_start, _after_
> tipc_mode is set to TIPC_NET_MODE
>
> 2) dereferenced without NULL pointer checks in either the
> send path or in the netlink configuration path, both of which
> are reachable from user space.
>
> So your patch fixes the last item on your list, but what
> about the others? In fact, I'll bet I can very quickly
> change the application to trip over a null tipc_local_nodes
> dereference by changing the destination address to be
> something within zone 0, cluster 0.
The semantics of TIPC addressing don't allow a node address of the form
<0.0.N> where N != 0, so this kind of a send ateempt should be caught
and handled by TIPC. However, you've already found one missing error
check, so it's certainly worth trying it out!
Regards,
Al
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox