* [PATCH] rtnetlink: fix error return code in rtnl_link_fill()
From: Wei Yongjun @ 2013-03-27 13:22 UTC (permalink / raw)
To: davem, john.r.fastabend, jiri, edumazet, vyasevic; +Cc: yongjun_wei, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Fix to return a negative error code from the error handling case
instead of 0(possible overwrite to 0 by ops->fill_xstats call),
as returned elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
net/core/rtnetlink.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index 5fb8d7e..b65441d 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -496,8 +496,10 @@ static int rtnl_link_fill(struct sk_buff *skb, const struct net_device *dev)
}
if (ops->fill_info) {
data = nla_nest_start(skb, IFLA_INFO_DATA);
- if (data == NULL)
+ if (data == NULL) {
+ err = -EMSGSIZE;
goto err_cancel_link;
+ }
err = ops->fill_info(skb, dev);
if (err < 0)
goto err_cancel_data;
^ permalink raw reply related
* [PATCH] bonding: fix disabling of arp_interval and miimon
From: Nikolay Aleksandrov @ 2013-03-27 13:32 UTC (permalink / raw)
To: netdev; +Cc: andy, fubar, davem
Currently if either arp_interval or miimon is disabled, they both get
disabled, and upon disabling they get executed once more which is not
the proper behaviour. Also when doing a no-op and disabling an already
disabled one, the other again gets disabled.
Also fix the error messages with the proper valid ranges, and a small
typo fix in the up delay error message (outputting "down delay", instead
of "up delay").
Signed-off-by: Nikolay Aleksandrov <nikolay@redhat.com>
---
drivers/net/bonding/bond_sysfs.c | 92 +++++++++++++++++++++-------------------
1 file changed, 48 insertions(+), 44 deletions(-)
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index db103e0..ea7a388 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -527,7 +527,7 @@ static ssize_t bonding_store_arp_interval(struct device *d,
goto out;
}
if (new_value < 0) {
- pr_err("%s: Invalid arp_interval value %d not in range 1-%d; rejected.\n",
+ pr_err("%s: Invalid arp_interval value %d not in range 0-%d; rejected.\n",
bond->dev->name, new_value, INT_MAX);
ret = -EINVAL;
goto out;
@@ -542,14 +542,15 @@ static ssize_t bonding_store_arp_interval(struct device *d,
pr_info("%s: Setting ARP monitoring interval to %d.\n",
bond->dev->name, new_value);
bond->params.arp_interval = new_value;
- if (bond->params.miimon) {
- pr_info("%s: ARP monitoring cannot be used with MII monitoring. %s Disabling MII monitoring.\n",
- bond->dev->name, bond->dev->name);
- bond->params.miimon = 0;
- }
- if (!bond->params.arp_targets[0]) {
- pr_info("%s: ARP monitoring has been set up, but no ARP targets have been specified.\n",
- bond->dev->name);
+ if (new_value) {
+ if (bond->params.miimon) {
+ pr_info("%s: ARP monitoring cannot be used with MII monitoring. %s Disabling MII monitoring.\n",
+ bond->dev->name, bond->dev->name);
+ bond->params.miimon = 0;
+ }
+ if (!bond->params.arp_targets[0])
+ pr_info("%s: ARP monitoring has been set up, but no ARP targets have been specified.\n",
+ bond->dev->name);
}
if (bond->dev->flags & IFF_UP) {
/* If the interface is up, we may need to fire off
@@ -557,10 +558,13 @@ static ssize_t bonding_store_arp_interval(struct device *d,
* timer will get fired off when the open function
* is called.
*/
- cancel_delayed_work_sync(&bond->mii_work);
- queue_delayed_work(bond->wq, &bond->arp_work, 0);
+ if (!new_value) {
+ cancel_delayed_work_sync(&bond->arp_work);
+ } else {
+ cancel_delayed_work_sync(&bond->mii_work);
+ queue_delayed_work(bond->wq, &bond->arp_work, 0);
+ }
}
-
out:
rtnl_unlock();
return ret;
@@ -702,7 +706,7 @@ static ssize_t bonding_store_downdelay(struct device *d,
}
if (new_value < 0) {
pr_err("%s: Invalid down delay value %d not in range %d-%d; rejected.\n",
- bond->dev->name, new_value, 1, INT_MAX);
+ bond->dev->name, new_value, 0, INT_MAX);
ret = -EINVAL;
goto out;
} else {
@@ -757,8 +761,8 @@ static ssize_t bonding_store_updelay(struct device *d,
goto out;
}
if (new_value < 0) {
- pr_err("%s: Invalid down delay value %d not in range %d-%d; rejected.\n",
- bond->dev->name, new_value, 1, INT_MAX);
+ pr_err("%s: Invalid up delay value %d not in range %d-%d; rejected.\n",
+ bond->dev->name, new_value, 0, INT_MAX);
ret = -EINVAL;
goto out;
} else {
@@ -968,37 +972,37 @@ static ssize_t bonding_store_miimon(struct device *d,
}
if (new_value < 0) {
pr_err("%s: Invalid miimon value %d not in range %d-%d; rejected.\n",
- bond->dev->name, new_value, 1, INT_MAX);
+ bond->dev->name, new_value, 0, INT_MAX);
ret = -EINVAL;
goto out;
- } else {
- pr_info("%s: Setting MII monitoring interval to %d.\n",
- bond->dev->name, new_value);
- bond->params.miimon = new_value;
- if (bond->params.updelay)
- pr_info("%s: Note: Updating updelay (to %d) since it is a multiple of the miimon value.\n",
- bond->dev->name,
- bond->params.updelay * bond->params.miimon);
- if (bond->params.downdelay)
- pr_info("%s: Note: Updating downdelay (to %d) since it is a multiple of the miimon value.\n",
- bond->dev->name,
- bond->params.downdelay * bond->params.miimon);
- if (bond->params.arp_interval) {
- pr_info("%s: MII monitoring cannot be used with ARP monitoring. Disabling ARP monitoring...\n",
- bond->dev->name);
- bond->params.arp_interval = 0;
- if (bond->params.arp_validate) {
- bond->params.arp_validate =
- BOND_ARP_VALIDATE_NONE;
- }
- }
-
- if (bond->dev->flags & IFF_UP) {
- /* If the interface is up, we may need to fire off
- * the MII timer. If the interface is down, the
- * timer will get fired off when the open function
- * is called.
- */
+ }
+ pr_info("%s: Setting MII monitoring interval to %d.\n",
+ bond->dev->name, new_value);
+ bond->params.miimon = new_value;
+ if (bond->params.updelay)
+ pr_info("%s: Note: Updating updelay (to %d) since it is a multiple of the miimon value.\n",
+ bond->dev->name,
+ bond->params.updelay * bond->params.miimon);
+ if (bond->params.downdelay)
+ pr_info("%s: Note: Updating downdelay (to %d) since it is a multiple of the miimon value.\n",
+ bond->dev->name,
+ bond->params.downdelay * bond->params.miimon);
+ if (new_value && bond->params.arp_interval) {
+ pr_info("%s: MII monitoring cannot be used with ARP monitoring. Disabling ARP monitoring...\n",
+ bond->dev->name);
+ bond->params.arp_interval = 0;
+ if (bond->params.arp_validate)
+ bond->params.arp_validate = BOND_ARP_VALIDATE_NONE;
+ }
+ if (bond->dev->flags & IFF_UP) {
+ /* If the interface is up, we may need to fire off
+ * the MII timer. If the interface is down, the
+ * timer will get fired off when the open function
+ * is called.
+ */
+ if (!new_value) {
+ cancel_delayed_work_sync(&bond->mii_work);
+ } else {
cancel_delayed_work_sync(&bond->arp_work);
queue_delayed_work(bond->wq, &bond->mii_work, 0);
}
--
1.7.11.7
^ permalink raw reply related
* Re: [RFC][PATCH] iproute: Faster ip link add, set and delete
From: Benoit Lourdelet @ 2013-03-27 13:37 UTC (permalink / raw)
To: Serge Hallyn, Eric W. Biederman; +Cc: Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <20130326143321.GA21768@sergelap>
Hello Serge,
I am indeed using Eric patch with lxc.
It solves the initial problem of slowness to start around 1600 containers.
I am now able to start more than 2000 without having new containers
slower and slower to start.
thanks
Benoit
On 26/03/2013 15:33, "Serge Hallyn" <serge.hallyn@ubuntu.com> wrote:
>Actually, lxc is using random names now, so it's ok.
>
>Benoit, can you use the patches from Eric with lxc (or use the script
>you were using before but specify names as he said)?
>
>-serge
>
^ permalink raw reply
* pull-request: can 2013-03-27
From: Marc Kleine-Budde @ 2013-03-27 14:05 UTC (permalink / raw)
To: netdev; +Cc: linux-can
Hello David,
here's a patch series for net for the v3.9 release cycle. Fengguang Wu found
two problems with the sja1000 drivers:
A macro in the SH architecture collides with one in the sja1000 driver. I
created a minimal patch suited for stable, only changing this particular
define. (Once net is merged back to net-next, I'll post a patch to uniformly
use a SJA1000_ prefix for the sja100 private defines.) If you prefer, I can
squash both patches together.
Fengguang further noticed that the peak pcmcia driver will not compile on archs
without ioport support. I created a patch to limit the driver to archs which
select HAS_IOPORT in Kconfig.
regards,
Marc
---
The following changes since commit b175293ccc98ab84e93d25472d7422b4a897614b:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-03-26 14:24:29 -0700)
are available in the git repository at:
git://gitorious.org/linux-can/linux-can.git fixes-for-3.9
for you to fetch changes up to 3fd33497f80aa528ded0db2851b48638635d5caa:
can: sja1000: limit PEAK PCAN-PC Card to HAS_IOPORT (2013-03-27 14:51:49 +0100)
----------------------------------------------------------------
Marc Kleine-Budde (2):
can: sja1000: fix define conflict on SH
can: sja1000: limit PEAK PCAN-PC Card to HAS_IOPORT
drivers/net/can/sja1000/Kconfig | 1 +
drivers/net/can/sja1000/plx_pci.c | 4 ++--
drivers/net/can/sja1000/sja1000.c | 6 +++---
drivers/net/can/sja1000/sja1000.h | 2 +-
4 files changed, 7 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH 2/2] can: sja1000: limit PEAK PCAN-PC Card to HAS_IOPORT
From: Marc Kleine-Budde @ 2013-03-27 14:05 UTC (permalink / raw)
To: netdev; +Cc: linux-can, Marc Kleine-Budde, Paul Mundt
In-Reply-To: <1364393128-19701-1-git-send-email-mkl@pengutronix.de>
This patch limits the PEAK PCAN-PC Card driver to systems with ioports. Fixes a
compile time breakage on SH:
drivers/net/can/sja1000/peak_pcmcia.c:626:2: error:
implicit declaration of function 'ioport_unmap'
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/sja1000/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/can/sja1000/Kconfig b/drivers/net/can/sja1000/Kconfig
index b39ca5b..ff2ba86 100644
--- a/drivers/net/can/sja1000/Kconfig
+++ b/drivers/net/can/sja1000/Kconfig
@@ -46,6 +46,7 @@ config CAN_EMS_PCI
config CAN_PEAK_PCMCIA
tristate "PEAK PCAN-PC Card"
depends on PCMCIA
+ depends on HAS_IOPORT
---help---
This driver is for the PCAN-PC Card PCMCIA adapter (1 or 2 channels)
from PEAK-System (http://www.peak-system.com). To compile this
--
1.8.2.rc2
^ permalink raw reply related
* [PATCH 1/2] can: sja1000: fix define conflict on SH
From: Marc Kleine-Budde @ 2013-03-27 14:05 UTC (permalink / raw)
To: netdev; +Cc: linux-can, Marc Kleine-Budde, linux-stable
In-Reply-To: <1364393128-19701-1-git-send-email-mkl@pengutronix.de>
Thias patch fixes a define conflict between the SH architecture and the sja1000
driver:
drivers/net/can/sja1000/sja1000.h:59:0: warning:
"REG_SR" redefined [enabled by default]
arch/sh/include/asm/ptrace_32.h:25:0: note:
this is the location of the previous definition
A SJA1000_ prefix is added to the offending sja1000 define only, to make a
minimal patch suited for stable. A later patch will add a SJA1000_ prefix to
all defines in sja1000.h.
Cc: linux-stable <stable@vger.kernel.org>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/sja1000/plx_pci.c | 4 ++--
drivers/net/can/sja1000/sja1000.c | 6 +++---
drivers/net/can/sja1000/sja1000.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
index a042cdc..3c18d7d 100644
--- a/drivers/net/can/sja1000/plx_pci.c
+++ b/drivers/net/can/sja1000/plx_pci.c
@@ -348,7 +348,7 @@ static inline int plx_pci_check_sja1000(const struct sja1000_priv *priv)
*/
if ((priv->read_reg(priv, REG_CR) & REG_CR_BASICCAN_INITIAL_MASK) ==
REG_CR_BASICCAN_INITIAL &&
- (priv->read_reg(priv, REG_SR) == REG_SR_BASICCAN_INITIAL) &&
+ (priv->read_reg(priv, SJA1000_REG_SR) == REG_SR_BASICCAN_INITIAL) &&
(priv->read_reg(priv, REG_IR) == REG_IR_BASICCAN_INITIAL))
flag = 1;
@@ -360,7 +360,7 @@ static inline int plx_pci_check_sja1000(const struct sja1000_priv *priv)
* See states on p. 23 of the Datasheet.
*/
if (priv->read_reg(priv, REG_MOD) == REG_MOD_PELICAN_INITIAL &&
- priv->read_reg(priv, REG_SR) == REG_SR_PELICAN_INITIAL &&
+ priv->read_reg(priv, SJA1000_REG_SR) == REG_SR_PELICAN_INITIAL &&
priv->read_reg(priv, REG_IR) == REG_IR_PELICAN_INITIAL)
return flag;
diff --git a/drivers/net/can/sja1000/sja1000.c b/drivers/net/can/sja1000/sja1000.c
index daf4013..e4df307 100644
--- a/drivers/net/can/sja1000/sja1000.c
+++ b/drivers/net/can/sja1000/sja1000.c
@@ -92,7 +92,7 @@ static void sja1000_write_cmdreg(struct sja1000_priv *priv, u8 val)
*/
spin_lock_irqsave(&priv->cmdreg_lock, flags);
priv->write_reg(priv, REG_CMR, val);
- priv->read_reg(priv, REG_SR);
+ priv->read_reg(priv, SJA1000_REG_SR);
spin_unlock_irqrestore(&priv->cmdreg_lock, flags);
}
@@ -502,7 +502,7 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
while ((isrc = priv->read_reg(priv, REG_IR)) && (n < SJA1000_MAX_IRQ)) {
n++;
- status = priv->read_reg(priv, REG_SR);
+ status = priv->read_reg(priv, SJA1000_REG_SR);
/* check for absent controller due to hw unplug */
if (status == 0xFF && sja1000_is_absent(priv))
return IRQ_NONE;
@@ -530,7 +530,7 @@ irqreturn_t sja1000_interrupt(int irq, void *dev_id)
/* receive interrupt */
while (status & SR_RBS) {
sja1000_rx(dev);
- status = priv->read_reg(priv, REG_SR);
+ status = priv->read_reg(priv, SJA1000_REG_SR);
/* check for absent controller */
if (status == 0xFF && sja1000_is_absent(priv))
return IRQ_NONE;
diff --git a/drivers/net/can/sja1000/sja1000.h b/drivers/net/can/sja1000/sja1000.h
index afa9984..aa48e05 100644
--- a/drivers/net/can/sja1000/sja1000.h
+++ b/drivers/net/can/sja1000/sja1000.h
@@ -56,7 +56,7 @@
/* SJA1000 registers - manual section 6.4 (Pelican Mode) */
#define REG_MOD 0x00
#define REG_CMR 0x01
-#define REG_SR 0x02
+#define SJA1000_REG_SR 0x02
#define REG_IR 0x03
#define REG_IER 0x04
#define REG_ALC 0x0B
--
1.8.2.rc2
^ permalink raw reply related
* pull-request: can-next 2013-03-27
From: Marc Kleine-Budde @ 2013-03-27 14:18 UTC (permalink / raw)
To: netdev; +Cc: linux-can@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]
Hello David,
this is a pull-request for net-next/master. It consists of three
patches by Lars-Peter Clausen to clean up the mcp251x spi-can driver,
two patches from Ludovic Desroches to bring device tree support to the
at91_can driver and a patch by me to fix a sparse warning in the
blackfin driver.
regards,
Marc
---
The following changes since commit 6bdeaba47d87f48a3943b6899d6c6e6f17d52f1d:
6lowpan: use IEEE802154_ADDR_LEN instead of a magic number (2013-03-27 00:52:16 -0400)
are available in the git repository at:
git@gitorious.org:linux-can/linux-can-next.git testing
for you to fetch changes up to 21c11bc5d016ede062843cb3f98ee6824e6bcae2:
can: bfin_can: declare locally used functions static (2013-03-27 13:07:10 +0100)
----------------------------------------------------------------
Lars-Peter Clausen (3):
can: mcp251x: Remove redundant spi driver bus initialization
can: mcp251x: Use module_spi_driver
can: mcp251x: Use dev_pm_ops
Ludovic Desroches (2):
can: at91_can: add dt support
can: Kconfig: CAN_AT91 depends on ARM
Marc Kleine-Budde (1):
can: bfin_can: declare locally used functions static
.../devicetree/bindings/net/can/atmel-can.txt | 14 ++++
drivers/net/can/Kconfig | 2 +-
drivers/net/can/at91_can.c | 76 ++++++++++++++++------
drivers/net/can/bfin_can.c | 4 +-
drivers/net/can/mcp251x.c | 35 ++++------
5 files changed, 88 insertions(+), 43 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/atmel-can.txt
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* [PATCH] igb: fix error return code in igb_sysfs_init()
From: Wei Yongjun @ 2013-03-27 14:18 UTC (permalink / raw)
To: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
peter.p.waskiewicz.jr, alexander.h.duyck, john.ronciak,
tushar.n.dave, stephen, akeem.g.abodunrin
Cc: yongjun_wei, e1000-devel, netdev
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Fix to return a negative error code from the error handling
case instead of 0, as returned elsewhere in this function.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/ethernet/intel/igb/igb_hwmon.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/intel/igb/igb_hwmon.c b/drivers/net/ethernet/intel/igb/igb_hwmon.c
index 0478a1a..3b750b2 100644
--- a/drivers/net/ethernet/intel/igb/igb_hwmon.c
+++ b/drivers/net/ethernet/intel/igb/igb_hwmon.c
@@ -208,6 +208,7 @@ int igb_sysfs_init(struct igb_adapter *adapter)
if (client == NULL) {
dev_info(&adapter->pdev->dev,
"Failed to create new i2c device..\n");
+ rc = -ENOMEM;
goto exit;
}
adapter->i2c_client = client;
^ permalink raw reply related
* Re: pull-request: can-next 2013-03-27
From: Marc Kleine-Budde @ 2013-03-27 14:22 UTC (permalink / raw)
To: netdev; +Cc: linux-can@vger.kernel.org
In-Reply-To: <5152FFB8.2000008@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1149 bytes --]
On 03/27/2013 03:18 PM, Marc Kleine-Budde wrote:
> Hello David,
>
> this is a pull-request for net-next/master. It consists of three
> patches by Lars-Peter Clausen to clean up the mcp251x spi-can driver,
> two patches from Ludovic Desroches to bring device tree support to the
> at91_can driver and a patch by me to fix a sparse warning in the
> blackfin driver.
>
> regards,
> Marc
>
> ---
>
> The following changes since commit 6bdeaba47d87f48a3943b6899d6c6e6f17d52f1d:
>
> 6lowpan: use IEEE802154_ADDR_LEN instead of a magic number (2013-03-27 00:52:16 -0400)
>
> are available in the git repository at:
>
> git@gitorious.org:linux-can/linux-can-next.git testing
Doh! "testing" equals "for-davem" currently and git picked the "wrong"
tree. It should be:
git://gitorious.org/linux-can/linux-can-next.git for-davem
sorry,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: sch_generic: missing u64 in psched_ratecfg_precompute()?
From: Eric Dumazet @ 2013-03-27 14:33 UTC (permalink / raw)
To: Sergey Popovich; +Cc: netdev
In-Reply-To: <4306359.Sd6orIF4zo@tuxracer.localdomain>
On Wed, 2013-03-27 at 15:00 +0200, Sergey Popovich wrote:
> Hello!
>
> It seems that commit
>
> commit 292f1c7ff6cc10516076ceeea45ed11833bb71c7
> Author: Jiri Pirko <jiri@resnulli.us>
> Date: Tue Feb 12 00:12:03 2013 +0000
>
> sch: make htb_rate_cfg and functions around that generic
>
> adds little regression.
>
> Before
> ----
> # tc qdisc add dev eth0 root handle 1: htb default ffff
> # tc class add dev eth0 classid 1:ffff htb rate 5Gbit
> # tc -s class show dev eth0
> class htb 1:ffff root prio 0 rate 5000Mbit ceil 5000Mbit burst 625b cburst
> 625b
> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
> rate 0bit 0pps backlog 0b 0p requeues 0
> lended: 0 borrowed: 0 giants: 0
> tokens: 31 ctokens: 31
>
> After
> ----
> # tc qdisc add dev eth0 root handle 1: htb default ffff
> # tc class add dev eth0 classid 1:ffff htb rate 5Gbit
> # tc -s class show dev eth0
> class htb 1:ffff root prio 0 rate 1544Mbit ceil 1544Mbit burst 625b cburst
> 625b
> Sent 5073 bytes 41 pkt (dropped 0, overlimits 0 requeues 0)
> rate 1976bit 2pps backlog 0b 0p requeues 0
> lended: 41 borrowed: 0 giants: 0
> tokens: 1802 ctokens: 1802
>
> This probably due to lost u64 cast of rate parameter in
> psched_ratecfg_precompute() (net/sched/sch_generic.c).
>
> Simple patch attached. Tested and found working for me at least
> on amd64.
>
Good catch !
Could you send an official patch, with your "Signed-off-by: Sergey
Popovich <popovich_sergei@mail.ru>" ?
Thanks
^ permalink raw reply
* [net-next PATCH 0/2] network performance improvement patches for TI CPSW and Davinci EMAC drivers
From: Mugunthan V N @ 2013-03-27 14:41 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-omap, Mugunthan V N
This patch series improves network performance of TI CPSW and Davinci EMAC
drivers during bulk transfer. During heavy Tx load CPDMA may run out of
descriptors and tx queue is stopped. When it descriptors are available it
is reported to the stack via netif_start_queue which doesn't schedule tx
queue immediately, so there can be dead time during continuous transfer,
this can be fixed by using netif_wake_queue api which will schedule tx queue
immediately.
Mugunthan V N (2):
drivers: net: ethernet: cpsw: use netif_wake_queue() while restarting
tx queue
drivers: net: ethernet: davinci_emac: use netif_wake_queue() while
restarting tx queue
drivers/net/ethernet/ti/cpsw.c | 2 +-
drivers/net/ethernet/ti/davinci_emac.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [net-next PATCH 1/2] drivers: net: ethernet: cpsw: use netif_wake_queue() while restarting tx queue
From: Mugunthan V N @ 2013-03-27 14:41 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-omap, Mugunthan V N
In-Reply-To: <1364395320-14973-1-git-send-email-mugunthanvnm@ti.com>
To restart tx queue use netif_wake_queue() intead of netif_start_queue()
so that net schedule will restart transmission immediately which will
increase network performance while doing huge data transfers.
Reported-by: Dan Franke <dan.franke@schneider-electric.com>
Suggested-by: Sriramakrishnan A G <srk@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index f4be85b..61ecebf 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -458,7 +458,7 @@ static void cpsw_tx_handler(void *token, int len, int status)
* queue is stopped then start the queue as we have free desc for tx
*/
if (unlikely(netif_queue_stopped(ndev)))
- netif_start_queue(ndev);
+ netif_wake_queue(ndev);
cpts_tx_timestamp(priv->cpts, skb);
priv->stats.tx_packets++;
priv->stats.tx_bytes += len;
--
1.7.9.5
^ permalink raw reply related
* [net-next PATCH 2/2] drivers: net: ethernet: davinci_emac: use netif_wake_queue() while restarting tx queue
From: Mugunthan V N @ 2013-03-27 14:42 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-omap, Mugunthan V N
In-Reply-To: <1364395320-14973-1-git-send-email-mugunthanvnm@ti.com>
To restart tx queue use netif_wake_queue() intead of netif_start_queue()
so that net schedule will restart transmission immediately which will
increase network performance while doing huge data transfers.
Reported-by: Dan Franke <dan.franke@schneider-electric.com>
Suggested-by: Sriramakrishnan A G <srk@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/davinci_emac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 8121a3d..6a0b477 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -1053,7 +1053,7 @@ static void emac_tx_handler(void *token, int len, int status)
* queue is stopped then start the queue as we have free desc for tx
*/
if (unlikely(netif_queue_stopped(ndev)))
- netif_start_queue(ndev);
+ netif_wake_queue(ndev);
ndev->stats.tx_packets++;
ndev->stats.tx_bytes += len;
dev_kfree_skb_any(skb);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH net-next 1/3] net: core: let skb_partial_csum_set() set transport header
From: Eric Dumazet @ 2013-03-27 14:42 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel, mst, Eric Dumazet
In-Reply-To: <1364375482-7439-1-git-send-email-jasowang@redhat.com>
On Wed, 2013-03-27 at 17:11 +0800, Jason Wang wrote:
> For untrusted packets with partial checksum, we need to set the transport header
> for precise packet length estimation. We can just let skb_pratial_csum_set() to
> do this to avoid extra call to skb_flow_dissect() and simplify the caller.
>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> net/core/skbuff.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 31c6737..ba64614 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -3370,6 +3370,7 @@ bool skb_partial_csum_set(struct sk_buff *skb, u16 start, u16 off)
> skb->ip_summed = CHECKSUM_PARTIAL;
> skb->csum_start = skb_headroom(skb) + start;
> skb->csum_offset = off;
> + skb_set_transport_header(skb, start);
> return true;
> }
> EXPORT_SYMBOL_GPL(skb_partial_csum_set);
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: core: introduce skb_probe_transport_header()
From: Eric Dumazet @ 2013-03-27 14:45 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel, mst, Eric Dumazet
In-Reply-To: <1364375482-7439-2-git-send-email-jasowang@redhat.com>
On Wed, 2013-03-27 at 17:11 +0800, Jason Wang wrote:
> Sometimes, we need probe and set the transport header for packets (e.g from
> untrusted source). This patch introduces a new helper
> skb_probe_transport_header() which tries to probe and set the l4 header through
> skb_flow_dissect(), if not just set the transport header to the hint passed by
> caller.
>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> include/linux/skbuff.h | 14 ++++++++++++++
> 1 files changed, 14 insertions(+), 0 deletions(-)
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next 3/3] net: switch to use skb_probe_transport_header()
From: Eric Dumazet @ 2013-03-27 14:46 UTC (permalink / raw)
To: Jason Wang; +Cc: davem, netdev, linux-kernel, mst, Eric Dumazet
In-Reply-To: <1364375482-7439-3-git-send-email-jasowang@redhat.com>
On Wed, 2013-03-27 at 17:11 +0800, Jason Wang wrote:
> Switch to use the new help skb_probe_transport_header() to do the l4 header
> probing for untrusted sources. For packets with partial csum, the header should
> already been set by skb_partial_csum_set().
>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/net/macvtap.c | 9 +--------
> drivers/net/tun.c | 10 +---------
> drivers/net/xen-netback/netback.c | 10 +---------
> net/packet/af_packet.c | 22 +++-------------------
> 4 files changed, 6 insertions(+), 45 deletions(-)
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH] igb: fix error return code in igb_sysfs_init()
From: Denis Kirjanov @ 2013-03-27 14:55 UTC (permalink / raw)
To: Wei Yongjun
Cc: jeffrey.t.kirsher, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
peter.p.waskiewicz.jr, alexander.h.duyck, john.ronciak,
tushar.n.dave, stephen, akeem.g.abodunrin, yongjun_wei,
e1000-devel, netdev
In-Reply-To: <CAPgLHd91Yf2-q1Vh+aTSZ2phqFQC6wbh-ixO6Yh6qu9qsCqnHw@mail.gmail.com>
Wouldn't it be better to return EIO since i2c_new_device() can fail
for many reasons...
On 3/27/13, Wei Yongjun <weiyj.lk@gmail.com> wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Fix to return a negative error code from the error handling
> case instead of 0, as returned elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> drivers/net/ethernet/intel/igb/igb_hwmon.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/intel/igb/igb_hwmon.c
> b/drivers/net/ethernet/intel/igb/igb_hwmon.c
> index 0478a1a..3b750b2 100644
> --- a/drivers/net/ethernet/intel/igb/igb_hwmon.c
> +++ b/drivers/net/ethernet/intel/igb/igb_hwmon.c
> @@ -208,6 +208,7 @@ int igb_sysfs_init(struct igb_adapter *adapter)
> if (client == NULL) {
> dev_info(&adapter->pdev->dev,
> "Failed to create new i2c device..\n");
> + rc = -ENOMEM;
> goto exit;
> }
> adapter->i2c_client = client;
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [net-next PATCH 1/2] drivers: net: ethernet: cpsw: use netif_wake_queue() while restarting tx queue
From: Eric Dumazet @ 2013-03-27 14:55 UTC (permalink / raw)
To: Mugunthan V N; +Cc: netdev, davem, linux-omap
In-Reply-To: <1364395320-14973-2-git-send-email-mugunthanvnm@ti.com>
On Wed, 2013-03-27 at 20:11 +0530, Mugunthan V N wrote:
> To restart tx queue use netif_wake_queue() intead of netif_start_queue()
> so that net schedule will restart transmission immediately which will
> increase network performance while doing huge data transfers.
>
> Reported-by: Dan Franke <dan.franke@schneider-electric.com>
> Suggested-by: Sriramakrishnan A G <srk@ti.com>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> drivers/net/ethernet/ti/cpsw.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
> index f4be85b..61ecebf 100644
> --- a/drivers/net/ethernet/ti/cpsw.c
> +++ b/drivers/net/ethernet/ti/cpsw.c
> @@ -458,7 +458,7 @@ static void cpsw_tx_handler(void *token, int len, int status)
> * queue is stopped then start the queue as we have free desc for tx
> */
> if (unlikely(netif_queue_stopped(ndev)))
> - netif_start_queue(ndev);
> + netif_wake_queue(ndev);
> cpts_tx_timestamp(priv->cpts, skb);
> priv->stats.tx_packets++;
> priv->stats.tx_bytes += len;
Its a bug fix, suitable for net tree
Acked-by: Eric Dumazet <edumazet@google.com>
BTW, it seems cpsw_ndo_start_xmit() can race with cpsw_tx_handler().
^ permalink raw reply
* Re: [PATCH regression/bisected] Revert "brcmsmac: support 4313iPA"
From: John W. Linville @ 2013-03-27 14:56 UTC (permalink / raw)
To: Piotr Haber
Cc: David Herrmann, linux-wireless, linux-kernel, Arend van Spriel,
brcm80211-dev-list, netdev, Pieter-Paul Giesberts
In-Reply-To: <51516AD4.8080306@broadcom.com>
On Tue, Mar 26, 2013 at 10:31:00AM +0100, Piotr Haber wrote:
> On 03/25/13 19:58, John W. Linville wrote:
> > On Mon, Mar 18, 2013 at 02:58:08PM +0100, David Herrmann wrote:
> >> Hi Piotr
> >>
> >> On Mon, Mar 18, 2013 at 2:49 PM, Piotr Haber <phaber@broadcom.com> wrote:
> >>> On 03/18/13 11:45, David Herrmann wrote:
> >>>> This reverts commit b6fc28a158076ca2764edc9a6d1e1402f56e1c0c. It breaks
> >>>> wireless AP reconnection on: (14e4:4727)
> >>>> Broadcom Corporation BCM4313 802.11b/g/n Wireless LAN Controller
> >>>>
> >>>> Any attempt to reconnect to an AP results in timeouts no matter how near to the
> >>>> AP I am:
> >>>> 00:10:40 $nb kernel: wlan0: authenticate with 00:18:39:0a:8e:23
> >>>> 00:10:40 $nb kernel: wlan0: direct probe to 00:18:39:0a:8e:23 (try 1/3)
> >>>> 00:10:40 $nb kernel: wlan0: direct probe to 00:18:39:0a:8e:23 (try 2/3)
> >>>> 00:10:41 $nb kernel: wlan0: direct probe to 00:18:39:0a:8e:23 (try 3/3)
> >>>> 00:10:41 $nb kernel: wlan0: authentication with 00:18:39:0a:8e:23 timed out
> >>>> ---
> >>>> Hi
> >>>>
> >>>> I tried coming up with a fix instead of reverting this commit, but the commit is
> >>>> way to big for me to understand what's going on. Sorry.
> >>>>
> >>>> With linux-3.8 connecting to an AP broke on my machine. I could connect to an AP
> >>>> one time, but any further attempt resulted in:
> >>>> 00:10:40 $nb kernel: wlan0: authenticate with 00:18:39:0a:8e:23
> >>>> 00:10:40 $nb kernel: wlan0: direct probe to 00:18:39:0a:8e:23 (try 1/3)
> >>>> 00:10:40 $nb kernel: wlan0: direct probe to 00:18:39:0a:8e:23 (try 2/3)
> >>>> 00:10:41 $nb kernel: wlan0: direct probe to 00:18:39:0a:8e:23 (try 3/3)
> >>>> 00:10:41 $nb kernel: wlan0: authentication with 00:18:39:0a:8e:23 timed out
> >>>>
> >>>> Even sitting right next to the AP didn't help so I started bisecting and it
> >>>> turned out to be:
> >>>> "brcmsmac: support 4313iPA" b6fc28a158076ca2764edc9a6d1e1402f56e1c0c
> >>>> Please revert it.
> >>>>
> >>>> Thanks
> >>>> David
> >>>>
> >>> Hi,
> >>> unfortunately this is not a first report of this patch breaking 4313 for some users.
> >>> I'm pretty confident that it is hardware revision related as we have 4313ePA and iPA boards running
> >>> successfully in our test setup.
> >>> Could you aid us in effort of finding the problem by supplying the contents of this debugfs file:
> >>> <debugfs_mount>/brcmsmac/bcma0:0/hardware
> >>
> >> Hi
> >>
> >> $ cat /sys/kernel/debug/brcmsmac/bcma0\:0/hardware
> >> board vendor: 185f
> >> board type: 51a
> >> board revision: 1408
> >> board flags: 8402a01
> >> board flags2: 880
> >> firmware revision: 262032b
> >>
> >> I can also try partial reverts of that commit, but I really don't know
> >> which parts might be important.
> >
> > Are we going to see a fix for this (very) soon? Or should I just go
> > ahead and revert this patch?
> >
> I cannot reproduce the issue on a set of devices we have here (3 different 4313 ePA models).
> Some of the devices that are reported to be broken are being shipped to us.
> So I would say we need around 2 weeks at least to resolve this (if we reproduce the problem and find
> a fix).
> Not sure this is soon enough.
> If not please go ahead an revert the patch.
I am reverting the patch.
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [net-next PATCH 2/2] drivers: net: ethernet: davinci_emac: use netif_wake_queue() while restarting tx queue
From: Eric Dumazet @ 2013-03-27 14:57 UTC (permalink / raw)
To: Mugunthan V N; +Cc: netdev, davem, linux-omap
In-Reply-To: <1364395320-14973-3-git-send-email-mugunthanvnm@ti.com>
On Wed, 2013-03-27 at 20:12 +0530, Mugunthan V N wrote:
> To restart tx queue use netif_wake_queue() intead of netif_start_queue()
> so that net schedule will restart transmission immediately which will
> increase network performance while doing huge data transfers.
>
> Reported-by: Dan Franke <dan.franke@schneider-electric.com>
> Suggested-by: Sriramakrishnan A G <srk@ti.com>
> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> ---
> drivers/net/ethernet/ti/davinci_emac.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
> index 8121a3d..6a0b477 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
> @@ -1053,7 +1053,7 @@ static void emac_tx_handler(void *token, int len, int status)
> * queue is stopped then start the queue as we have free desc for tx
> */
> if (unlikely(netif_queue_stopped(ndev)))
> - netif_start_queue(ndev);
> + netif_wake_queue(ndev);
> ndev->stats.tx_packets++;
> ndev->stats.tx_bytes += len;
> dev_kfree_skb_any(skb);
same remark here, its a bug fix
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [RFC][PATCH] iproute: Faster ip link add, set and delete
From: Eric W. Biederman @ 2013-03-27 15:11 UTC (permalink / raw)
To: Benoit Lourdelet; +Cc: Serge Hallyn, Stephen Hemminger, netdev@vger.kernel.org
In-Reply-To: <CD78B3C3.76D3%blourdel@juniper.net>
Benoit Lourdelet <blourdel@juniper.net> writes:
> Hello Serge,
>
> I am indeed using Eric patch with lxc.
>
> It solves the initial problem of slowness to start around 1600
> containers.
Good so now we just need a production ready patch for iproute.
> I am now able to start more than 2000 without having new containers
> slower and slower to start.
May I ask how large a box you are running and how complex your
containers are. I am trying to get a feel for how common it is likely
to be to find people running thousands of containers on a single
machine.
Eric
^ permalink raw reply
* Re: /128 link-local subnet on 6in4 (sit) tunnels?
From: Hannes Frederic Sowa @ 2013-03-27 15:12 UTC (permalink / raw)
To: Wilco Baan Hofman; +Cc: netdev
In-Reply-To: <1364335457.8215.21.camel@localhost>
On Tue, Mar 26, 2013 at 11:04:17PM +0100, Wilco Baan Hofman wrote:
> I was trying to get OSPFv3 working on NBMA 6in4 tunnel on linux 3.8, but
> it does not work. I noticed it uses a /128 fe80 link-local subnet
> instead of the rfc4213[1]-mandated /64.. This breaks bird (likely for
> other reasons), but also interoperability with cisco, which mandates
> OSPFv3 NBMA on link-local addresses.
>
> So I was wondering, is there any particular reason for the use of a /128
> link-local or is this just a bug?
Can you show me the commands how you set up the tunnel. It does create /64 ll
with embedded ipv4 addresses for me here on v3.8.
^ permalink raw reply
* Re: [PATCH net-next] openvswitch: correct an invalid BUG_ON
From: Jesse Gross @ 2013-03-27 15:19 UTC (permalink / raw)
To: Hong Zhiguo
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1364388077-30480-1-git-send-email-honkiko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Mar 27, 2013 at 5:41 AM, Hong Zhiguo <honkiko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> table->count is uint32_t
>
> Signed-off-by: Hong Zhiguo <honkiko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net : Fix broken IPv6 routing table after loopback down-up
From: Eric Dumazet @ 2013-03-27 15:26 UTC (permalink / raw)
To: YOSHIFUJI Hideaki
Cc: Balakumaran Kannan, davem, kuznet, jmorris, kaber, netdev,
Balakumaran.Kannan, maruthi.thotad
In-Reply-To: <5152D012.4030805@linux-ipv6.org>
On Wed, 2013-03-27 at 19:55 +0900, YOSHIFUJI Hideaki wrote:
> Balakumaran Kannan wrote:
> > add_addr(idev, &in6addr_loopback, 128, IFA_HOST);
> > +
> > + while ((sp_dev = dev_get_by_index(dev_net(dev), i++))) {
> > +
>
> I think this cannot work because we may have missing index.
> Why no dev_get_by_name()?
I might 'work' because lo interface index is 1 on all network
namespaces.
But yes, this ugly loop is not needed at all.
^ permalink raw reply
* Fw: [Bug 55861] New: PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information
From: Stephen Hemminger @ 2013-03-27 15:31 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Wed, 27 Mar 2013 08:25:40 -0700
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 55861] New: PMTU discovery no longer works in Linux 3.6+ with routers that do not send next hop MTU information
https://bugzilla.kernel.org/show_bug.cgi?id=55861
Summary: PMTU discovery no longer works in Linux 3.6+ with
routers that do not send next hop MTU information
Product: Networking
Version: 2.5
Kernel Version: 3.6 onwards
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: IPV4
AssignedTo: shemminger@linux-foundation.org
ReportedBy: _@maxb.eu
Regression: Yes
After upgrading recently, I found that path MTU discovery no longer worked
correctly for accessing some devices on the other side of an IPsec tunnel.
Bisection revealed the problems started with 3.6 and are still present in
3.9-rc4 (latest available at time of reporting).
Some investigation into code changes leads me to the belief that Linux lost
support for handling ICMP destination unreachable fragmentation needed packets
for which the next hop MTU field is zero. This is an expected condition when
dealing with older routers, as RFC792 originally defined ICMP destination
unreachable fragmentation needed without a next hop MTU field, and it was later
added in bytes previously allocated as unused.
The particular router in my case generating such packets is a machine running
OpenBSD 4.6.
A commit that appears to be of particular interest in this bug is
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=46517008e1168dc926cf2c47d529efc07eca85c0
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ 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