* [PATCH 2/3] Bluetooth: Convert debug files to actually use debugfs instead of sysfs
From: Marcel Holtmann @ 2010-03-21 5:41 UTC (permalink / raw)
To: David Miller, Linus Torvalds; +Cc: netdev
In-Reply-To: <cover.1269149354.git.marcel@holtmann.org>
Some of the debug files ended up wrongly in sysfs, because at that point
of time, debugfs didn't exist. Convert these files to use debugfs and
also seq_file. This patch converts all of these files at once and then
removes the exported symbol for the Bluetooth sysfs class.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/bluetooth.h | 2 +-
net/bluetooth/hci_sysfs.c | 3 +-
net/bluetooth/l2cap.c | 51 +++++++++++++++++++++---------------
net/bluetooth/rfcomm/core.c | 52 ++++++++++++++++++++----------------
net/bluetooth/rfcomm/sock.c | 47 +++++++++++++++++++--------------
net/bluetooth/sco.c | 47 ++++++++++++++++++---------------
6 files changed, 114 insertions(+), 88 deletions(-)
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index 04a6908..ff77e8f 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -176,6 +176,6 @@ extern void hci_sock_cleanup(void);
extern int bt_sysfs_init(void);
extern void bt_sysfs_cleanup(void);
-extern struct class *bt_class;
+extern struct dentry *bt_debugfs;
#endif /* __BLUETOOTH_H */
diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index cafb55b..05fd125 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -8,8 +8,7 @@
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
-struct class *bt_class = NULL;
-EXPORT_SYMBOL_GPL(bt_class);
+static struct class *bt_class;
struct dentry *bt_debugfs = NULL;
EXPORT_SYMBOL_GPL(bt_debugfs);
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 2755182..43e17f7 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -40,6 +40,8 @@
#include <linux/skbuff.h>
#include <linux/list.h>
#include <linux/device.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
#include <linux/uaccess.h>
#include <linux/crc16.h>
#include <net/sock.h>
@@ -3937,39 +3939,42 @@ drop:
return 0;
}
-static ssize_t l2cap_sysfs_show(struct class *dev,
- struct class_attribute *attr,
- char *buf)
+static int l2cap_debugfs_show(struct seq_file *f, void *p)
{
struct sock *sk;
struct hlist_node *node;
- char *str = buf;
- int size = PAGE_SIZE;
read_lock_bh(&l2cap_sk_list.lock);
sk_for_each(sk, node, &l2cap_sk_list.head) {
struct l2cap_pinfo *pi = l2cap_pi(sk);
- int len;
-
- len = snprintf(str, size, "%s %s %d %d 0x%4.4x 0x%4.4x %d %d %d\n",
- batostr(&bt_sk(sk)->src), batostr(&bt_sk(sk)->dst),
- sk->sk_state, __le16_to_cpu(pi->psm), pi->scid,
- pi->dcid, pi->imtu, pi->omtu, pi->sec_level);
-
- size -= len;
- if (size <= 0)
- break;
- str += len;
+ seq_printf(f, "%s %s %d %d 0x%4.4x 0x%4.4x %d %d %d\n",
+ batostr(&bt_sk(sk)->src),
+ batostr(&bt_sk(sk)->dst),
+ sk->sk_state, __le16_to_cpu(pi->psm),
+ pi->scid, pi->dcid,
+ pi->imtu, pi->omtu, pi->sec_level);
}
read_unlock_bh(&l2cap_sk_list.lock);
- return str - buf;
+ return 0;
}
-static CLASS_ATTR(l2cap, S_IRUGO, l2cap_sysfs_show, NULL);
+static int l2cap_debugfs_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, l2cap_debugfs_show, inode->i_private);
+}
+
+static const struct file_operations l2cap_debugfs_fops = {
+ .open = l2cap_debugfs_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static struct dentry *l2cap_debugfs;
static const struct proto_ops l2cap_sock_ops = {
.family = PF_BLUETOOTH,
@@ -4029,8 +4034,12 @@ static int __init l2cap_init(void)
goto error;
}
- if (class_create_file(bt_class, &class_attr_l2cap) < 0)
- BT_ERR("Failed to create L2CAP info file");
+ if (bt_debugfs) {
+ l2cap_debugfs = debugfs_create_file("l2cap", 0444,
+ bt_debugfs, NULL, &l2cap_debugfs_fops);
+ if (!l2cap_debugfs)
+ BT_ERR("Failed to create L2CAP debug file");
+ }
BT_INFO("L2CAP ver %s", VERSION);
BT_INFO("L2CAP socket layer initialized");
@@ -4044,7 +4053,7 @@ error:
static void __exit l2cap_exit(void)
{
- class_remove_file(bt_class, &class_attr_l2cap);
+ debugfs_remove(l2cap_debugfs);
if (bt_sock_unregister(BTPROTO_L2CAP) < 0)
BT_ERR("L2CAP socket unregistration failed");
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index cf16407..13f114e 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -33,6 +33,8 @@
#include <linux/init.h>
#include <linux/wait.h>
#include <linux/device.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
#include <linux/net.h>
#include <linux/mutex.h>
#include <linux/kthread.h>
@@ -2098,14 +2100,10 @@ static struct hci_cb rfcomm_cb = {
.security_cfm = rfcomm_security_cfm
};
-static ssize_t rfcomm_dlc_sysfs_show(struct class *dev,
- struct class_attribute *attr,
- char *buf)
+static int rfcomm_dlc_debugfs_show(struct seq_file *f, void *x)
{
struct rfcomm_session *s;
struct list_head *pp, *p;
- char *str = buf;
- int size = PAGE_SIZE;
rfcomm_lock();
@@ -2114,29 +2112,33 @@ static ssize_t rfcomm_dlc_sysfs_show(struct class *dev,
list_for_each(pp, &s->dlcs) {
struct sock *sk = s->sock->sk;
struct rfcomm_dlc *d = list_entry(pp, struct rfcomm_dlc, list);
- int len;
- len = snprintf(str, size, "%s %s %ld %d %d %d %d\n",
- batostr(&bt_sk(sk)->src), batostr(&bt_sk(sk)->dst),
- d->state, d->dlci, d->mtu, d->rx_credits, d->tx_credits);
-
- size -= len;
- if (size <= 0)
- break;
-
- str += len;
+ seq_printf(f, "%s %s %ld %d %d %d %d\n",
+ batostr(&bt_sk(sk)->src),
+ batostr(&bt_sk(sk)->dst),
+ d->state, d->dlci, d->mtu,
+ d->rx_credits, d->tx_credits);
}
-
- if (size <= 0)
- break;
}
rfcomm_unlock();
- return (str - buf);
+ return 0;
+}
+
+static int rfcomm_dlc_debugfs_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, rfcomm_dlc_debugfs_show, inode->i_private);
}
-static CLASS_ATTR(rfcomm_dlc, S_IRUGO, rfcomm_dlc_sysfs_show, NULL);
+static const struct file_operations rfcomm_dlc_debugfs_fops = {
+ .open = rfcomm_dlc_debugfs_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static struct dentry *rfcomm_dlc_debugfs;
/* ---- Initialization ---- */
static int __init rfcomm_init(void)
@@ -2153,8 +2155,12 @@ static int __init rfcomm_init(void)
goto unregister;
}
- if (class_create_file(bt_class, &class_attr_rfcomm_dlc) < 0)
- BT_ERR("Failed to create RFCOMM info file");
+ if (bt_debugfs) {
+ rfcomm_dlc_debugfs = debugfs_create_file("rfcomm_dlc", 0444,
+ bt_debugfs, NULL, &rfcomm_dlc_debugfs_fops);
+ if (!rfcomm_dlc_debugfs)
+ BT_ERR("Failed to create RFCOMM debug file");
+ }
err = rfcomm_init_ttys();
if (err < 0)
@@ -2182,7 +2188,7 @@ unregister:
static void __exit rfcomm_exit(void)
{
- class_remove_file(bt_class, &class_attr_rfcomm_dlc);
+ debugfs_remove(rfcomm_dlc_debugfs);
hci_unregister_cb(&rfcomm_cb);
diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
index 8d0ee0b..7f43976 100644
--- a/net/bluetooth/rfcomm/sock.c
+++ b/net/bluetooth/rfcomm/sock.c
@@ -40,6 +40,8 @@
#include <linux/skbuff.h>
#include <linux/list.h>
#include <linux/device.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
#include <net/sock.h>
#include <asm/system.h>
@@ -1061,37 +1063,38 @@ done:
return result;
}
-static ssize_t rfcomm_sock_sysfs_show(struct class *dev,
- struct class_attribute *attr,
- char *buf)
+static int rfcomm_sock_debugfs_show(struct seq_file *f, void *p)
{
struct sock *sk;
struct hlist_node *node;
- char *str = buf;
- int size = PAGE_SIZE;
read_lock_bh(&rfcomm_sk_list.lock);
sk_for_each(sk, node, &rfcomm_sk_list.head) {
- int len;
-
- len = snprintf(str, size, "%s %s %d %d\n",
- batostr(&bt_sk(sk)->src), batostr(&bt_sk(sk)->dst),
+ seq_printf(f, "%s %s %d %d\n",
+ batostr(&bt_sk(sk)->src),
+ batostr(&bt_sk(sk)->dst),
sk->sk_state, rfcomm_pi(sk)->channel);
-
- size -= len;
- if (size <= 0)
- break;
-
- str += len;
}
read_unlock_bh(&rfcomm_sk_list.lock);
- return (str - buf);
+ return 0;
}
-static CLASS_ATTR(rfcomm, S_IRUGO, rfcomm_sock_sysfs_show, NULL);
+static int rfcomm_sock_debugfs_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, rfcomm_sock_debugfs_show, inode->i_private);
+}
+
+static const struct file_operations rfcomm_sock_debugfs_fops = {
+ .open = rfcomm_sock_debugfs_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static struct dentry *rfcomm_sock_debugfs;
static const struct proto_ops rfcomm_sock_ops = {
.family = PF_BLUETOOTH,
@@ -1131,8 +1134,12 @@ int __init rfcomm_init_sockets(void)
if (err < 0)
goto error;
- if (class_create_file(bt_class, &class_attr_rfcomm) < 0)
- BT_ERR("Failed to create RFCOMM info file");
+ if (bt_debugfs) {
+ rfcomm_sock_debugfs = debugfs_create_file("rfcomm", 0444,
+ bt_debugfs, NULL, &rfcomm_sock_debugfs_fops);
+ if (!rfcomm_sock_debugfs)
+ BT_ERR("Failed to create RFCOMM debug file");
+ }
BT_INFO("RFCOMM socket layer initialized");
@@ -1146,7 +1153,7 @@ error:
void rfcomm_cleanup_sockets(void)
{
- class_remove_file(bt_class, &class_attr_rfcomm);
+ debugfs_remove(rfcomm_sock_debugfs);
if (bt_sock_unregister(BTPROTO_RFCOMM) < 0)
BT_ERR("RFCOMM socket layer unregistration failed");
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 967a751..e5b16b7 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -38,6 +38,8 @@
#include <linux/socket.h>
#include <linux/skbuff.h>
#include <linux/device.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
#include <linux/list.h>
#include <net/sock.h>
@@ -953,37 +955,36 @@ drop:
return 0;
}
-static ssize_t sco_sysfs_show(struct class *dev,
- struct class_attribute *attr,
- char *buf)
+static int sco_debugfs_show(struct seq_file *f, void *p)
{
struct sock *sk;
struct hlist_node *node;
- char *str = buf;
- int size = PAGE_SIZE;
read_lock_bh(&sco_sk_list.lock);
sk_for_each(sk, node, &sco_sk_list.head) {
- int len;
-
- len = snprintf(str, size, "%s %s %d\n",
- batostr(&bt_sk(sk)->src), batostr(&bt_sk(sk)->dst),
- sk->sk_state);
-
- size -= len;
- if (size <= 0)
- break;
-
- str += len;
+ seq_printf(f, "%s %s %d\n", batostr(&bt_sk(sk)->src),
+ batostr(&bt_sk(sk)->dst), sk->sk_state);
}
read_unlock_bh(&sco_sk_list.lock);
- return (str - buf);
+ return 0;
}
-static CLASS_ATTR(sco, S_IRUGO, sco_sysfs_show, NULL);
+static int sco_debugfs_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, sco_debugfs_show, inode->i_private);
+}
+
+static const struct file_operations sco_debugfs_fops = {
+ .open = sco_debugfs_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
+static struct dentry *sco_debugfs;
static const struct proto_ops sco_sock_ops = {
.family = PF_BLUETOOTH,
@@ -1041,8 +1042,12 @@ static int __init sco_init(void)
goto error;
}
- if (class_create_file(bt_class, &class_attr_sco) < 0)
- BT_ERR("Failed to create SCO info file");
+ if (bt_debugfs) {
+ sco_debugfs = debugfs_create_file("sco", 0444,
+ bt_debugfs, NULL, &sco_debugfs_fops);
+ if (!sco_debugfs)
+ BT_ERR("Failed to create SCO debug file");
+ }
BT_INFO("SCO (Voice Link) ver %s", VERSION);
BT_INFO("SCO socket layer initialized");
@@ -1056,7 +1061,7 @@ error:
static void __exit sco_exit(void)
{
- class_remove_file(bt_class, &class_attr_sco);
+ debugfs_remove(sco_debugfs);
if (bt_sock_unregister(BTPROTO_SCO) < 0)
BT_ERR("SCO socket unregistration failed");
--
1.6.6.1
^ permalink raw reply related
* [PATCH 3/3] Bluetooth: Fix kernel crash on L2CAP stress tests
From: Marcel Holtmann @ 2010-03-21 5:41 UTC (permalink / raw)
To: David Miller, Linus Torvalds; +Cc: netdev
In-Reply-To: <cover.1269149354.git.marcel@holtmann.org>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Added very simple check that req buffer has enough space to
fit configuration parameters. Shall be enough to reject packets
with configuration size more than req buffer.
Crash trace below
[ 6069.659393] Unable to handle kernel paging request at virtual address 02000205
[ 6069.673034] Internal error: Oops: 805 [#1] PREEMPT
...
[ 6069.727172] PC is at l2cap_add_conf_opt+0x70/0xf0 [l2cap]
[ 6069.732604] LR is at l2cap_recv_frame+0x1350/0x2e78 [l2cap]
...
[ 6070.030303] Backtrace:
[ 6070.032806] [<bf1c2880>] (l2cap_add_conf_opt+0x0/0xf0 [l2cap]) from
[<bf1c6624>] (l2cap_recv_frame+0x1350/0x2e78 [l2cap])
[ 6070.043823] r8:dc5d3100 r7:df2a91d6 r6:00000001 r5:df2a8000 r4:00000200
[ 6070.050659] [<bf1c52d4>] (l2cap_recv_frame+0x0/0x2e78 [l2cap]) from
[<bf1c8408>] (l2cap_recv_acldata+0x2bc/0x350 [l2cap])
[ 6070.061798] [<bf1c814c>] (l2cap_recv_acldata+0x0/0x350 [l2cap]) from
[<bf0037a4>] (hci_rx_task+0x244/0x478 [bluetooth])
[ 6070.072631] r6:dc647700 r5:00000001 r4:df2ab740
[ 6070.077362] [<bf003560>] (hci_rx_task+0x0/0x478 [bluetooth]) from
[<c006b9fc>] (tasklet_action+0x78/0xd8)
[ 6070.087005] [<c006b984>] (tasklet_action+0x0/0xd8) from [<c006c160>]
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: Gustavo F. Padovan <gustavo@padovan.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/l2cap.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 43e17f7..7794a2e 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2832,6 +2832,11 @@ static inline int l2cap_config_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hdr
int len = cmd->len - sizeof(*rsp);
char req[64];
+ if (len > sizeof(req) - sizeof(struct l2cap_conf_req)) {
+ l2cap_send_disconn_req(conn, sk);
+ goto done;
+ }
+
/* throw out any old stored conf requests */
result = L2CAP_CONF_SUCCESS;
len = l2cap_parse_conf_rsp(sk, rsp->data,
--
1.6.6.1
^ permalink raw reply related
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: Timo Teräs @ 2010-03-21 7:34 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, David S. Miller
In-Reply-To: <20100321004659.GA5895@gondor.apana.org.au>
Herbert Xu wrote:
> On Sat, Mar 20, 2010 at 06:26:00PM +0200, Timo Teräs wrote:
>> So should go ahead and:
>> 1. modify flow cache to be more generic (have virtual put and get
>> for each object; and remove the atomic_t pointer)
>> 2. modify flow cache to have slow and fast resolvers so we can
>> copy with the current sleeping requirement
>
> I don't think we need either of these. To support the sleep
> requirement, just return -EAGAIN from the resolver when the
> template can't be resolved. Then the caller of flow_cache_lookup
> can sleep as it does now. It simply has to repeat the flow
> cache lookup afterwards.
Ok, we can do that to skip 2. But I think 1 would be still useful.
It'd probably be good to actually have flow_cache_ops pointer in
each entry instead of the atomic_t pointer.
The reasoning:
- we can then have type-based checks that the reference count
is valid (e.g. policy's refcount must not go to zero, it's bug,
and we can call dst_release which warns if refcount goes to
negative); imho it's hack to call atomic_dec instead of the
real type's xxx_put
- the flow cache needs to somehow know if the entry is stale so
it'll try to refresh it atomically; e.g. if there's no
check for 'stale', the lookup returns stale xfrm_dst. we'd
then need new api to update the stale entry, or flush it out
and repeat the lookup. the virtual get could check for it being
stale (if so release the entry) and then return null for the
generic code to call the resolver atomically
- for paranoia we can actually check the type of the object in
cache via the ops (if needed)
>> 3. cache bundles instead of policies for outgoing stuff
>> 4. kill find_bundle and just instantiate new ones if we get cache
>> miss
>> 5. put all bundles to global hlist (since only place that walks
>> through them is gc, and stale bundle can be dst_free'd right
>> away); use genid's for policy to flush old bundles
>> 6. dst_free and unlink bundle immediately if it's found to be stale
>
> Sounds good.
Okay. Sounds like a plan. I'll work on this next week.
I'll also try to make it a series of patches instead of the big
hunk I sent initially.
- Timo
^ permalink raw reply
* Re: [PATCH] xfrm: cache bundle lookup results in flow cache
From: Timo Teräs @ 2010-03-21 8:31 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev, David S. Miller
In-Reply-To: <4BA5CC16.9040606@iki.fi>
Timo Teräs wrote:
> Herbert Xu wrote:
>> On Sat, Mar 20, 2010 at 06:26:00PM +0200, Timo Teräs wrote:
>>> So should go ahead and:
>>> 1. modify flow cache to be more generic (have virtual put and get
>>> for each object; and remove the atomic_t pointer)
>>> 2. modify flow cache to have slow and fast resolvers so we can
>>> copy with the current sleeping requirement
>>
>> I don't think we need either of these. To support the sleep
>> requirement, just return -EAGAIN from the resolver when the
>> template can't be resolved. Then the caller of flow_cache_lookup
>> can sleep as it does now. It simply has to repeat the flow
>> cache lookup afterwards.
>
> Ok, we can do that to skip 2. But I think 1 would be still useful.
> It'd probably be good to actually have flow_cache_ops pointer in
> each entry instead of the atomic_t pointer.
>
> The reasoning:
> - we can then have type-based checks that the reference count
> is valid (e.g. policy's refcount must not go to zero, it's bug,
> and we can call dst_release which warns if refcount goes to
> negative); imho it's hack to call atomic_dec instead of the
> real type's xxx_put
> - the flow cache needs to somehow know if the entry is stale so
> it'll try to refresh it atomically; e.g. if there's no
> check for 'stale', the lookup returns stale xfrm_dst. we'd
> then need new api to update the stale entry, or flush it out
> and repeat the lookup. the virtual get could check for it being
> stale (if so release the entry) and then return null for the
> generic code to call the resolver atomically
> - for paranoia we can actually check the type of the object in
> cache via the ops (if needed)
- could cache bundle OR policy for outgoing stuff. it's useful
to cache the policy in case we need to sleep, or if it's a
policy forbidding traffic. in those cases there's no bundle
to cache at all. alternatively we can make dummy bundles that
are marked invalid and are just used to keep a reference to
the policy.
Oh, this also implies that the resolver function should be
changed to get the old stale object so it can re-use it to
get the policy object instead of searching it all over again.
- Timo
^ permalink raw reply
* [patch] sunrpc: handle allocation errors from __rpc_lookup_create()
From: Dan Carpenter @ 2010-03-21 9:28 UTC (permalink / raw)
To: Trond Myklebust
Cc: J. Bruce Fields, Neil Brown, David S. Miller,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
__rpc_lookup_create() can return ERR_PTR(-ENOMEM).
Signed-off-by: Dan Carpenter <error27-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index 8d63f8f..20e30c6 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -587,6 +587,8 @@ static struct dentry *__rpc_lookup_create_exclusive(struct dentry *parent,
struct dentry *dentry;
dentry = __rpc_lookup_create(parent, name);
+ if (IS_ERR(dentry))
+ return dentry;
if (dentry->d_inode == NULL)
return dentry;
dput(dentry);
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 related
* Re: Unable to create more than 1 guest virtio-net device using vhost-net backend
From: Michael S. Tsirkin @ 2010-03-21 9:55 UTC (permalink / raw)
To: Sridhar Samudrala; +Cc: netdev, kvm@vger.kernel.org, avi, gleb
In-Reply-To: <1269037167.5127.12.camel@w-sridhar.beaverton.ibm.com>
On Fri, Mar 19, 2010 at 03:19:27PM -0700, Sridhar Samudrala wrote:
> When creating a guest with 2 virtio-net interfaces, i am running
> into a issue causing the 2nd i/f falling back to userpace virtio
> even when vhost is enabled.
>
> After some debugging, it turned out that KVM_IOEVENTFD ioctl()
> call in qemu is failing with ENOSPC.
> This is because of the NR_IOBUS_DEVS(6) limit in kvm_io_bus_register_dev()
> routine in the host kernel.
>
> I think we need to increase this limit if we want to support multiple
> network interfaces using vhost-net.
> Is there an alternate solution?
>
> Thanks
> Sridhar
Nothing easy that I can see. Each device needs 2 of these. Avi, Gleb,
any objections to increasing the limit to say 16? That would give us
5 more devices to the limit of 6 per guest.
--
MST
^ permalink raw reply
* Re: Unable to create more than 1 guest virtio-net device using vhost-net backend
From: Avi Kivity @ 2010-03-21 10:11 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Sridhar Samudrala, netdev, kvm@vger.kernel.org, gleb
In-Reply-To: <20100321095544.GA6443@redhat.com>
On 03/21/2010 11:55 AM, Michael S. Tsirkin wrote:
> On Fri, Mar 19, 2010 at 03:19:27PM -0700, Sridhar Samudrala wrote:
>
>> When creating a guest with 2 virtio-net interfaces, i am running
>> into a issue causing the 2nd i/f falling back to userpace virtio
>> even when vhost is enabled.
>>
>> After some debugging, it turned out that KVM_IOEVENTFD ioctl()
>> call in qemu is failing with ENOSPC.
>> This is because of the NR_IOBUS_DEVS(6) limit in kvm_io_bus_register_dev()
>> routine in the host kernel.
>>
>> I think we need to increase this limit if we want to support multiple
>> network interfaces using vhost-net.
>> Is there an alternate solution?
>>
>> Thanks
>> Sridhar
>>
> Nothing easy that I can see. Each device needs 2 of these. Avi, Gleb,
> any objections to increasing the limit to say 16? That would give us
> 5 more devices to the limit of 6 per guest.
>
Increase it to 200, then.
Is the limit visible to userspace? If not, we need to expose it.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Unable to create more than 1 guest virtio-net device using vhost-net backend
From: Michael S. Tsirkin @ 2010-03-21 10:15 UTC (permalink / raw)
To: Avi Kivity; +Cc: Sridhar Samudrala, netdev, kvm@vger.kernel.org, gleb
In-Reply-To: <4BA5F0D5.6020801@redhat.com>
On Sun, Mar 21, 2010 at 12:11:33PM +0200, Avi Kivity wrote:
> On 03/21/2010 11:55 AM, Michael S. Tsirkin wrote:
>> On Fri, Mar 19, 2010 at 03:19:27PM -0700, Sridhar Samudrala wrote:
>>
>>> When creating a guest with 2 virtio-net interfaces, i am running
>>> into a issue causing the 2nd i/f falling back to userpace virtio
>>> even when vhost is enabled.
>>>
>>> After some debugging, it turned out that KVM_IOEVENTFD ioctl()
>>> call in qemu is failing with ENOSPC.
>>> This is because of the NR_IOBUS_DEVS(6) limit in kvm_io_bus_register_dev()
>>> routine in the host kernel.
>>>
>>> I think we need to increase this limit if we want to support multiple
>>> network interfaces using vhost-net.
>>> Is there an alternate solution?
>>>
>>> Thanks
>>> Sridhar
>>>
>> Nothing easy that I can see. Each device needs 2 of these. Avi, Gleb,
>> any objections to increasing the limit to say 16? That would give us
>> 5 more devices to the limit of 6 per guest.
>>
>
> Increase it to 200, then.
OK. I think we'll also need a smarter allocator
than bus->dev_count++ than we now have. Right?
> Is the limit visible to userspace? If not, we need to expose it.
I don't think it's visible: it seems to be used in a single
place in kvm. Let's add an ioctl? Note that qemu doesn't
need it now ...
> --
> error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Unable to create more than 1 guest virtio-net device using vhost-net backend
From: Gleb Natapov @ 2010-03-21 10:21 UTC (permalink / raw)
To: Avi Kivity
Cc: Michael S. Tsirkin, Sridhar Samudrala, netdev,
kvm@vger.kernel.org
In-Reply-To: <4BA5F0D5.6020801@redhat.com>
On Sun, Mar 21, 2010 at 12:11:33PM +0200, Avi Kivity wrote:
> On 03/21/2010 11:55 AM, Michael S. Tsirkin wrote:
> >On Fri, Mar 19, 2010 at 03:19:27PM -0700, Sridhar Samudrala wrote:
> >>When creating a guest with 2 virtio-net interfaces, i am running
> >>into a issue causing the 2nd i/f falling back to userpace virtio
> >>even when vhost is enabled.
> >>
> >>After some debugging, it turned out that KVM_IOEVENTFD ioctl()
> >>call in qemu is failing with ENOSPC.
> >>This is because of the NR_IOBUS_DEVS(6) limit in kvm_io_bus_register_dev()
> >>routine in the host kernel.
> >>
> >>I think we need to increase this limit if we want to support multiple
> >>network interfaces using vhost-net.
> >>Is there an alternate solution?
> >>
> >>Thanks
> >>Sridhar
> >Nothing easy that I can see. Each device needs 2 of these. Avi, Gleb,
> >any objections to increasing the limit to say 16? That would give us
> >5 more devices to the limit of 6 per guest.
>
> Increase it to 200, then.
>
Currently on each device read/write we iterate over all registered
devices. This is not scalable.
> Is the limit visible to userspace? If not, we need to expose it.
>
> --
> error compiling committee.c: too many arguments to function
--
Gleb.
^ permalink raw reply
* Re: Unable to create more than 1 guest virtio-net device using vhost-net backend
From: Avi Kivity @ 2010-03-21 10:29 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Sridhar Samudrala, netdev, kvm@vger.kernel.org, gleb
In-Reply-To: <20100321101527.GH6443@redhat.com>
On 03/21/2010 12:15 PM, Michael S. Tsirkin wrote:
>>> Nothing easy that I can see. Each device needs 2 of these. Avi, Gleb,
>>> any objections to increasing the limit to say 16? That would give us
>>> 5 more devices to the limit of 6 per guest.
>>>
>>>
>> Increase it to 200, then.
>>
> OK. I think we'll also need a smarter allocator
> than bus->dev_count++ than we now have. Right?
>
No, why?
Eventually we'll want faster scanning than the linear search we employ
now, though.
>> Is the limit visible to userspace? If not, we need to expose it.
>>
> I don't think it's visible: it seems to be used in a single
> place in kvm. Let's add an ioctl? Note that qemu doesn't
> need it now ...
>
We usually expose limits via KVM_CHECK_EXTENSION(KVM_CAP_BLAH). We can
expose it via KVM_CAP_IOEVENTFD (and need to reserve iodev entries for
those).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Unable to create more than 1 guest virtio-net device using vhost-net backend
From: Avi Kivity @ 2010-03-21 10:31 UTC (permalink / raw)
To: Gleb Natapov
Cc: Michael S. Tsirkin, Sridhar Samudrala, netdev,
kvm@vger.kernel.org
In-Reply-To: <20100321102143.GC13522@redhat.com>
On 03/21/2010 12:21 PM, Gleb Natapov wrote:
> On Sun, Mar 21, 2010 at 12:11:33PM +0200, Avi Kivity wrote:
>
>> On 03/21/2010 11:55 AM, Michael S. Tsirkin wrote:
>>
>>> On Fri, Mar 19, 2010 at 03:19:27PM -0700, Sridhar Samudrala wrote:
>>>
>>>> When creating a guest with 2 virtio-net interfaces, i am running
>>>> into a issue causing the 2nd i/f falling back to userpace virtio
>>>> even when vhost is enabled.
>>>>
>>>> After some debugging, it turned out that KVM_IOEVENTFD ioctl()
>>>> call in qemu is failing with ENOSPC.
>>>> This is because of the NR_IOBUS_DEVS(6) limit in kvm_io_bus_register_dev()
>>>> routine in the host kernel.
>>>>
>>>> I think we need to increase this limit if we want to support multiple
>>>> network interfaces using vhost-net.
>>>> Is there an alternate solution?
>>>>
>>>> Thanks
>>>> Sridhar
>>>>
>>> Nothing easy that I can see. Each device needs 2 of these. Avi, Gleb,
>>> any objections to increasing the limit to say 16? That would give us
>>> 5 more devices to the limit of 6 per guest.
>>>
>> Increase it to 200, then.
>>
>>
> Currently on each device read/write we iterate over all registered
> devices. This is not scalable.
>
Yeah. We need first to drop the callback based matching and replace it
with explicit ranges, then to replace the search with a hash table for
small ranges (keeping a linear search for large ranges, can happen for
coalesced mmio).
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Unable to create more than 1 guest virtio-net device using vhost-net backend
From: Michael S. Tsirkin @ 2010-03-21 11:34 UTC (permalink / raw)
To: Avi Kivity; +Cc: Sridhar Samudrala, netdev, kvm@vger.kernel.org, gleb
In-Reply-To: <4BA5F50B.8080302@redhat.com>
On Sun, Mar 21, 2010 at 12:29:31PM +0200, Avi Kivity wrote:
> On 03/21/2010 12:15 PM, Michael S. Tsirkin wrote:
>>>> Nothing easy that I can see. Each device needs 2 of these. Avi, Gleb,
>>>> any objections to increasing the limit to say 16? That would give us
>>>> 5 more devices to the limit of 6 per guest.
>>>>
>>>>
>>> Increase it to 200, then.
>>>
>> OK. I think we'll also need a smarter allocator
>> than bus->dev_count++ than we now have. Right?
>>
>
> No, why?
We'll run into problems if devices are created/removed in random order,
won't we?
> Eventually we'll want faster scanning than the linear search we employ
> now, though.
Yes I suspect with 200 entries we will :). Let's just make it 16 for
now?
>>> Is the limit visible to userspace? If not, we need to expose it.
>>>
>> I don't think it's visible: it seems to be used in a single
>> place in kvm. Let's add an ioctl? Note that qemu doesn't
>> need it now ...
>>
>
> We usually expose limits via KVM_CHECK_EXTENSION(KVM_CAP_BLAH). We can
> expose it via KVM_CAP_IOEVENTFD (and need to reserve iodev entries for
> those).
>
> --
> error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: Unable to create more than 1 guest virtio-net device using vhost-net backend
From: Avi Kivity @ 2010-03-21 11:58 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Sridhar Samudrala, netdev, kvm@vger.kernel.org, gleb
In-Reply-To: <20100321113443.GB12339@redhat.com>
On 03/21/2010 01:34 PM, Michael S. Tsirkin wrote:
> On Sun, Mar 21, 2010 at 12:29:31PM +0200, Avi Kivity wrote:
>
>> On 03/21/2010 12:15 PM, Michael S. Tsirkin wrote:
>>
>>>>> Nothing easy that I can see. Each device needs 2 of these. Avi, Gleb,
>>>>> any objections to increasing the limit to say 16? That would give us
>>>>> 5 more devices to the limit of 6 per guest.
>>>>>
>>>>>
>>>>>
>>>> Increase it to 200, then.
>>>>
>>>>
>>> OK. I think we'll also need a smarter allocator
>>> than bus->dev_count++ than we now have. Right?
>>>
>>>
>> No, why?
>>
> We'll run into problems if devices are created/removed in random order,
> won't we?
>
unregister_dev() takes care of it.
>> Eventually we'll want faster scanning than the linear search we employ
>> now, though.
>>
> Yes I suspect with 200 entries we will :). Let's just make it 16 for
> now?
>
Let's make it 200 and fix the performance problems later. Making it 16
is just asking for trouble.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [patch] sunrpc: handle allocation errors from __rpc_lookup_create()
From: Trond Myklebust @ 2010-03-21 16:27 UTC (permalink / raw)
To: Dan Carpenter
Cc: J. Bruce Fields, Neil Brown, David S. Miller,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100321092818.GI5331@bicker>
On Sun, 2010-03-21 at 12:28 +0300, Dan Carpenter wrote:
> __rpc_lookup_create() can return ERR_PTR(-ENOMEM).
>
> Signed-off-by: Dan Carpenter <error27-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Well spotted. Applied!
Cheers
Trond
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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
* 2.6.34-rc2: Reported regressions from 2.6.33
From: Rafael J. Wysocki @ 2010-03-21 19:58 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
[NOTES:
* In this cycle the regressions reported by e-mail will only be put into the
Bugzilla 1 week after they have been submitted, if not fixed in the
meantime. The reason is that some regressions are fixed in less than a
week time and there's no point listing them. [We also hope that people will
try to fix bugs faster to avoid being listed. ;-)] If that works, we'll
adopt it as a general rule.
* All of the regressions reported by e-mail that are listed below have been
put into the Bugzilla by Maciej, because I literally didn't have the time
to do that (that's also why the summary reports are delayed).
Thanks Maciej!]
This message contains a list of some regressions from 2.6.33,
for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved regressions from 2.6.33, please let us
know either and we'll add them to the list. Also, please let us know
if any of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply
to this message with CCs to the people involved in reporting and handling
the issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-03-21 15 13 10
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15590
Subject : 2.6.34-rc1: regression: ^Z no longer stops sound
Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Date : 2010-03-14 7:58 (8 days old)
Message-ID : <20100314075831.GA13457-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126855353122623&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15589
Subject : 2.6.34-rc1: Badness at fs/proc/generic.c:316
Submitter : Christian Kujau <lists-AanptEQQ3TL9uQeqpI+JUg@public.gmane.org>
Date : 2010-03-13 23:53 (9 days old)
Message-ID : <alpine.DEB.2.01.1003131544340.5493-uKsf7x9sgtqQ/Pez2Lbyp4QuADTiUCJX@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126852442903680&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15584
Subject : 2.6.34-rc1: lockdep warning on geode subnotebook
Submitter : Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>
Date : 2010-03-13 10:51 (9 days old)
Message-ID : <20100313105109.GA9966-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126847750927601&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15555
Subject : 2.6.34-rc1: kernel BUG at mm/slab.c:2989!
Submitter : Américo Wang <xiyou.wangcong-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-03-10 8:29 (12 days old)
Message-ID : <2375c9f91003100029q7d64bbf7xce15eee97f7e2190-JsoAwUIsXounXO2b/Sh1tA@public.gmane.orgom>
References : http://marc.info/?l=linux-kernel&m=126820979017089&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15549
Subject : [2.6.34-rc1][libata] regression?
Submitter : Etienne Basset <etienne.basset-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
Date : 2010-03-09 21:47 (13 days old)
Message-ID : <4B96C202.6050606-Bf/eaXMDFuuXqB7oj33eUg@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126817180811846&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15548
Subject : BUG: key f70f4b50 not in .data
Submitter : Sergey Senozhatsky <sergey.senozhatsky-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-03-09 10:27 (13 days old)
Message-ID : <20100309102754.GA3316-dY8u8AhHFaWtd10JCjopabkcH5ONE+aC@public.gmane.org>
References : http://marc.info/?l=linux-kernel&m=126813046113130&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15533
Subject : i915 fails to set mode in 2.6.34-rc1, ok in 2.6.33-rc8
Submitter : Pete Zaitcev <zaitcev-/E1597aS9LQAvxtiuMwx3w@public.gmane.org>
Date : 2010-03-13 20:37 (9 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15518
Subject : CONFIG_NO_BOOTMEM=y breaks boot on 32bit
Submitter : Daniel Vetter <daniel-/w4YWyX8dFk@public.gmane.org>
Date : 2010-03-11 15:37 (11 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15496
Subject : 2.6.34-rc1 crashes early while startup
Submitter : Thomas Meyer <thomas-VsYtu1Qij5c@public.gmane.org>
Date : 2010-03-09 19:40 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15495
Subject : Flood of SELinux denials on polkitd
Submitter : Alex Villacis Lasso <avillaci-x0m+Mc+nT7uljOmnV8AmnkElSqmLX1BE@public.gmane.org>
Date : 2010-03-09 16:47 (13 days old)
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15537
Subject : 2.6.34-rc1 hangs for 30 seconds when trying to access the disk
Submitter : Andrew Benton <b3nton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date : 2010-03-14 23:26 (8 days old)
Handled-By : Jeff Garzik <jgarzik-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=25516
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15505
Subject : No more b43 wireless interface since 2.6.34-rc1
Submitter : Christian Casteyde <casteyde.christian-GANU6spQydw@public.gmane.org>
Date : 2010-03-10 06:59 (12 days old)
Handled-By : Yinghai Lu <yinghai-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Patch : https://bugzilla.kernel.org/show_bug.cgi?id=15505#c11
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15480
Subject : [regression] Fails to boot properly unless given pci=nocrs
Submitter : Yanko Kaneti <yaneti-jUE9FD3ILm5BDgjK7y7TUQ@public.gmane.org>
Date : 2010-03-09 01:24 (13 days old)
Handled-By : Bjorn Helgaas <bjorn.helgaas-VXdhtT5mjnY@public.gmane.org>
Patch : http://lkml.org/lkml/2010/3/11/512
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions from 2.6.33,
unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=15310
Please let the tracking team know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
^ permalink raw reply
* RCU problems in fib_table_insert
From: Andi Kleen @ 2010-03-21 20:25 UTC (permalink / raw)
To: robert.olsson, netdev; +Cc: paulmck
Hi,
I got the following warning at boot with a 2.6.34-rc2ish git kernel
with RCU debugging and preemption enabled.
It seems the problem is that not all callers of fib_find_node
call it with rcu_read_lock() to stabilize access to the fib.
I tried to fix it, but especially for fib_table_insert() that's rather
tricky: it does a lot of memory allocations and also route flushing and
other blocking operations while assuming the original fa is RCU stable.
I first tried to move some allocations to the beginning and keep
preemption disabled in the rest, but it's difficult with all of them.
No patch because of that.
Does the fa need an additional reference count for this problem?
Or perhaps some optimistic locking?
-Andi
==================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
/home/lsrc/git/linux-2.6/net/ipv4/fib_trie.c:964 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 0
2 locks held by ip/4521:
#0: (rtnl_mutex){+.+.+.}, at: [<ffffffff816466af>] rtnetlink_rcv+0x1f/0x40
#1: ((inetaddr_chain).rwsem){.+.+.+}, at: [<ffffffff8107cde7>] __blocking_notifier_call_chain+0x47/0x90
stack backtrace:
Pid: 4521, comm: ip Not tainted 2.6.34-rc2 #5
Call Trace:
[<ffffffff8108b7e9>] lockdep_rcu_dereference+0xb9/0xc0
[<ffffffff81696a05>] fib_find_node+0x185/0x1b0
[<ffffffff8101155f>] ? save_stack_trace+0x2f/0x50
[<ffffffff81699b1c>] fib_table_insert+0xdc/0xa90
[<ffffffff8107cde7>] ? __blocking_notifier_call_chain+0x47/0x90
[<ffffffff8108edb5>] ? __lock_acquire+0x1485/0x1d50
[<ffffffff816926b0>] fib_magic+0xc0/0xd0
[<ffffffff81692738>] fib_add_ifaddr+0x78/0x1a0
[<ffffffff81692e60>] fib_inetaddr_event+0x50/0x2a0
[<ffffffff8173152d>] notifier_call_chain+0x6d/0xb0
[<ffffffff8107cdfd>] __blocking_notifier_call_chain+0x5d/0x90
[<ffffffff8107ce46>] blocking_notifier_call_chain+0x16/0x20
[<ffffffff81688c0a>] __inet_insert_ifa+0xea/0x180
[<ffffffff8168971d>] inetdev_event+0x43d/0x490
[<ffffffff8173152d>] notifier_call_chain+0x6d/0xb0
[<ffffffff8107cb06>] raw_notifier_call_chain+0x16/0x20
[<ffffffff81639f00>] __dev_notify_flags+0x40/0xa0
[<ffffffff81639fa5>] dev_change_flags+0x45/0x70
[<ffffffff81645c2c>] do_setlink+0x2fc/0x4a0
[<ffffffff81294176>] ? nla_parse+0x36/0x110
[<ffffffff81646d54>] rtnl_newlink+0x444/0x540
[<ffffffff8108c44d>] ? mark_held_locks+0x6d/0x90
[<ffffffff8172b8c5>] ? mutex_lock_nested+0x335/0x3c0
[<ffffffff8164685e>] rtnetlink_rcv_msg+0x18e/0x240
[<ffffffff816466d0>] ? rtnetlink_rcv_msg+0x0/0x240
[<ffffffff816520b9>] netlink_rcv_skb+0x89/0xb0
[<ffffffff816466be>] rtnetlink_rcv+0x2e/0x40
[<ffffffff81651b6b>] ? netlink_unicast+0x11b/0x2f0
[<ffffffff81651d2c>] netlink_unicast+0x2dc/0x2f0
[<ffffffff81630a3c>] ? memcpy_fromiovec+0x7c/0xa0
[<ffffffff81652643>] netlink_sendmsg+0x1d3/0x2e0
[<ffffffff81624e20>] sock_sendmsg+0xc0/0xf0
[<ffffffff8108f9cd>] ? lock_release_non_nested+0x9d/0x340
[<ffffffff810fa33b>] ? might_fault+0x7b/0xd0
[<ffffffff810fa33b>] ? might_fault+0x7b/0xd0
[<ffffffff810fa386>] ? might_fault+0xc6/0xd0
[<ffffffff810fa33b>] ? might_fault+0x7b/0xd0
[<ffffffff81630bfc>] ? verify_iovec+0x4c/0xe0
[<ffffffff81625c3e>] sys_sendmsg+0x1ae/0x360
[<ffffffff810fadf9>] ? __do_fault+0x3f9/0x550
[<ffffffff810fd143>] ? handle_mm_fault+0x1a3/0x790
[<ffffffff8112cc77>] ? fget_light+0xe7/0x2f0
[<ffffffff8108c735>] ? trace_hardirqs_on_caller+0x135/0x180
[<ffffffff8172ccc2>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff810030db>] system_call_fastpath+0x16/0x1b
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* 2.6.34-rc2: Reported regressions 2.6.32 -> 2.6.33
From: Rafael J. Wysocki @ 2010-03-21 20:27 UTC (permalink / raw)
To: Linux Kernel Mailing List
Cc: Maciej Rutecki, Andrew Morton, Linus Torvalds,
Kernel Testers List, Network Development, Linux ACPI,
Linux PM List, Linux SCSI List, Linux Wireless List, DRI
[NOTE:
Well, we seem to have two reports that are almost 2 months old and with
patches. Somebody care to push those patches to Linus or say why they
are invalid, pretty please?]
This message contains a list of some post-2.6.32 regressions introduced before
2.6.33, for which there are no fixes in the mainline known to the tracking team.
If any of them have been fixed already, please let us know.
If you know of any other unresolved post-2.6.32 regressions, please let us know
either and we'll add them to the list. Also, please let us know if any
of the entries below are invalid.
Each entry from the list will be sent additionally in an automatic reply to
this message with CCs to the people involved in reporting and handling the
issue.
Listed regressions statistics:
Date Total Pending Unresolved
----------------------------------------
2010-03-21 133 38 34
2010-02-21 115 34 27
2010-02-15 112 34 31
2010-02-07 97 27 20
2010-02-01 85 26 21
2010-01-24 75 29 23
2010-01-10 55 33 21
2009-12-29 36 34 27
Unresolved regressions
----------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15585
Subject : [Bisected Regression in 2.6.32.8] i915 with KMS enabled causes memorycorruption when resuming from suspend-to-disk
Submitter : M. Vefa Bicakci <bicave@superonline.com>
Date : 2010-03-13 5:11 (9 days old)
First-Bad-Commit: http://git.kernel.org/git/linus/d8e0902806c0bd2ccc4f6a267ff52565a3ec933b
Message-ID : <4B9B1E8F.5090806@superonline.com>
References : http://marc.info/?l=linux-kernel&m=126845754409543&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15544
Subject : black screen upon S3 resume, syslog has "render error" and "page table error"
Submitter : Sanjoy Mahajan <sanjoy@mit.edu>
Date : 2010-03-16 00:45 (6 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15534
Subject : 07ca:b808 crashing and breaking usb's
Submitter : Alex Fiestas <alex@eyeos.org>
Date : 2010-03-14 15:56 (8 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15527
Subject : [BUG] NULL pointer dereference in i915_gem_object_save_bit_17_swizzle
Submitter : Justin Madru <jdm64@gawab.com>
Date : 2010-03-04 9:00 (18 days old)
First-Bad-Commit: http://git.kernel.org/git/linus/280b713b5b0fd84cf2469098aee88acbb5de859c
Message-ID : <20100304090047.23689.qmail@info88.gawab.com>
References : http://marc.info/?l=linux-kernel&m=126769366716380&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15525
Subject : Blank screen after some time, after hibernation/suspend
Submitter : <capsel@matrix.inten.pl>
Date : 2010-03-12 17:24 (10 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15502
Subject : render error detected, EIR: 0x00000010
Submitter : Artem Anisimov <aanisimov@inbox.ru>
Date : 2010-03-10 05:45 (12 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15494
Subject : BUG: key ffff88013d4f4c70 not in .data! when loading microcode.ko
Submitter : Alex Villacis Lasso <avillaci@ceibo.fiec.espol.edu.ec>
Date : 2010-03-09 16:28 (13 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15474
Subject : r8169 fails to bring up ethernet
Submitter : Matteo <rootkit85@yahoo.it>
Date : 2010-03-07 23:57 (15 days old)
First-Bad-Commit: http://git.kernel.org/git/linus/ac1aa47b131416a6ff37eb1005a0a1d2541aad6c
Handled-By : Francois Romieu <romieu@fr.zoreil.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15466
Subject : 2.6.33 dies on modprobe
Submitter : M G Berberich <berberic@fmi.uni-passau.de>
Date : 2010-02-28 22:12 (22 days old)
Message-ID : <20100228221257.GA8858@invalid>
References : http://marc.info/?l=linux-kernel&m=126739570819208&w=2
Handled-By : Américo Wang <xiyou.wangcong@gmail.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15465
Subject : 2.6.33 problems
Submitter : werner@guyane.dyn-o-saur.com
Date : 2010-02-27 17:09 (23 days old)
Message-ID : <1267290551.13148@guyane.dyn-o-saur.com>
References : http://marc.info/?l=linux-kernel&m=126729183719672&w=2
Handled-By : Tejun Heo <tj@kernel.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15454
Subject : r8169 exits with error -22 since 2.6.33
Submitter : Conrad Kostecki <ConiKost@gmx.de>
Date : 2010-03-05 22:32 (17 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15439
Subject : Laptop does consume more power when booted "cold" -- Thinkpad X200s
Submitter : <johannes.schlatow@googlemail.com>
Date : 2010-03-03 23:09 (19 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15418
Subject : battery status info broken; missing entry in ec_dmi_table for specific MSI hardware (notebook)
Submitter : Tom-Steve Watzke <tswatzke@arcor.de>
Date : 2010-03-01 07:25 (21 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15392
Subject : The kernel does not start up.
Submitter : Kristóf Ralovich <kristof.ralovich@gmail.com>
Date : 2010-02-25 06:52 (25 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15376
Subject : regression (oops) with usb in 2.6.33-rc8
Submitter : Christophe Fergeau <cfergeau@mandriva.com>
Date : 2010-02-23 10:58 (27 days old)
Handled-By : Sarah Sharp <sarah.a.sharp@linux.intel.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15319
Subject : [BUG]: Possibe recursive locking detected in sysfs
Submitter : John Kacur <jkacur@redhat.com>
Date : 2010-02-11 17:11 (39 days old)
Message-ID : <520f0cf11002110911t3f125649v73062e9851e2cfb3@mail.gmail.com>
References : http://marc.info/?l=linux-kernel&m=126590832432598&w=2
Handled-By : Eric Biederman <ebiederm@aristanetworks.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15317
Subject : Lockdep report while running aplay with pulse as the default
Submitter : Ed Tomlinson <edt@aei.ca>
Date : 2010-02-13 17:17 (37 days old)
Message-ID : <201002131217.10579.edt@aei.ca>
References : http://marc.info/?l=linux-kernel&m=126608146427546&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15311
Subject : Starting pulseaudio causes a NULL pointer hit
Submitter : Ed Tomlinson <edt@aei.ca>
Date : 2010-02-14 23:41 (36 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15305
Subject : Dell video dies when booting
Submitter : David Ronis <ronis@ronispc.chem.mcgill.ca>
Date : 2010-02-14 1:07 (36 days old)
Message-ID : <1266109622.11290.10.camel@montroll.chem.mcgill.ca>
References : http://marc.info/?l=linux-kernel&m=126611098225127&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15278
Subject : lockdep warning for iscsi in 2.6.33-rc6
Submitter : Tao Ma <tao.ma@oracle.com>
Date : 2010-02-09 6:59 (41 days old)
Message-ID : <4B7107CF.3060703@oracle.com>
References : http://marc.info/?l=linux-kernel&m=126569884330200&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15277
Subject : 2.6.33-rc6 crashes on resume
Submitter : Bill Davidsen <davidsen@roadwarrior3.tmr.com>
Date : 2010-02-08 23:03 (42 days old)
Message-ID : <4B70982F.8090208@roadwarrior3.tmr.com>
References : http://marc.info/?l=linux-kernel&m=126567021801935&w=2
Handled-By : Rafael J. Wysocki <rjw@sisk.pl>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15276
Subject : latest git kernel: general protection fault: 0000 [#1]
Submitter : Markus Trippelsdorf <markus@trippelsdorf.de>
Date : 2010-02-09 8:36 (41 days old)
Message-ID : <20100209083605.GA1766@arch.tripp.de>
References : http://marc.info/?l=linux-kernel&m=126570498804223&w=2
Handled-By : Jérôme Glisse <glisse@freedesktop.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15259
Subject : Corruption with OpenGL since Intel's big DRM push on i945
Submitter : Alexandre Demers <papouta@hotmail.com>
Date : 2010-02-08 13:19 (42 days old)
First-Bad-Commit: http://git.kernel.org/git/linus/76446cac68568fc7f5168a27deaf803ed22a4360
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15246
Subject : BUG: Bad page state in process portageq
Submitter : Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>
Date : 2010-02-07 0:45 (43 days old)
References : http://marc.info/?l=linux-kernel&m=126550356515887&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15245
Subject : [2.6.33-rc6 Weird JCPU times?
Submitter : Shawn Starr <shawn.starr@rogers.com>
Date : 2010-02-06 7:24 (44 days old)
References : http://marc.info/?l=linux-kernel&m=126544107816889&w=2
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15244
Subject : PROBLEM: hda-intel divide by zero kernel crash in azx_position_ok()
Submitter : Jody Bruchon <jody@nctritech.com>
Date : 2010-02-06 0:32 (44 days old)
References : http://marc.info/?l=linux-kernel&m=126541276028173&w=2
Handled-By : Takashi Iwai <tiwai@suse.de>
Jody Bruchon <jody@nctritech.com>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15202
Subject : lockdep warning during elevator_switch
Submitter : Hugh Dickins <hugh.dickins@tiscali.co.uk>
Date : 2010-01-31 23:55 (50 days old)
References : http://marc.info/?l=linux-kernel&m=126498212613051&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15200
Subject : NFS problems in 2.6.33-rc6: Unknown error 526
Submitter : J.A. Magallón <jamagallon@ono.com>
Date : 2010-01-31 22:46 (50 days old)
References : http://marc.info/?l=linux-kernel&m=126497800408928&w=4
Handled-By : Bruce Fields <bfields@fieldses.org>
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15139
Subject : e1000: transmit queue 0 timed out
Submitter : Alexander Beregalov <a.beregalov@gmail.com>
Date : 2010-01-23 15:37 (58 days old)
References : http://marc.info/?l=linux-netdev&m=126426149306083&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15076
Subject : System panic under load with clockevents_program_event
Submitter : okias <d.okias@gmail.com>
Date : 2010-01-17 13:03 (64 days old)
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15036
Subject : soft lockup in dmesg after suspend/resume
Submitter : ykzhao <yakui.zhao@intel.com>
Date : 2010-01-04 5:36 (77 days old)
References : http://marc.info/?l=linux-kernel&m=126258356202722&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14950
Subject : tbench regression with 2.6.33-rc1
Submitter : Lin Ming <ming.m.lin@intel.com>
Date : 2009-12-25 11:11 (87 days old)
References : http://marc.info/?l=linux-kernel&m=126174044213172&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14937
Subject : WARNING: at kernel/lockdep.c:2830
Submitter : Grant Wilson <grant.wilson@zen.co.uk>
Date : 2009-12-27 13:35 (85 days old)
References : http://marc.info/?l=linux-kernel&m=126192220404829&w=4
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14792
Subject : Misdetection of the TV output
Submitter : Santi <santi@agolina.net>
Date : 2009-12-12 13:28 (100 days old)
First-Bad-Commit: http://git.kernel.org/git/linus/27dfaf4f5825a119305db1bc63bef30ed400e376
Handled-By : Zhao Yakui <yakui.zhao@intel.com>
Regressions with patches
------------------------
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15328
Subject : high load avg, extreme sluggishness on T41 w/ Radeon Mobility M7
Submitter : John W. Linville <linville@tuxdriver.com>
Date : 2010-02-16 20:25 (34 days old)
Handled-By : Francisco Jerez <currojerez@riseup.net>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=25118
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15287
Subject : RadeonKMS segfaults kdm on mobility radeon x700 pcie
Submitter : Jan Kreuzer <kontrollator@gmx.de>
Date : 2010-02-12 17:58 (38 days old)
Handled-By : Matthew Wilcox <matthew@wil.cx>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=25483
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15192
Subject : netperf ~50% regression with 2.6.33-rc1, bisect to 1b9508f
Submitter : Lin Ming <ming.m.lin@intel.com>
Date : 2010-01-25 10:03 (56 days old)
First-Bad-Commit: http://git.kernel.org/git/linus/1b9508f6831e10d53256825de8904caa22d1ca2c
References : http://marc.info/?l=linux-kernel&m=126441481427331&w=4
Handled-By : Mike Galbraith <efault@gmx.de>
Peter Zijlstra <peterz@infradead.org>
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Patch : http://patchwork.kernel.org/patch/78544/
Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15142
Subject : sysfs-related lockdep warning in __blkdev_get
Submitter : Matti Aarnio <matti.aarnio--kernel-bugzilla@zmailer.org>
Date : 2010-01-25 13:38 (56 days old)
Handled-By : NeilBrown <neilb@suse.de>
Patch : https://bugzilla.kernel.org/attachment.cgi?id=25085
For details, please visit the bug entries and follow the links given in
references.
As you can see, there is a Bugzilla entry for each of the listed regressions.
There also is a Bugzilla entry used for tracking the regressions introduced
between 2.6.32 and 2.6.33, unresolved as well as resolved, at:
http://bugzilla.kernel.org/show_bug.cgi?id=14885
Please let the tracking teak know if there are any Bugzilla entries that
should be added to the list in there.
Thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" 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: RCU problems in fib_table_insert
From: Eric Dumazet @ 2010-03-21 21:25 UTC (permalink / raw)
To: Andi Kleen; +Cc: robert.olsson, netdev, paulmck
In-Reply-To: <20100321202525.GA966@basil.fritz.box>
Le dimanche 21 mars 2010 à 21:25 +0100, Andi Kleen a écrit :
> Hi,
>
> I got the following warning at boot with a 2.6.34-rc2ish git kernel
> with RCU debugging and preemption enabled.
>
> It seems the problem is that not all callers of fib_find_node
> call it with rcu_read_lock() to stabilize access to the fib.
>
> I tried to fix it, but especially for fib_table_insert() that's rather
> tricky: it does a lot of memory allocations and also route flushing and
> other blocking operations while assuming the original fa is RCU stable.
>
> I first tried to move some allocations to the beginning and keep
> preemption disabled in the rest, but it's difficult with all of them.
> No patch because of that.
>
> Does the fa need an additional reference count for this problem?
> Or perhaps some optimistic locking?
>
> -Andi
No real changes needed, only a lockdep warning...
Probably a rcu_dereference() should be changed to
rcu_dereference_check() like we did for __in6_dev_get()
We hold RTNL or rcu_read_lock
[PATCH] net: fib_find_node() rcu check
We hold rcu read lock or RTNL when fib_find_node() is called.
Shutup lockdep complain.
Reported-by: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index af5d897..471fe07 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -961,7 +961,8 @@ fib_find_node(struct trie *t, u32 key)
struct node *n;
pos = 0;
- n = rcu_dereference(t->trie);
+ n = rcu_dereference_check(t->trie,
+ rcu_read_lock_held() || lockdep_rtnl_is_held());
while (n != NULL && NODE_TYPE(n) == T_TNODE) {
tn = (struct tnode *) n;
^ permalink raw reply related
* Re: RCU problems in fib_table_insert
From: Paul E. McKenney @ 2010-03-21 21:37 UTC (permalink / raw)
To: Andi Kleen; +Cc: robert.olsson, netdev
In-Reply-To: <20100321202525.GA966@basil.fritz.box>
On Sun, Mar 21, 2010 at 09:25:25PM +0100, Andi Kleen wrote:
> Hi,
>
> I got the following warning at boot with a 2.6.34-rc2ish git kernel
> with RCU debugging and preemption enabled.
>
> It seems the problem is that not all callers of fib_find_node
> call it with rcu_read_lock() to stabilize access to the fib.
>
> I tried to fix it, but especially for fib_table_insert() that's rather
> tricky: it does a lot of memory allocations and also route flushing and
> other blocking operations while assuming the original fa is RCU stable.
>
> I first tried to move some allocations to the beginning and keep
> preemption disabled in the rest, but it's difficult with all of them.
> No patch because of that.
>
> Does the fa need an additional reference count for this problem?
> Or perhaps some optimistic locking?
>
> -Andi
>
>
> ==================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> /home/lsrc/git/linux-2.6/net/ipv4/fib_trie.c:964 invoked rcu_dereference_check() without protection!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 0
> 2 locks held by ip/4521:
> #0: (rtnl_mutex){+.+.+.}, at: [<ffffffff816466af>] rtnetlink_rcv+0x1f/0x40
> #1: ((inetaddr_chain).rwsem){.+.+.+}, at: [<ffffffff8107cde7>] __blocking_notifier_call_chain+0x47/0x90
Looks to me like a false positive: If I rememeber correctly, it is OK
to invoke the fib-trie functions either inside an RCU read-side critical
section or with RTNL held. However, I must defer to the networking guys.
For one thing, things might have changed since I last looked at this code.
But if I am correct, the following patch should work. If I am wrong,
this patch will instead incorrectly enforce my misconceptions. ;-)
Thanx, Paul
------------------------------------------------------------------------
net: suppress lockdep-RCU false positive in FIB trie.
Allow fib_find_node() to be called either under rcu_read_lock()
protection or with RTNL held.
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
fib_trie.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index af5d897..01ef8ba 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -961,7 +961,9 @@ fib_find_node(struct trie *t, u32 key)
struct node *n;
pos = 0;
- n = rcu_dereference(t->trie);
+ n = rcu_dereference_check(t->trie,
+ rcu_read_lock_held() ||
+ lockdep_rtnl_is_held());
while (n != NULL && NODE_TYPE(n) == T_TNODE) {
tn = (struct tnode *) n;
^ permalink raw reply related
* Re: RCU problems in fib_table_insert
From: Paul E. McKenney @ 2010-03-21 21:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andi Kleen, robert.olsson, netdev
In-Reply-To: <1269206752.3004.9.camel@edumazet-laptop>
On Sun, Mar 21, 2010 at 10:25:52PM +0100, Eric Dumazet wrote:
> Le dimanche 21 mars 2010 à 21:25 +0100, Andi Kleen a écrit :
> > Hi,
> >
> > I got the following warning at boot with a 2.6.34-rc2ish git kernel
> > with RCU debugging and preemption enabled.
> >
> > It seems the problem is that not all callers of fib_find_node
> > call it with rcu_read_lock() to stabilize access to the fib.
> >
> > I tried to fix it, but especially for fib_table_insert() that's rather
> > tricky: it does a lot of memory allocations and also route flushing and
> > other blocking operations while assuming the original fa is RCU stable.
> >
> > I first tried to move some allocations to the beginning and keep
> > preemption disabled in the rest, but it's difficult with all of them.
> > No patch because of that.
> >
> > Does the fa need an additional reference count for this problem?
> > Or perhaps some optimistic locking?
> >
> > -Andi
>
> No real changes needed, only a lockdep warning...
>
> Probably a rcu_dereference() should be changed to
> rcu_dereference_check() like we did for __in6_dev_get()
>
> We hold RTNL or rcu_read_lock
>
> [PATCH] net: fib_find_node() rcu check
>
> We hold rcu read lock or RTNL when fib_find_node() is called.
> Shutup lockdep complain.
You beat me to it, Eric. ;-)
So:
Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Reported-by: Andi Kleen <andi@firstfloor.org>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
> index af5d897..471fe07 100644
> --- a/net/ipv4/fib_trie.c
> +++ b/net/ipv4/fib_trie.c
> @@ -961,7 +961,8 @@ fib_find_node(struct trie *t, u32 key)
> struct node *n;
>
> pos = 0;
> - n = rcu_dereference(t->trie);
> + n = rcu_dereference_check(t->trie,
> + rcu_read_lock_held() || lockdep_rtnl_is_held());
>
> while (n != NULL && NODE_TYPE(n) == T_TNODE) {
> tn = (struct tnode *) n;
>
>
^ permalink raw reply
* Re: RCU problems in fib_table_insert
From: Eric Dumazet @ 2010-03-21 21:49 UTC (permalink / raw)
To: paulmck; +Cc: Andi Kleen, robert.olsson, netdev
In-Reply-To: <20100321213803.GE2517@linux.vnet.ibm.com>
Le dimanche 21 mars 2010 à 14:38 -0700, Paul E. McKenney a écrit :
> You beat me to it, Eric. ;-)
>
> So:
>
> Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Well, to be fair, I typed less text than you did ;)
Thanks
^ permalink raw reply
* [PATCH] Netfilter: Fix integer overflow in net/ipv6/netfilter/ip6_tables.c (fwd)
From: James Morris @ 2010-03-21 21:50 UTC (permalink / raw)
To: netdev
---------- Forwarded message ----------
Date: Sat, 20 Mar 2010 22:32:40 +0800
From: wzt.wzt@gmail.com
To: linux-kernel@vger.kernel.org
Cc: netfilter-devel@vger.kernel.org, kaber@trash.net
Subject: [PATCH] Netfilter: Fix integer overflow in
net/ipv6/netfilter/ip6_tables.c
The get.size field in the get_entries() interface is not bounded
correctly. The size is used to determine the total entry size.
The size is bounded, but can overflow and so the size checks may
not be sufficient to catch invalid size. Fix it by catching size
values that would cause overflows before calculating the size.
Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com>
---
net/ipv4/netfilter/ip_tables.c | 4 ++++
net/ipv6/netfilter/ip6_tables.c | 4 ++++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index 4e7c719..6abd3d2 100644
--- a/net/ipv4/netfilter/ip_tables.c
+++ b/net/ipv4/netfilter/ip_tables.c
@@ -1164,6 +1164,10 @@ get_entries(struct net *net, struct ipt_get_entries __user *uptr, int *len)
}
if (copy_from_user(&get, uptr, sizeof(get)) != 0)
return -EFAULT;
+
+ if (get.size >= INT_MAX / sizeof(struct ipt_get_entries))
+ return -EINVAL;
+
if (*len != sizeof(struct ipt_get_entries) + get.size) {
duprintf("get_entries: %u != %zu\n",
*len, sizeof(get) + get.size);
diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c
index 0b4557e..5185822 100644
--- a/net/ipv6/netfilter/ip6_tables.c
+++ b/net/ipv6/netfilter/ip6_tables.c
@@ -1190,6 +1190,10 @@ get_entries(struct net *net, struct ip6t_get_entries __user *uptr, int *len)
}
if (copy_from_user(&get, uptr, sizeof(get)) != 0)
return -EFAULT;
+
+ if (get.size >= INT_MAX / sizeof(struct ip6t_get_entries))
+ return -EINVAL;
+
if (*len != sizeof(struct ip6t_get_entries) + get.size) {
duprintf("get_entries: %u != %zu\n",
*len, sizeof(get) + get.size);
--
1.6.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply related
* Re: [PATCH] fix PHY polling system blocking
From: Stefani Seibold @ 2010-03-21 21:54 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, netdev, Thomas Gleixner, David Miller
In-Reply-To: <20100312144248.ade8b700.akpm@linux-foundation.org>
I had now analyzed the PHY handling in most of the network drivers. Most
of the PHY communication will be handled in a polling/blocking way,
write a command word and then wait for the results. Due the nature of
the PHY attachment, this will take some time.
Some of the network drivers do this polling/blocking also in atomic code
paths, like interrupts or timer. So activities on the PHY can cause huge
latency jitters.
On the other side, most of the network driver handle the PHY without
using or only partially using the phylib.
The phylib has also a drawback, because it polls the PHY despite if it
has interrupt support for it or not. I can't see a reason for this
behavior.
So the problem of huge latencies by polling the PHY occurs in most of
the network drivers. For example have a look at the e100 network driver
in the file drivers/net/e100.c, function mdio_ctrl_hw(): This function
will poll for max. of 4000 us or 4 ms.
To fix this latency jitter problem with the PHY polling there are the
following steps to do:
- disable polling in driver/net/phy.c if an interrupt for the PHY is
available
- create an own single or per cpu workqueue for the phylib, so that the
PHY specific code can temporary schedule or block
- prevent all current user of the phylib to access the PHY in a atomic
code path
- modify all current users of the phylib from using cpu_relax() to
cond_resched() and replace the counters against inquiring a timeout
- modify all other network drivers to use the phylib
What do you think?
Stefani
^ permalink raw reply
* Re: [PATCH] Netfilter: Fix integer overflow in net/ipv6/netfilter/ip6_tables.c (fwd)
From: Eric Dumazet @ 2010-03-21 21:59 UTC (permalink / raw)
To: James Morris; +Cc: netdev
In-Reply-To: <alpine.LRH.2.00.1003220850180.3232@tundra.namei.org>
Le lundi 22 mars 2010 à 08:50 +1100, James Morris a écrit :
> ---------- Forwarded message ----------
> Date: Sat, 20 Mar 2010 22:32:40 +0800
> From: wzt.wzt@gmail.com
> To: linux-kernel@vger.kernel.org
> Cc: netfilter-devel@vger.kernel.org, kaber@trash.net
> Subject: [PATCH] Netfilter: Fix integer overflow in
> net/ipv6/netfilter/ip6_tables.c
>
> The get.size field in the get_entries() interface is not bounded
> correctly. The size is used to determine the total entry size.
> The size is bounded, but can overflow and so the size checks may
> not be sufficient to catch invalid size. Fix it by catching size
> values that would cause overflows before calculating the size.
>
> Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com>
>
Unless I am wrong, this patch is not necessary, since we do a bit
later :
if (get.size == private->size)
ret = copy_entries_to_user(private->size,
t, uptr->entrytable);
else {
duprintf("get_entries: I've got %u not %u!\n",
private->size, get.size);
ret = -EAGAIN;
}
So if get.size doesnt match private->size (kernel certified), we exit
with an error. No calculation, no overflow involved.
^ permalink raw reply
* Re: RCU problems in fib_table_insert
From: Paul E. McKenney @ 2010-03-21 22:57 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Andi Kleen, robert.olsson, netdev
In-Reply-To: <1269208186.3004.12.camel@edumazet-laptop>
On Sun, Mar 21, 2010 at 10:49:46PM +0100, Eric Dumazet wrote:
> Le dimanche 21 mars 2010 à 14:38 -0700, Paul E. McKenney a écrit :
>
> > You beat me to it, Eric. ;-)
> >
> > So:
> >
> > Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> Well, to be fair, I typed less text than you did ;)
;-) ;-) ;-)
Thanx, Paul
^ 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