* [PATCH 10/15] irda: sh_irda: Enable driver compilation with COMPILE_TEST
From: Laurent Pinchart @ 2013-11-27 1:18 UTC (permalink / raw)
To: linux-sh; +Cc: linux-arm-kernel, Samuel Ortiz, netdev
In-Reply-To: <1385515117-23664-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
This helps increasing build testing coverage.
Cc: Samuel Ortiz <samuel@sortiz.org>
Cc: netdev@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Simon Horman <horms@verge.net.au>
---
drivers/net/irda/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/irda/Kconfig b/drivers/net/irda/Kconfig
index 2a30193..cae5ee2 100644
--- a/drivers/net/irda/Kconfig
+++ b/drivers/net/irda/Kconfig
@@ -403,7 +403,8 @@ config MCS_FIR
config SH_IRDA
tristate "SuperH IrDA driver"
- depends on IRDA && ARCH_SHMOBILE
+ depends on IRDA
+ depends on ARCH_SHMOBILE || COMPILE_TEST
help
Say Y here if your want to enable SuperH IrDA devices.
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH] macvtap: Do not double-count received packets
From: Jason Wang @ 2013-11-27 2:12 UTC (permalink / raw)
To: Vlad Yasevich, netdev; +Cc: mst
In-Reply-To: <1385487432-17651-1-git-send-email-vyasevic@redhat.com>
On 11/27/2013 01:37 AM, Vlad Yasevich wrote:
> Currently macvlan will count received packets after calling each
> vlans receive handler. Macvtap attempts to count the packet
> yet again when the user reads the packet from the tap socket.
> This code doesn't do this consistently either. Remove the
> counting from macvap and let only macvlan count received
> packets.
>
> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
> ---
> drivers/net/macvtap.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index dc76670..50f8dce 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -767,7 +767,6 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
> const struct sk_buff *skb,
> const struct iovec *iv, int len)
> {
> - struct macvlan_dev *vlan;
> int ret;
> int vnet_hdr_len = 0;
> int vlan_offset = 0;
> @@ -821,15 +820,6 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
> copied += len;
>
> done:
> - rcu_read_lock();
> - vlan = rcu_dereference(q->vlan);
> - if (vlan) {
> - preempt_disable();
> - macvlan_count_rx(vlan, copied - vnet_hdr_len, ret == 0, 0);
> - preempt_enable();
> - }
> - rcu_read_unlock();
> -
> return ret ? ret : copied;
> }
>
Acked-by: Jason Wang <jasowang@redhat.com>
^ permalink raw reply
* No netlink notification for user-initiated NUD state change
From: Bob Gilligan @ 2013-11-27 2:28 UTC (permalink / raw)
To: netdev
Hi -- The neighbour code sends up an RTM_NEWNEIGH netlink notification
if the NUD state of a neighbour cache entry is changed by a timer (e.g.
from REACHABLE to STALE), even if the lladdr of the entry has not changed.
But a user-initiated change to the the NUD state of a neighbour cache
entry that does not change the lladdr (e.g. via "ip -4 neigh change ...
nud ...") does not trigger a netlink notification.
I'm wondering if that is intended behavior? Is there any reason not to
send a netlink notification in this case? The situation we've seen
where it would be nice to have these notifications is if a user changes
an existing resolved entry to PERMANENT.
This one-line change to neigh_update() would trigger netlink
notifications on all user-initiated state changes:
Index: linux-3.12.1/net/core/neighbour.c
===================================================================
--- linux-3.12.1.orig/net/core/neighbour.c
+++ linux-3.12.1/net/core/neighbour.c
@@ -1161,6 +1161,7 @@ int neigh_update(struct neighbour *neigh
neigh->parms->reachable_time :
0)));
neigh->nud_state = new;
+ notify = 1;
}
if (lladdr != neigh->ha) {
I'd be happy to submit a properly formatted patch if there's agreement
that this is an issue.
Bob.
^ permalink raw reply
* [PATCH] WIFI: handle a neglected case in nl80211_new_interface()
From: Chao Bi @ 2013-11-27 3:00 UTC (permalink / raw)
To: Johannes Berg, John W. Linville, David S. Miller
Cc: linux-kernel, netdev, linux-wireless
In nl80211_new_interface(), it calls rdev_add_virtual_intf() to create
a new interface, however, it only checks whether returned value is err
code, but doesn't check if returned value is NULL. The returned value
could be NULL, for example, memory allocation failed when creating a
new interface.
when get a NULL returned value, nl80211_new_interface() is expected to
return but it actually runs down to access the NULL pointer, this could
lead to a panic.
Signed-off-by: Chao Bi <chao.bi@intel.com>
---
net/wireless/nl80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index a1eb210..27feeaf 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2512,7 +2512,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
wdev = rdev_add_virtual_intf(rdev,
nla_data(info->attrs[NL80211_ATTR_IFNAME]),
type, err ? NULL : &flags, ¶ms);
- if (IS_ERR(wdev)) {
+ if (!wdev || IS_ERR(wdev)) {
nlmsg_free(msg);
return PTR_ERR(wdev);
}
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 0/5] net: hwmon fixes
From: Guenter Roeck @ 2013-11-27 3:28 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev, David S. Miller, Jeff Kirsher, Jesse Brandeburg,
Bruce Allan, Carolyn Wyborny, Don Skidmore, Greg Rose,
Nithin Nayak Sujir, Michael Chan, e1000-devel, lm-sensors
In-Reply-To: <1385496510.1586.63.camel@bwh-desktop.uk.level5networks.com>
On 11/26/2013 12:08 PM, Ben Hutchings wrote:
> On Mon, 2013-11-25 at 09:48 -0800, Guenter Roeck wrote:
>> On 11/25/2013 09:15 AM, Ben Hutchings wrote:
>>> On Sat, 2013-11-23 at 09:07 -0800, Guenter Roeck wrote:
>>>> On 11/23/2013 08:48 AM, Ben Hutchings wrote:
>>>>> On Fri, 2013-11-22 at 22:07 -0800, Guenter Roeck wrote:
>>>>>> The hwmon subsystem is used by various network drivers to report temperature
>>>>>> sensor and other information. Unfortunately, its use is often not correct.
>>>>>> Typical errors are that the mandatory name sysfs attribute is not created,
>>>>>> that the temperature sensor index starts with 0 instead of 1, and/or that
>>>>>> sysfs attributes are created after the hwmon device was created.
>>>>>
>>>>> As it happens, I was just looking at what we do in sfc
>>>>> (drivers/net/ethernet/sfc/mcdi_mon.c) and wondering why I made it create
>>>>> the hwmon device before the attributes. I think I avoided the other
>>>>> bugs though.
>>>>>
>>>> Hi Ben,
>>>>
>>>> Yes, I know about that one. It concluded that it would be too invasive
>>>> and risky to try to fix it without access to hardware to test the results.
>>>> That is why I said "fixes _most_ of the problems".
>>>>
>>>> As for why the attributes are created after registration, it was most likely
>>>> because there was no API available to attach the sysfs attributes to
>>>> the hwmon device in a clean way. The new APIs fix that.
>>>
>>> We don't attach them to the hwmon device either, and I would rather not
>>> change that yet because lm-sensors 2 is still widely used.
>>>
>>
>> Hmm .. then there should be no good reason to create the attributes
>> only after hwmon registration.
>>
>> As for lm-sensors 2 ... really ? Seems odd that people would use the
>> latest kernel with 5+ years old versions of applications / libraries.
>> but I guess the world is full of such oddities, so maybe I should not
>> be surprised.
> [...]
>
> As Jean pointed out, the net drivers implementing hwmon aren't supported
> by lm-sensors 2 anyway. So we should go ahead and use the new API in
> sfc. I've opened an internal bug report for this, but it is likely to
> be low priority for the team. But if you write a patch I can test it.
>
You'll get one shortly.
Thanks,
Guenter
^ permalink raw reply
* [PATCH] sfc: Convert to use hwmon_device_register_with_groups
From: Guenter Roeck @ 2013-11-27 3:30 UTC (permalink / raw)
To: netdev; +Cc: linux-net-drivers, lm-sensors, Guenter Roeck
Simplify the code. Avoid race conditions caused by attributes
being created after hwmon device registration. Implicitly
(through hwmon API) add mandatory 'name' sysfs attribute.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
Compile tested only.
drivers/net/ethernet/sfc/mcdi.h | 2 +
drivers/net/ethernet/sfc/mcdi_mon.c | 76 +++++++++++++----------------------
2 files changed, 31 insertions(+), 47 deletions(-)
diff --git a/drivers/net/ethernet/sfc/mcdi.h b/drivers/net/ethernet/sfc/mcdi.h
index 656a327..15816ca 100644
--- a/drivers/net/ethernet/sfc/mcdi.h
+++ b/drivers/net/ethernet/sfc/mcdi.h
@@ -75,6 +75,8 @@ struct efx_mcdi_mon {
unsigned long last_update;
struct device *device;
struct efx_mcdi_mon_attribute *attrs;
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
unsigned int n_attrs;
};
diff --git a/drivers/net/ethernet/sfc/mcdi_mon.c b/drivers/net/ethernet/sfc/mcdi_mon.c
index 4cc5d95..ee7ce65 100644
--- a/drivers/net/ethernet/sfc/mcdi_mon.c
+++ b/drivers/net/ethernet/sfc/mcdi_mon.c
@@ -139,13 +139,6 @@ static int efx_mcdi_mon_update(struct efx_nic *efx)
return rc;
}
-static ssize_t efx_mcdi_mon_show_name(struct device *dev,
- struct device_attribute *attr,
- char *buf)
-{
- return sprintf(buf, "%s\n", KBUILD_MODNAME);
-}
-
static int efx_mcdi_mon_get_entry(struct device *dev, unsigned int index,
efx_dword_t *entry)
{
@@ -263,7 +256,7 @@ static ssize_t efx_mcdi_mon_show_label(struct device *dev,
efx_mcdi_sensor_type[mon_attr->type].label);
}
-static int
+static void
efx_mcdi_mon_add_attr(struct efx_nic *efx, const char *name,
ssize_t (*reader)(struct device *,
struct device_attribute *, char *),
@@ -272,7 +265,6 @@ efx_mcdi_mon_add_attr(struct efx_nic *efx, const char *name,
{
struct efx_mcdi_mon *hwmon = efx_mcdi_mon(efx);
struct efx_mcdi_mon_attribute *attr = &hwmon->attrs[hwmon->n_attrs];
- int rc;
strlcpy(attr->name, name, sizeof(attr->name));
attr->index = index;
@@ -286,10 +278,7 @@ efx_mcdi_mon_add_attr(struct efx_nic *efx, const char *name,
attr->dev_attr.attr.name = attr->name;
attr->dev_attr.attr.mode = S_IRUGO;
attr->dev_attr.show = reader;
- rc = device_create_file(&efx->pci_dev->dev, &attr->dev_attr);
- if (rc == 0)
- ++hwmon->n_attrs;
- return rc;
+ hwmon->group.attrs[hwmon->n_attrs++] = &attr->dev_attr.attr;
}
int efx_mcdi_mon_probe(struct efx_nic *efx)
@@ -338,26 +327,22 @@ int efx_mcdi_mon_probe(struct efx_nic *efx)
efx_mcdi_mon_update(efx);
/* Allocate space for the maximum possible number of
- * attributes for this set of sensors: name of the driver plus
+ * attributes for this set of sensors:
* value, min, max, crit, alarm and label for each sensor.
*/
- n_attrs = 1 + 6 * n_sensors;
+ n_attrs = 6 * n_sensors;
hwmon->attrs = kcalloc(n_attrs, sizeof(*hwmon->attrs), GFP_KERNEL);
if (!hwmon->attrs) {
rc = -ENOMEM;
goto fail;
}
-
- hwmon->device = hwmon_device_register(&efx->pci_dev->dev);
- if (IS_ERR(hwmon->device)) {
- rc = PTR_ERR(hwmon->device);
+ hwmon->group.attrs = kcalloc(n_attrs + 1, sizeof(struct attribute *),
+ GFP_KERNEL);
+ if (!hwmon->group.attrs) {
+ rc = -ENOMEM;
goto fail;
}
- rc = efx_mcdi_mon_add_attr(efx, "name", efx_mcdi_mon_show_name, 0, 0, 0);
- if (rc)
- goto fail;
-
for (i = 0, j = -1, type = -1; ; i++) {
enum efx_hwmon_type hwmon_type;
const char *hwmon_prefix;
@@ -372,7 +357,7 @@ int efx_mcdi_mon_probe(struct efx_nic *efx)
page = type / 32;
j = -1;
if (page == n_pages)
- return 0;
+ goto hwmon_register;
MCDI_SET_DWORD(inbuf, SENSOR_INFO_EXT_IN_PAGE,
page);
@@ -453,28 +438,22 @@ int efx_mcdi_mon_probe(struct efx_nic *efx)
if (min1 != max1) {
snprintf(name, sizeof(name), "%s%u_input",
hwmon_prefix, hwmon_index);
- rc = efx_mcdi_mon_add_attr(
+ efx_mcdi_mon_add_attr(
efx, name, efx_mcdi_mon_show_value, i, type, 0);
- if (rc)
- goto fail;
if (hwmon_type != EFX_HWMON_POWER) {
snprintf(name, sizeof(name), "%s%u_min",
hwmon_prefix, hwmon_index);
- rc = efx_mcdi_mon_add_attr(
+ efx_mcdi_mon_add_attr(
efx, name, efx_mcdi_mon_show_limit,
i, type, min1);
- if (rc)
- goto fail;
}
snprintf(name, sizeof(name), "%s%u_max",
hwmon_prefix, hwmon_index);
- rc = efx_mcdi_mon_add_attr(
+ efx_mcdi_mon_add_attr(
efx, name, efx_mcdi_mon_show_limit,
i, type, max1);
- if (rc)
- goto fail;
if (min2 != max2) {
/* Assume max2 is critical value.
@@ -482,32 +461,38 @@ int efx_mcdi_mon_probe(struct efx_nic *efx)
*/
snprintf(name, sizeof(name), "%s%u_crit",
hwmon_prefix, hwmon_index);
- rc = efx_mcdi_mon_add_attr(
+ efx_mcdi_mon_add_attr(
efx, name, efx_mcdi_mon_show_limit,
i, type, max2);
- if (rc)
- goto fail;
}
}
snprintf(name, sizeof(name), "%s%u_alarm",
hwmon_prefix, hwmon_index);
- rc = efx_mcdi_mon_add_attr(
+ efx_mcdi_mon_add_attr(
efx, name, efx_mcdi_mon_show_alarm, i, type, 0);
- if (rc)
- goto fail;
if (type < ARRAY_SIZE(efx_mcdi_sensor_type) &&
efx_mcdi_sensor_type[type].label) {
snprintf(name, sizeof(name), "%s%u_label",
hwmon_prefix, hwmon_index);
- rc = efx_mcdi_mon_add_attr(
+ efx_mcdi_mon_add_attr(
efx, name, efx_mcdi_mon_show_label, i, type, 0);
- if (rc)
- goto fail;
}
}
+hwmon_register:
+ hwmon->groups[0] = &hwmon->group;
+ hwmon->device = hwmon_device_register_with_groups(&efx->pci_dev->dev,
+ KBUILD_MODNAME, NULL,
+ hwmon->groups);
+ if (IS_ERR(hwmon->device)) {
+ rc = PTR_ERR(hwmon->device);
+ goto fail;
+ }
+
+ return 0;
+
fail:
efx_mcdi_mon_remove(efx);
return rc;
@@ -516,14 +501,11 @@ fail:
void efx_mcdi_mon_remove(struct efx_nic *efx)
{
struct efx_mcdi_mon *hwmon = efx_mcdi_mon(efx);
- unsigned int i;
- for (i = 0; i < hwmon->n_attrs; i++)
- device_remove_file(&efx->pci_dev->dev,
- &hwmon->attrs[i].dev_attr);
- kfree(hwmon->attrs);
if (hwmon->device)
hwmon_device_unregister(hwmon->device);
+ kfree(hwmon->attrs);
+ kfree(hwmon->group.attrs);
efx_nic_free_buffer(efx, &hwmon->dma_buf);
}
--
1.7.9.7
^ permalink raw reply related
* [PATCH] sfc: Convert to use hwmon_device_register_with_groups
From: Guenter Roeck @ 2013-11-27 3:33 UTC (permalink / raw)
To: netdev; +Cc: linux-net-drivers, Ben Hutchings, lm-sensors, Guenter Roeck
Simplify the code. Avoid race conditions caused by attributes
being created after hwmon device registration. Implicitly
(through hwmon API) add mandatory 'name' sysfs attribute.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
Compile tested only.
drivers/net/ethernet/sfc/mcdi.h | 2 +
drivers/net/ethernet/sfc/mcdi_mon.c | 76 +++++++++++++----------------------
2 files changed, 31 insertions(+), 47 deletions(-)
diff --git a/drivers/net/ethernet/sfc/mcdi.h b/drivers/net/ethernet/sfc/mcdi.h
index 656a327..15816ca 100644
--- a/drivers/net/ethernet/sfc/mcdi.h
+++ b/drivers/net/ethernet/sfc/mcdi.h
@@ -75,6 +75,8 @@ struct efx_mcdi_mon {
unsigned long last_update;
struct device *device;
struct efx_mcdi_mon_attribute *attrs;
+ struct attribute_group group;
+ const struct attribute_group *groups[2];
unsigned int n_attrs;
};
diff --git a/drivers/net/ethernet/sfc/mcdi_mon.c b/drivers/net/ethernet/sfc/mcdi_mon.c
index 4cc5d95..ee7ce65 100644
--- a/drivers/net/ethernet/sfc/mcdi_mon.c
+++ b/drivers/net/ethernet/sfc/mcdi_mon.c
@@ -139,13 +139,6 @@ static int efx_mcdi_mon_update(struct efx_nic *efx)
return rc;
}
-static ssize_t efx_mcdi_mon_show_name(struct device *dev,
- struct device_attribute *attr,
- char *buf)
-{
- return sprintf(buf, "%s\n", KBUILD_MODNAME);
-}
-
static int efx_mcdi_mon_get_entry(struct device *dev, unsigned int index,
efx_dword_t *entry)
{
@@ -263,7 +256,7 @@ static ssize_t efx_mcdi_mon_show_label(struct device *dev,
efx_mcdi_sensor_type[mon_attr->type].label);
}
-static int
+static void
efx_mcdi_mon_add_attr(struct efx_nic *efx, const char *name,
ssize_t (*reader)(struct device *,
struct device_attribute *, char *),
@@ -272,7 +265,6 @@ efx_mcdi_mon_add_attr(struct efx_nic *efx, const char *name,
{
struct efx_mcdi_mon *hwmon = efx_mcdi_mon(efx);
struct efx_mcdi_mon_attribute *attr = &hwmon->attrs[hwmon->n_attrs];
- int rc;
strlcpy(attr->name, name, sizeof(attr->name));
attr->index = index;
@@ -286,10 +278,7 @@ efx_mcdi_mon_add_attr(struct efx_nic *efx, const char *name,
attr->dev_attr.attr.name = attr->name;
attr->dev_attr.attr.mode = S_IRUGO;
attr->dev_attr.show = reader;
- rc = device_create_file(&efx->pci_dev->dev, &attr->dev_attr);
- if (rc == 0)
- ++hwmon->n_attrs;
- return rc;
+ hwmon->group.attrs[hwmon->n_attrs++] = &attr->dev_attr.attr;
}
int efx_mcdi_mon_probe(struct efx_nic *efx)
@@ -338,26 +327,22 @@ int efx_mcdi_mon_probe(struct efx_nic *efx)
efx_mcdi_mon_update(efx);
/* Allocate space for the maximum possible number of
- * attributes for this set of sensors: name of the driver plus
+ * attributes for this set of sensors:
* value, min, max, crit, alarm and label for each sensor.
*/
- n_attrs = 1 + 6 * n_sensors;
+ n_attrs = 6 * n_sensors;
hwmon->attrs = kcalloc(n_attrs, sizeof(*hwmon->attrs), GFP_KERNEL);
if (!hwmon->attrs) {
rc = -ENOMEM;
goto fail;
}
-
- hwmon->device = hwmon_device_register(&efx->pci_dev->dev);
- if (IS_ERR(hwmon->device)) {
- rc = PTR_ERR(hwmon->device);
+ hwmon->group.attrs = kcalloc(n_attrs + 1, sizeof(struct attribute *),
+ GFP_KERNEL);
+ if (!hwmon->group.attrs) {
+ rc = -ENOMEM;
goto fail;
}
- rc = efx_mcdi_mon_add_attr(efx, "name", efx_mcdi_mon_show_name, 0, 0, 0);
- if (rc)
- goto fail;
-
for (i = 0, j = -1, type = -1; ; i++) {
enum efx_hwmon_type hwmon_type;
const char *hwmon_prefix;
@@ -372,7 +357,7 @@ int efx_mcdi_mon_probe(struct efx_nic *efx)
page = type / 32;
j = -1;
if (page == n_pages)
- return 0;
+ goto hwmon_register;
MCDI_SET_DWORD(inbuf, SENSOR_INFO_EXT_IN_PAGE,
page);
@@ -453,28 +438,22 @@ int efx_mcdi_mon_probe(struct efx_nic *efx)
if (min1 != max1) {
snprintf(name, sizeof(name), "%s%u_input",
hwmon_prefix, hwmon_index);
- rc = efx_mcdi_mon_add_attr(
+ efx_mcdi_mon_add_attr(
efx, name, efx_mcdi_mon_show_value, i, type, 0);
- if (rc)
- goto fail;
if (hwmon_type != EFX_HWMON_POWER) {
snprintf(name, sizeof(name), "%s%u_min",
hwmon_prefix, hwmon_index);
- rc = efx_mcdi_mon_add_attr(
+ efx_mcdi_mon_add_attr(
efx, name, efx_mcdi_mon_show_limit,
i, type, min1);
- if (rc)
- goto fail;
}
snprintf(name, sizeof(name), "%s%u_max",
hwmon_prefix, hwmon_index);
- rc = efx_mcdi_mon_add_attr(
+ efx_mcdi_mon_add_attr(
efx, name, efx_mcdi_mon_show_limit,
i, type, max1);
- if (rc)
- goto fail;
if (min2 != max2) {
/* Assume max2 is critical value.
@@ -482,32 +461,38 @@ int efx_mcdi_mon_probe(struct efx_nic *efx)
*/
snprintf(name, sizeof(name), "%s%u_crit",
hwmon_prefix, hwmon_index);
- rc = efx_mcdi_mon_add_attr(
+ efx_mcdi_mon_add_attr(
efx, name, efx_mcdi_mon_show_limit,
i, type, max2);
- if (rc)
- goto fail;
}
}
snprintf(name, sizeof(name), "%s%u_alarm",
hwmon_prefix, hwmon_index);
- rc = efx_mcdi_mon_add_attr(
+ efx_mcdi_mon_add_attr(
efx, name, efx_mcdi_mon_show_alarm, i, type, 0);
- if (rc)
- goto fail;
if (type < ARRAY_SIZE(efx_mcdi_sensor_type) &&
efx_mcdi_sensor_type[type].label) {
snprintf(name, sizeof(name), "%s%u_label",
hwmon_prefix, hwmon_index);
- rc = efx_mcdi_mon_add_attr(
+ efx_mcdi_mon_add_attr(
efx, name, efx_mcdi_mon_show_label, i, type, 0);
- if (rc)
- goto fail;
}
}
+hwmon_register:
+ hwmon->groups[0] = &hwmon->group;
+ hwmon->device = hwmon_device_register_with_groups(&efx->pci_dev->dev,
+ KBUILD_MODNAME, NULL,
+ hwmon->groups);
+ if (IS_ERR(hwmon->device)) {
+ rc = PTR_ERR(hwmon->device);
+ goto fail;
+ }
+
+ return 0;
+
fail:
efx_mcdi_mon_remove(efx);
return rc;
@@ -516,14 +501,11 @@ fail:
void efx_mcdi_mon_remove(struct efx_nic *efx)
{
struct efx_mcdi_mon *hwmon = efx_mcdi_mon(efx);
- unsigned int i;
- for (i = 0; i < hwmon->n_attrs; i++)
- device_remove_file(&efx->pci_dev->dev,
- &hwmon->attrs[i].dev_attr);
- kfree(hwmon->attrs);
if (hwmon->device)
hwmon_device_unregister(hwmon->device);
+ kfree(hwmon->attrs);
+ kfree(hwmon->group.attrs);
efx_nic_free_buffer(efx, &hwmon->dma_buf);
}
--
1.7.9.7
^ permalink raw reply related
* Re: [PATCH] sfc: Convert to use hwmon_device_register_with_groups
From: Guenter Roeck @ 2013-11-27 3:34 UTC (permalink / raw)
To: netdev; +Cc: linux-net-drivers, lm-sensors, Guenter Roeck
In-Reply-To: <1385523037-3774-1-git-send-email-linux@roeck-us.net>
On 11/26/2013 07:30 PM, Guenter Roeck wrote:
> Simplify the code. Avoid race conditions caused by attributes
> being created after hwmon device registration. Implicitly
> (through hwmon API) add mandatory 'name' sysfs attribute.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> ---
> Compile tested only.
>
Sorry for the noise if you see this patch multiple times. My send script tried to annoy me.
Guenter
^ permalink raw reply
* [PATCH] net: 8139cp: fix a BUG_ON triggered by wrong bytes_compl
From: Yang Yingliang @ 2013-11-27 4:07 UTC (permalink / raw)
To: netdev, davem; +Cc: dwmw2, dave.taht
Using iperf to send packets(GSO mode is on), a bug is triggered:
[ 212.672781] kernel BUG at lib/dynamic_queue_limits.c:26!
[ 212.673396] invalid opcode: 0000 [#1] SMP
[ 212.673882] Modules linked in: 8139cp(O) nls_utf8 edd fuse loop dm_mod ipv6 i2c_piix4 8139too i2c_core intel_agp joydev pcspkr hid_generic intel_gtt floppy sr_mod mii button sg cdrom ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore sd_mod usb_common crc_t10dif crct10dif_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata scsi_mod [last unloaded: 8139cp]
[ 212.676084] CPU: 0 PID: 4124 Comm: iperf Tainted: G O 3.12.0-0.7-default+ #16
[ 212.676084] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 212.676084] task: ffff8800d83966c0 ti: ffff8800db4c8000 task.ti: ffff8800db4c8000
[ 212.676084] RIP: 0010:[<ffffffff8122e23f>] [<ffffffff8122e23f>] dql_completed+0x17f/0x190
[ 212.676084] RSP: 0018:ffff880116e03e30 EFLAGS: 00010083
[ 212.676084] RAX: 00000000000005ea RBX: 0000000000000f7c RCX: 0000000000000002
[ 212.676084] RDX: ffff880111dd0dc0 RSI: 0000000000000bd4 RDI: ffff8800db6ffcc0
[ 212.676084] RBP: ffff880116e03e48 R08: 0000000000000992 R09: 0000000000000000
[ 212.676084] R10: ffffffff8181e400 R11: 0000000000000004 R12: 000000000000000f
[ 212.676084] R13: ffff8800d94ec840 R14: ffff8800db440c80 R15: 000000000000000e
[ 212.676084] FS: 00007f6685a3c700(0000) GS:ffff880116e00000(0000) knlGS:0000000000000000
[ 212.676084] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 212.676084] CR2: 00007f6685ad6460 CR3: 00000000db714000 CR4: 00000000000006f0
[ 212.676084] Stack:
[ 212.676084] ffff8800db6ffc00 000000000000000f ffff8800d94ec840 ffff880116e03eb8
[ 212.676084] ffffffffa041509f ffff880116e03e88 0000000f16e03e88 ffff8800d94ec000
[ 212.676084] 00000bd400059858 000000050000000f ffffffff81094c36 ffff880116e03eb8
[ 212.676084] Call Trace:
[ 212.676084] <IRQ>
[ 212.676084] [<ffffffffa041509f>] cp_interrupt+0x4ef/0x590 [8139cp]
[ 212.676084] [<ffffffff81094c36>] ? ktime_get+0x56/0xd0
[ 212.676084] [<ffffffff8108cf73>] handle_irq_event_percpu+0x53/0x170
[ 212.676084] [<ffffffff8108d0cc>] handle_irq_event+0x3c/0x60
[ 212.676084] [<ffffffff8108fdb5>] handle_fasteoi_irq+0x55/0xf0
[ 212.676084] [<ffffffff810045df>] handle_irq+0x1f/0x30
[ 212.676084] [<ffffffff81003c8b>] do_IRQ+0x5b/0xe0
[ 212.676084] [<ffffffff8142beaa>] common_interrupt+0x6a/0x6a
[ 212.676084] <EOI>
[ 212.676084] [<ffffffffa0416a21>] ? cp_start_xmit+0x621/0x97c [8139cp]
[ 212.676084] [<ffffffffa0416a09>] ? cp_start_xmit+0x609/0x97c [8139cp]
[ 212.676084] [<ffffffff81378ed9>] dev_hard_start_xmit+0x2c9/0x550
[ 212.676084] [<ffffffff813960a9>] sch_direct_xmit+0x179/0x1d0
[ 212.676084] [<ffffffff813793f3>] dev_queue_xmit+0x293/0x440
[ 212.676084] [<ffffffff813b0e46>] ip_finish_output+0x236/0x450
[ 212.676084] [<ffffffff810e59e7>] ? __alloc_pages_nodemask+0x187/0xb10
[ 212.676084] [<ffffffff813b10e8>] ip_output+0x88/0x90
[ 212.676084] [<ffffffff813afa64>] ip_local_out+0x24/0x30
[ 212.676084] [<ffffffff813aff0d>] ip_queue_xmit+0x14d/0x3e0
[ 212.676084] [<ffffffff813c6fd1>] tcp_transmit_skb+0x501/0x840
[ 212.676084] [<ffffffff813c8323>] tcp_write_xmit+0x1e3/0xb20
[ 212.676084] [<ffffffff81363237>] ? skb_page_frag_refill+0x87/0xd0
[ 212.676084] [<ffffffff813c8c8b>] tcp_push_one+0x2b/0x40
[ 212.676084] [<ffffffff813bb7e6>] tcp_sendmsg+0x926/0xc90
[ 212.676084] [<ffffffff813e1d21>] inet_sendmsg+0x61/0xc0
[ 212.676084] [<ffffffff8135e861>] sock_aio_write+0x101/0x120
[ 212.676084] [<ffffffff81107cf1>] ? vma_adjust+0x2e1/0x5d0
[ 212.676084] [<ffffffff812163e0>] ? timerqueue_add+0x60/0xb0
[ 212.676084] [<ffffffff81130b60>] do_sync_write+0x60/0x90
[ 212.676084] [<ffffffff81130d44>] ? rw_verify_area+0x54/0xf0
[ 212.676084] [<ffffffff81130f66>] vfs_write+0x186/0x190
[ 212.676084] [<ffffffff811317fd>] SyS_write+0x5d/0xa0
[ 212.676084] [<ffffffff814321e2>] system_call_fastpath+0x16/0x1b
[ 212.676084] Code: ca 41 89 dc 41 29 cc 45 31 db 29 c2 41 89 c5 89 d0 45 29 c5 f7 d0 c1 e8 1f e9 43 ff ff ff 66 0f 1f 44 00 00 31 c0 e9 7b ff ff ff <0f> 0b eb fe 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 c7 47 40 00
[ 212.676084] RIP [<ffffffff8122e23f>] dql_completed+0x17f/0x190
------------[ cut here ]------------
When a skb has frags, bytes_compl plus skb->len nr_frags times in cp_tx().
It's not the correct value(actually, it should plus skb->len once) and it
will trigger the BUG_ON(bytes_compl > num_queued - dql->num_completed).Use
txd->opts1 which stores the real length of a frag in cp_start_xmit() to
calculate bytes_compl.
pkts_compl also has a wrong value, fix it too.
It's introduced by commit 871f0d4c("8139cp: enable bql").
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
---
drivers/net/ethernet/realtek/8139cp.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index f2a2128..3b837f0 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -664,7 +664,7 @@ static void cp_tx (struct cp_private *cp)
while (tx_tail != tx_head) {
struct cp_desc *txd = cp->tx_ring + tx_tail;
struct sk_buff *skb;
- u32 status;
+ u32 status, flags;
rmb();
status = le32_to_cpu(txd->opts1);
@@ -678,8 +678,10 @@ static void cp_tx (struct cp_private *cp)
le32_to_cpu(txd->opts1) & 0xffff,
PCI_DMA_TODEVICE);
- bytes_compl += skb->len;
- pkts_compl++;
+ flags = le32_to_cpu(txd->opts1);
+ bytes_compl += (flags & 0xffff);
+ if (flags & FirstFrag)
+ pkts_compl++;
if (status & LastFrag) {
if (status & (TxError | TxFIFOUnder)) {
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] net: 8139cp: fix a BUG_ON triggered by wrong bytes_compl
From: Eric Dumazet @ 2013-11-27 4:35 UTC (permalink / raw)
To: Yang Yingliang; +Cc: netdev, davem, dwmw2, dave.taht
In-Reply-To: <1385525270-56580-1-git-send-email-yangyingliang@huawei.com>
On Wed, 2013-11-27 at 12:07 +0800, Yang Yingliang wrote:
> Using iperf to send packets(GSO mode is on), a bug is triggered:
>
> When a skb has frags, bytes_compl plus skb->len nr_frags times in cp_tx().
> It's not the correct value(actually, it should plus skb->len once) and it
> will trigger the BUG_ON(bytes_compl > num_queued - dql->num_completed).Use
> txd->opts1 which stores the real length of a frag in cp_start_xmit() to
> calculate bytes_compl.
> pkts_compl also has a wrong value, fix it too.
>
> It's introduced by commit 871f0d4c("8139cp: enable bql").
>
> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
> ---
> drivers/net/ethernet/realtek/8139cp.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
> index f2a2128..3b837f0 100644
> --- a/drivers/net/ethernet/realtek/8139cp.c
> +++ b/drivers/net/ethernet/realtek/8139cp.c
> @@ -664,7 +664,7 @@ static void cp_tx (struct cp_private *cp)
> while (tx_tail != tx_head) {
> struct cp_desc *txd = cp->tx_ring + tx_tail;
> struct sk_buff *skb;
> - u32 status;
> + u32 status, flags;
>
> rmb();
> status = le32_to_cpu(txd->opts1);
> @@ -678,8 +678,10 @@ static void cp_tx (struct cp_private *cp)
> le32_to_cpu(txd->opts1) & 0xffff,
> PCI_DMA_TODEVICE);
>
> - bytes_compl += skb->len;
> - pkts_compl++;
> + flags = le32_to_cpu(txd->opts1);
Why not using 'status' here, its the same value.
> + bytes_compl += (flags & 0xffff);
> + if (flags & FirstFrag)
> + pkts_compl++;
>
> if (status & LastFrag) {
> if (status & (TxError | TxFIFOUnder)) {
I dont know, this seems a bit convoluted and dangerous, as
cp_start_xmit() did :
netdev_sent_queue(dev, skb->len);
So I would just use :
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index f2a2128165dd..4a935a966e28 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -678,8 +678,6 @@ static void cp_tx (struct cp_private *cp)
le32_to_cpu(txd->opts1) & 0xffff,
PCI_DMA_TODEVICE);
- bytes_compl += skb->len;
- pkts_compl++;
if (status & LastFrag) {
if (status & (TxError | TxFIFOUnder)) {
@@ -702,6 +700,8 @@ static void cp_tx (struct cp_private *cp)
netif_dbg(cp, tx_done, cp->dev,
"tx done, slot %d\n", tx_tail);
}
+ bytes_compl += skb->len;
+ pkts_compl++;
dev_kfree_skb_irq(skb);
}
^ permalink raw reply related
* [PATCH] net: mac80211: tx.c: be sure of 'sdata->vif.type' must be NL80211_IFTYPE_AP when be in NL80211_IFTYPE_AP case
From: Chen Gang @ 2013-11-27 4:53 UTC (permalink / raw)
To: John W. Linville
Cc: rkuo, linux-kernel@vger.kernel.org, David Miller, linux-wireless,
netdev
In-Reply-To: <5294255E.7040105@gmail.com>
In next-20131122 tree, if "sdata->vif.type != NL80211_IFTYPE_AP",
'chanctx_conf' will be not initialized, so need check it. Related
warning (with allmodconfig under hexagon):
CC [M] net/mac80211/tx.o
net/mac80211/tx.c: In function 'ieee80211_subif_start_xmit':
net/mac80211/tx.c:1827:27: warning: 'chanctx_conf' may be used uninitialized in this function [-Wuninitialized]
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
net/mac80211/tx.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index c558b24..f3245d6 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1814,8 +1814,9 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
break;
/* fall through */
case NL80211_IFTYPE_AP:
- if (sdata->vif.type == NL80211_IFTYPE_AP)
- chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
+ if (sdata->vif.type != NL80211_IFTYPE_AP)
+ goto fail_rcu;
+ chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf);
if (!chanctx_conf)
goto fail_rcu;
fc |= cpu_to_le16(IEEE80211_FCTL_FROMDS);
--
1.7.7.6
^ permalink raw reply related
* RE: [PATCH net] be2net: call napi_disable() for all event queues
From: Sathya Perla @ 2013-11-27 5:28 UTC (permalink / raw)
To: Ivan Vecera, netdev@vger.kernel.org
Cc: Subramanian Seetharaman, Ajit Khaparde
In-Reply-To: <1385484881-25715-1-git-send-email-ivecera@redhat.com>
> -----Original Message-----
> From: Ivan Vecera [mailto:ivecera@redhat.com]
>
> The recent be2net commit 6384a4d (adds a support for busy polling)
> introduces a regression that results in kernel crash. It incorrectly
> modified be_close() so napi_disable() is called only for the first queue.
> This breaks a correct pairing of napi_enable/_disable for the rest
> of event queues and causes a crash in subsequent be_open() call.
>
> Cc: Sathya Perla <sathya.perla@emulex.com>
> Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
> Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
> b/drivers/net/ethernet/emulex/benet/be_main.c
> index 78a0e85..0aec4d2 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -2663,8 +2663,8 @@ static int be_close(struct net_device *netdev)
> napi_disable(&eqo->napi);
> be_disable_busy_poll(eqo);
> }
> - adapter->flags &= ~BE_FLAGS_NAPI_ENABLED;
> }
> + adapter->flags &= ~BE_FLAGS_NAPI_ENABLED;
>
Ivan, Thanks for spotting this.
Your fix is correct but it'll be nice if the for-loop for napi_disable
is not even entered when FLAGS_NAPI_ENABLED is not set, as in:
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 603b662..40d2adb 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -2658,8 +2658,8 @@ static int be_close(struct net_device *netdev)
be_roce_dev_close(adapter);
- for_all_evt_queues(adapter, eqo, i) {
- if (adapter->flags & BE_FLAGS_NAPI_ENABLED) {
+ if (adapter->flags & BE_FLAGS_NAPI_ENABLED) {
+ for_all_evt_queues(adapter, eqo, i) {
napi_disable(&eqo->napi);
be_disable_busy_poll(eqo);
}
Could you also add the following line to your patch as it fixes a
regression caused by an older be2net commit:
Fixes: 6384a4d0dcf9 ("be2net: add support for ndo_busy_poll")
-Sathya
^ permalink raw reply related
* Re: [PATCH] net: 8139cp: fix a BUG_ON triggered by wrong bytes_compl
From: Yang Yingliang @ 2013-11-27 6:05 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem, dwmw2, dave.taht
In-Reply-To: <1385526903.5352.6.camel@edumazet-glaptop2.roam.corp.google.com>
On 2013/11/27 12:35, Eric Dumazet wrote:
> On Wed, 2013-11-27 at 12:07 +0800, Yang Yingliang wrote:
>> Using iperf to send packets(GSO mode is on), a bug is triggered:
>>
>
>> When a skb has frags, bytes_compl plus skb->len nr_frags times in cp_tx().
>> It's not the correct value(actually, it should plus skb->len once) and it
>> will trigger the BUG_ON(bytes_compl > num_queued - dql->num_completed).Use
>> txd->opts1 which stores the real length of a frag in cp_start_xmit() to
>> calculate bytes_compl.
>> pkts_compl also has a wrong value, fix it too.
>>
>> It's introduced by commit 871f0d4c("8139cp: enable bql").
>>
>> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
>> ---
>> drivers/net/ethernet/realtek/8139cp.c | 8 +++++---
>> 1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
>> index f2a2128..3b837f0 100644
>> --- a/drivers/net/ethernet/realtek/8139cp.c
>> +++ b/drivers/net/ethernet/realtek/8139cp.c
>> @@ -664,7 +664,7 @@ static void cp_tx (struct cp_private *cp)
>> while (tx_tail != tx_head) {
>> struct cp_desc *txd = cp->tx_ring + tx_tail;
>> struct sk_buff *skb;
>> - u32 status;
>> + u32 status, flags;
>>
>> rmb();
>> status = le32_to_cpu(txd->opts1);
>> @@ -678,8 +678,10 @@ static void cp_tx (struct cp_private *cp)
>> le32_to_cpu(txd->opts1) & 0xffff,
>> PCI_DMA_TODEVICE);
>>
>> - bytes_compl += skb->len;
>> - pkts_compl++;
>> + flags = le32_to_cpu(txd->opts1);
>
> Why not using 'status' here, its the same value.
>
>> + bytes_compl += (flags & 0xffff);
>> + if (flags & FirstFrag)
>> + pkts_compl++;
>>
>> if (status & LastFrag) {
>> if (status & (TxError | TxFIFOUnder)) {
>
> I dont know, this seems a bit convoluted and dangerous, as
> cp_start_xmit() did :
>
> netdev_sent_queue(dev, skb->len);
I tried to let pkts_compl equals sum of every frags' length.
Your way looks more simpler. I'll post an updated version of
the patch as you suggested.
Thanks!
>
> So I would just use :
>
> diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
> index f2a2128165dd..4a935a966e28 100644
> --- a/drivers/net/ethernet/realtek/8139cp.c
> +++ b/drivers/net/ethernet/realtek/8139cp.c
> @@ -678,8 +678,6 @@ static void cp_tx (struct cp_private *cp)
> le32_to_cpu(txd->opts1) & 0xffff,
> PCI_DMA_TODEVICE);
>
> - bytes_compl += skb->len;
> - pkts_compl++;
>
> if (status & LastFrag) {
> if (status & (TxError | TxFIFOUnder)) {
> @@ -702,6 +700,8 @@ static void cp_tx (struct cp_private *cp)
> netif_dbg(cp, tx_done, cp->dev,
> "tx done, slot %d\n", tx_tail);
> }
> + bytes_compl += skb->len;
> + pkts_compl++;
> dev_kfree_skb_irq(skb);
> }
>
>
>
>
> .
>
^ permalink raw reply
* [PATCH v2] net: 8139cp: fix a BUG_ON triggered by wrong bytes_compl
From: Yang Yingliang @ 2013-11-27 6:32 UTC (permalink / raw)
To: Eric Dumazet, netdev, davem; +Cc: dwmw2, dave.taht
In-Reply-To: <1385526903.5352.6.camel@edumazet-glaptop2.roam.corp.google.com>
From: Yang Yingliang <yangyingliang@huawei.com>
Using iperf to send packets(GSO mode is on), a bug is triggered:
[ 212.672781] kernel BUG at lib/dynamic_queue_limits.c:26!
[ 212.673396] invalid opcode: 0000 [#1] SMP
[ 212.673882] Modules linked in: 8139cp(O) nls_utf8 edd fuse loop dm_mod ipv6 i2c_piix4 8139too i2c_core intel_agp joydev pcspkr hid_generic intel_gtt floppy sr_mod mii button sg cdrom ext3 jbd mbcache usbhid hid uhci_hcd ehci_hcd usbcore sd_mod usb_common crc_t10dif crct10dif_common processor thermal_sys hwmon scsi_dh_emc scsi_dh_rdac scsi_dh_hp_sw scsi_dh ata_generic ata_piix libata scsi_mod [last unloaded: 8139cp]
[ 212.676084] CPU: 0 PID: 4124 Comm: iperf Tainted: G O 3.12.0-0.7-default+ #16
[ 212.676084] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 212.676084] task: ffff8800d83966c0 ti: ffff8800db4c8000 task.ti: ffff8800db4c8000
[ 212.676084] RIP: 0010:[<ffffffff8122e23f>] [<ffffffff8122e23f>] dql_completed+0x17f/0x190
[ 212.676084] RSP: 0018:ffff880116e03e30 EFLAGS: 00010083
[ 212.676084] RAX: 00000000000005ea RBX: 0000000000000f7c RCX: 0000000000000002
[ 212.676084] RDX: ffff880111dd0dc0 RSI: 0000000000000bd4 RDI: ffff8800db6ffcc0
[ 212.676084] RBP: ffff880116e03e48 R08: 0000000000000992 R09: 0000000000000000
[ 212.676084] R10: ffffffff8181e400 R11: 0000000000000004 R12: 000000000000000f
[ 212.676084] R13: ffff8800d94ec840 R14: ffff8800db440c80 R15: 000000000000000e
[ 212.676084] FS: 00007f6685a3c700(0000) GS:ffff880116e00000(0000) knlGS:0000000000000000
[ 212.676084] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 212.676084] CR2: 00007f6685ad6460 CR3: 00000000db714000 CR4: 00000000000006f0
[ 212.676084] Stack:
[ 212.676084] ffff8800db6ffc00 000000000000000f ffff8800d94ec840 ffff880116e03eb8
[ 212.676084] ffffffffa041509f ffff880116e03e88 0000000f16e03e88 ffff8800d94ec000
[ 212.676084] 00000bd400059858 000000050000000f ffffffff81094c36 ffff880116e03eb8
[ 212.676084] Call Trace:
[ 212.676084] <IRQ>
[ 212.676084] [<ffffffffa041509f>] cp_interrupt+0x4ef/0x590 [8139cp]
[ 212.676084] [<ffffffff81094c36>] ? ktime_get+0x56/0xd0
[ 212.676084] [<ffffffff8108cf73>] handle_irq_event_percpu+0x53/0x170
[ 212.676084] [<ffffffff8108d0cc>] handle_irq_event+0x3c/0x60
[ 212.676084] [<ffffffff8108fdb5>] handle_fasteoi_irq+0x55/0xf0
[ 212.676084] [<ffffffff810045df>] handle_irq+0x1f/0x30
[ 212.676084] [<ffffffff81003c8b>] do_IRQ+0x5b/0xe0
[ 212.676084] [<ffffffff8142beaa>] common_interrupt+0x6a/0x6a
[ 212.676084] <EOI>
[ 212.676084] [<ffffffffa0416a21>] ? cp_start_xmit+0x621/0x97c [8139cp]
[ 212.676084] [<ffffffffa0416a09>] ? cp_start_xmit+0x609/0x97c [8139cp]
[ 212.676084] [<ffffffff81378ed9>] dev_hard_start_xmit+0x2c9/0x550
[ 212.676084] [<ffffffff813960a9>] sch_direct_xmit+0x179/0x1d0
[ 212.676084] [<ffffffff813793f3>] dev_queue_xmit+0x293/0x440
[ 212.676084] [<ffffffff813b0e46>] ip_finish_output+0x236/0x450
[ 212.676084] [<ffffffff810e59e7>] ? __alloc_pages_nodemask+0x187/0xb10
[ 212.676084] [<ffffffff813b10e8>] ip_output+0x88/0x90
[ 212.676084] [<ffffffff813afa64>] ip_local_out+0x24/0x30
[ 212.676084] [<ffffffff813aff0d>] ip_queue_xmit+0x14d/0x3e0
[ 212.676084] [<ffffffff813c6fd1>] tcp_transmit_skb+0x501/0x840
[ 212.676084] [<ffffffff813c8323>] tcp_write_xmit+0x1e3/0xb20
[ 212.676084] [<ffffffff81363237>] ? skb_page_frag_refill+0x87/0xd0
[ 212.676084] [<ffffffff813c8c8b>] tcp_push_one+0x2b/0x40
[ 212.676084] [<ffffffff813bb7e6>] tcp_sendmsg+0x926/0xc90
[ 212.676084] [<ffffffff813e1d21>] inet_sendmsg+0x61/0xc0
[ 212.676084] [<ffffffff8135e861>] sock_aio_write+0x101/0x120
[ 212.676084] [<ffffffff81107cf1>] ? vma_adjust+0x2e1/0x5d0
[ 212.676084] [<ffffffff812163e0>] ? timerqueue_add+0x60/0xb0
[ 212.676084] [<ffffffff81130b60>] do_sync_write+0x60/0x90
[ 212.676084] [<ffffffff81130d44>] ? rw_verify_area+0x54/0xf0
[ 212.676084] [<ffffffff81130f66>] vfs_write+0x186/0x190
[ 212.676084] [<ffffffff811317fd>] SyS_write+0x5d/0xa0
[ 212.676084] [<ffffffff814321e2>] system_call_fastpath+0x16/0x1b
[ 212.676084] Code: ca 41 89 dc 41 29 cc 45 31 db 29 c2 41 89 c5 89 d0 45 29 c5 f7 d0 c1 e8 1f e9 43 ff ff ff 66 0f 1f 44 00 00 31 c0 e9 7b ff ff ff <0f> 0b eb fe 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 c7 47 40 00
[ 212.676084] RIP [<ffffffff8122e23f>] dql_completed+0x17f/0x190
------------[ cut here ]------------
When a skb has frags, bytes_compl plus skb->len nr_frags times in cp_tx().
It's not the correct value(actually, it should plus skb->len once) and it
will trigger the BUG_ON(bytes_compl > num_queued - dql->num_completed).
So only increase bytes_compl when finish sending all frags. pkts_compl also
has a wrong value, fix it too.
It's introduced by commit 871f0d4c("8139cp: enable bql").
Suggested-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
---
drivers/net/ethernet/realtek/8139cp.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/realtek/8139cp.c b/drivers/net/ethernet/realtek/8139cp.c
index f2a2128..737c1a8 100644
--- a/drivers/net/ethernet/realtek/8139cp.c
+++ b/drivers/net/ethernet/realtek/8139cp.c
@@ -678,9 +678,6 @@ static void cp_tx (struct cp_private *cp)
le32_to_cpu(txd->opts1) & 0xffff,
PCI_DMA_TODEVICE);
- bytes_compl += skb->len;
- pkts_compl++;
-
if (status & LastFrag) {
if (status & (TxError | TxFIFOUnder)) {
netif_dbg(cp, tx_err, cp->dev,
@@ -702,6 +699,8 @@ static void cp_tx (struct cp_private *cp)
netif_dbg(cp, tx_done, cp->dev,
"tx done, slot %d\n", tx_tail);
}
+ bytes_compl += skb->len;
+ pkts_compl++;
dev_kfree_skb_irq(skb);
}
-- 1.8.0
^ permalink raw reply related
* Re: [PATCH v2] mac80211: add assoc beacon timeout logic
From: Felipe Contreras @ 2013-11-27 6:44 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless Mailing List, netdev, John W. Linville,
David S. Miller
In-Reply-To: <CAMP44s1orLwg4v8UPM_1c-PspKQd5run_wAwHj-8oKmj2uqUgw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Nov 14, 2013 at 4:44 AM, Felipe Contreras
<felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Wed, Nov 13, 2013 at 12:30 PM, Johannes Berg
> <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
>> In any case, I'm not really comfortable connecting to an AP that we
>> never ever receive beacons from.
>
> Well, we are *already* doing that for every driver, except the ones
> that do IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC, which are few.
Since you didn't reply I'm going to arrive to the obvious conclusion;
we *already* connect to APs even if we don't receive any beacons, my
patch simply makes it consistent for the drivers that set
IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC.
Therefore all your reasons to not apply the patch have been dismissed.
--
Felipe Contreras
--
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
* [RESEND/PATCH v2] mac80211: add assoc beacon timeout logic
From: Felipe Contreras @ 2013-11-27 6:45 UTC (permalink / raw)
To: linux-wireless-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, John W. Linville, Johannes Berg,
David S. Miller, Felipe Contreras
We don't want to be waiting forever for a beacon that will never come,
just continue the association.
Signed-off-by: Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
This is exactly the same as the previous patch.
All the reasons given to not apply this patch have been dismissed. Power saving
is disabled as expected, regulatory/radar doesn't apply to the station mode, we
already connect if there are no APs for other drivers.
Therefore there's no reason standing to not apply the patch.
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/mlme.c | 32 ++++++++++++++++++++++++++------
2 files changed, 27 insertions(+), 6 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 611abfc..e1f858d 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -358,6 +358,7 @@ struct ieee80211_mgd_assoc_data {
const u8 *supp_rates;
unsigned long timeout;
+ unsigned long beacon_timeout;
int tries;
u16 capability;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 86e4ad5..68f76f7 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -38,6 +38,7 @@
#define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
#define IEEE80211_ASSOC_TIMEOUT_LONG (HZ / 2)
#define IEEE80211_ASSOC_TIMEOUT_SHORT (HZ / 10)
+#define IEEE80211_ASSOC_BEACON_TIMEOUT 2 * HZ
#define IEEE80211_ASSOC_MAX_TRIES 3
static int max_nullfunc_tries = 2;
@@ -3475,6 +3476,24 @@ void ieee80211_mgd_conn_tx_status(struct ieee80211_sub_if_data *sdata,
ieee80211_queue_work(&local->hw, &sdata->work);
}
+static int check_beacon(struct ieee80211_sub_if_data *sdata)
+{
+ struct ieee80211_if_managed *ifmgd = &sdata->u.mgd;
+ struct ieee80211_mgd_assoc_data *assoc_data = ifmgd->assoc_data;
+
+ if (!assoc_data->need_beacon || ifmgd->have_beacon)
+ return true;
+
+ if (time_after(jiffies, assoc_data->beacon_timeout)) {
+ sdata_info(sdata, "no beacon from %pM\n", assoc_data->bss->bssid);
+ return true;
+ }
+
+ assoc_data->timeout = TU_TO_EXP_TIME(assoc_data->bss->beacon_interval);
+ run_again(sdata, assoc_data->timeout);
+ return false;
+}
+
void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
{
struct ieee80211_local *local = sdata->local;
@@ -3533,12 +3552,12 @@ void ieee80211_sta_work(struct ieee80211_sub_if_data *sdata)
if (ifmgd->assoc_data && ifmgd->assoc_data->timeout_started &&
time_after(jiffies, ifmgd->assoc_data->timeout)) {
- if ((ifmgd->assoc_data->need_beacon && !ifmgd->have_beacon) ||
- ieee80211_do_assoc(sdata)) {
- struct cfg80211_bss *bss = ifmgd->assoc_data->bss;
^ permalink raw reply related
* Re: bridge not getting ip since 3.11.5 and 3.4.66
From: Mark Trompell @ 2013-11-27 6:46 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: Veaceslav Falico, Linux-Kernel, netdev, herbert
In-Reply-To: <5294BD63.7020905@gmail.com>
On Tue, Nov 26, 2013 at 4:25 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
> On 11/26/2013 08:27 AM, Mark Trompell wrote:
>> Answering my own mail again and even top posting, sorry, but makes
>> more sense to me in that case).
>> I reverted bridge related patches from 3.11.5 and it boils down to
>> commit 0e308361d7ca0bf8b23fd472b90aae0fb10a1c32
>> Author: Herbert Xu <herbert@gondor.apana.org.au>
>> Date: Thu Sep 12 17:12:05 2013 +1000
>>
>> bridge: Clamp forward_delay when enabling STP
>>
>> [ Upstream commit be4f154d5ef0ca147ab6bcd38857a774133f5450 ]
>>
>> At some point limits were added to forward_delay. However, the
>> limits are only enforced when STP is enabled. This created a
>> scenario where you could have a value outside the allowed range
>> while STP is disabled, which then stuck around even after STP
>> is enabled.
>>
>> This patch fixes this by clamping the value when we enable STP.
>>
>> I had to move the locking around a bit to ensure that there is
>> no window where someone could insert a value outside the range
>> while we're in the middle of enabling STP.
>>
>> Causing the issue for me. Reverting that patch and br0 comes up again
>> and gets an ip.
>
> yes, that patch introduced a bug where we always used the
> max_forward delay value.
>
> you have 2 options:
> 1) disable STP. Since you are just running VMs and you have a single
> physical connection on the bridge, you can safely disable STP since
> your system is a leaf node.
disabling stp indeed helps here, but ...
> 2) Get the latest stable kernel. The bug has been fixed there.
3.12.1 still doesn't work with stp enabled.
I guess you're talking about 4b6c7879d84ad06a2ac5b964808ed599187a188d
bridge: Correctly clamp MAX forward_delay when enabling STP
which should fix that?
> -vlad
Mark
>>
>> On Tue, Nov 12, 2013 at 11:57 AM, Mark Trompell <mark@foresightlinux.org> wrote:
>>> On Mon, Nov 11, 2013 at 1:52 PM, Mark Trompell <mark@foresightlinux.org> wrote:
>>>> On Mon, Nov 11, 2013 at 12:07 PM, Veaceslav Falico <veaceslav@falico.eu> wrote:
>>>>> On Mon, Nov 11, 2013 at 11:29 AM, Mark Trompell <mark@foresightlinux.org> wrote:
>>>>>> my bridge br0 doesn't get an ip from dhcp anymore after 3.11.5 and 3.4.66,
>>>>>> What information would be helpful and required to find out what's going wrong.
>>>>>
>>>>> CC netdev
>>>>>
>>>>> First thing would be to provide the network scheme. Do you use vlans?
>>>>> Which network
>>>>> cards/drivers are you using? Do you use some kind of virtualization?
>>>>> Is bonding involved?
>>>>>
>>>> Actually this is my desktop machine using kvm for a virtual machine
>>>> that uses eth0 which is connected to the bridge
>>>> which is used as interface for the host.
>>>>
>>>> $ ip addr
>>>> 2. eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast
>>>> master br0 qlen 1000
>>>> ...
>>>> 3. br0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc noqueue
>>>> ...
>>>>
>>>> Anything else?
>>>
>>> Okay more about my hardware and configuration:
>>> from lspci:
>>> 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network
>>> Connection (rev 04)
>>>
>>> /etc/sysconfig/network-scripts/ifcfg-br0
>>> DEVICE=br0
>>> ONBOOT=yes
>>> MACADDR=00:19:99:ac:b3:24
>>> TYPE=Bridge
>>> BOOTPROTO=dhcp
>>> STP=on
>>> NM_CONTROLLED=no
>>> DELAY=0
>>>
>>> /etc/sysconfig/network-scripts/ifcfg-eth0
>>> DEVICE=eth0
>>> HWADDR=00:19:99:cd:a5:e6
>>> #BOOTPROTO=dhcp
>>> ONBOOT=yes
>>> BRIDGE=br0
>>> TYPE=Ethernet
>>> NM_CONTROLLED=no
>>>
>>>
>>>> Greetings
>>>> Mark
>>
>>
>>
>
--
Mark Trompell
Foresight Linux Xfce Edition
Cause your desktop should be freaking cool
(and Xfce)
^ permalink raw reply
* [PATCH net v2] be2net: call napi_disable() for all event queues
From: Ivan Vecera @ 2013-11-27 7:59 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla, Subbu Seetharaman, Ajit Khaparde
The recent be2net commit 6384a4d (adds a support for busy polling)
introduces a regression that results in kernel crash. It incorrectly
modified be_close() so napi_disable() is called only for the first queue.
This breaks a correct pairing of napi_enable/_disable for the rest
of event queues and causes a crash in subsequent be_open() call.
v2: Applied suggestions from Sathya
Fixes: 6384a4d ("be2net: add support for ndo_busy_poll")
Cc: Sathya Perla <sathya.perla@emulex.com>
Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 78a0e85..fee64bf 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -2658,8 +2658,8 @@ static int be_close(struct net_device *netdev)
be_roce_dev_close(adapter);
- for_all_evt_queues(adapter, eqo, i) {
- if (adapter->flags & BE_FLAGS_NAPI_ENABLED) {
+ if (adapter->flags & BE_FLAGS_NAPI_ENABLED) {
+ for_all_evt_queues(adapter, eqo, i) {
napi_disable(&eqo->napi);
be_disable_busy_poll(eqo);
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH net] r8169: check ALDPS bit and disable it if enabled for the 8168g
From: David Chang @ 2013-11-27 7:48 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Francois Romieu, Hayes Wang, jlee
Windows driver will enable ALDPS function, but linux driver and firmware
do not have any configuration related to ALDPS function for 8168g.
So restart system to linux and remove the NIC cable, LAN enter ALDPS,
then LAN RX will be disabled.
This issue can be easily reproduced on dual boot windows and linux
system with RTL_GIGA_MAC_VER_40 chip.
Realtek said, ALDPS function can be disabled by configuring to PHY,
switch to page 0x0A43, reg0x10 bit2=0.
Signed-off-by: David Chang <dchang@suse.com>
---
drivers/net/ethernet/realtek/r8169.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 7993875..c737f0e 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -3465,6 +3465,11 @@ static void rtl8168g_1_hw_phy_config(struct rtl8169_private *tp)
rtl_writephy(tp, 0x14, 0x9065);
rtl_writephy(tp, 0x14, 0x1065);
+ /* Check ALDPS bit, disable it if enabled */
+ rtl_writephy(tp, 0x1f, 0x0a43);
+ if (rtl_readphy(tp, 0x10) & 0x0004)
+ rtl_w1w0_phy(tp, 0x10, 0x0000, 0x0004);
+
rtl_writephy(tp, 0x1f, 0x0000);
}
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH net] be2net: call napi_disable() for all event queues
From: Ivan Vecera @ 2013-11-27 8:00 UTC (permalink / raw)
To: Sathya Perla
Cc: netdev@vger.kernel.org, Subramanian Seetharaman, Ajit Khaparde
In-Reply-To: <f158e8ac-98d2-4be4-b801-20a18912d672@CMEXHTCAS1.ad.emulex.com>
On 11/27/2013 06:28 AM, Sathya Perla wrote:
>> -----Original Message-----
>> From: Ivan Vecera [mailto:ivecera@redhat.com]
>>
>> The recent be2net commit 6384a4d (adds a support for busy polling)
>> introduces a regression that results in kernel crash. It incorrectly
>> modified be_close() so napi_disable() is called only for the first queue.
>> This breaks a correct pairing of napi_enable/_disable for the rest
>> of event queues and causes a crash in subsequent be_open() call.
>>
>> Cc: Sathya Perla <sathya.perla@emulex.com>
>> Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
>> Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
>> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
>> ---
>> drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
>> b/drivers/net/ethernet/emulex/benet/be_main.c
>> index 78a0e85..0aec4d2 100644
>> --- a/drivers/net/ethernet/emulex/benet/be_main.c
>> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
>> @@ -2663,8 +2663,8 @@ static int be_close(struct net_device *netdev)
>> napi_disable(&eqo->napi);
>> be_disable_busy_poll(eqo);
>> }
>> - adapter->flags &= ~BE_FLAGS_NAPI_ENABLED;
>> }
>> + adapter->flags &= ~BE_FLAGS_NAPI_ENABLED;
>>
>
> Ivan, Thanks for spotting this.
> Your fix is correct but it'll be nice if the for-loop for napi_disable
> is not even entered when FLAGS_NAPI_ENABLED is not set, as in:
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
> index 603b662..40d2adb 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -2658,8 +2658,8 @@ static int be_close(struct net_device *netdev)
>
> be_roce_dev_close(adapter);
>
> - for_all_evt_queues(adapter, eqo, i) {
> - if (adapter->flags & BE_FLAGS_NAPI_ENABLED) {
> + if (adapter->flags & BE_FLAGS_NAPI_ENABLED) {
> + for_all_evt_queues(adapter, eqo, i) {
> napi_disable(&eqo->napi);
> be_disable_busy_poll(eqo);
> }
>
> Could you also add the following line to your patch as it fixes a
> regression caused by an older be2net commit:
> Fixes: 6384a4d0dcf9 ("be2net: add support for ndo_busy_poll")
>
Sure, I'm sending v2.
Ivan
^ permalink raw reply
* Re: Kernel Panic in IPv6 vxlan
From: Fan Du @ 2013-11-27 8:25 UTC (permalink / raw)
To: Ryan Whelan; +Cc: netdev, amwang
In-Reply-To: <CAM3m09T2tuFCMjzdJq7AVBDnPeK0kVKt51JXsE954cHO6u_u2A@mail.gmail.com>
Hallo,
On 2013年11月27日 05:41, Ryan Whelan wrote:
> I'm not sure if this is the right place to report this- please correct
> me if I'm mistaken.
>
> When creating a vxlan interface with an IPv6 multicast group but not
> specifying an underlying device, the kernel panics when the vxlan
> interface is brought up. This doesn't happen with an IPv4 multicast
> group. Linux 3.12.1 x86_64
>
> `ip link add vxlan0 type vxlan id 42 group ff0e::110`
You forgot to attach vxlan0 to a physical netdev ;) try:
ip link add vxlan0 type vxlan id 42 group ff0e::110 dev ethX
This will work anyway.
--
浮沉随浪只记今朝笑
--fan fan
^ permalink raw reply
* [PATCH] {vxlan,inet6} Mark vxlan_dev flags with VXLAN_F_IPV6
From: Fan Du @ 2013-11-27 8:46 UTC (permalink / raw)
To: Ryan Whelan; +Cc: netdev, amwang
In-Reply-To: <CAM3m09T2tuFCMjzdJq7AVBDnPeK0kVKt51JXsE954cHO6u_u2A@mail.gmail.com>
On 2013年11月27日 05:41, Ryan Whelan wrote:
> I'm not sure if this is the right place to report this- please correct
> me if I'm mistaken.
>
> When creating a vxlan interface with an IPv6 multicast group but not
> specifying an underlying device, the kernel panics when the vxlan
> interface is brought up. This doesn't happen with an IPv4 multicast
> group. Linux 3.12.1 x86_64
>
> `ip link add vxlan0 type vxlan id 42 group ff0e::110`
> `ip link set vxlan0 up`
>
> [ 192.037669] BUG: unable to handle kernel NULL pointer dereference
> at 0000000000000080
ok, without attaching physical netdev to vxlan is not a big crime to
crash kernel safely every time. Could you please test this patch?
From ae2121bb0e0becbec340bcf199ad0250402ea4c3 Mon Sep 17 00:00:00 2001
From: Fan Du <fan.du@windriver.com>
Date: Wed, 27 Nov 2013 16:31:49 +0800
Subject: [PATCH] {vxlan,inet6} Mark vxlan_dev flags with VXLAN_F_IPV6
properly
Even if user don't supply the physical netdev to attach vxlan dev
to, and at the same time user want to vxlan sit top of IPv6, mark
vxlan_dev flags with VXLAN_F_IPV6 to create IPv6 based socket,
otherwise kernel spit below messages, and host totally stuck!
[ 62.656266] BUG: unable to handle kernel NULL pointer dereference[ 62.656320] ip (3008) used greatest stack depth: 3912 bytes left
at 0000000000000046
[ 62.656423] IP: [<ffffffff816d822d>] ip6_route_output+0xbd/0xe0
[ 62.656525] PGD 2c966067 PUD 2c9a2067 PMD 0
[ 62.656674] Oops: 0000 [#1] SMP
[ 62.656781] Modules linked in: vxlan netconsole deflate zlib_deflate af_key
[ 62.657083] CPU: 1 PID: 2128 Comm: whoopsie Not tainted 3.12.0+ #182
[ 62.657083] Hardware name: innotek GmbH VirtualBox, BIOS VirtualBox 12/01/2006
[ 62.657083] task: ffff88002e2335d0 ti: ffff88002c94c000 task.ti: ffff88002c94c000
[ 62.657083] RIP: 0010:[<ffffffff816d822d>] [<ffffffff816d822d>] ip6_route_output+0xbd/0xe0
[ 62.657083] RSP: 0000:ffff88002fd038f8 EFLAGS: 00210296
[ 62.657083] RAX: 0000000000000000 RBX: ffff88002fd039e0 RCX: 0000000000000000
[ 62.657083] RDX: ffff88002fd0eb68 RSI: ffff88002fd0d278 RDI: ffff88002fd0d278
[ 62.657083] RBP: ffff88002fd03918 R08: 0000000002000000 R09: 0000000000000000
[ 62.657083] R10: 00000000000001ff R11: 0000000000000000 R12: 0000000000000001
[ 62.657083] R13: ffff88002d96b480 R14: ffffffff81c8e2c0 R15: 0000000000000001
[ 62.657083] FS: 0000000000000000(0000) GS:ffff88002fd00000(0063) knlGS:00000000f693b740
[ 62.657083] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
[ 62.657083] CR2: 0000000000000046 CR3: 000000002c9d2000 CR4: 00000000000006e0
[ 62.657083] Stack:
[ 62.657083] ffff88002fd03a40 ffffffff81c8e2c0 ffff88002fd039e0 ffff88002d96b480
[ 62.657083] ffff88002fd03958 ffffffff816cac8b ffff880019277cc0 ffff8800192b5d00
[ 62.657083] ffff88002d5bc000 ffff880019277cc0 0000000000001821 0000000000000001
[ 62.657083] Call Trace:
[ 62.657083] <IRQ>
[ 62.657083] [<ffffffff816cac8b>] ip6_dst_lookup_tail+0xdb/0xf0
[ 62.657083] [<ffffffff816caea0>] ip6_dst_lookup+0x10/0x20
[ 62.657083] [<ffffffffa0020c13>] vxlan_xmit_one+0x193/0x9c0 [vxlan]
[ 62.657083] [<ffffffff8137b3b7>] ? account+0xc7/0x1f0
[ 62.657083] [<ffffffffa0021513>] vxlan_xmit+0xd3/0x400 [vxlan]
[ 62.657083] [<ffffffff8161390d>] dev_hard_start_xmit+0x49d/0x5e0
[ 62.657083] [<ffffffff81613d29>] dev_queue_xmit+0x2d9/0x480
[ 62.657083] [<ffffffff817cb854>] ? _raw_write_unlock_bh+0x14/0x20
[ 62.657083] [<ffffffff81630565>] ? eth_header+0x35/0xe0
[ 62.657083] [<ffffffff8161bc5e>] neigh_resolve_output+0x11e/0x1e0
[ 62.657083] [<ffffffff816ce0e0>] ? ip6_fragment+0xad0/0xad0
[ 62.657083] [<ffffffff816cb465>] ip6_finish_output2+0x2f5/0x470
[ 62.657083] [<ffffffff816ce166>] ip6_finish_output+0x86/0xc0
[ 62.657083] [<ffffffff816ce218>] ip6_output+0x78/0xb0
[ 62.657083] [<ffffffff816eadd6>] mld_sendpack+0x256/0x2a0
[ 62.657083] [<ffffffff816ebd8c>] mld_ifc_timer_expire+0x17c/0x290
[ 62.657083] [<ffffffff816ebc10>] ? igmp6_timer_handler+0x80/0x80
[ 62.657083] [<ffffffff816ebc10>] ? igmp6_timer_handler+0x80/0x80
[ 62.657083] [<ffffffff81051065>] call_timer_fn+0x45/0x150
[ 62.657083] [<ffffffff816ebc10>] ? igmp6_timer_handler+0x80/0x80
[ 62.657083] [<ffffffff81052353>] run_timer_softirq+0x1f3/0x2a0
[ 62.657083] [<ffffffff8102dfd8>] ? lapic_next_event+0x18/0x20
[ 62.657083] [<ffffffff8109e36f>] ? clockevents_program_event+0x6f/0x110
[ 62.657083] [<ffffffff8104a2f6>] __do_softirq+0xd6/0x2b0
[ 62.657083] [<ffffffff8104a75e>] irq_exit+0x7e/0xa0
[ 62.657083] [<ffffffff8102ea15>] smp_apic_timer_interrupt+0x45/0x60
[ 62.657083] [<ffffffff817d3eca>] apic_timer_interrupt+0x6a/0x70
[ 62.657083] <EOI>
[ 62.657083] [<ffffffff817d4a35>] ? sysenter_dispatch+0x7/0x1a
[ 62.657083] Code: 4d 8b 85 a8 02 00 00 4c 89 e9 ba 03 04 00 00 48 c7 c6 c0 be 8d 81 48 c7 c7 48 35 a3 81 31 c0 e8 db 68 0e 00 49 8b 85 a8 02 00 00 <0f> b6 40 46 c0 e8 05 0f b6 c0 c1 e0 03 41 09 c4 e9 77 ff ff ff
[ 62.657083] RIP [<ffffffff816d822d>] ip6_route_output+0xbd/0xe0
[ 62.657083] RSP <ffff88002fd038f8>
[ 62.657083] CR2: 0000000000000046
[ 62.657083] ---[ end trace ba8a9583d7cd1934 ]---
[ 62.657083] Kernel panic - not syncing: Fatal exception in interrupt
Signed-off-by: Fan Du <fan.du@windriver.com>
---
drivers/net/vxlan.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index 78df8f3..8e7ceb7 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2432,7 +2432,8 @@ static int vxlan_newlink(struct net *net, struct net_device *dev,
/* update header length based on lower device */
dev->hard_header_len = lowerdev->hard_header_len +
(use_ipv6 ? VXLAN6_HEADROOM : VXLAN_HEADROOM);
- }
+ } else if (use_ipv6)
+ vxlan->flags |= VXLAN_F_IPV6;
if (data[IFLA_VXLAN_TOS])
vxlan->tos = nla_get_u8(data[IFLA_VXLAN_TOS]);
--
1.7.9.5
--
浮沉随浪只记今朝笑
--fan fan
^ permalink raw reply related
* RE: [PATCH net v2] be2net: call napi_disable() for all event queues
From: Sathya Perla @ 2013-11-27 10:08 UTC (permalink / raw)
To: Ivan Vecera, netdev@vger.kernel.org
Cc: Subramanian Seetharaman, Ajit Khaparde
In-Reply-To: <1385539172-4744-1-git-send-email-ivecera@redhat.com>
> -----Original Message-----
> From: Ivan Vecera [mailto:ivecera@redhat.com]
>
> The recent be2net commit 6384a4d (adds a support for busy polling)
> introduces a regression that results in kernel crash. It incorrectly
> modified be_close() so napi_disable() is called only for the first queue.
> This breaks a correct pairing of napi_enable/_disable for the rest
> of event queues and causes a crash in subsequent be_open() call.
>
> v2: Applied suggestions from Sathya
>
> Fixes: 6384a4d ("be2net: add support for ndo_busy_poll")
> Cc: Sathya Perla <sathya.perla@emulex.com>
> Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
> Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Acked-by: Sathya Perla <sathya.perla@emulex.com>
> ---
> drivers/net/ethernet/emulex/benet/be_main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/emulex/benet/be_main.c
> b/drivers/net/ethernet/emulex/benet/be_main.c
> index 78a0e85..fee64bf 100644
> --- a/drivers/net/ethernet/emulex/benet/be_main.c
> +++ b/drivers/net/ethernet/emulex/benet/be_main.c
> @@ -2658,8 +2658,8 @@ static int be_close(struct net_device *netdev)
>
> be_roce_dev_close(adapter);
>
> - for_all_evt_queues(adapter, eqo, i) {
> - if (adapter->flags & BE_FLAGS_NAPI_ENABLED) {
> + if (adapter->flags & BE_FLAGS_NAPI_ENABLED) {
> + for_all_evt_queues(adapter, eqo, i) {
> napi_disable(&eqo->napi);
> be_disable_busy_poll(eqo);
> }
> --
> 1.8.3.2
^ permalink raw reply
* Re: netfilter: active obj WARN when cleaning up
From: Thomas Gleixner @ 2013-11-27 10:45 UTC (permalink / raw)
To: Pablo Neira Ayuso
Cc: Sasha Levin, Patrick McHardy, kadlec, David S. Miller,
netfilter-devel, coreteam, netdev, LKML, linux-mm, Andrew Morton,
Christoph Lameter, Greg KH, Russell King
In-Reply-To: <20131126230709.GA10948@localhost>
On Wed, 27 Nov 2013, Pablo Neira Ayuso wrote:
> On Tue, Nov 26, 2013 at 02:11:57PM -0500, Sasha Levin wrote:
> > Ping? I still see this warning.
>
> Did your test include patch 0c3c6c00c6?
And how is that patch supposed to help?
> > >[ 418.312449] WARNING: CPU: 6 PID: 4178 at lib/debugobjects.c:260 debug_print_object+0x8d/0xb0()
> > >[ 418.313243] ODEBUG: free active (active state 0) object type: timer_list hint:
> > >delayed_work_timer_fn+0x0/0x20
> > >[ 418.321101] [<ffffffff812874d7>] kmem_cache_free+0x197/0x340
> > >[ 418.321101] [<ffffffff81249e76>] kmem_cache_destroy+0x86/0xe0
> > >[ 418.321101] [<ffffffff83d5d681>] nf_conntrack_cleanup_net_list+0x131/0x170
The debug code detects an active timer, which itself is part of a
delayed work struct. The call comes from kmem_cache_destroy().
kmem_cache_free(kmem_cache, s);
So debug object says: s contains an active timer. s is the kmem_cache
which is destroyed from nf_conntrack_cleanup_net_list.
Now struct kmem_cache has in case of SLUB:
struct kobject kobj; /* For sysfs */
and struct kobject has:
#ifdef CONFIG_DEBUG_KOBJECT_RELEASE
struct delayed_work release;
#endif
So this is the thing you want to look at:
commit c817a67ec (kobject: delayed kobject release: help find buggy
drivers) added that delayed work thing.
I fear that does not work for kobjects which are embedded into
something else.
Handing off to rmk, mm and kobject folks.
Thanks,
tglx
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: netfilter: active obj WARN when cleaning up
From: Russell King - ARM Linux @ 2013-11-27 11:39 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Pablo Neira Ayuso, Sasha Levin, Patrick McHardy, kadlec,
David S. Miller, netfilter-devel, coreteam, netdev, LKML,
linux-mm, Andrew Morton, Christoph Lameter, Greg KH
In-Reply-To: <alpine.DEB.2.02.1311271106090.30673@ionos.tec.linutronix.de>
On Wed, Nov 27, 2013 at 11:45:17AM +0100, Thomas Gleixner wrote:
> On Wed, 27 Nov 2013, Pablo Neira Ayuso wrote:
>
> > On Tue, Nov 26, 2013 at 02:11:57PM -0500, Sasha Levin wrote:
> > > Ping? I still see this warning.
> >
> > Did your test include patch 0c3c6c00c6?
>
> And how is that patch supposed to help?
>
> > > >[ 418.312449] WARNING: CPU: 6 PID: 4178 at lib/debugobjects.c:260 debug_print_object+0x8d/0xb0()
> > > >[ 418.313243] ODEBUG: free active (active state 0) object type: timer_list hint:
> > > >delayed_work_timer_fn+0x0/0x20
>
> > > >[ 418.321101] [<ffffffff812874d7>] kmem_cache_free+0x197/0x340
> > > >[ 418.321101] [<ffffffff81249e76>] kmem_cache_destroy+0x86/0xe0
> > > >[ 418.321101] [<ffffffff83d5d681>] nf_conntrack_cleanup_net_list+0x131/0x170
>
> The debug code detects an active timer, which itself is part of a
> delayed work struct. The call comes from kmem_cache_destroy().
>
> kmem_cache_free(kmem_cache, s);
>
> So debug object says: s contains an active timer. s is the kmem_cache
> which is destroyed from nf_conntrack_cleanup_net_list.
>
> Now struct kmem_cache has in case of SLUB:
>
> struct kobject kobj; /* For sysfs */
>
> and struct kobject has:
>
> #ifdef CONFIG_DEBUG_KOBJECT_RELEASE
> struct delayed_work release;
> #endif
>
> So this is the thing you want to look at:
>
> commit c817a67ec (kobject: delayed kobject release: help find buggy
> drivers) added that delayed work thing.
>
> I fear that does not work for kobjects which are embedded into
> something else.
No, kobjects embedded into something else have their lifetime determined
by the embedded kobject. That's rule #1 of kobjects - or rather reference
counted objects.
The point at which the kobject gets destructed is when the release function
is called. If it is destructed before that time, that's a violation of
the reference counted nature of kobjects, and that's what the delay on
releasing is designed to catch.
It's designed to catch code which does this exact path:
put(obj)
free(obj)
rather than code which does it the right way:
put(obj)
-> refcount becomes 0
-> release function gets called
->free(obj)
The former is unsafe because obj may have other references.
^ 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