* [BUG net-next] lost bnx2x
From: Eric Dumazet @ 2011-09-19 4:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Eilon Greenstein
With latest net-next, my bnx2x doesnt start
bnx2x: Can't load firmware file bnx2x/bnx2x-e1h-7.0.23.0.fw
But I do have the file in /lib/firmware/bnx2x/bnx2x-e1h-7.0.23.0.fw
^ permalink raw reply
* linux-next: manual merge of the net tree with Linus' tree
From: Stephen Rothwell @ 2011-09-19 4:41 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Toshiharu Okada, Jeff Kirsher
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/Kconfig between commit 7756332f5b64 ("pch_gbe: support ML7831
IOH") from Linus' tree and the driver rearrangement patches from the net
tree.
The changes in the commit from Linus' tree don;t affect fucntionality, so
I just used the net tree version.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* linux-next: manual merge of the net tree with Linus' tree
From: Stephen Rothwell @ 2011-09-19 4:51 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Yaniv Rosner, Eilon Greenstein,
Joe Perches
Hi all,
Today's linux-next merge of the net tree got a conflict in
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c between commit
c482e6c06461 ("bnx2x: Fix ETS bandwidth") from Linus' tree and commit
94f05b0f60de ("bnx2x: Coalesce pr_cont uses and fix DP typos") from the
net tree.
The former removes the code cleaned up by the latter, so I used the
former (see below).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
index ba15bdc,8e9b87b..0000000
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@@ -852,20 -852,26 +852,20 @@@ static int bnx2x_ets_e3b0_get_total_bw
/* Calculate total BW requested */
for (cos_idx = 0; cos_idx < ets_params->num_of_cos; cos_idx++) {
if (bnx2x_cos_state_bw == ets_params->cos[cos_idx].state) {
-
- if (0 == ets_params->cos[cos_idx].params.bw_params.bw) {
- DP(NETIF_MSG_LINK,
- "bnx2x_ets_E3B0_config BW was set to 0\n");
- return -EINVAL;
+ *total_bw +=
+ ets_params->cos[cos_idx].params.bw_params.bw;
}
- *total_bw +=
- ets_params->cos[cos_idx].params.bw_params.bw;
- }
}
- /*Check taotl BW is valid */
+ /* Check total BW is valid */
if ((100 != *total_bw) || (0 == *total_bw)) {
if (0 == *total_bw) {
- DP(NETIF_MSG_LINK, "bnx2x_ets_E3B0_config toatl BW"
- "shouldn't be 0\n");
+ DP(NETIF_MSG_LINK,
+ "bnx2x_ets_E3B0_config toatl BW shouldn't be 0\n");
return -EINVAL;
}
- DP(NETIF_MSG_LINK, "bnx2x_ets_E3B0_config toatl BW should be"
- "100\n");
+ DP(NETIF_MSG_LINK,
+ "bnx2x_ets_E3B0_config toatl BW should be 100\n");
/**
* We can handle a case whre the BW isn't 100 this can happen
* if the TC are joined.
^ permalink raw reply
* Re: MSI-X vector count on 82754L
From: Arnaud Lacombe @ 2011-09-19 5:34 UTC (permalink / raw)
To: Bruce Allan, Jeff Kirsher; +Cc: netdev, Jack Vogel
In-Reply-To: <CACqU3MVZ6GT7hNKsnWq-otxsX4TDtTi8qYPG=4gYn=cBF7-tJg@mail.gmail.com>
[fixing address of the netdev@ list, sorry - A.]
On Mon, Sep 19, 2011 at 1:31 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> Hi folks,
>
> In:
>
> commit 4662e82b2cb41c60826e50474dd86dd5c6372b0c
> Author: Bruce Allan <bruce.w.allan@intel.com>
> Date: Tue Aug 26 18:37:06 2008 -0700
>
> e1000e: add support for new 82574L part
>
> This new part has the same feature set as previous parts with the addition
> of MSI-X support.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
>
> MSI-X support was added to the e1000e driver, later on slightly reworked by:
>
> commit 8e86acd7d5968e08b3e1604e685a8c45f6fd7f40
> Author: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Mon Aug 2 14:27:23 2010 +0000
>
> e1000e: Fix irq_synchronize in MSI-X case
>
> Based on original patch/work from Jean Delvare <jdelvare@suse.de>
> Synchronize all IRQs when in MSI-X IRQ mode.
>
> Jean's original patch hard coded the sync with the 3 possible vectors,
> this patch incorporates more flexibility for the future and aligns
> with how igb stores the number of vectors into the adapter structure.
>
> CC: Jean Delvare <jdelvare@suse.de>
> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Acked-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> [It is unclear to what "Jean" does this commit log refers to, as the
> support MSI-X was added Bruce, anyway...]
>
> Why only 3 vectors are used when both the product brief and the
> datasheet advertise up to 5 MSI-X vector usable by the chip ? That is
> 2*RX + 2*TX.
>
> Thanks in advance,
> - Arnaud
>
^ permalink raw reply
* Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X
From: Michael S. Tsirkin @ 2011-09-19 6:01 UTC (permalink / raw)
To: Rusty Russell; +Cc: Sasha Levin, linux-kernel, virtualization, netdev, kvm
In-Reply-To: <871uvdryq2.fsf@rustcorp.com.au>
On Mon, Sep 19, 2011 at 01:05:17PM +0930, Rusty Russell wrote:
> On Sat, 20 Aug 2011 23:00:44 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Fri, Aug 19, 2011 at 07:33:07PM +0300, Sasha Levin wrote:
> > > Maybe this is better solved by copying the way it was done in PCI itself
> > > with capability linked list?
> >
> > There are any number of ways to lay out the structure. I went for what
> > seemed a simplest one. For MSI-X the train has left the station. We
> > can probably still tweak where the high 32 bit features
> > for 64 bit features are. No idea if it's worth it.
>
> Sorry, this has been in the back of my mind. I think it's a good idea;
> can we use the capability linked list for pre-device specific stuff from
> now on?
>
> Thanks,
> Rusty.
Do we even want capability bits then?
We can give each capability an ack flag ...
--
MST
^ permalink raw reply
* Re: RFS issue: no HW filter for paused stream
From: Amir Vadai @ 2011-09-19 6:05 UTC (permalink / raw)
To: Tom Herbert; +Cc: oren, liranl, netdev, amirv
In-Reply-To: <CAP7N4Kfd9TOPr_V6+R9yVtK80eGWbkAvPE8BStG0+WhvJHaLGg@mail.gmail.com>
(Resending in plain text)
Tom Hi,
When a stream is paused, and its rule is expired while it is paused,
no new rule will be configured to the HW when traffic resume.
Scenario:
1. Start iperf.
2. Pause it using Ctrl-Z
3. Start another iperf (to make sure first stream rule is expired)
4. Stop the second stream.
5. Resume first stream. Traffic is not steered to the right rx-queue.
From looking at the code:
- When first stream started, RSS steered traffic to rx-queue 'x'.
Because iperf server was running on a different CPU, a new rule was
added and current-cpu was set to desired-cpu.
- After paused, rule was expired and removed from HW by net driver.
But current-cpu wasn't cleared and still is equal to desired-cpu.
- When stream was resumed, traffic was steered again by RSS, and
because current-cpu was equal to desired-cpu, ndo_rx_flow_steer
wasn't called and no rule was configured to the HW.
Why isn't current-cpu cleared when expiring a rule?
- Amir
^ permalink raw reply
* Re: linux-next: manual merge of the net tree with Linus' tree
From: Dmitry Kravkov @ 2011-09-19 6:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev@vger.kernel.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org, Yaniv Rosner, Eilon Greenstein,
Joe Perches
In-Reply-To: <20110919145103.6c3e73edf51599eaa703294a@canb.auug.org.au>
On Sun, 2011-09-18 at 21:51 -0700, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net tree got a conflict in
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c between commit
> c482e6c06461 ("bnx2x: Fix ETS bandwidth") from Linus' tree and commit
> 94f05b0f60de ("bnx2x: Coalesce pr_cont uses and fix DP typos") from the
> net tree.
>
> The former removes the code cleaned up by the latter, so I used the
> former (see below).
Can you use this one instead?
Contains spell fixes and some formatting.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 34 ++++++++-------------
1 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
index 8e9b87b..733ace0 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@ -850,32 +850,24 @@ static int bnx2x_ets_e3b0_get_total_bw(
*total_bw = 0 ;
/* Calculate total BW requested */
- for (cos_idx = 0; cos_idx < ets_params->num_of_cos; cos_idx++) {
- if (bnx2x_cos_state_bw == ets_params->cos[cos_idx].state) {
+ for (cos_idx = 0; cos_idx < ets_params->num_of_cos; cos_idx++)
+ if (bnx2x_cos_state_bw == ets_params->cos[cos_idx].state)
+ *total_bw +=
+ ets_params->cos[cos_idx].params.bw_params.bw;
- if (0 == ets_params->cos[cos_idx].params.bw_params.bw) {
- DP(NETIF_MSG_LINK,
- "bnx2x_ets_E3B0_config BW was set to 0\n");
- return -EINVAL;
- }
- *total_bw +=
- ets_params->cos[cos_idx].params.bw_params.bw;
- }
- }
-
- /*Check taotl BW is valid */
+ /* Check total BW is valid */
if ((100 != *total_bw) || (0 == *total_bw)) {
if (0 == *total_bw) {
- DP(NETIF_MSG_LINK,
- "bnx2x_ets_E3B0_config toatl BW shouldn't be 0\n");
+ DP(NETIF_MSG_LINK, "bnx2x_ets_E3B0_config total BW"
+ "shouldn't be 0\n");
return -EINVAL;
}
- DP(NETIF_MSG_LINK,
- "bnx2x_ets_E3B0_config toatl BW should be 100\n");
- /**
- * We can handle a case whre the BW isn't 100 this can happen
- * if the TC are joined.
- */
+ DP(NETIF_MSG_LINK, "bnx2x_ets_E3B0_config total BW should be"
+ "100\n");
+ /*
+ * We can handle a case where the BW isn't 100 this can happen
+ * if the TC are joined.
+ */
}
return 0;
}
--
1.7.2.2
^ permalink raw reply related
* [PATCH 1/1] snmp6 relevant data structures are freed twice.
From: rongqing.li @ 2011-09-19 7:03 UTC (permalink / raw)
To: netdev
From: Roy.Li <rongqing.li@windriver.com>
When calling snmp6_alloc_dev fails, the snmp6 relevant memory
are freed by snmp6_alloc_dev. Calling in6_dev_finish_destroy
will free these memory twice.
Double free will lead that undefined behavior occurs.
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
---
net/ipv6/addrconf.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 8f1e5be..ba01f72 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -374,8 +374,8 @@ static struct inet6_dev * ipv6_add_dev(struct net_device *dev)
"%s(): cannot allocate memory for statistics; dev=%s.\n",
__func__, dev->name));
neigh_parms_release(&nd_tbl, ndev->nd_parms);
- ndev->dead = 1;
- in6_dev_finish_destroy(ndev);
+ dev_put(dev);
+ kfree(ndev);
return NULL;
}
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X
From: Rusty Russell @ 2011-09-19 7:49 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Sasha Levin, linux-kernel, virtualization, netdev, kvm
In-Reply-To: <20110919060150.GB1569@redhat.com>
On Mon, 19 Sep 2011 09:01:50 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Mon, Sep 19, 2011 at 01:05:17PM +0930, Rusty Russell wrote:
> > On Sat, 20 Aug 2011 23:00:44 +0300, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > > On Fri, Aug 19, 2011 at 07:33:07PM +0300, Sasha Levin wrote:
> > > > Maybe this is better solved by copying the way it was done in PCI itself
> > > > with capability linked list?
> > >
> > > There are any number of ways to lay out the structure. I went for what
> > > seemed a simplest one. For MSI-X the train has left the station. We
> > > can probably still tweak where the high 32 bit features
> > > for 64 bit features are. No idea if it's worth it.
> >
> > Sorry, this has been in the back of my mind. I think it's a good idea;
> > can we use the capability linked list for pre-device specific stuff from
> > now on?
> >
> > Thanks,
> > Rusty.
>
> Do we even want capability bits then?
> We can give each capability an ack flag ...
We could have, and if I'd known PCI when I designed virtio I might have.
But it's not easy now to map structure offsets to that scheme, and we
can't really force such a change on the non-PCI users. So I'd say we
should only do it for the non-device-specific options. ie. we'll still
have the MSI-X case move the device-specific config, but we'll use a
linked list from now on, eg. for the next 32 features bits...
Thoughts?
Rusty.
^ permalink raw reply
* Re: [PATCH -next v2] unix stream: Fix use-after-free crashes
From: Eric Dumazet @ 2011-09-19 7:57 UTC (permalink / raw)
To: Tim Chen
Cc: David Miller, zheng.z.yan, zheng.z.yan, netdev, sfr, jirislaby,
sedat.dilek, alex.shi
In-Reply-To: <1316191845.2201.5.camel@schen9-mobl>
Le vendredi 16 septembre 2011 à 09:50 -0700, Tim Chen a écrit :
> On Fri, 2011-09-16 at 19:35 -0400, David Miller wrote:
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Wed, 07 Sep 2011 04:55:26 +0200
> >
> > > Please David just revert 0856a304091b33a8e
> >
> > Done.
>
> Eric,
>
> Can you re-spin a patch that incorporates your idea that we don't
> add pid/credential references when we are not requesting credentials
> in the socket. And probably another one that remove unnecessary
> pid/credentials references in send/receive when we do use credentials?
Sure, I did it this morning, please review it if you have some time.
If we find a regression (some popular app doing write() and expecting
credential to be sent to receiver), we could test the SOCK_PASSCRED flag
on receiver socket.
^ permalink raw reply
* Re: [PATCH 1/1] snmp6 relevant data structures are freed twice.
From: Eric Dumazet @ 2011-09-19 8:29 UTC (permalink / raw)
To: rongqing.li; +Cc: netdev
In-Reply-To: <1316415793-2711-1-git-send-email-rongqing.li@windriver.com>
Le lundi 19 septembre 2011 à 15:03 +0800, rongqing.li@windriver.com a
écrit :
> From: Roy.Li <rongqing.li@windriver.com>
>
> When calling snmp6_alloc_dev fails, the snmp6 relevant memory
> are freed by snmp6_alloc_dev. Calling in6_dev_finish_destroy
> will free these memory twice.
>
> Double free will lead that undefined behavior occurs.
>
> Signed-off-by: Roy.Li <rongqing.li@windriver.com>
> ---
> net/ipv6/addrconf.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 8f1e5be..ba01f72 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -374,8 +374,8 @@ static struct inet6_dev * ipv6_add_dev(struct net_device *dev)
> "%s(): cannot allocate memory for statistics; dev=%s.\n",
> __func__, dev->name));
> neigh_parms_release(&nd_tbl, ndev->nd_parms);
> - ndev->dead = 1;
> - in6_dev_finish_destroy(ndev);
> + dev_put(dev);
> + kfree(ndev);
> return NULL;
> }
>
This seems a very old bug, and your fix applicable to old kernels as
well, thanks.
Could your patch title could be refined to the following ?
0) No need for the 1/1 suffix
1) include ipv6: prefix
2) change the message a bit, since normal operations are OK, only
failure and error recovery is buggy.
[PATCH] ipv6: fix a possible double free
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/1] snmp6 relevant data structures are freed twice.
From: Rongqing Li @ 2011-09-19 8:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1316420989.2539.5.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On 09/19/2011 04:29 PM, Eric Dumazet wrote:
> Le lundi 19 septembre 2011 à 15:03 +0800, rongqing.li@windriver.com a
> écrit :
>> From: Roy.Li<rongqing.li@windriver.com>
>>
>> When calling snmp6_alloc_dev fails, the snmp6 relevant memory
>> are freed by snmp6_alloc_dev. Calling in6_dev_finish_destroy
>> will free these memory twice.
>>
>> Double free will lead that undefined behavior occurs.
>>
>> Signed-off-by: Roy.Li<rongqing.li@windriver.com>
>> ---
>> net/ipv6/addrconf.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index 8f1e5be..ba01f72 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -374,8 +374,8 @@ static struct inet6_dev * ipv6_add_dev(struct net_device *dev)
>> "%s(): cannot allocate memory for statistics; dev=%s.\n",
>> __func__, dev->name));
>> neigh_parms_release(&nd_tbl, ndev->nd_parms);
>> - ndev->dead = 1;
>> - in6_dev_finish_destroy(ndev);
>> + dev_put(dev);
>> + kfree(ndev);
>> return NULL;
>> }
>>
>
> This seems a very old bug, and your fix applicable to old kernels as
> well, thanks.
>
> Could your patch title could be refined to the following ?
>
> 0) No need for the 1/1 suffix
> 1) include ipv6: prefix
> 2) change the message a bit, since normal operations are OK, only
> failure and error recovery is buggy.
>
> [PATCH] ipv6: fix a possible double free
>
> Acked-by: Eric Dumazet<eric.dumazet@gmail.com>
>
>
>
Ok, I will resend it.
--
Best Reagrds,
Roy | RongQing Li
^ permalink raw reply
* linux-next: build failure after merge of the final tree (origin/net-current tree related)
From: Stephen Rothwell @ 2011-09-19 8:35 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Eric Dumazet
[-- Attachment #1: Type: text/plain, Size: 465 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
net/built-in.o: In function `tcp_v4_conn_request':
(.text+0x5b700): undefined reference to `cookie_v4_init_sequence'
This error has already been noted elsewhere and a fix queued, so I have
merged a newer version of the net-current tree that contains the fix for
today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] net/fec: add imx6q enet support
From: Shawn Guo @ 2011-09-19 9:08 UTC (permalink / raw)
To: Francois Romieu
Cc: Shawn Guo, netdev, David S. Miller, linux-arm-kernel, patches
In-Reply-To: <20110918180912.GA3734@electric-eye.fr.zoreil.com>
On Sun, Sep 18, 2011 at 08:09:12PM +0200, Francois Romieu wrote:
> Shawn Guo <shawn.guo@linaro.org> :
> [...]
> > diff --git a/drivers/net/fec.c b/drivers/net/fec.c
> > index 04206e4..849cb0b 100644
> > --- a/drivers/net/fec.c
> > +++ b/drivers/net/fec.c
> > @@ -442,18 +453,23 @@ fec_restart(struct net_device *ndev, int duplex)
> > /* Enable flow control and length check */
> > rcntl |= 0x40000000 | 0x00000020;
> >
> > - /* MII or RMII */
> > + /* RGMII, RMII or MII */
> > + if (fep->phy_interface == PHY_INTERFACE_MODE_RGMII)
> > + rcntl |= (1 << 6);
> > if (fep->phy_interface == PHY_INTERFACE_MODE_RMII)
> ^^^^ missing "else"
>
Yes, my bad.
> [...]
> > + /* 1G, 100M or 10M */
> > + if (fep->phy_dev) {
> > + if (fep->phy_dev->speed == SPEED_1000)
> > + ecntl |= (1 << 8);
Right, this is a typo. It should be (1 << 5);
> > + else if (fep->phy_dev->speed == SPEED_100)
> > + rcntl &= ~(1 << 9);
> > + else
> > + rcntl |= (1 << 9);
> > + }
> [...]
> > + if (id_entry->driver_data & FEC_QUIRK_ENET_MAC) {
> > + /* enable ENET endian swap */
> > + ecntl |= (1 << 8);
>
> I do not understand why the endian swap bit of ecntl needs to be
> set the same in these two different paths, especially as the latter
> handles the old faulty imx28 and the former the newly fixed imx6q.
> Typo ?
>
Nice catches. Thanks a lot, Ueimor.
--
Regards,
Shawn
^ permalink raw reply
* PATCH Question, Firewall mark inherit for ip6_tunnel
From: Hans Schillström @ 2011-09-19 8:47 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
Hello Eric,
For a year ago you send an untested patch to Anders Franzen
I think the subject was "not possible to do policy routing for next hop on tunnels."
The patch have been used since that and it works perfectly,
I made some minor changes to reflect the flowi changes.
Would it be possible for you to submit that patch, since (I guess) you are the author
I can prepare it if you want.
The included patch is for linux-3.0.4
Regards
Hans Schillstrom
diff --git a/include/linux/ip6_tunnel.h b/include/linux/ip6_tunnel.h
index acb9ad6..bf22b03 100644
--- a/include/linux/ip6_tunnel.h
+++ b/include/linux/ip6_tunnel.h
@@ -16,6 +16,8 @@
#define IP6_TNL_F_MIP6_DEV 0x8
/* copy DSCP from the outer packet */
#define IP6_TNL_F_RCV_DSCP_COPY 0x10
+/* copy fwmark from inner packet */
+#define IP6_TNL_F_USE_ORIG_FWMARK 0x20
struct ip6_tnl_parm {
char name[IFNAMSIZ]; /* name of tunnel device */
diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c
index 36c2842..64be21c 100644
--- a/net/ipv6/ip6_tunnel.c
+++ b/net/ipv6/ip6_tunnel.c
@@ -897,7 +897,7 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
int err = -1;
int pkt_len;
- if ((dst = ip6_tnl_dst_check(t)) != NULL)
+ if (!fl6->flowi6_mark && (dst = ip6_tnl_dst_check(t)) != NULL)
dst_hold(dst);
else {
dst = ip6_route_output(net, NULL, fl6);
@@ -955,7 +955,7 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
skb = new_skb;
}
skb_dst_drop(skb);
- skb_dst_set(skb, dst_clone(dst));
+ skb_dst_set(skb, fl6->flowi6_mark ? dst : dst_clone(dst));
skb->transport_header = skb->network_header;
@@ -987,7 +987,9 @@ static int ip6_tnl_xmit2(struct sk_buff *skb,
stats->tx_errors++;
stats->tx_aborted_errors++;
}
- ip6_tnl_dst_store(t, dst);
+ if (!fl6->flowi6_mark)
+ ip6_tnl_dst_store(t, dst);
+
return 0;
tx_err_link_failure:
stats->tx_carrier_errors++;
@@ -1023,6 +1025,8 @@ ip4ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
if ((t->parms.flags & IP6_TNL_F_USE_ORIG_TCLASS))
fl6.flowlabel |= htonl((__u32)iph->tos << IPV6_TCLASS_SHIFT)
& IPV6_TCLASS_MASK;
+ if ((t->parms.flags & IP6_TNL_F_USE_ORIG_FWMARK))
+ fl6.flowi6_mark = skb->mark;
err = ip6_tnl_xmit2(skb, dev, dsfield, &fl6, encap_limit, &mtu);
if (err != 0) {
@@ -1073,7 +1077,8 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, struct net_device *dev)
fl6.flowlabel |= (*(__be32 *) ipv6h & IPV6_TCLASS_MASK);
if ((t->parms.flags & IP6_TNL_F_USE_ORIG_FLOWLABEL))
fl6.flowlabel |= (*(__be32 *) ipv6h & IPV6_FLOWLABEL_MASK);
-
+ if ((t->parms.flags & IP6_TNL_F_USE_ORIG_FWMARK))
+ fl6.flowi6_mark = skb->mark;
err = ip6_tnl_xmit2(skb, dev, dsfield, &fl6, encap_limit, &mtu);
if (err != 0) {
if (err == -EMSGSIZE)
--
1.7.4.4
^ permalink raw reply related
* Re: PATCH Question, Firewall mark inherit for ip6_tunnel
From: Eric Dumazet @ 2011-09-19 9:25 UTC (permalink / raw)
To: Hans Schillström; +Cc: netdev@vger.kernel.org
In-Reply-To: <C8A6796DE7C66C4ABCBC18106CB6C1CC106D903109@ESESSCMS0356.eemea.ericsson.se>
Le lundi 19 septembre 2011 à 10:47 +0200, Hans Schillström a écrit :
> Hello Eric,
> For a year ago you send an untested patch to Anders Franzen
> I think the subject was "not possible to do policy routing for next hop on tunnels."
>
> The patch have been used since that and it works perfectly,
> I made some minor changes to reflect the flowi changes.
>
> Would it be possible for you to submit that patch, since (I guess) you are the author
> I can prepare it if you want.
> The included patch is for linux-3.0.4
>
> Regards
> Hans Schillstrom
Hello Hans
Yes, I'll respin this patch on top on net-next, with your "Tested-by"
signature ;)
Thanks
^ permalink raw reply
* Re: [net-next RFC V2 PATCH 0/5] Multiqueue support in tun/tap
From: Jason Wang @ 2011-09-19 9:44 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: krkumar2, kvm, eric.dumazet, qemu-devel, netdev, rusty,
linux-kernel, virtualization, joe, shemminger, mirq-linux, davem
In-Reply-To: <20110917191709.GA6127@redhat.com>
On 09/18/2011 03:17 AM, Michael S. Tsirkin wrote:
> On Sat, Sep 17, 2011 at 02:02:04PM +0800, Jason Wang wrote:
>> A wiki-page was created to narrate the detail design of all parts
>> involved in the multi queue implementation:
>> http://www.linux-kvm.org/page/Multiqueue and some basic tests result
>> could be seen in this page
>> http://www.linux-kvm.org/page/Multiqueue-performance-Sep-13. I would
>> post the detail numbers in attachment as the reply of this thread.
> Does it make sense to test both with and without RPS in guest?
>
I've tested with RPS in guest, but didn't see improvements.
^ permalink raw reply
* [PATCH] macvtap: fix the uninitialized var using in macvtap_alloc_skb()
From: Jason Wang @ 2011-09-19 9:48 UTC (permalink / raw)
To: netdev, mst, davem, linux-kernel
Commit d1b08284 use new frag API but would leave f to be used
uninitialized, this patch fix it.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvtap.c | 12 +++++-------
1 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 7c3f84a..3da5578 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -453,7 +453,6 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
int copy = skb_headlen(skb);
int size, offset1 = 0;
int i = 0;
- skb_frag_t *f;
/* Skip over from offset */
while (count && (offset >= from->iov_len)) {
@@ -503,14 +502,13 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
skb->truesize += len;
atomic_add(len, &skb->sk->sk_wmem_alloc);
while (len) {
- __skb_fill_page_desc(
- skb, i, page[i],
- base & ~PAGE_MASK,
- min_t(int, len, PAGE_SIZE - f->page_offset));
+ int off = base & ~PAGE_MASK;
+ int size = min_t(int, len, PAGE_SIZE - off);
+ __skb_fill_page_desc(skb, i, page[i], off, size);
skb_shinfo(skb)->nr_frags++;
/* increase sk_wmem_alloc */
- base += f->size;
- len -= f->size;
+ base += size;
+ len -= size;
i++;
}
offset1 = 0;
^ permalink raw reply related
* Re: [PATCH] macvtap: fix the uninitialized var using in macvtap_alloc_skb()
From: Michael S. Tsirkin @ 2011-09-19 9:54 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, davem, linux-kernel
In-Reply-To: <20110919094830.6272.40503.stgit@dhcp-91-7.nay.redhat.com.englab.nay.redhat.com>
On Mon, Sep 19, 2011 at 05:48:31PM +0800, Jason Wang wrote:
> Commit d1b08284 use new frag API but would leave f to be used
> uninitialized, this patch fix it.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Good catch. Makes absolute sense.
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> drivers/net/macvtap.c | 12 +++++-------
> 1 files changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 7c3f84a..3da5578 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -453,7 +453,6 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
> int copy = skb_headlen(skb);
> int size, offset1 = 0;
> int i = 0;
> - skb_frag_t *f;
>
> /* Skip over from offset */
> while (count && (offset >= from->iov_len)) {
> @@ -503,14 +502,13 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
> skb->truesize += len;
> atomic_add(len, &skb->sk->sk_wmem_alloc);
> while (len) {
> - __skb_fill_page_desc(
> - skb, i, page[i],
> - base & ~PAGE_MASK,
> - min_t(int, len, PAGE_SIZE - f->page_offset));
> + int off = base & ~PAGE_MASK;
> + int size = min_t(int, len, PAGE_SIZE - off);
> + __skb_fill_page_desc(skb, i, page[i], off, size);
> skb_shinfo(skb)->nr_frags++;
> /* increase sk_wmem_alloc */
> - base += f->size;
> - len -= f->size;
> + base += size;
> + len -= size;
> i++;
> }
> offset1 = 0;
^ permalink raw reply
* RE: PATCH Question, Firewall mark inherit for ip6_tunnel
From: Hans Schillström @ 2011-09-19 9:52 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <1316424324.2539.6.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
>From: Eric Dumazet [eric.dumazet@gmail.com]
>Sent: Monday, September 19, 2011 11:25
>To: Hans Schillström
>Cc: netdev@vger.kernel.org
>Subject: Re: PATCH Question, Firewall mark inherit for ip6_tunnel
>
>Le lundi 19 septembre 2011 à 10:47 +0200, Hans Schillström a écrit :
>> Hello Eric,
>> For a year ago you send an untested patch to Anders Franzen
>> I think the subject was "not possible to do policy routing for next hop on tunnels."
>>
>> The patch have been used since that and it works perfectly,
>> I made some minor changes to reflect the flowi changes.
>>
>> Would it be possible for you to submit that patch, since (I guess) you are the author
>> I can prepare it if you want.
>> The included patch is for linux-3.0.4
>>
>> Regards
>> Hans Schillstrom
>
>Hello Hans
>
>Yes, I'll respin this patch on top on net-next, with your "Tested-by"
>signature ;)
>
>Thanks
Thanks Eric,
Do you take care of the user mode part as well (i.ie ip commad)
Hans
^ permalink raw reply
* RE: PATCH Question, Firewall mark inherit for ip6_tunnel
From: Eric Dumazet @ 2011-09-19 10:32 UTC (permalink / raw)
To: Hans Schillström; +Cc: netdev@vger.kernel.org
In-Reply-To: <C8A6796DE7C66C4ABCBC18106CB6C1CC106D90310A@ESESSCMS0356.eemea.ericsson.se>
Le lundi 19 septembre 2011 à 11:52 +0200, Hans Schillström a écrit :
> Thanks Eric,
> Do you take care of the user mode part as well (i.ie ip commad)
Yes, I'll send the iproute2 part as well.
^ permalink raw reply
* Re: [GIT] Networking
From: Neil Horman @ 2011-09-19 11:02 UTC (permalink / raw)
To: David Ward; +Cc: Linus Torvalds, David Miller, akpm, netdev, linux-kernel
In-Reply-To: <4E76864D.4080907@ll.mit.edu>
On Sun, Sep 18, 2011 at 08:01:17PM -0400, David Ward wrote:
> On 09/18/2011 02:06 PM, Linus Torvalds wrote:
> >2011/9/17 David Miller<davem@davemloft.net>:
> >>dpward (2):
> >> net: Make flow cache namespace-aware
> >> net: Handle different key sizes between address families in flow cache
> >>
> >>nhorman (1):
> >> net: don't clear IFF_XMIT_DST_RELEASE in ether_setup
> >>
> >>rajan.aggarwal85@gmail.com (1):
> >> net/can/af_can.c: Change del_timer to del_timer_sync
> >Guys, if somebody has such a broken email setup that they don't even
> >show their own name, don't take patches from them.
>
> At least in my case, that is Patchwork's fault. My name only
> started showing up like that in commits after I registered for an
> account (http://patchwork.ozlabs.org/register/), and I don't see any
> way to change the way my name appears in the Patchwork profile
> options.
>
> The emails I sent to the netdev list showed my full name; see:
> http://marc.info/?l=linux-netdev&m=131527867326729&w=2
> http://marc.info/?l=linux-netdev&m=131527879226819&w=2
>
I noticed this the other day when I registered as well. Not sure what patchwork
is doing.
Neil
> David
>
^ permalink raw reply
* 群发软件+买家搜索机+109届广交会买家、海关数据,B2B询盘买家500万。
From: 仅10元每天 @ 2011-09-19 11:15 UTC (permalink / raw)
To: net.inox, net, net, net6688yes, netavemshink, netc75, netdev,
netflagking
群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。
保证每天都有买家回复。
保证每天都有买家回复。
1、群发软件： 操作简单，功能强大，模仿人工操作模式，到达率高，日发送5万封以上。
2、500万广交会买家资源： 赠送的500万买家资源库，每月更新 。
3、超级海外买家Email搜索机： 每天能搜索1-2万以上买家真实EMAIL，成单率高。
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625218@qq.com
免费赠送:
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季109届广交会买家现场询盘数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，购买后可以免费更新2011秋季广交会+2012春季广交会买家数据。太超值了。
3，最新全球买家库,共451660条数据。 (最新更新日期 2011-05-16日)
4，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
5，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
6，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
7，48.68万条最新买家询盘，购买后每月更新 1-2万条，包括2部分，1，最新的询盘 2，最新的展会买家。免费更新36个月。
8，2009年海关提单数据piers版数据 1千万。
诚信为本，支持支付宝担保交易 (先发货并安装设置群发软件，然后付款) 彻底打消您的 顾虑。
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
^ permalink raw reply
* Re: [BUG net-next] lost bnx2x
From: Dmitry Kravkov @ 2011-09-19 11:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Eilon Greenstein
In-Reply-To: <1316406760.2521.18.camel@edumazet-laptop>
On Sun, 2011-09-18 at 21:32 -0700, Eric Dumazet wrote:
> With latest net-next, my bnx2x doesnt start
>
> bnx2x: Can't load firmware file bnx2x/bnx2x-e1h-7.0.23.0.fw
>
> But I do have the file in /lib/firmware/bnx2x/bnx2x-e1h-7.0.23.0.fw
>
Just pulled net-next - bnx2x device can load and pass traffic(on x86-64)
Can you provide more details about your setup?
^ permalink raw reply
* Re: [BUG net-next] lost bnx2x
From: Eric Dumazet @ 2011-09-19 12:05 UTC (permalink / raw)
To: dmitry; +Cc: David Miller, netdev, Eilon Greenstein
In-Reply-To: <1316433250.4154.3.camel@lb-tlvb-dmitry>
Le lundi 19 septembre 2011 à 14:54 +0300, Dmitry Kravkov a écrit :
> On Sun, 2011-09-18 at 21:32 -0700, Eric Dumazet wrote:
> > With latest net-next, my bnx2x doesnt start
> >
> > bnx2x: Can't load firmware file bnx2x/bnx2x-e1h-7.0.23.0.fw
> >
> > But I do have the file in /lib/firmware/bnx2x/bnx2x-e1h-7.0.23.0.fw
> >
>
> Just pulled net-next - bnx2x device can load and pass traffic(on x86-64)
> Can you provide more details about your setup?
Please hold on, it might be because of my af_unix patches.
I am investigating right now.
^ 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