* [PATCH] tcp: fix validation of D-SACK
From: Yan, Zheng @ 2011-09-19 2:05 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: David Miller, eric.dumazet@gmail.com
In-Reply-To: <20110918.210725.2061666096968958448.davem@davemloft.net>
D-SACK is allowed to reside below snd_una. But the corresponding check
in tcp_is_sackblock_valid() is the exact opposite. It looks like a typo.
Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index ea0d218..21fab3e 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -1124,7 +1124,7 @@ static int tcp_is_sackblock_valid(struct tcp_sock *tp, int is_dsack,
return 0;
/* ...Then it's D-SACK, and must reside below snd_una completely */
- if (!after(end_seq, tp->snd_una))
+ if (after(end_seq, tp->snd_una))
return 0;
if (!before(start_seq, tp->undo_marker))
^ permalink raw reply related
* Re: [PATCH] tcp: fix validation of D-SACK
From: David Miller @ 2011-09-19 2:37 UTC (permalink / raw)
To: zheng.z.yan; +Cc: netdev, eric.dumazet
In-Reply-To: <4E76A36B.4060109@intel.com>
From: "Yan, Zheng" <zheng.z.yan@intel.com>
Date: Mon, 19 Sep 2011 10:05:31 +0800
> D-SACK is allowed to reside below snd_una. But the corresponding check
> in tcp_is_sackblock_valid() is the exact opposite. It looks like a typo.
>
> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [GIT] Networking
From: Jeremy Kerr @ 2011-09-19 2:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, david.ward, akpm, netdev, linux-kernel
In-Reply-To: <CA+55aFyENEpGJmTq55=n0_gDiF6RQmdKw-ts4AdQAFQJ1TkF-Q@mail.gmail.com>
Hi all,
> Hmm. I *think* the right person for patchwork issues is Jeremy Kerr,
> but I migth be wrong..
Yes, that's correct.
> Jeremy, the fact that apparently patchworks loses proper names is a
> killer feature - but very much in the wrong meaning of "killer". Any
> way to make sure that doesn't happen?
Yeah, probably not the killer feature we're after.
I've found the problem, and committed a fix & testcase:
http://git.ozlabs.org/?p=patchwork;a=commitdiff;h=4bc2c34d
That fix has been applied to the patchwork.ozlabs.org instance, and I've
manually updated the incorrect (ie, username-only) entries in the
patchwork database.
Cheers,
Jeremy
^ permalink raw reply
* Re: [GIT] Networking
From: David Miller @ 2011-09-19 3:00 UTC (permalink / raw)
To: jk; +Cc: torvalds, david.ward, akpm, netdev, linux-kernel
In-Reply-To: <1316401043.2768.52.camel@pororo>
From: Jeremy Kerr <jk@ozlabs.org>
Date: Mon, 19 Sep 2011 10:57:23 +0800
> I've found the problem, and committed a fix & testcase:
>
> http://git.ozlabs.org/?p=patchwork;a=commitdiff;h=4bc2c34d
>
> That fix has been applied to the patchwork.ozlabs.org instance, and I've
> manually updated the incorrect (ie, username-only) entries in the
> patchwork database.
Thanks a bunch Jeremy!
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-09-19 3:13 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
I fixed up Eric's build fix and also there is a fix for a
reversed test in TCP's DSACK validation from Zheng Yan.
Please pull, thanks a lot!
The following changes since commit b0e7031ac08fa0aa242531c8d9a0cf9ae8ee276d:
Merge git://github.com/davem330/net (2011-09-18 11:02:26 -0700)
are available in the git repository at:
git://github.com/davem330/net.git master
Eric Dumazet (1):
tcp: fix build error if !CONFIG_SYN_COOKIES
Zheng Yan (1):
tcp: fix validation of D-SACK
include/net/tcp.h | 19 ++++++++++++++++++-
net/ipv4/tcp_input.c | 2 +-
2 files changed, 19 insertions(+), 2 deletions(-)
^ permalink raw reply
* Re: [GIT] Networking
From: Eric Dumazet @ 2011-09-19 3:17 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, markus, akpm, netdev, linux-kernel
In-Reply-To: <20110918.214540.33131923686632079.davem@davemloft.net>
Le dimanche 18 septembre 2011 à 21:45 -0400, David Miller a écrit :
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Sun, 18 Sep 2011 18:26:33 -0700
>
> > Stop with the "this might just work" crap. Because -rc7 is just too
> > late to dick around like that.
>
> I'll sort this out.
Oh well, I did compile the thing on my slow netbook, not on my usual 16
core dev machine, and I had to catch a very small window of Internet
access (my ADSL box collapsed when a thunderstrike hit the church in my
neighbourhood)
Thanks guys.
^ permalink raw reply
* Re: [PATCH] virtio-net: Read MAC only after initializing MSI-X
From: Rusty Russell @ 2011-09-19 3:35 UTC (permalink / raw)
To: Michael S. Tsirkin, Sasha Levin; +Cc: linux-kernel, virtualization, netdev, kvm
In-Reply-To: <20110820200043.GB5276@redhat.com>
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.
^ permalink raw reply
* wireless build errors on latest net-next
From: Eric Dumazet @ 2011-09-19 4:22 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Kernel: arch/x86/boot/bzImage is ready (#299)
Building modules, stage 2.
MODPOST 1778 modules
ERROR: "iwl_dump_fh" [drivers/net/wireless/iwlwifi/iwlagn.ko] undefined!
ERROR: "iwl_dump_csr" [drivers/net/wireless/iwlwifi/iwlagn.ko]
undefined!
make[1]: *** [__modpost] Erreur 1
make: *** [modules] Erreur 2
^ permalink raw reply
* GET BACK TO ME ASAP
From: Hassan @ 2011-09-18 22:07 UTC (permalink / raw)
Hello,
How are you today?
I contacted you to assist in distributing the money left behind
by my late client,whom you share the same last name with.
Get back to me for more details.
Regards,
Barr Musa Kumar Hassan.
Attorney At Law.
^ permalink raw reply
* Re: [PATCH net-next] af_unix: dont send SCM_CREDENTIALS by default
From: Eric Dumazet @ 2011-09-19 4:28 UTC (permalink / raw)
To: David Miller
Cc: tim.c.chen, zheng.z.yan, yanzheng, netdev, sfr, jirislaby,
sedat.dilek, alex.shi, Valdis.Kletnieks
In-Reply-To: <20110918.210758.2207266633127640132.davem@davemloft.net>
Le dimanche 18 septembre 2011 à 21:07 -0400, David Miller a écrit :
> Eric, please respin your patches against current net-next, thanks!
Sure, here it is :
Its a bit different, so I didnt add Tim 'Acked-by'
[PATCH net-next] af_unix: dont send SCM_CREDENTIALS by default
Since commit 7361c36c5224 (af_unix: Allow credentials to work across
user and pid namespaces) af_unix performance dropped a lot.
This is because we now take a reference on pid and cred in each write(),
and release them in read(), usually done from another process,
eventually from another cpu. This triggers false sharing.
# Events: 154K cycles
#
# Overhead Command Shared Object Symbol
# ........ ....... .................. .........................
#
10.40% hackbench [kernel.kallsyms] [k] put_pid
8.60% hackbench [kernel.kallsyms] [k] unix_stream_recvmsg
7.87% hackbench [kernel.kallsyms] [k] unix_stream_sendmsg
6.11% hackbench [kernel.kallsyms] [k] do_raw_spin_lock
4.95% hackbench [kernel.kallsyms] [k] unix_scm_to_skb
4.87% hackbench [kernel.kallsyms] [k] pid_nr_ns
4.34% hackbench [kernel.kallsyms] [k] cred_to_ucred
2.39% hackbench [kernel.kallsyms] [k] unix_destruct_scm
2.24% hackbench [kernel.kallsyms] [k] sub_preempt_count
1.75% hackbench [kernel.kallsyms] [k] fget_light
1.51% hackbench [kernel.kallsyms] [k]
__mutex_lock_interruptible_slowpath
1.42% hackbench [kernel.kallsyms] [k] sock_alloc_send_pskb
This patch includes SCM_CREDENTIALS information in a af_unix message/skb
only if requested by the sender, [man 7 unix for details how to include
ancillary data using sendmsg() system call]
Note: This might break buggy applications that expected SCM_CREDENTIAL
from an unaware write() system call.
Performance boost in hackbench : more than 50% gain on a 16 thread
machine (2 quad-core cpus, 2 threads per core)
hackbench 20 thread 2000
4.228 sec instead of 9.102 sec
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
include/net/scm.h | 5 ++---
net/core/scm.c | 10 ++++++----
net/netlink/af_netlink.c | 5 ++---
net/unix/af_unix.c | 4 +++-
4 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/include/net/scm.h b/include/net/scm.h
index 745460f..d456f4c 100644
--- a/include/net/scm.h
+++ b/include/net/scm.h
@@ -49,7 +49,7 @@ static __inline__ void scm_set_cred(struct scm_cookie *scm,
struct pid *pid, const struct cred *cred)
{
scm->pid = get_pid(pid);
- scm->cred = get_cred(cred);
+ scm->cred = cred ? get_cred(cred) : NULL;
cred_to_ucred(pid, cred, &scm->creds);
}
@@ -73,8 +73,7 @@ static __inline__ void scm_destroy(struct scm_cookie *scm)
static __inline__ int scm_send(struct socket *sock, struct msghdr *msg,
struct scm_cookie *scm)
{
- scm_set_cred(scm, task_tgid(current), current_cred());
- scm->fp = NULL;
+ memset(scm, 0, sizeof(*scm));
unix_get_peersec_dgram(sock, scm);
if (msg->msg_controllen <= 0)
return 0;
diff --git a/net/core/scm.c b/net/core/scm.c
index 811b53f..ff52ad0 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -173,7 +173,7 @@ int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
if (err)
goto error;
- if (pid_vnr(p->pid) != p->creds.pid) {
+ if (!p->pid || pid_vnr(p->pid) != p->creds.pid) {
struct pid *pid;
err = -ESRCH;
pid = find_get_pid(p->creds.pid);
@@ -183,8 +183,9 @@ int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
p->pid = pid;
}
- if ((p->cred->euid != p->creds.uid) ||
- (p->cred->egid != p->creds.gid)) {
+ if (!p->cred ||
+ (p->cred->euid != p->creds.uid) ||
+ (p->cred->egid != p->creds.gid)) {
struct cred *cred;
err = -ENOMEM;
cred = prepare_creds();
@@ -193,7 +194,8 @@ int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
cred->uid = cred->euid = p->creds.uid;
cred->gid = cred->egid = p->creds.gid;
- put_cred(p->cred);
+ if (p->cred)
+ put_cred(p->cred);
p->cred = cred;
}
break;
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 4330db9..1201b6d 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1324,10 +1324,9 @@ static int netlink_sendmsg(struct kiocb *kiocb, struct socket *sock,
if (msg->msg_flags&MSG_OOB)
return -EOPNOTSUPP;
- if (NULL == siocb->scm) {
+ if (NULL == siocb->scm)
siocb->scm = &scm;
- memset(&scm, 0, sizeof(scm));
- }
+
err = scm_send(sock, msg, siocb->scm);
if (err < 0)
return err;
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index ec68e1c..90c55c6 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1381,8 +1381,10 @@ static int unix_attach_fds(struct scm_cookie *scm, struct sk_buff *skb)
static int unix_scm_to_skb(struct scm_cookie *scm, struct sk_buff *skb, bool send_fds)
{
int err = 0;
+
UNIXCB(skb).pid = get_pid(scm->pid);
- UNIXCB(skb).cred = get_cred(scm->cred);
+ if (scm->cred)
+ UNIXCB(skb).cred = get_cred(scm->cred);
UNIXCB(skb).fp = NULL;
if (scm->fp && send_fds)
err = unix_attach_fds(scm, skb);
^ permalink raw reply related
* [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
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