* [PATCH] net_sched: red: Make minor corrections to comments
From: David Ward @ 2012-04-15 22:31 UTC (permalink / raw)
To: netdev; +Cc: David Ward
In-Reply-To: <1334529106-5035-1-git-send-email-david.ward@ll.mit.edu>
Signed-off-by: David Ward <david.ward@ll.mit.edu>
---
include/net/red.h | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/net/red.h b/include/net/red.h
index 77d4c37..c0bc25e 100644
--- a/include/net/red.h
+++ b/include/net/red.h
@@ -28,7 +28,7 @@
the inertia of the algorithm. To allow larger bursts, W should be
decreased.
- if (avg > th_max) -> packet marked (dropped).
+ if (avg > th_max) -> packet marked (dropped) with probability max_P.
if (avg < th_min) -> packet passes.
if (th_min < avg < th_max) we calculate probability:
@@ -245,7 +245,7 @@ static inline unsigned long red_calc_qavg_from_idle_time(const struct red_parms
*
* dummy packets as a burst after idle time, i.e.
*
- * p->qavg *= (1-W)^m
+ * v->qavg *= (1-W)^m
*
* This is an apparently overcomplicated solution (f.e. we have to
* precompute a table to make this calculation in reasonable time)
@@ -279,7 +279,7 @@ static inline unsigned long red_calc_qavg_no_idle_time(const struct red_parms *p
unsigned int backlog)
{
/*
- * NOTE: p->qavg is fixed point number with point at Wlog.
+ * NOTE: v->qavg is fixed point number with point at Wlog.
* The formula below is equvalent to floating point
* version:
*
@@ -390,7 +390,7 @@ static inline void red_adaptative_algo(struct red_parms *p, struct red_vars *v)
if (red_is_idling(v))
qavg = red_calc_qavg_from_idle_time(p, v);
- /* p->qavg is fixed point number with point at Wlog */
+ /* v->qavg is fixed point number with point at Wlog */
qavg >>= p->Wlog;
if (qavg > p->target_max && p->max_P <= MAX_P_MAX)
--
1.7.1
^ permalink raw reply related
* [PATCH] net_sched: gred: Fix oops in gred_dump() in WRED mode
From: David Ward @ 2012-04-15 22:31 UTC (permalink / raw)
To: netdev; +Cc: David Ward
A parameter set exists for WRED mode, called wred_set, to hold the same
values for qavg and qidlestart across all VQs. The WRED mode values had
been previously held in the VQ for the default DP. After these values
were moved to wred_set, the VQ for the default DP was no longer created
automatically (so that it could be omitted on purpose, to have packets
in the default DP enqueued directly to the device without using RED).
However, gred_dump() was overlooked during that change; in WRED mode it
still reads qavg/qidlestart from the VQ for the default DP, which might
not even exist. As a result, this command sequence will cause an oops:
tc qdisc add dev $DEV handle $HANDLE parent $PARENT gred setup \
DPs 3 default 2 grio
tc qdisc change dev $DEV handle $HANDLE gred DP 0 prio 8 $RED_OPTIONS
tc qdisc change dev $DEV handle $HANDLE gred DP 1 prio 8 $RED_OPTIONS
This fixes gred_dump() in WRED mode to use the values held in wred_set.
Signed-off-by: David Ward <david.ward@ll.mit.edu>
---
net/sched/sch_gred.c | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/net/sched/sch_gred.c b/net/sched/sch_gred.c
index 55e3310..ab620bf 100644
--- a/net/sched/sch_gred.c
+++ b/net/sched/sch_gred.c
@@ -567,11 +567,8 @@ static int gred_dump(struct Qdisc *sch, struct sk_buff *skb)
opt.packets = q->packetsin;
opt.bytesin = q->bytesin;
- if (gred_wred_mode(table)) {
- q->vars.qidlestart =
- table->tab[table->def]->vars.qidlestart;
- q->vars.qavg = table->tab[table->def]->vars.qavg;
- }
+ if (gred_wred_mode(table))
+ gred_load_wred_set(table, q);
opt.qave = red_calc_qavg(&q->parms, &q->vars, q->vars.qavg);
--
1.7.1
^ permalink raw reply related
* Re: Patch for man unix(7)
From: Michael Kerrisk (man-pages) @ 2012-04-15 22:40 UTC (permalink / raw)
To: Tetsuo Handa
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
Michael Kerrisk
In-Reply-To: <CAKgNAkgNRbdcWwo0nhsbCxtnagEucxm6d76ugGAAUAd+ukBLCQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Apr 16, 2012 at 9:42 AM, Michael Kerrisk (man-pages)
<mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hello Tetsuao Handa
>
> [Thanks for the text program that you sent more recently]
>
> On Wed, Nov 24, 2010 at 1:59 AM, Tetsuo Handa
> <penguin-kernel-1yMVhJb1mP/7nzcFbJAaVXf5DAMn2ifp@public.gmane.org> wrote:
>> From f388eedbdc0b099bb9f36ab007f9370432abb300 Mon Sep 17 00:00:00 2001
>> From: Tetsuo Handa <penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
>> Date: Tue, 23 Nov 2010 21:34:25 +0900
>> Subject: [PATCH] unix.7: Fix description of "pathname" sockets
>>
>> Since unix_mkname() in net/unix/af_unix.c does
>>
>> ((char *)sunaddr)[len] = 0;
>>
>> rather than
>>
>> ((char *)sunaddr)[len - 1] = 0;
>>
>> , sunaddr->sun_path may not be terminated with a null byte if
>> len == sizeof(*sunaddr).
>>
>> Therefore, the caller of getsockname(), getpeername(), accept() must not assume
>> that sunaddr->sun_path contains a null-terminated pathname even if the returned
>> addrlen is greater than sizeof(sa_family_t) and sun_path[0] != '\0'.
>
> Thanks. I see what you mean. However, I'm wondering, is the kernel
> behavior simply a bug that should be fixed, so that a null terminator
> is always placed in sun_path?
>
> I realize that's an ABI change, but:
> a) I suspect most sane applications would never create a sun_path that
> didn't contain a null terminator within sizeof(sun_path) bytes.
> b) Considering these two sets:
> 1. [applications that would break if the assumption that there
> is no null terminator inside sizeof(sun_path) bytes doesn't
Sorry! Small thinko in previous line:
"is no null terminator" ==> "is a null terminator"
Thanks,
Michael
> hold true]
> 2. [applications that would break if the kernel behavior changed]
> I suspect that set 1 is much larger than set 2.
>
> Your thoughts?
>
> Thanks,
>
> Michael
>
>> Signed-off-by: Tetsuo Handa <penguin-kernel-JPay3/Yim36HaxMnTkn67Xf5DAMn2ifp@public.gmane.org>
>> ---
>> man7/unix.7 | 19 ++++++++++++++++---
>> 1 files changed, 16 insertions(+), 3 deletions(-)
>>
>> diff --git a/man7/unix.7 b/man7/unix.7
>> index b53328b..7b0b47c 100644
>> --- a/man7/unix.7
>> +++ b/man7/unix.7
>> @@ -80,10 +80,23 @@ When the address of the socket is returned by
>> and
>> .BR accept (2),
>> its length is
>> -.IR "offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1" ,
>> +.IR "offsetof(struct sockaddr_un, sun_path) + strlen(sun_path) + 1".
>> +Note that this length can be one byte larger than
>> +.IR "sizeof(struct sockaddr_un)"
>> +because
>> +.BR bind (2)
>> +accepts
>> +.IR sun_path
>> +which is not terminated with a null byte ('\\0').
>> +Therefore, you must not use string manipulation functions (e.g. strlen(),
>> +printf("%s")) against
>> +.IR sun_path
>> +because
>> +.BR getsockname (2),
>> +.BR getpeername (2),
>> and
>> -.I sun_path
>> -contains the null-terminated pathname.
>> +.BR accept (2)
>> +may not have stored a null-terminated string.
>> .IP *
>> .IR unnamed :
>> A stream socket that has not been bound to a pathname using
>> --
>> 1.6.1
>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface"; http://man7.org/tlpi/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" 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 6/6] tilegx network driver: initial support
From: Chris Metcalf @ 2012-04-15 23:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <201204101042.39877.arnd@arndb.de>
Arnd Bergmann wrote:
> > We need "tile_net_devs_for_channel" because we share a single hardware
> > queue for all devices, and each packet's metadata contains a "channel"
> > value which indicates the device.
>
> Ok, but please remove tile_net_devs then.
I spent some time on Friday with the driver author and we made some good changes, switching over to using more of a per-channel model for everything. We also removed the per-cpu per-driver stats structures and just use atomics to update the per-driver stats directly. The upshot is a much cleaner set of data structures, but unfortunately we didn't have time to work all the way through the ramifications before the weekend, and I'm out next week for spring school vacation.
Thanks again for the feedback!
Chris Metcalf
^ permalink raw reply
* [PATCH net] dummy: Add ndo_uninit().
From: Hiroaki SHIMODA @ 2012-04-15 23:26 UTC (permalink / raw)
To: davem; +Cc: netdev
In register_netdevice(), when ndo_init() is successful and later
some error occurred, ndo_uninit() will be called.
So dummy deivce is desirable to implement ndo_uninit() method
to free percpu stats for this case.
And, ndo_uninit() is also called along with dev->destructor() when
device is unregistered, so in order to prevent dev->dstats from
being freed twice, dev->destructor is modified to free_netdev().
Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
---
drivers/net/dummy.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c
index d5c6d92..442d91a 100644
--- a/drivers/net/dummy.c
+++ b/drivers/net/dummy.c
@@ -107,14 +107,14 @@ static int dummy_dev_init(struct net_device *dev)
return 0;
}
-static void dummy_dev_free(struct net_device *dev)
+static void dummy_dev_uninit(struct net_device *dev)
{
free_percpu(dev->dstats);
- free_netdev(dev);
}
static const struct net_device_ops dummy_netdev_ops = {
.ndo_init = dummy_dev_init,
+ .ndo_uninit = dummy_dev_uninit,
.ndo_start_xmit = dummy_xmit,
.ndo_validate_addr = eth_validate_addr,
.ndo_set_rx_mode = set_multicast_list,
@@ -128,7 +128,7 @@ static void dummy_setup(struct net_device *dev)
/* Initialize the device structure. */
dev->netdev_ops = &dummy_netdev_ops;
- dev->destructor = dummy_dev_free;
+ dev->destructor = free_netdev;
/* Fill in device structure with ethernet-generic values. */
dev->tx_queue_len = 0;
--
1.7.8.5
^ permalink raw reply related
* Re: [PATCH net-next] tcp: RFC6298 supersedes RFC2988bis
From: Jerry Chu @ 2012-04-16 2:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Tom Herbert
In-Reply-To: <1334520061.28012.36.camel@edumazet-glaptop>
n Sun, Apr 15, 2012 at 1:01 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sun, 2012-04-15 at 11:33 -0700, Jerry Chu wrote:
>> [send again - it looks like my previous comment was lost...]
>>
>> On Thu, Apr 12, 2012 at 10:48 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> > Updates some comments to track RFC6298
>> >
>> > Signed-off-by: Eric Dumazet <edumazet@google.com>
>> > Cc: H.K. Jerry Chu <hkchu@google.com>
>> > Cc: Tom Herbert <therbert@google.com>
>> > ---
>> > BTW, one side effect of the TCP_TIMEOUT_INIT change (3 -> 1) is
>> > () latency is 200% worse:
>>
>> Or even worse - 300% (3/1)?
>
> well, 3 instead of 1 is a 200% increase ;)
>
>>
>> >
>> > It fires every 200ms and scans 40% of hash table each time, listener
>> > socket held.
>>
>> If this becomes a real issue we could decrease TCP_SYNQ_INTERVAL,
>> essentially making the keepalive timer fire more often, but each time with
>> less work to do?
>
> Hmm... 200ms is already aggressive for power saving
Not sure how much power saving can one attain when syn_table is non-empty
anyway.
>
>>
>> Also why is
>> budget = 2 * (lopt->nr_table_entries / (timeout / interval));
>> rather than
>> budget = (lopt->nr_table_entries / (timeout / interval)) + 1;
>> ?
>
> Thats because if we do that, retransmits could be delayed by 100%,
> instead of 50% with this solution.
Oh, that's right - the delay can be upto the time to scan the whole table
so it's a balance between how much delay vs the processing overhead
in the current data structure...
Thanks,
Jerry
>
> (right now it takes 2.5 rounds to scan whole table, so a one sec 'timer'
> can be fired after 1.6 second)
>
>
>
^ permalink raw reply
* linux-next: manual merge of the wireless-next tree with the net-next tree
From: Stephen Rothwell @ 2012-04-16 2:48 UTC (permalink / raw)
To: John W. Linville
Cc: linux-next, linux-kernel, David Miller, netdev, Johannes Berg,
Wey-Yi Guy
[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
drivers/net/wireless/iwlwifi/iwl-testmode.c between commit d33e152e1edd
("iwlwifi: Stop using NLA_PUT*()") from the net-next tree and commit
11483b5c2296 ("iwlwifi: move eeprom into priv") from the wireless-next
tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc drivers/net/wireless/iwlwifi/iwl-testmode.c
index f31a062,c8e89ca..0000000
--- a/drivers/net/wireless/iwlwifi/iwl-testmode.c
+++ b/drivers/net/wireless/iwlwifi/iwl-testmode.c
@@@ -543,12 -539,11 +543,12 @@@ static int iwl_testmode_driver(struct i
IWL_ERR(priv, "Memory allocation fail\n");
return -ENOMEM;
}
- NLA_PUT_U32(skb, IWL_TM_ATTR_COMMAND,
- IWL_TM_CMD_DEV2APP_EEPROM_RSP);
- NLA_PUT(skb, IWL_TM_ATTR_EEPROM,
- cfg(priv)->base_params->eeprom_size,
- priv->eeprom);
+ if (nla_put_u32(skb, IWL_TM_ATTR_COMMAND,
+ IWL_TM_CMD_DEV2APP_EEPROM_RSP) ||
+ nla_put(skb, IWL_TM_ATTR_EEPROM,
+ cfg(priv)->base_params->eeprom_size,
- priv->shrd->eeprom))
++ priv->eeprom))
+ goto nla_put_failure;
status = cfg80211_testmode_reply(skb);
if (status < 0)
IWL_ERR(priv, "Error sending msg : %d\n",
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the wireless-next tree with the net-next tree
From: Stephen Rothwell @ 2012-04-16 2:49 UTC (permalink / raw)
To: John W. Linville
Cc: linux-next, linux-kernel, David Miller, netdev, Pontus Fuchs
[-- Attachment #1: Type: text/plain, Size: 1483 bytes --]
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
net/wireless/nl80211.c between commit 9360ffd18597 ("wireless: Stop using
NLA_PUT*()") from the net-next tree and commit d91df0e3a1b9 ("cfg80211:
Add channel information to NL80211_CMD_GET_INTERFACE") from the
wireless-next tree.
I applied this merge fix patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 16 Apr 2012 12:45:25 +1000
Subject: [PATCH] cfg80211: fix up for NLA_PUT_ api changes
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
net/wireless/nl80211.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b33a852..acae9d4 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1546,10 +1546,11 @@ static int nl80211_send_iface(struct sk_buff *msg, u32 pid, u32 seq, int flags,
chan = rdev->ops->get_channel(&rdev->wiphy, &channel_type);
if (chan) {
- NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_FREQ,
- chan->center_freq);
- NLA_PUT_U32(msg, NL80211_ATTR_WIPHY_CHANNEL_TYPE,
- channel_type);
+ if (nla_put_u32(msg, NL80211_ATTR_WIPHY_FREQ,
+ chan->center_freq) ||
+ nla_put_u32(msg, NL80211_ATTR_WIPHY_CHANNEL_TYPE,
+ channel_type))
+ goto nla_put_failure;
}
}
--
1.7.10.rc3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* linux-next: manual merge of the wireless-next tree with the net-next tree
From: Stephen Rothwell @ 2012-04-16 2:49 UTC (permalink / raw)
To: John W. Linville
Cc: linux-next, linux-kernel, David Miller, netdev, Eric Dumazet,
Samuel Ortiz, Eric Lapuyade
[-- Attachment #1: Type: text/plain, Size: 895 bytes --]
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
include/net/nfc/nfc.h between commit 95c961747284 ("net: cleanup unsigned
to unsigned int") from the net-next tree and commits c4fbb6515a4d ("NFC:
The core part should generate the target index") and 01ae0eea9bed ("NFC:
Fix next target_idx type and rename for clarity") from the wireless-next
tree.
Just context changes. I fixed it up (see below) and can carry the fix as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/net/nfc/nfc.h
index 79955a2,313d00f..0000000
--- a/include/net/nfc/nfc.h
+++ b/include/net/nfc/nfc.h
@@@ -86,7 -90,8 +90,8 @@@ struct nfc_genl_data
};
struct nfc_dev {
- unsigned idx;
+ unsigned int idx;
+ u32 target_next_idx;
struct nfc_target *targets;
int n_targets;
int targets_generation;
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH net-next] drivers/net: fix unresolved 64bit math in mellanox/mlx4/en_dcb_nl.c
From: Paul Gortmaker @ 2012-04-16 3:09 UTC (permalink / raw)
To: netdev; +Cc: Paul Gortmaker, Amir Vadai, David S. Miller
Commit 109d2446052a484c58f07f71f9457bf7b71017f8
"net/mlx4_en: Set max rate-limit for a TC"
introduced 64 bit math operations into mlx4_en_dcbnl_ieee_setmaxrate()
causing the following final link failure on an x86_32 allmodconfig
ERROR: "__udivdi3" [drivers/net/ethernet/mellanox/mlx4/mlx4_en.ko] undefined!
Convert it to use div_u64() instead.
Cc: Amir Vadai <amirv@mellanox.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[seen in linux-next: http://kisskb.ellerman.id.au/kisskb/buildresult/6091475/]
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
index 0cc6c96..720cb55 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
@@ -227,9 +227,9 @@ static int mlx4_en_dcbnl_ieee_setmaxrate(struct net_device *dev,
/* Convert from Kbps into HW units, rounding result up.
* Setting to 0, means unlimited BW.
*/
- tmp[i] =
- (maxrate->tc_maxrate[i] + MLX4_RATELIMIT_UNITS_IN_KB -
- 1) / MLX4_RATELIMIT_UNITS_IN_KB;
+ tmp[i] = div_u64(maxrate->tc_maxrate[i] +
+ MLX4_RATELIMIT_UNITS_IN_KB - 1,
+ MLX4_RATELIMIT_UNITS_IN_KB);
}
err = mlx4_en_config_port_scheduler(priv, NULL, tmp);
--
1.7.9.1
^ permalink raw reply related
* linux-next: manual merge of the security tree with the net-next tree
From: Stephen Rothwell @ 2012-04-16 3:29 UTC (permalink / raw)
To: James Morris
Cc: linux-next, linux-kernel, David Miller, netdev, Jiri Pirko,
Will Drewry
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
Hi James,
Today's linux-next merge of the security tree got a conflict in
include/linux/filter.h between commit ffe06c17afbb ("filter: add XOR
operation") from the net-next tree and commit 46b325c7eb01
("sk_run_filter: add BPF_S_ANC_SECCOMP_LD_W") from the security tree.
Just context changes. I fixed it up (see below) and can carry the fax as
necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc include/linux/filter.h
index 7209099,f2e5315..0000000
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@@ -232,7 -239,7 +243,8 @@@ enum
BPF_S_ANC_HATYPE,
BPF_S_ANC_RXHASH,
BPF_S_ANC_CPU,
+ BPF_S_ANC_ALU_XOR_X,
+ BPF_S_ANC_SECCOMP_LD_W,
};
#endif /* __KERNEL__ */
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] drivers/net: fix unresolved 64bit math in mellanox/mlx4/en_dcb_nl.c
From: David Miller @ 2012-04-16 3:31 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev, amirv
In-Reply-To: <1334545794-16703-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Sun, 15 Apr 2012 23:09:54 -0400
> Commit 109d2446052a484c58f07f71f9457bf7b71017f8
>
> "net/mlx4_en: Set max rate-limit for a TC"
>
> introduced 64 bit math operations into mlx4_en_dcbnl_ieee_setmaxrate()
>
> causing the following final link failure on an x86_32 allmodconfig
>
> ERROR: "__udivdi3" [drivers/net/ethernet/mellanox/mlx4/mlx4_en.ko] undefined!
>
> Convert it to use div_u64() instead.
>
> Cc: Amir Vadai <amirv@mellanox.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Please add an explicit linux/math64.h include here too, thanks.
^ permalink raw reply
* [PATCH v2 net-next] drivers/net: fix unresolved 64bit math in mellanox/mlx4/en_dcb_nl.c
From: Paul Gortmaker @ 2012-04-16 4:17 UTC (permalink / raw)
To: netdev; +Cc: Paul Gortmaker, Amir Vadai, David S. Miller
In-Reply-To: <20120415.233139.452372897242947075.davem@davemloft.net>
Commit 109d2446052a484c58f07f71f9457bf7b71017f8
"net/mlx4_en: Set max rate-limit for a TC"
introduced 64 bit math operations into mlx4_en_dcbnl_ieee_setmaxrate()
causing the following final link failure on an x86_32 allmodconfig
ERROR: "__udivdi3" [drivers/net/ethernet/mellanox/mlx4/mlx4_en.ko] undefined!
Convert it to use div_u64() instead.
Cc: Amir Vadai <amirv@mellanox.com>
Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[ v2: add an explicit linux/math64.h include as per davem req ]
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
index 0cc6c96..5d367958 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_dcb_nl.c
@@ -32,6 +32,7 @@
*/
#include <linux/dcbnl.h>
+#include <linux/math64.h>
#include "mlx4_en.h"
@@ -227,9 +228,9 @@ static int mlx4_en_dcbnl_ieee_setmaxrate(struct net_device *dev,
/* Convert from Kbps into HW units, rounding result up.
* Setting to 0, means unlimited BW.
*/
- tmp[i] =
- (maxrate->tc_maxrate[i] + MLX4_RATELIMIT_UNITS_IN_KB -
- 1) / MLX4_RATELIMIT_UNITS_IN_KB;
+ tmp[i] = div_u64(maxrate->tc_maxrate[i] +
+ MLX4_RATELIMIT_UNITS_IN_KB - 1,
+ MLX4_RATELIMIT_UNITS_IN_KB);
}
err = mlx4_en_config_port_scheduler(priv, NULL, tmp);
--
1.7.9.1
^ permalink raw reply related
* Re: [PATCH] 9p: disconnect channel when PCI device is removed
From: Sasha Levin @ 2012-04-16 4:35 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: davem, ericvh, jvrao, rusty, netdev, linux-kernel, davej
In-Reply-To: <87iph118pd.fsf@skywalker.in.ibm.com>
On Sun, Apr 15, 2012 at 2:27 PM, Aneesh Kumar K.V
<aneesh.kumar@linux.vnet.ibm.com> wrote:
> Sasha Levin <levinsasha928@gmail.com> writes:
>
>> When a virtio_9p pci device is being removed, we should close down any
>> active channels and free up resources, we're not supposed to BUG() if there's
>> still an open channel since it's a valid case when removing the PCI device.
>>
>> Otherwise, removing the PCI device with an open channel would cause the
>> following BUG():
>>
> ...
>
>> diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
>> index 3d43206..5af18d1 100644
>> --- a/net/9p/trans_virtio.c
>> +++ b/net/9p/trans_virtio.c
>> @@ -615,7 +615,8 @@ static void p9_virtio_remove(struct virtio_device *vdev)
>> {
>> struct virtio_chan *chan = vdev->priv;
>>
>> - BUG_ON(chan->inuse);
>> + if (chan->inuse)
>> + p9_virtio_close(chan->client);
>> vdev->config->del_vqs(vdev);
>>
>> mutex_lock(&virtio_9p_lock);
>
> But an umount should have resulted in p9_virtio_close ? How are you
> removing the device ? Are you removing the device with file system
> mounted ?. In that case may be we should return EBUSY ?
I signal the underlying PCI device to remove (echo 1 >
/sys/devices/pci0000\:00/[...]/remove), we can't really prevent that
thing so we must clean up ourselves.
^ permalink raw reply
* Re: [PATCH] bnx2x: tx-switching module parameter
From: John Fastabend @ 2012-04-16 5:11 UTC (permalink / raw)
To: eilong; +Cc: davem, Stephen Hemminger, Ariel Elior, netdev
In-Reply-To: <1329422255.30697.5.camel@lb-tlvb-eilong.il.broadcom.com>
On 2/16/2012 11:57 AM, Eilon Greenstein wrote:
>>>> "Ariel Elior" <ariele@broadcom.com> wrote:
>>>>
>>>>> In 57712 and 578xx the tx-switching module parameter allows the user to control
>>>>> whether outgoing traffic can be loopbacked into the device in case there is a
>>>>> relevant client for the data using the same device for rx.
[...]
>>> But netdev is a great place to ask - are there other vendors out there
>>> that requires this control over internal switching? If so, we can define
>>> a new ethtool command. The alternative of using the ethtool private
>>> flags seems just as inconvenient from administrators point of view and
>>> also seem less appropriate since this configuration is more likely to be
>>> the same for all PFs on the same machine.
>>>
[...]
> OK, thanks John. Dave - please do not apply this patch. We need to look
> at the alternatives suggested by John.
>
> Thanks,
> Eilon
>
Eilon, any progress with this? We need this to support VEPA modes in
macvlan running over SR-IOV devices or other embedded switches. The
problem being if the stacked device expects the packet to be sent
to the reflexive relay on the switch in the SR-IOV case the embedded
switch may not actually do this.
Thanks,
John
^ permalink raw reply
* Re: [net-next 1/4 (V3)] net: ethtool: add the EEE support
From: Giuseppe CAVALLARO @ 2012-04-16 5:41 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, rayagond, davem
In-Reply-To: <1334269598.2497.50.camel@bwh-desktop.uk.solarflarecom.com>
On 4/13/2012 12:26 AM, Ben Hutchings wrote:
> On Fri, 2012-04-06 at 11:29 +0200, Giuseppe CAVALLARO wrote:
>> This patch adds two new functions to detect if Energy-Efficient
>> Ethernet (EEE) is supported and the way to enable/disable it.
>>
>> As Ben said, it is certainly necessary to distinguish:
>>
>> a. PHY is advertising EEE from
>> b. Link partner is advertising EEE
>> or
>> c. EEE will be used (= a && b)
>>
>> The logic behind this code, is that .get_eee will pass
>> to the user-space if the EEE is actually used and available (so point c).
>> The .set_eee should used to force the MAC to disable/enable the EEE (if
>> actually supported by MAC+PHY).
> [...]
>
> What I meant is that userland should be able to find out (a), and,
> *separately*, either (b) or (c). That is, there must be at least 2
> separate flags for this. In fact, I explicitly requested you define
> supported/advertising/lp_advertising bitmasks for EEE link modes just
> like we have for autonegotiation. But you've made no substantive
> changes in response to my review, aside from dropping the added field in
> ethtool_cmd.
Sorry Ben but I believed that (c) was enough.
> What you're submitting just isn't good enough for a generic interface,
> as the ethtool API is supposed to be. It's not even a good interface to
> your driver.
yes! I'll rework this and provide new patches asap.
peppe
> Ben.
>
^ permalink raw reply
* Re: [PATCH] ath6kl: fix memory leak in ath6kl_fwlog_block_read()
From: Kalle Valo @ 2012-04-16 6:07 UTC (permalink / raw)
To: Jesper Juhl
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Robert Love,
John W. Linville, ath6kl-devel
In-Reply-To: <alpine.LNX.2.00.1204112239070.2137-h2p7t3/P30RzeRGmFJ5qR7ZzlVVXadcDXqFh9Ls21Oc@public.gmane.org>
On 04/11/2012 11:41 PM, Jesper Juhl wrote:
> If, in
> drivers/net/wireless/ath/ath6kl/debug.c::ath6kl_fwlog_block_read(),
> the call to wait_for_completion_interruptible() returns -ERESTARTSYS
> then we'll return without freeing the (as yet unused) memory we
> allocated for 'buf' - thus leaking it.
>
> Signed-off-by: Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org>
Thanks, applied to ath6kl.git.
Kalle
--
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
* [PATCH 1/6] macvtap: zerocopy: fix offset calculation when building skb
From: Jason Wang @ 2012-04-16 6:07 UTC (permalink / raw)
To: netdev, xma, davem, linux-kernel, mst; +Cc: ebiederm
This patch fixes the offset calculation when build skb:
- offset1 were used as skb data offset not vector offset
- reset offset to zero only when we advance to next vector
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvtap.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 0427c65..bd4a70d 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -505,10 +505,11 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
if (copy > size) {
++from;
--count;
- }
+ offset = 0;
+ } else
+ offset += size;
copy -= size;
offset1 += size;
- offset = 0;
}
if (len == offset1)
@@ -519,13 +520,13 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
int num_pages;
unsigned long base;
- len = from->iov_len - offset1;
+ len = from->iov_len - offset;
if (!len) {
- offset1 = 0;
+ offset = 0;
++from;
continue;
}
- base = (unsigned long)from->iov_base + offset1;
+ base = (unsigned long)from->iov_base + offset;
size = ((base & ~PAGE_MASK) + len + ~PAGE_MASK) >> PAGE_SHIFT;
num_pages = get_user_pages_fast(base, size, 0, &page[i]);
if ((num_pages != size) ||
@@ -546,7 +547,7 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
len -= size;
i++;
}
- offset1 = 0;
+ offset = 0;
++from;
}
return 0;
^ permalink raw reply related
* [PATCH 2/6] macvtap: zerocopy: fix truesize underestimation
From: Jason Wang @ 2012-04-16 6:07 UTC (permalink / raw)
To: netdev, xma, davem, linux-kernel, mst; +Cc: ebiederm
In-Reply-To: <20120416060749.14140.19433.stgit@intel-e5620-16-2.englab.nay.redhat.com>
As the skb fragment were pinned/built from user pages, we should
account the page instead of length for truesize.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvtap.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index bd4a70d..7cb2684 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -519,6 +519,7 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
struct page *page[MAX_SKB_FRAGS];
int num_pages;
unsigned long base;
+ unsigned long truesize;
len = from->iov_len - offset;
if (!len) {
@@ -533,10 +534,11 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
(num_pages > MAX_SKB_FRAGS - skb_shinfo(skb)->nr_frags))
/* put_page is in skb free */
return -EFAULT;
+ truesize = size * PAGE_SIZE;
skb->data_len += len;
skb->len += len;
- skb->truesize += len;
- atomic_add(len, &skb->sk->sk_wmem_alloc);
+ skb->truesize += truesize;
+ atomic_add(truesize, &skb->sk->sk_wmem_alloc);
while (len) {
int off = base & ~PAGE_MASK;
int size = min_t(int, len, PAGE_SIZE - off);
^ permalink raw reply related
* [PATCH 3/6] macvtap: zerocopy: validate vector length before pinning user pages
From: Jason Wang @ 2012-04-16 6:08 UTC (permalink / raw)
To: netdev, xma, davem, linux-kernel, mst; +Cc: ebiederm
In-Reply-To: <20120416060749.14140.19433.stgit@intel-e5620-16-2.englab.nay.redhat.com>
Currently we do not validate the vector length before calling
get_user_pages_fast(), host stack would be easily overflowed by
malicious guest driver who give us a descriptor with length greater
than MAX_SKB_FRAGS. Solve this problem by checking the free entries
before trying to pin user pages.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvtap.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 7cb2684..d197a78 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -529,6 +529,8 @@ static int zerocopy_sg_from_iovec(struct sk_buff *skb, const struct iovec *from,
}
base = (unsigned long)from->iov_base + offset;
size = ((base & ~PAGE_MASK) + len + ~PAGE_MASK) >> PAGE_SHIFT;
+ if (i + size >= MAX_SKB_FRAGS)
+ return -EFAULT;
num_pages = get_user_pages_fast(base, size, 0, &page[i]);
if ((num_pages != size) ||
(num_pages > MAX_SKB_FRAGS - skb_shinfo(skb)->nr_frags))
^ permalink raw reply related
* [PATCH 4/6] macvtap: zerocopy: set SKBTX_DEV_ZEROCOPY only when skb is built successfully
From: Jason Wang @ 2012-04-16 6:08 UTC (permalink / raw)
To: netdev, xma, davem, linux-kernel, mst; +Cc: ebiederm
In-Reply-To: <20120416060749.14140.19433.stgit@intel-e5620-16-2.englab.nay.redhat.com>
Current the SKBTX_DEV_ZEROCOPY is set unconditionally after
zerocopy_sg_from_iovec(), this would lead NULL pointer when macvtap
fails to build zerocopy skb because destructor_arg was not
initialized. Solve this by set this flag after the skb were built
successfully.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/net/macvtap.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index d197a78..c030468 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -699,10 +699,9 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q, struct msghdr *m,
if (!skb)
goto err;
- if (zerocopy) {
+ if (zerocopy)
err = zerocopy_sg_from_iovec(skb, iv, vnet_hdr_len, count);
- skb_shinfo(skb)->tx_flags |= SKBTX_DEV_ZEROCOPY;
- } else
+ else
err = skb_copy_datagram_from_iovec(skb, 0, iv, vnet_hdr_len,
len);
if (err)
@@ -721,8 +720,10 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q, struct msghdr *m,
rcu_read_lock_bh();
vlan = rcu_dereference_bh(q->vlan);
/* copy skb_ubuf_info for callback when skb has no error */
- if (zerocopy)
+ if (zerocopy) {
skb_shinfo(skb)->destructor_arg = m->msg_control;
+ skb_shinfo(skb)->tx_flags |= SKBTX_DEV_ZEROCOPY;
+ }
if (vlan)
macvlan_start_xmit(skb, vlan->dev);
else
^ permalink raw reply related
* [PATCH 5/6] vhost_net: fix use after free of vq->ubufs
From: Jason Wang @ 2012-04-16 6:08 UTC (permalink / raw)
To: netdev, xma, davem, linux-kernel, mst; +Cc: ebiederm
In-Reply-To: <20120416060749.14140.19433.stgit@intel-e5620-16-2.englab.nay.redhat.com>
When zerocopy socket is used, ubufs pointer were used in handle_tx()
without any validation. This would cause NULL pointer deference after
it has been freed in vhost_net_set_backend(). Fix this by check the
pointer before using it.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index f0da2c3..29abd65 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -163,10 +163,15 @@ static void handle_tx(struct vhost_net *net)
mutex_lock(&vq->mutex);
vhost_disable_notify(&net->dev, vq);
+ zcopy = vhost_sock_zcopy(sock);
+ if (zcopy && !vq->ubufs) {
+ mutex_unlock(&vq->mutex);
+ return;
+ }
+
if (wmem < sock->sk->sk_sndbuf / 2)
tx_poll_stop(net);
hdr_size = vq->vhost_hlen;
- zcopy = vhost_sock_zcopy(sock);
for (;;) {
/* Release DMAs done buffers first */
^ permalink raw reply related
* [PATCH 6/6] vhost_net: don't poll on -EFAULT
From: Jason Wang @ 2012-04-16 6:08 UTC (permalink / raw)
To: netdev, xma, davem, linux-kernel, mst; +Cc: ebiederm
In-Reply-To: <20120416060749.14140.19433.stgit@intel-e5620-16-2.englab.nay.redhat.com>
Currently, we restart tx polling unconditionally when sendmsg()
fails. This would cause unnecessary wakeups of vhost wokers as it's
only needed when the socket send buffer were exceeded. Fix this by
restart the tx polling only when sendmsg() returns value other than
-EFAULT.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 29abd65..035fa95 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -262,7 +262,8 @@ static void handle_tx(struct vhost_net *net)
UIO_MAXIOV;
}
vhost_discard_vq_desc(vq, 1);
- tx_poll_start(net, sock);
+ if (err != -EFAULT)
+ tx_poll_start(net, sock);
break;
}
if (err != len)
^ permalink raw reply related
* Re: [PATCH v2 net-next] drivers/net: fix unresolved 64bit math in mellanox/mlx4/en_dcb_nl.c
From: David Miller @ 2012-04-16 6:12 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev, amirv
In-Reply-To: <1334549854-16370-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Mon, 16 Apr 2012 00:17:34 -0400
> Commit 109d2446052a484c58f07f71f9457bf7b71017f8
>
> "net/mlx4_en: Set max rate-limit for a TC"
>
> introduced 64 bit math operations into mlx4_en_dcbnl_ieee_setmaxrate()
>
> causing the following final link failure on an x86_32 allmodconfig
>
> ERROR: "__udivdi3" [drivers/net/ethernet/mellanox/mlx4/mlx4_en.ko] undefined!
>
> Convert it to use div_u64() instead.
>
> Cc: Amir Vadai <amirv@mellanox.com>
> Cc: David S. Miller <davem@davemloft.net>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Applied, thanks Paul.
^ permalink raw reply
* Re: [PATCH linux-next 1/1] ath6k: Normalize use of FW_DIR
From: Kalle Valo @ 2012-04-16 6:39 UTC (permalink / raw)
To: Tim Gardner
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, John W. Linville,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, ath6kl-devel
In-Reply-To: <1334337448-26270-2-git-send-email-tim.gardner-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
On 04/13/2012 08:17 PM, Tim Gardner wrote:
> Cc: Kalle Valo <kvalo-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>
> Cc: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
> Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Tim Gardner <tim.gardner-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
Thanks, applied to ath6kl.git. But ar6004 hw1.2 supports wasn't in
linux-next yet so I changed it as well. If you can, please check my changes:
https://github.com/kvalo/ath6kl/commit/2023dbb8310ab39ac1119a32ef52405f7a73f51f
Kalle
--
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
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