* [PATCH 9/13] unix_diag: Unix inode info NLA
From: Pavel Emelyanov @ 2011-12-15 12:45 UTC (permalink / raw)
To: David Miller, Linux Netdev List
In-Reply-To: <4EE9EB2A.4040909@parallels.com>
Actually, the socket path if it's not anonymous doesn't give
a clue to which file the socket is bound to. Even if the path
is absolute, it can be unlinked and then new socket can be
bound to it.
With this NLA it's possible to check which file a particular
socket is really bound to.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
include/linux/unix_diag.h | 7 +++++++
net/unix/diag.c | 21 +++++++++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/include/linux/unix_diag.h b/include/linux/unix_diag.h
index cc4df34..3e53adb 100644
--- a/include/linux/unix_diag.h
+++ b/include/linux/unix_diag.h
@@ -12,6 +12,7 @@ struct unix_diag_req {
};
#define UDIAG_SHOW_NAME 0x00000001 /* show name (not path) */
+#define UDIAG_SHOW_VFS 0x00000002 /* show VFS inode info */
struct unix_diag_msg {
__u8 udiag_family;
@@ -25,8 +26,14 @@ struct unix_diag_msg {
enum {
UNIX_DIAG_NAME,
+ UNIX_DIAG_VFS,
UNIX_DIAG_MAX,
};
+struct unix_diag_vfs {
+ __u32 udiag_vfs_ino;
+ __u32 udiag_vfs_dev;
+};
+
#endif
diff --git a/net/unix/diag.c b/net/unix/diag.c
index 161ce6c..83799ef 100644
--- a/net/unix/diag.c
+++ b/net/unix/diag.c
@@ -26,6 +26,23 @@ rtattr_failure:
return -EMSGSIZE;
}
+static int sk_diag_dump_vfs(struct sock *sk, struct sk_buff *nlskb)
+{
+ struct dentry *dentry = unix_sk(sk)->dentry;
+ struct unix_diag_vfs *uv;
+
+ if (dentry) {
+ uv = UNIX_DIAG_PUT(nlskb, UNIX_DIAG_VFS, sizeof(*uv));
+ uv->udiag_vfs_ino = dentry->d_inode->i_ino;
+ uv->udiag_vfs_dev = dentry->d_sb->s_dev;
+ }
+
+ return 0;
+
+rtattr_failure:
+ return -EMSGSIZE;
+}
+
static int sk_diag_fill(struct sock *sk, struct sk_buff *skb, struct unix_diag_req *req,
u32 pid, u32 seq, u32 flags, int sk_ino)
{
@@ -48,6 +65,10 @@ static int sk_diag_fill(struct sock *sk, struct sk_buff *skb, struct unix_diag_r
sk_diag_dump_name(sk, skb))
goto nlmsg_failure;
+ if ((req->udiag_show & UDIAG_SHOW_VFS) &&
+ sk_diag_dump_vfs(sk, skb))
+ goto nlmsg_failure;
+
nlh->nlmsg_len = skb_tail_pointer(skb) - b;
return skb->len;
--
1.5.5.6
^ permalink raw reply related
* [PATCH 8/13] unix_diag: Unix socket name NLA
From: Pavel Emelyanov @ 2011-12-15 12:45 UTC (permalink / raw)
To: David Miller, Linux Netdev List
In-Reply-To: <4EE9EB2A.4040909@parallels.com>
Report the sun_path when requested as NLA. With leading '\0' if
present but without the leading AF_UNIX bits.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
include/linux/unix_diag.h | 8 ++++++++
net/unix/diag.c | 20 ++++++++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/include/linux/unix_diag.h b/include/linux/unix_diag.h
index 445184a..cc4df34 100644
--- a/include/linux/unix_diag.h
+++ b/include/linux/unix_diag.h
@@ -11,6 +11,8 @@ struct unix_diag_req {
__u32 udiag_cookie[2];
};
+#define UDIAG_SHOW_NAME 0x00000001 /* show name (not path) */
+
struct unix_diag_msg {
__u8 udiag_family;
__u8 udiag_type;
@@ -21,4 +23,10 @@ struct unix_diag_msg {
__u32 udiag_cookie[2];
};
+enum {
+ UNIX_DIAG_NAME,
+
+ UNIX_DIAG_MAX,
+};
+
#endif
diff --git a/net/unix/diag.c b/net/unix/diag.c
index d7bd48c..161ce6c 100644
--- a/net/unix/diag.c
+++ b/net/unix/diag.c
@@ -10,6 +10,22 @@
#define UNIX_DIAG_PUT(skb, attrtype, attrlen) \
RTA_DATA(__RTA_PUT(skb, attrtype, attrlen))
+static int sk_diag_dump_name(struct sock *sk, struct sk_buff *nlskb)
+{
+ struct unix_address *addr = unix_sk(sk)->addr;
+ char *s;
+
+ if (addr) {
+ s = UNIX_DIAG_PUT(nlskb, UNIX_DIAG_NAME, addr->len - sizeof(short));
+ memcpy(s, addr->name->sun_path, addr->len - sizeof(short));
+ }
+
+ return 0;
+
+rtattr_failure:
+ return -EMSGSIZE;
+}
+
static int sk_diag_fill(struct sock *sk, struct sk_buff *skb, struct unix_diag_req *req,
u32 pid, u32 seq, u32 flags, int sk_ino)
{
@@ -28,6 +44,10 @@ static int sk_diag_fill(struct sock *sk, struct sk_buff *skb, struct unix_diag_r
rep->udiag_ino = sk_ino;
sock_diag_save_cookie(sk, rep->udiag_cookie);
+ if ((req->udiag_show & UDIAG_SHOW_NAME) &&
+ sk_diag_dump_name(sk, skb))
+ goto nlmsg_failure;
+
nlh->nlmsg_len = skb_tail_pointer(skb) - b;
return skb->len;
--
1.5.5.6
^ permalink raw reply related
* [PATCH 7/13] unix_diag: Dumping exact socket core
From: Pavel Emelyanov @ 2011-12-15 12:45 UTC (permalink / raw)
To: David Miller, Linux Netdev List
In-Reply-To: <4EE9EB2A.4040909@parallels.com>
The socket inode is used as a key for lookup. This is effectively
the only really unique ID of a unix socket, but using this for
search currently has one problem -- it is O(number of sockets) :(
Does it worth fixing this lookup or inventing some other ID for
unix sockets?
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
net/unix/diag.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 66 insertions(+), 1 deletions(-)
diff --git a/net/unix/diag.c b/net/unix/diag.c
index 86d85ab..d7bd48c 100644
--- a/net/unix/diag.c
+++ b/net/unix/diag.c
@@ -89,11 +89,76 @@ done:
return skb->len;
}
+static struct sock *unix_lookup_by_ino(int ino)
+{
+ int i;
+ struct sock *sk;
+
+ spin_lock(&unix_table_lock);
+ for (i = 0; i <= UNIX_HASH_SIZE; i++) {
+ struct hlist_node *node;
+
+ sk_for_each(sk, node, &unix_socket_table[i])
+ if (ino == sock_i_ino(sk)) {
+ sock_hold(sk);
+ spin_unlock(&unix_table_lock);
+
+ return sk;
+ }
+ }
+
+ spin_unlock(&unix_table_lock);
+ return NULL;
+}
+
static int unix_diag_get_exact(struct sk_buff *in_skb,
const struct nlmsghdr *nlh,
struct unix_diag_req *req)
{
- return -EAFNOSUPPORT;
+ int err = -EINVAL;
+ struct sock *sk;
+ struct sk_buff *rep;
+ unsigned int extra_len;
+
+ if (req->udiag_ino == 0)
+ goto out_nosk;
+
+ sk = unix_lookup_by_ino(req->udiag_ino);
+ err = -ENOENT;
+ if (sk == NULL)
+ goto out_nosk;
+
+ err = sock_diag_check_cookie(sk, req->udiag_cookie);
+ if (err)
+ goto out;
+
+ extra_len = 256;
+again:
+ err = -ENOMEM;
+ rep = alloc_skb(NLMSG_SPACE((sizeof(struct unix_diag_msg) + extra_len)),
+ GFP_KERNEL);
+ if (!rep)
+ goto out;
+
+ err = sk_diag_fill(sk, rep, req, NETLINK_CB(in_skb).pid,
+ nlh->nlmsg_seq, 0, req->udiag_ino);
+ if (err < 0) {
+ kfree_skb(rep);
+ extra_len += 256;
+ if (extra_len >= PAGE_SIZE)
+ goto out;
+
+ goto again;
+ }
+ err = netlink_unicast(sock_diag_nlsk, rep, NETLINK_CB(in_skb).pid,
+ MSG_DONTWAIT);
+ if (err > 0)
+ err = 0;
+out:
+ if (sk)
+ sock_put(sk);
+out_nosk:
+ return err;
}
static int unix_diag_handler_dump(struct sk_buff *skb, struct nlmsghdr *h)
--
1.5.5.6
^ permalink raw reply related
* [PATCH 6/13] unix_diag: Dumping all sockets core
From: Pavel Emelyanov @ 2011-12-15 12:44 UTC (permalink / raw)
To: David Miller, Linux Netdev List
In-Reply-To: <4EE9EB2A.4040909@parallels.com>
Walk the unix sockets table and fill the core response structure,
which includes type, state and inode.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
net/unix/diag.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/net/unix/diag.c b/net/unix/diag.c
index 6be16c0..86d85ab 100644
--- a/net/unix/diag.c
+++ b/net/unix/diag.c
@@ -10,9 +10,83 @@
#define UNIX_DIAG_PUT(skb, attrtype, attrlen) \
RTA_DATA(__RTA_PUT(skb, attrtype, attrlen))
+static int sk_diag_fill(struct sock *sk, struct sk_buff *skb, struct unix_diag_req *req,
+ u32 pid, u32 seq, u32 flags, int sk_ino)
+{
+ unsigned char *b = skb_tail_pointer(skb);
+ struct nlmsghdr *nlh;
+ struct unix_diag_msg *rep;
+
+ nlh = NLMSG_PUT(skb, pid, seq, SOCK_DIAG_BY_FAMILY, sizeof(*rep));
+ nlh->nlmsg_flags = flags;
+
+ rep = NLMSG_DATA(nlh);
+
+ rep->udiag_family = AF_UNIX;
+ rep->udiag_type = sk->sk_type;
+ rep->udiag_state = sk->sk_state;
+ rep->udiag_ino = sk_ino;
+ sock_diag_save_cookie(sk, rep->udiag_cookie);
+
+ nlh->nlmsg_len = skb_tail_pointer(skb) - b;
+ return skb->len;
+
+nlmsg_failure:
+ nlmsg_trim(skb, b);
+ return -EMSGSIZE;
+}
+
+static int sk_diag_dump(struct sock *sk, struct sk_buff *skb, struct unix_diag_req *req,
+ u32 pid, u32 seq, u32 flags)
+{
+ int sk_ino;
+
+ unix_state_lock(sk);
+ sk_ino = sock_i_ino(sk);
+ unix_state_unlock(sk);
+
+ if (!sk_ino)
+ return 0;
+
+ return sk_diag_fill(sk, skb, req, pid, seq, flags, sk_ino);
+}
+
static int unix_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
{
- return 0;
+ struct unix_diag_req *req;
+ int num, s_num, slot, s_slot;
+
+ req = NLMSG_DATA(cb->nlh);
+
+ s_slot = cb->args[0];
+ num = s_num = cb->args[1];
+
+ spin_lock(&unix_table_lock);
+ for (slot = s_slot; slot <= UNIX_HASH_SIZE; s_num = 0, slot++) {
+ struct sock *sk;
+ struct hlist_node *node;
+
+ num = 0;
+ sk_for_each(sk, node, &unix_socket_table[slot]) {
+ if (num < s_num)
+ goto next;
+ if (!(req->udiag_states & (1 << sk->sk_state)))
+ goto next;
+ if (sk_diag_dump(sk, skb, req,
+ NETLINK_CB(cb->skb).pid,
+ cb->nlh->nlmsg_seq,
+ NLM_F_MULTI) < 0)
+ goto done;
+next:
+ num++;
+ }
+ }
+done:
+ spin_unlock(&unix_table_lock);
+ cb->args[0] = slot;
+ cb->args[1] = num;
+
+ return skb->len;
}
static int unix_diag_get_exact(struct sk_buff *in_skb,
--
1.5.5.6
^ permalink raw reply related
* [PATCH 5/13] unix_diag: Basic module skeleton
From: Pavel Emelyanov @ 2011-12-15 12:44 UTC (permalink / raw)
To: David Miller, Linux Netdev List
In-Reply-To: <4EE9EB2A.4040909@parallels.com>
Includes basic module_init/_exit functionality, dump/get_exact stubs
and declares the basic API structures for request and response.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
include/linux/unix_diag.h | 24 +++++++++++++++++++
net/unix/diag.c | 57 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 81 insertions(+), 0 deletions(-)
create mode 100644 include/linux/unix_diag.h
create mode 100644 net/unix/diag.c
diff --git a/include/linux/unix_diag.h b/include/linux/unix_diag.h
new file mode 100644
index 0000000..445184a
--- /dev/null
+++ b/include/linux/unix_diag.h
@@ -0,0 +1,24 @@
+#ifndef __UNIX_DIAG_H__
+#define __UNIX_DIAG_H__
+
+struct unix_diag_req {
+ __u8 sdiag_family;
+ __u8 sdiag_protocol;
+ __u16 pad;
+ __u32 udiag_states;
+ __u32 udiag_ino;
+ __u32 udiag_show;
+ __u32 udiag_cookie[2];
+};
+
+struct unix_diag_msg {
+ __u8 udiag_family;
+ __u8 udiag_type;
+ __u8 udiag_state;
+ __u8 pad;
+
+ __u32 udiag_ino;
+ __u32 udiag_cookie[2];
+};
+
+#endif
diff --git a/net/unix/diag.c b/net/unix/diag.c
new file mode 100644
index 0000000..6be16c0
--- /dev/null
+++ b/net/unix/diag.c
@@ -0,0 +1,57 @@
+#include <linux/types.h>
+#include <linux/spinlock.h>
+#include <linux/sock_diag.h>
+#include <linux/unix_diag.h>
+#include <linux/skbuff.h>
+#include <net/netlink.h>
+#include <net/af_unix.h>
+#include <net/tcp_states.h>
+
+#define UNIX_DIAG_PUT(skb, attrtype, attrlen) \
+ RTA_DATA(__RTA_PUT(skb, attrtype, attrlen))
+
+static int unix_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ return 0;
+}
+
+static int unix_diag_get_exact(struct sk_buff *in_skb,
+ const struct nlmsghdr *nlh,
+ struct unix_diag_req *req)
+{
+ return -EAFNOSUPPORT;
+}
+
+static int unix_diag_handler_dump(struct sk_buff *skb, struct nlmsghdr *h)
+{
+ int hdrlen = sizeof(struct unix_diag_req);
+
+ if (nlmsg_len(h) < hdrlen)
+ return -EINVAL;
+
+ if (h->nlmsg_flags & NLM_F_DUMP)
+ return netlink_dump_start(sock_diag_nlsk, skb, h,
+ unix_diag_dump, NULL, 0);
+ else
+ return unix_diag_get_exact(skb, h, (struct unix_diag_req *)NLMSG_DATA(h));
+}
+
+static struct sock_diag_handler unix_diag_handler = {
+ .family = AF_UNIX,
+ .dump = unix_diag_handler_dump,
+};
+
+static int __init unix_diag_init(void)
+{
+ return sock_diag_register(&unix_diag_handler);
+}
+
+static void __exit unix_diag_exit(void)
+{
+ sock_diag_unregister(&unix_diag_handler);
+}
+
+module_init(unix_diag_init);
+module_exit(unix_diag_exit);
+MODULE_LICENSE("GPL");
+MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 1 /* AF_LOCAL */);
--
1.5.5.6
^ permalink raw reply related
* [PATCH 4/13] af_unix: Export stuff required for diag module
From: Pavel Emelyanov @ 2011-12-15 12:44 UTC (permalink / raw)
To: David Miller, Linux Netdev List
In-Reply-To: <4EE9EB2A.4040909@parallels.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
include/net/af_unix.h | 3 +++
net/unix/af_unix.c | 9 ++++++---
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/include/net/af_unix.h b/include/net/af_unix.h
index 91ab5b0..63b1781 100644
--- a/include/net/af_unix.h
+++ b/include/net/af_unix.h
@@ -11,10 +11,13 @@ extern void unix_notinflight(struct file *fp);
extern void unix_gc(void);
extern void wait_for_unix_gc(void);
extern struct sock *unix_get_socket(struct file *filp);
+extern struct sock *unix_peer_get(struct sock *);
#define UNIX_HASH_SIZE 256
extern unsigned int unix_tot_inflight;
+extern spinlock_t unix_table_lock;
+extern struct hlist_head unix_socket_table[UNIX_HASH_SIZE + 1];
struct unix_address {
atomic_t refcnt;
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index b595a3d..e1b9358 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -115,8 +115,10 @@
#include <net/checksum.h>
#include <linux/security.h>
-static struct hlist_head unix_socket_table[UNIX_HASH_SIZE + 1];
-static DEFINE_SPINLOCK(unix_table_lock);
+struct hlist_head unix_socket_table[UNIX_HASH_SIZE + 1];
+EXPORT_SYMBOL_GPL(unix_socket_table);
+DEFINE_SPINLOCK(unix_table_lock);
+EXPORT_SYMBOL_GPL(unix_table_lock);
static atomic_long_t unix_nr_socks;
#define unix_sockets_unbound (&unix_socket_table[UNIX_HASH_SIZE])
@@ -172,7 +174,7 @@ static inline int unix_recvq_full(struct sock const *sk)
return skb_queue_len(&sk->sk_receive_queue) > sk->sk_max_ack_backlog;
}
-static struct sock *unix_peer_get(struct sock *s)
+struct sock *unix_peer_get(struct sock *s)
{
struct sock *peer;
@@ -183,6 +185,7 @@ static struct sock *unix_peer_get(struct sock *s)
unix_state_unlock(s);
return peer;
}
+EXPORT_SYMBOL_GPL(unix_peer_get);
static inline void unix_release_addr(struct unix_address *addr)
{
--
1.5.5.6
^ permalink raw reply related
* [PATCH 3/13] sock_diag: Generalize requests cookies managements
From: Pavel Emelyanov @ 2011-12-15 12:43 UTC (permalink / raw)
To: David Miller, Linux Netdev List
In-Reply-To: <4EE9EB2A.4040909@parallels.com>
The sk address is used as a cookie between dump/get_exact calls.
It will be required for unix socket sdumping, so move it from
inet_diag to sock_diag.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
include/linux/inet_diag.h | 1 -
include/linux/sock_diag.h | 3 +++
net/core/sock_diag.c | 19 +++++++++++++++++++
net/ipv4/inet_diag.c | 23 ++++-------------------
net/ipv4/udp_diag.c | 2 +-
5 files changed, 27 insertions(+), 21 deletions(-)
diff --git a/include/linux/inet_diag.h b/include/linux/inet_diag.h
index a27e621..afa5d5c 100644
--- a/include/linux/inet_diag.h
+++ b/include/linux/inet_diag.h
@@ -168,7 +168,6 @@ int inet_diag_dump_one_icsk(struct inet_hashinfo *hashinfo,
struct inet_diag_req *req);
int inet_diag_bc_sk(const struct nlattr *_bc, struct sock *sk);
-int inet_diag_check_cookie(struct sock *sk, struct inet_diag_req *req);
extern int inet_diag_register(const struct inet_diag_handler *handler);
extern void inet_diag_unregister(const struct inet_diag_handler *handler);
diff --git a/include/linux/sock_diag.h b/include/linux/sock_diag.h
index 7999778..379d5dc 100644
--- a/include/linux/sock_diag.h
+++ b/include/linux/sock_diag.h
@@ -22,5 +22,8 @@ void sock_diag_unregister(struct sock_diag_handler *h);
void sock_diag_register_inet_compat(int (*fn)(struct sk_buff *skb, struct nlmsghdr *nlh));
void sock_diag_unregister_inet_compat(int (*fn)(struct sk_buff *skb, struct nlmsghdr *nlh));
+int sock_diag_check_cookie(void *sk, __u32 *cookie);
+void sock_diag_save_cookie(void *sk, __u32 *cookie);
+
extern struct sock *sock_diag_nlsk;
#endif
diff --git a/net/core/sock_diag.c b/net/core/sock_diag.c
index cee96f3..711bdef 100644
--- a/net/core/sock_diag.c
+++ b/net/core/sock_diag.c
@@ -12,6 +12,25 @@ static struct sock_diag_handler *sock_diag_handlers[AF_MAX];
static int (*inet_rcv_compat)(struct sk_buff *skb, struct nlmsghdr *nlh);
static DEFINE_MUTEX(sock_diag_table_mutex);
+int sock_diag_check_cookie(void *sk, __u32 *cookie)
+{
+ if ((cookie[0] != INET_DIAG_NOCOOKIE ||
+ cookie[1] != INET_DIAG_NOCOOKIE) &&
+ ((u32)(unsigned long)sk != cookie[0] ||
+ (u32)((((unsigned long)sk) >> 31) >> 1) != cookie[1]))
+ return -ESTALE;
+ else
+ return 0;
+}
+EXPORT_SYMBOL_GPL(sock_diag_check_cookie);
+
+void sock_diag_save_cookie(void *sk, __u32 *cookie)
+{
+ cookie[0] = (u32)(unsigned long)sk;
+ cookie[1] = (u32)(((unsigned long)sk >> 31) >> 1);
+}
+EXPORT_SYMBOL_GPL(sock_diag_save_cookie);
+
void sock_diag_register_inet_compat(int (*fn)(struct sk_buff *skb, struct nlmsghdr *nlh))
{
mutex_lock(&sock_diag_table_mutex);
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index fa27313..fb2e47f 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -102,8 +102,7 @@ int inet_sk_diag_fill(struct sock *sk, struct inet_connection_sock *icsk,
r->idiag_retrans = 0;
r->id.idiag_if = sk->sk_bound_dev_if;
- r->id.idiag_cookie[0] = (u32)(unsigned long)sk;
- r->id.idiag_cookie[1] = (u32)(((unsigned long)sk >> 31) >> 1);
+ sock_diag_save_cookie(sk, r->id.idiag_cookie);
r->id.idiag_sport = inet->inet_sport;
r->id.idiag_dport = inet->inet_dport;
@@ -221,8 +220,7 @@ static int inet_twsk_diag_fill(struct inet_timewait_sock *tw,
r->idiag_family = tw->tw_family;
r->idiag_retrans = 0;
r->id.idiag_if = tw->tw_bound_dev_if;
- r->id.idiag_cookie[0] = (u32)(unsigned long)tw;
- r->id.idiag_cookie[1] = (u32)(((unsigned long)tw >> 31) >> 1);
+ sock_diag_save_cookie(tw, r->id.idiag_cookie);
r->id.idiag_sport = tw->tw_sport;
r->id.idiag_dport = tw->tw_dport;
r->id.idiag_src[0] = tw->tw_rcv_saddr;
@@ -261,18 +259,6 @@ static int sk_diag_fill(struct sock *sk, struct sk_buff *skb,
return inet_csk_diag_fill(sk, skb, r, pid, seq, nlmsg_flags, unlh);
}
-int inet_diag_check_cookie(struct sock *sk, struct inet_diag_req *req)
-{
- if ((req->id.idiag_cookie[0] != INET_DIAG_NOCOOKIE ||
- req->id.idiag_cookie[1] != INET_DIAG_NOCOOKIE) &&
- ((u32)(unsigned long)sk != req->id.idiag_cookie[0] ||
- (u32)((((unsigned long)sk) >> 31) >> 1) != req->id.idiag_cookie[1]))
- return -ESTALE;
- else
- return 0;
-}
-EXPORT_SYMBOL_GPL(inet_diag_check_cookie);
-
int inet_diag_dump_one_icsk(struct inet_hashinfo *hashinfo, struct sk_buff *in_skb,
const struct nlmsghdr *nlh, struct inet_diag_req *req)
{
@@ -304,7 +290,7 @@ int inet_diag_dump_one_icsk(struct inet_hashinfo *hashinfo, struct sk_buff *in_s
if (sk == NULL)
goto out_nosk;
- err = inet_diag_check_cookie(sk, req);
+ err = sock_diag_check_cookie(sk, req->id.idiag_cookie);
if (err)
goto out;
@@ -617,8 +603,7 @@ static int inet_diag_fill_req(struct sk_buff *skb, struct sock *sk,
r->idiag_retrans = req->retrans;
r->id.idiag_if = sk->sk_bound_dev_if;
- r->id.idiag_cookie[0] = (u32)(unsigned long)req;
- r->id.idiag_cookie[1] = (u32)(((unsigned long)req >> 31) >> 1);
+ sock_diag_save_cookie(req, r->id.idiag_cookie);
tmo = req->expires - jiffies;
if (tmo < 0)
diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
index fe9db86..69f8a7c 100644
--- a/net/ipv4/udp_diag.c
+++ b/net/ipv4/udp_diag.c
@@ -57,7 +57,7 @@ static int udp_dump_one(struct udp_table *tbl, struct sk_buff *in_skb,
if (sk == NULL)
goto out_nosk;
- err = inet_diag_check_cookie(sk, req);
+ err = sock_diag_check_cookie(sk, req->id.idiag_cookie);
if (err)
goto out;
--
1.5.5.6
^ permalink raw reply related
* [PATCH 2/13] sock_diag: Fix module netlink aliases
From: Pavel Emelyanov @ 2011-12-15 12:43 UTC (permalink / raw)
To: David Miller, Linux Netdev List
In-Reply-To: <4EE9EB2A.4040909@parallels.com>
I've made a mistake when fixing the sock_/inet_diag aliases :(
1. The sock_diag layer should request the family-based alias,
not just the IPPROTO_IP one;
2. The inet_diag layer should request for AF_INET+protocol alias,
not just the protocol one.
Thus fix this.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
net/core/sock_diag.c | 4 ++--
net/dccp/diag.c | 2 +-
net/ipv4/inet_diag.c | 7 ++++---
net/ipv4/tcp_diag.c | 2 +-
net/ipv4/udp_diag.c | 4 ++--
5 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/net/core/sock_diag.c b/net/core/sock_diag.c
index 9c27bcd..cee96f3 100644
--- a/net/core/sock_diag.c
+++ b/net/core/sock_diag.c
@@ -64,7 +64,7 @@ static inline struct sock_diag_handler *sock_diag_lock_handler(int family)
{
if (sock_diag_handlers[family] == NULL)
request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
- NETLINK_SOCK_DIAG, IPPROTO_IP);
+ NETLINK_SOCK_DIAG, family);
mutex_lock(&sock_diag_table_mutex);
return sock_diag_handlers[family];
@@ -103,7 +103,7 @@ static int sock_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
case DCCPDIAG_GETSOCK:
if (inet_rcv_compat == NULL)
request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
- NETLINK_SOCK_DIAG, IPPROTO_IP);
+ NETLINK_SOCK_DIAG, AF_INET);
mutex_lock(&sock_diag_table_mutex);
if (inet_rcv_compat != NULL)
diff --git a/net/dccp/diag.c b/net/dccp/diag.c
index e29214d..8f16257 100644
--- a/net/dccp/diag.c
+++ b/net/dccp/diag.c
@@ -83,4 +83,4 @@ module_exit(dccp_diag_fini);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Arnaldo Carvalho de Melo <acme@mandriva.com>");
MODULE_DESCRIPTION("DCCP inet_diag handler");
-MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 33);
+MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 2-33 /* AF_INET - IPPROTO_DCCP */);
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index 575e28c..fa27313 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -54,8 +54,8 @@ static DEFINE_MUTEX(inet_diag_table_mutex);
static const struct inet_diag_handler *inet_diag_lock_handler(int proto)
{
if (!inet_diag_table[proto])
- request_module("net-pf-%d-proto-%d-type-%d", PF_NETLINK,
- NETLINK_SOCK_DIAG, proto);
+ request_module("net-pf-%d-proto-%d-type-%d-%d", PF_NETLINK,
+ NETLINK_SOCK_DIAG, AF_INET, proto);
mutex_lock(&inet_diag_table_mutex);
if (!inet_diag_table[proto])
@@ -1087,4 +1087,5 @@ static void __exit inet_diag_exit(void)
module_init(inet_diag_init);
module_exit(inet_diag_exit);
MODULE_LICENSE("GPL");
-MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 0);
+MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 2 /* AF_INET */);
+MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 10 /* AF_INET6 */);
diff --git a/net/ipv4/tcp_diag.c b/net/ipv4/tcp_diag.c
index 6334b1f..8cd357a 100644
--- a/net/ipv4/tcp_diag.c
+++ b/net/ipv4/tcp_diag.c
@@ -66,4 +66,4 @@ static void __exit tcp_diag_exit(void)
module_init(tcp_diag_init);
module_exit(tcp_diag_exit);
MODULE_LICENSE("GPL");
-MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 6);
+MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 2-6 /* AF_INET - IPPROTO_TCP */);
diff --git a/net/ipv4/udp_diag.c b/net/ipv4/udp_diag.c
index 27910c1..fe9db86 100644
--- a/net/ipv4/udp_diag.c
+++ b/net/ipv4/udp_diag.c
@@ -197,5 +197,5 @@ static void __exit udp_diag_exit(void)
module_init(udp_diag_init);
module_exit(udp_diag_exit);
MODULE_LICENSE("GPL");
-MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 17);
-MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 136);
+MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 2-17 /* AF_INET - IPPROTO_UDP */);
+MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_NETLINK, NETLINK_SOCK_DIAG, 2-136 /* AF_INET - IPPROTO_UDPLITE */);
--
1.5.5.6
^ permalink raw reply related
* [PATCH 1/13] sock_diag: Move the SOCK_DIAG_BY_FAMILY cmd declaration
From: Pavel Emelyanov @ 2011-12-15 12:42 UTC (permalink / raw)
To: David Miller, Linux Netdev List
In-Reply-To: <4EE9EB2A.4040909@parallels.com>
It should belong to sock_diag, not inet_diag.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
---
include/linux/inet_diag.h | 1 -
include/linux/sock_diag.h | 3 +++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/include/linux/inet_diag.h b/include/linux/inet_diag.h
index 78972a1..a27e621 100644
--- a/include/linux/inet_diag.h
+++ b/include/linux/inet_diag.h
@@ -6,7 +6,6 @@
/* Just some random number */
#define TCPDIAG_GETSOCK 18
#define DCCPDIAG_GETSOCK 19
-#define SOCK_DIAG_BY_FAMILY 20
#define INET_DIAG_GETSOCK_MAX 24
diff --git a/include/linux/sock_diag.h b/include/linux/sock_diag.h
index ba4933b..7999778 100644
--- a/include/linux/sock_diag.h
+++ b/include/linux/sock_diag.h
@@ -1,5 +1,8 @@
#ifndef __SOCK_DIAG_H__
#define __SOCK_DIAG_H__
+
+#define SOCK_DIAG_BY_FAMILY 20
+
struct sk_buff;
struct nlmsghdr;
--
1.5.5.6
^ permalink raw reply related
* [PATCH 0/13] Dumping AF_UNIX sockets via netlink
From: Pavel Emelyanov @ 2011-12-15 12:42 UTC (permalink / raw)
To: David Miller, Linux Netdev List
Make the unix_diag.ko module, which is the AF_UNIX client for the sock_diag.
Use the sock_i_ino() as the primary ID key for sockets. This is currently the
only unique (except for the sk address itself) ID of a unix socket and is de
facto used in the ss tool to identify sockets. Thus the basic nlk request and
response structures operate on this ID. Other socket info (sun_name, peer, etc.)
are reported in the respective NLA-s (patches 8 through 12).
There's a locking trickery in patch #11. I've tried to study it carefully and
checked with lockdep, but anyway, please, pay special attention to it.
The patch for ss tool is also included.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
^ permalink raw reply
* Re: [PATCH v9 1/9] Basic kernel memory functionality for the Memory Controller
From: Glauber Costa @ 2011-12-15 12:29 UTC (permalink / raw)
To: Michal Hocko
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
paul-inf54ven1CmVyaH7bEyXVA, lizf-BthXqXjhjHXQFUHtdCDX3A,
kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, gthelen-hpIqsD4AKlfQT0dZR+AlfA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
kirill-oKw7cIdHH8eLwutG50LtGA, avagin-bzQdu9zFT3WakBO8gow8eQ,
devel-GEFAQzZX7r8dnm+yROfE0A, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
cgroups-u79uwXL29TY76Z2rM5mHXA, Johannes Weiner
In-Reply-To: <20111214170447.GB4856-VqjxzfR4DlwKmadIfiO5sKVXKuFTiq87@public.gmane.org>
On 12/14/2011 09:04 PM, Michal Hocko wrote:
> [Now with the current patch version, I hope]
>
> On Mon 12-12-11 11:47:01, Glauber Costa wrote:
>> This patch lays down the foundation for the kernel memory component
>> of the Memory Controller.
>>
>> As of today, I am only laying down the following files:
>>
>> * memory.independent_kmem_limit
>
> Maybe has been already discussed but the name is rather awkward and it
> would deserve more clarification. It is independent in the way that it
> doesn't add up to the standard (user) allocations or it enables/disables
> accounting?
If turned on, it doesn't add up to the user allocations.
As for the name, this is marked experimental, so I don't think anyone
will be relying on it for a while. We can change it, if you have a
better suggestion.
>> * memory.kmem.limit_in_bytes (currently ignored)
>
> What happens if we reach the limit? Are all kernel allocations
> considered or only selected caches? How do I find out which are those?
>
> AFAIU you have implemented it for network buffers at this stage but I
> guess that dentries will follow...
Further allocations should fail.
About other caches, tcp is a bit different because we are concerned with
conditions that applies after the allocation already took place. It is
not clear to me if we will treat the other caches as a single entity, or
separate them.
>> * memory.kmem.usage_in_bytes (always zero)
>>
>> Signed-off-by: Glauber Costa<glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>> CC: Kirill A. Shutemov<kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
>> CC: Paul Menage<paul-inf54ven1CmVyaH7bEyXVA@public.gmane.org>
>> CC: Greg Thelen<gthelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
>> CC: Johannes Weiner<jweiner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> CC: Michal Hocko<mhocko-AlSwsSmVLrQ@public.gmane.org>
>> ---
>> Documentation/cgroups/memory.txt | 40 ++++++++++++++-
>> init/Kconfig | 11 ++++
>> mm/memcontrol.c | 105 ++++++++++++++++++++++++++++++++++++--
>> 3 files changed, 149 insertions(+), 7 deletions(-)
>>
>> diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
>> index cc0ebc5..f245324 100644
>> --- a/Documentation/cgroups/memory.txt
>> +++ b/Documentation/cgroups/memory.txt
>> @@ -44,8 +44,9 @@ Features:
>> - oom-killer disable knob and oom-notifier
>> - Root cgroup has no limit controls.
>>
>> - Kernel memory and Hugepages are not under control yet. We just manage
>> - pages on LRU. To add more controls, we have to take care of performance.
>> + Hugepages is not under control yet. We just manage pages on LRU. To add more
>
> Hugepages are not
> Anyway this sounds outdated as we track both THP and hugetlb, right?
>
>> + controls, we have to take care of performance. Kernel memory support is work
>> + in progress, and the current version provides basically functionality.
>
> s/basically/basic/
>
>>
>> Brief summary of control files.
>>
>> @@ -56,8 +57,11 @@ Brief summary of control files.
>> (See 5.5 for details)
>> memory.memsw.usage_in_bytes # show current res_counter usage for memory+Swap
>> (See 5.5 for details)
>> + memory.kmem.usage_in_bytes # show current res_counter usage for kmem only.
>> + (See 2.7 for details)
>> memory.limit_in_bytes # set/show limit of memory usage
>> memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
>> + memory.kmem.limit_in_bytes # if allowed, set/show limit of kernel memory
>> memory.failcnt # show the number of memory usage hits limits
>> memory.memsw.failcnt # show the number of memory+Swap hits limits
>> memory.max_usage_in_bytes # show max memory usage recorded
>> @@ -72,6 +76,9 @@ Brief summary of control files.
>> memory.oom_control # set/show oom controls.
>> memory.numa_stat # show the number of memory usage per numa node
>>
>> + memory.independent_kmem_limit # select whether or not kernel memory limits are
>> + independent of user limits
>> +
>
> It is not clear what happens in enabled/disabled cases. Let's say they
> are not independent. Does it form a single limit with user charges or it
> toggles kmem charging on/off.
>
>> 1. History
>>
>> The memory controller has a long history. A request for comments for the memory
>> @@ -255,6 +262,35 @@ When oom event notifier is registered, event will be delivered.
>> per-zone-per-cgroup LRU (cgroup's private LRU) is just guarded by
>> zone->lru_lock, it has no lock of its own.
>>
>> +2.7 Kernel Memory Extension (CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
>> +
>> +With the Kernel memory extension, the Memory Controller is able to limit
>> +the amount of kernel memory used by the system. Kernel memory is fundamentally
>> +different than user memory, since it can't be swapped out, which makes it
>> +possible to DoS the system by consuming too much of this precious resource.
>> +
>> +Some kernel memory resources may be accounted and limited separately from the
>> +main "kmem" resource. For instance, a slab cache that is considered important
>> +enough to be limited separately may have its own knobs.
>
> How do you tell which are those that are accounted to the "main kmem"?
Besides being in this list, they should have they own files, like tcp.
>
>> +
>> +Kernel memory limits are not imposed for the root cgroup. Usage for the root
>> +cgroup may or may not be accounted.
>> +
>> +Memory limits as specified by the standard Memory Controller may or may not
>> +take kernel memory into consideration. This is achieved through the file
>> +memory.independent_kmem_limit. A Value different than 0 will allow for kernel
>> +memory to be controlled separately.
>
> Separately from user space allocations, right?
Yes.
> What happens if we reach the limit in both cases?
For kernel memory, further allocations should fail.
>
>> @@ -344,9 +353,14 @@ enum charge_type {
>> };
>>
>> /* for encoding cft->private value on file */
>> -#define _MEM (0)
>> -#define _MEMSWAP (1)
>> -#define _OOM_TYPE (2)
>> +
>> +enum mem_type {
>> + _MEM = 0,
>> + _MEMSWAP,
>> + _OOM_TYPE,
>> + _KMEM,
>> +};
>> +
>
> Probably in a separate (cleanup) patch?
>
>> #define MEMFILE_PRIVATE(x, val) (((x)<< 16) | (val))
>> #define MEMFILE_TYPE(val) (((val)>> 16)& 0xffff)
>> #define MEMFILE_ATTR(val) ((val)& 0xffff)
>> @@ -3848,10 +3862,17 @@ static inline u64 mem_cgroup_usage(struct mem_cgroup *memcg, bool swap)
>> u64 val;
>>
>> if (!mem_cgroup_is_root(memcg)) {
>> + val = 0;
>> +#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
>> + if (!memcg->kmem_independent_accounting)
>> + val = res_counter_read_u64(&memcg->kmem, RES_USAGE);
>> +#endif
>> if (!swap)
>> - return res_counter_read_u64(&memcg->res, RES_USAGE);
>> + val += res_counter_read_u64(&memcg->res, RES_USAGE);
>> else
>> - return res_counter_read_u64(&memcg->memsw, RES_USAGE);
>> + val += res_counter_read_u64(&memcg->memsw, RES_USAGE);
>> +
>> + return val;
>> }
>
> So you report kmem+user but we do not consider kmem during charge so one
> can easily end up with usage_in_bytes over limit but no reclaim is going
> on. Not good, I would say.
>
> OK, so to sum it up. The biggest problem I see is the (non)independent
> accounting. We simply cannot mix user+kernel limits otherwise we would
> see issues (like kernel resource hog would force memcg-oom and innocent
> members would die because their rss is much bigger).
> It is also not clear to me what should happen when we hit the kmem
> limit. I guess it will be kmem cache dependent.
So right now, tcp is completely independent, since it is not accounted
to kmem. In summary, we still never do non-independent accounting. When
we start doing it for the other caches, We will have to add a test at
charge time as well.
We still need to keep it separate though, in case the independent flag
is turned on/off
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Linux-zigbee-devel] ieee802154: WARNING: at mm/page_alloc.c:2095
From: Alexander Smirnov @ 2011-12-15 12:21 UTC (permalink / raw)
To: Sasha Levin; +Cc: dbaryshkov, slapin, davem, netdev, linux-zigbee-devel
In-Reply-To: <1321948410.3787.3.camel@lappy>
Hi Sasha,
first of all could you please specify:
1. What's the kernel do you use?
2. What's the config options are enabled in your kernel?
3. What the HW do you use and what is the use case?
4. What you do to represent this error?
BTW: I cut linux-kernel list, not sure that it's suitable for such questions.
With best regards,
Alexander
2011/11/22 Sasha Levin <levinsasha928@gmail.com>:
> Hi all,
>
> I got the following warning when trying out ieee802154:
>
> [ 157.736372] WARNING: at mm/page_alloc.c:2095 __alloc_pages_nodemask+0x177/0x722()
> [ 157.737707] Pid: 9100, comm: trinity Not tainted 3.2.0-rc2-sasha-00280-g45a222d #22
> [ 157.739114] Call Trace:
> [ 157.739559] [<ffffffff810fcd7f>] ? __alloc_pages_nodemask+0x177/0x722
> [ 157.740746] [<ffffffff81086984>] warn_slowpath_common+0x7b/0x93
> [ 157.741824] [<ffffffff81086a47>] warn_slowpath_null+0x15/0x17
> [ 157.743283] [<ffffffff810fcd7f>] __alloc_pages_nodemask+0x177/0x722
> [ 157.744434] [<ffffffff8112f8a3>] ? __slab_alloc.clone.46+0x42d/0x456
> [ 157.745598] [<ffffffff810b1d97>] ? trace_hardirqs_on_caller+0x151/0x197
> [ 157.747204] [<ffffffff8112f8ab>] ? __slab_alloc.clone.46+0x435/0x456
> [ 157.748375] [<ffffffff810a4875>] ? sched_clock_local+0x12/0x75
> [ 157.749475] [<ffffffff81b96dd6>] ? __alloc_skb+0x42/0x14a
> [ 157.750682] [<ffffffff810b2c3a>] ? lock_is_held+0x92/0x9d
> [ 157.751693] [<ffffffff8112d399>] kmalloc_large_node+0x51/0x83
> [ 157.752757] [<ffffffff81131ada>] __kmalloc_node_track_caller+0x29/0x127
> [ 157.753955] [<ffffffff81b9449e>] ? sock_alloc_send_pskb+0xbd/0x2d7
> [ 157.755084] [<ffffffff81b96e0a>] __alloc_skb+0x76/0x14a
> [ 157.756055] [<ffffffff81b9449e>] sock_alloc_send_pskb+0xbd/0x2d7
> [ 157.757155] [<ffffffff81b9e6ed>] ? rcu_read_unlock+0x21/0x23
> [ 157.758206] [<ffffffff81b946c8>] sock_alloc_send_skb+0x10/0x12
> [ 157.759292] [<ffffffff81e18f4c>] dgram_sendmsg+0xa8/0x22c
> [ 157.760292] [<ffffffff81e182af>] ieee802154_sock_sendmsg+0xf/0x11
> [ 157.761376] [<ffffffff81b8fc6f>] __sock_sendmsg+0x65/0x72
> [ 157.762388] [<ffffffff81b908bb>] sock_sendmsg+0xa3/0xbc
> [ 157.763351] [<ffffffff810a4875>] ? sched_clock_local+0x12/0x75
> [ 157.764420] [<ffffffff8107ecfc>] ? get_parent_ip+0x11/0x41
> [ 157.765428] [<ffffffff8107ecfc>] ? get_parent_ip+0x11/0x41
> [ 157.766439] [<ffffffff810b2c3a>] ? lock_is_held+0x92/0x9d
> [ 157.767440] [<ffffffff81141631>] ? fget_light+0x35/0x9e
> [ 157.768409] [<ffffffff810a355f>] ? up_read+0x1e/0x35
> [ 157.769336] [<ffffffff81b90479>] ? sockfd_lookup_light+0x1b/0x53
> [ 157.770434] [<ffffffff81b91b1d>] sys_sendto+0x12d/0x16f
> [ 157.771396] [<ffffffff810b1e8f>] ? trace_hardirqs_off_caller+0xa3/0x10b
> [ 157.772594] [<ffffffff81e6fd1d>] ? retint_swapgs+0x13/0x1b
> [ 157.773599] [<ffffffff810b1d97>] ? trace_hardirqs_on_caller+0x151/0x197
> [ 157.774826] [<ffffffff8161620e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
> [ 157.775989] [<ffffffff81e705d2>] system_call_fastpath+0x16/0x1b
>
> Please let me know if theres anything I can help with debugging it.
>
> --
>
> Sasha.
>
>
>
> ------------------------------------------------------------------------------
> 10 Tips for Better Server Consolidation
> Server virtualization is being driven by many needs.
> But none more important than the need to reduce IT complexity
> while improving strategic productivity. Learn More!
> http://www.accelacomm.com/jaw/sdnl/114/51507609/
> _______________________________________________
> Linux-zigbee-devel mailing list
> Linux-zigbee-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
^ permalink raw reply
* [patch -next] tcp_memcontrol: fix reversed if condition
From: Dan Carpenter @ 2011-12-15 11:05 UTC (permalink / raw)
To: Glauber Costa
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, kernel-janitors
We should only dereference the pointer if it's valid, not the other way
round.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/ipv4/tcp_memcontrol.c b/net/ipv4/tcp_memcontrol.c
index 171d7b6..7fed04f 100644
--- a/net/ipv4/tcp_memcontrol.c
+++ b/net/ipv4/tcp_memcontrol.c
@@ -44,7 +44,7 @@ static inline struct tcp_memcontrol *tcp_from_cgproto(struct cg_proto *cg_proto)
static void memcg_tcp_enter_memory_pressure(struct sock *sk)
{
- if (!sk->sk_cgrp->memory_pressure)
+ if (sk->sk_cgrp->memory_pressure)
*sk->sk_cgrp->memory_pressure = 1;
}
EXPORT_SYMBOL(memcg_tcp_enter_memory_pressure);
^ permalink raw reply related
* Re: [PATCH 3/3] qmi_wwan: Driver for WWAN devices requiring use of the QMI protocol
From: Bjørn Mork @ 2011-12-15 10:02 UTC (permalink / raw)
To: Dan Williams
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1323882501.2077.3.camel-wKZy7rqYPVb5EHUCmHmTqw@public.gmane.org>
Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> So I thought the protocol acronym stood for "Qualcomm MSM/Modem
> Interface" (see
> https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=commitdiff;h=5f6f87b51184e13b6c493012de787895d5d18765)
That's probably correct. Don't know where I got the messaging part
from. Should be corrected....
> In any case, great work here. But I'm a bit concerned about how all
> this should fit together. QMI is a huge protocol that does everything a
> modem would ever want to do, and we'd likely want to be able to speak
> QMI from userspace to the modem too so that modem managers can expose
> the full functionality of the modems. For example Gobi modems have a
> very minimal AT command set and most of the functionality is exposed
> over QMI or DM. That's why the Qualcomm GobiNet driver also
> exposed /dev/qmi for userspace access.
Yes, I believe some interface should be exported. But my primary goal
was to make something that would just work as an ethernet device with a
minimum of external userspace dependencies. And this modem seems to
have a fairly complete set of AT commands anyway. Ideally I would want
to stick
auto wwan0
iface wwan0 inet dhcp
in my /etc/network/interface and not need any application for that to
work. But I realize that I must enter a SIM PIN1 code first (unless
disabled), and that most users will want to configure a specific APN
(although the null APN "" most likely will work just fine).
But I agree that eventually the full QMI protocol should be made
available to userspace for other uses. That should be fairly easy to do
if you just proxy the commands. But I'm worring about the interface.
Is the /dev/qmi from GobiNet acceptable? Why isn't it merged yet?
Wouldn't something like netlink have been more suitable? How about
security and the ability to control privileges on a command to command
basis? And are there users? Note that even the Windows application
supplied with the modem uses AT commands for SMS sending/receiving etc.
The snoop I did showed a very minimal set of QMI commands. These were
all Windows used for startup of the network interface (partly decoded by
me):
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x01
.msgid = 0x0021
.len = 0x0004
[0x01] (1) ff .
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x02
.msgid = 0x0021
.len = 0x0004
[0x01] (1) ff .
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x03
.msgid = 0x0021
.len = 0x0004
[0x01] (1) ff .
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x04
.msgid = 0x0021
.len = 0x0004
[0x01] (1) ff .
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x05
.msgid = 0x0021
.len = 0x0004
[0x01] (1) ff .
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x06
.msgid = 0x0021
.len = 0x0004
[0x01] (1) ff .
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x07
.msgid = 0x0021
.len = 0x0004
[0x01] (1) ff .
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x08
.msgid = 0x0021
.len = 0x0004
[0x01] (1) ff .
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x09
.msgid = 0x0021
.len = 0x0004
[0x01] (1) ff .
.tf = 0x01
.len = 0x000b
.ctrl = 0x80 service
.service = 0x00
.qmicid = 0x00
.flags = 0x02 response
.tid = 0x00
.msgid = 0x0027
.len = 000000
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x0a
.msgid = 0x0021
.len = 0x0004
[0x01] (1) ff .
.tf = 0x01
.len = 0x0057
.ctrl = 0x80 service
.service = 0x00
.qmicid = 0x00
.flags = 0x01 invalid
.tid = 0x0a
.msgid = 0x0021
.len = 0x004c
[0x02] (4) SUCCESS (0x0000) QMI_ERR_NONE
[0x01] (66) 0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d1 0e 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ..................................................................
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x0b
.msgid = 0x0022
.len = 0x0004
[0x01] (1) 02 .
.tf = 0x01
.len = 0x0017
.ctrl = 0x80 service
.service = 0x00
.qmicid = 0x00
.flags = 0x01 invalid
.tid = 0x0b
.msgid = 0x0022
.len = 0x000c
[0x02] (4) SUCCESS (0x0000) QMI_ERR_NONE
[0x01] (2) 02 01 ..
.tf = 0x01
.len = 0x000c
.ctrl = 0x00 control point
.service = 0x02
.qmicid = 0x01
.flags = 0x00 request
.tid = 0x0001
.msgid = 0x0021
.len = 000000
.tf = 0x01
.len = 0x002b
.ctrl = 0x80 service
.service = 0x02
.qmicid = 0x01
.flags = 0x02 response
.tid = 0x0001
.msgid = 0x0021
.len = 0x001f
[0x02] (4) SUCCESS (0x0000) QMI_ERR_NONE
[0x01] (21) 51 55 41 4c 43 4f 4d 4d 20 49 4e 43 4f 52 50 4f 52 41 54 45 44 QUALCOMM INCORPORATED
.tf = 0x01
.len = 0x000c
.ctrl = 0x00 control point
.service = 0x02
.qmicid = 0x01
.flags = 0x00 request
.tid = 0x0002
.msgid = 0x0024
.len = 000000
.tf = 0x01
.len = 0x0013
.ctrl = 0x80 service
.service = 0x02
.qmicid = 0x01
.flags = 0x02 response
.tid = 0x0002
.msgid = 0x0024
.len = 0x0007
[0x02] (4) FAILED (0x0025) QMI_ERR_UIM_NOT_INITIALIZED
.tf = 0x01
.len = 0x000c
.ctrl = 0x00 control point
.service = 0x02
.qmicid = 0x01
.flags = 0x00 request
.tid = 0x0003
.msgid = 0x0025
.len = 000000
.tf = 0x01
.len = 0x0029
.ctrl = 0x80 service
.service = 0x02
.qmicid = 0x01
.flags = 0x02 response
.tid = 0x0003
.msgid = 0x0025
.len = 0x001d
[0x02] (4) SUCCESS (0x0000) QMI_ERR_NONE
[0x10] (1) 30 0
[0x11] (15) 38 36 30 39 39 39 30 30 30 30 32 33 37 30 37 860999000023707
.tf = 0x01
.len = 0x0010
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x0c
.msgid = 0x0023
.len = 0x0005
[0x01] (2) 02 01 ..
.tf = 0x01
.len = 0x0017
.ctrl = 0x80 service
.service = 0x00
.qmicid = 0x00
.flags = 0x01 invalid
.tid = 0x0c
.msgid = 0x0023
.len = 0x000c
[0x02] (4) SUCCESS (0x0000) QMI_ERR_NONE
[0x01] (2) 02 01 ..
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x0d
.msgid = 0x0022
.len = 0x0004
[0x01] (1) 01 .
.tf = 0x01
.len = 0x0017
.ctrl = 0x80 service
.service = 0x00
.qmicid = 0x00
.flags = 0x01 invalid
.tid = 0x0d
.msgid = 0x0022
.len = 0x000c
[0x02] (4) SUCCESS (0x0000) QMI_ERR_NONE
[0x01] (2) 01 01 ..
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x0e
.msgid = 0x0020
.len = 0x0004
[0x01] (1) 00 .
.tf = 0x01
.len = 0x0017
.ctrl = 0x80 service
.service = 0x00
.qmicid = 0x00
.flags = 0x01 invalid
.tid = 0x0e
.msgid = 0x0020
.len = 0x000c
[0x02] (4) SUCCESS (0x0000) QMI_ERR_NONE
[0x01] (2) 00 00 ..
.tf = 0x01
.len = 0x000b
.ctrl = 0x80 service
.service = 0x00
.qmicid = 0x00
.flags = 0x02 response
.tid = 0x00
.msgid = 0x0027
.len = 000000
.tf = 0x01
.len = 0x000b
.ctrl = 0x80 service
.service = 0x00
.qmicid = 0x00
.flags = 0x02 response
.tid = 0x00
.msgid = 0x0027
.len = 000000
.tf = 0x01
.len = 0x000b
.ctrl = 0x80 service
.service = 0x00
.qmicid = 0x00
.flags = 0x02 response
.tid = 0x00
.msgid = 0x0027
.len = 000000
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x0f
.msgid = 0x0022
.len = 0x0004
[0x01] (1) 02 .
.tf = 0x01
.len = 0x0017
.ctrl = 0x80 service
.service = 0x00
.qmicid = 0x00
.flags = 0x01 invalid
.tid = 0x0f
.msgid = 0x0022
.len = 0x000c
[0x02] (4) SUCCESS (0x0000) QMI_ERR_NONE
[0x01] (2) 02 02 ..
.tf = 0x01
.len = 0x000c
.ctrl = 0x00 control point
.service = 0x02
.qmicid = 0x02
.flags = 0x00 request
.tid = 0x0001
.msgid = 0x0022
.len = 000000
.tf = 0x01
.len = 0x0017
.ctrl = 0x80 service
.service = 0x02
.qmicid = 0x02
.flags = 0x02 response
.tid = 0x0001
.msgid = 0x0022
.len = 0x000b
[0x02] (4) SUCCESS (0x0000) QMI_ERR_NONE
[0x01] (1) 30 0
.tf = 0x01
.len = 0x000f
.ctrl = 0x00 control point
.service = 0x00
.qmicid = 0x00
.flags = 0x00 request
.tid = 0x10
.msgid = 0x0022
.len = 0x0004
[0x01] (1) 01 .
.tf = 0x01
.len = 0x0017
.ctrl = 0x80 service
.service = 0x00
.qmicid = 0x00
.flags = 0x01 invalid
.tid = 0x10
.msgid = 0x0022
.len = 0x000c
[0x02] (4) SUCCESS (0x0000) QMI_ERR_NONE
[0x01] (2) 01 02 ..
.tf = 0x01
.len = 0x000c
.ctrl = 0x00 control point
.service = 0x01
.qmicid = 0x02
.flags = 0x00 request
.tid = 0x0002
.msgid = 0x0022
.len = 000000
.tf = 0x01
.len = 0x0017
.ctrl = 0x80 service
.service = 0x01
.qmicid = 0x02
.flags = 0x02 response
.tid = 0x0002
.msgid = 0x0022
.len = 0x000b
[0x02] (4) SUCCESS (0x0000) QMI_ERR_NONE
[0x01] (1) 01 .
> Second, does the modem actually respond to DHCP over the ECM interface?
Yes. And IMHO that's the only sensible thing to do. Cannot be very
difficult to implement that feature in the firmware. It's not like you
need to write a dhcp server. You know you have only a single client on
the other end of a point-to-point link, and the address configuration is
given. And all broadcast/multicast requires special treatment anyway.
I actually thought about implementing the DHCP functionality in the
driver before I knew that the firmware already provided this.
FWIW, the Windows driver implementation also depends on DHCP for address
configuration .
> If you take a look at the Android rmnet code (which is similar to your
> driver) you'll see they extract the IP address and DNS details from the
> QMI response. Do we need to do that here too?
Based on the above, I don't think so.
And if you still want to extract address details without using DHCP,
then that information is available via the AT^DHCP? command anyway. You
don't need QMI for that part.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/2] Explicitly call tcp creation and init from memcontrol.c
From: Glauber Costa @ 2011-12-15 9:34 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Glauber Costa, Hiroyouki Kamezawa, Eric Dumazet, Stephen Rothwell
In-Reply-To: <1323941672-14324-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Walking the proto_list holds a read_lock, which prevents us from doing
allocations. Splitting the tcp create function into create + init is
good, but it is not enough since create_files will do allocations as well
(dentry ones, mostly).
Since this does not involve any protocol state, I propose we call the tcp
functions explicitly from memcontrol.c
With this, we lose by now the ability of doing cgroup memcontrol for
protocols that are loaded as modules. But at least the ones I have in mind
won't really need it (tcp_ipv6 being the only one, but it uses the same data
structures as tcp_ipv4). So I believe this to be the simpler solution to this
problem.
Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
CC: Hiroyouki Kamezawa <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
CC: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
CC: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
CC: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
---
include/net/sock.h | 2 --
include/net/tcp_memcontrol.h | 19 ++++++++++++++++++-
mm/memcontrol.c | 13 ++++---------
net/core/sock.c | 37 -------------------------------------
net/ipv4/tcp_memcontrol.c | 11 ++++++-----
5 files changed, 28 insertions(+), 54 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 1df44e2..6cbee80 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -64,8 +64,6 @@
#include <net/dst.h>
#include <net/checksum.h>
-int mem_cgroup_sockets_init(struct cgroup *cgrp, struct cgroup_subsys *ss);
-void mem_cgroup_sockets_destroy(struct cgroup *cgrp, struct cgroup_subsys *ss);
/*
* This structure really needs to be cleaned up.
* Most of it is for TCP, and not used by any of
diff --git a/include/net/tcp_memcontrol.h b/include/net/tcp_memcontrol.h
index 3512082..f1ff94a 100644
--- a/include/net/tcp_memcontrol.h
+++ b/include/net/tcp_memcontrol.h
@@ -11,9 +11,26 @@ struct tcp_memcontrol {
int tcp_memory_pressure;
};
-struct cg_proto *tcp_proto_cgroup(struct mem_cgroup *memcg);
+struct cgroup;
+struct cgroup_subsys;
+#if defined(CONFIG_INET) && defined(CONFIG_CGROUP_MEM_RES_CTLR_KMEM)
int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss);
void tcp_destroy_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss);
+void tcp_create_cgroup(struct mem_cgroup *memcg, struct mem_cgroup *parent);
+#else
+static inline int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss)
+{
+ return 0;
+}
+static inline void tcp_destroy_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss)
+{
+}
+static inline void
+tcp_create_cgroup(struct mem_cgroup *memcg, struct mem_cgroup *parent)
+{
+}
+#endif
+struct cg_proto *tcp_proto_cgroup(struct mem_cgroup *memcg);
unsigned long long tcp_max_memory(const struct mem_cgroup *memcg);
void tcp_prot_mem(struct mem_cgroup *memcg, long val, int idx);
#endif /* _TCP_MEMCG_H */
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 7266202..e3d8886 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4749,22 +4749,15 @@ static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
ret = cgroup_add_files(cont, ss, kmem_cgroup_files,
ARRAY_SIZE(kmem_cgroup_files));
- /*
- * Part of this would be better living in a separate allocation
- * function, leaving us with just the cgroup tree population work.
- * We, however, depend on state such as network's proto_list that
- * is only initialized after cgroup creation. I found the less
- * cumbersome way to deal with it to defer it all to populate time
- */
if (!ret)
- ret = mem_cgroup_sockets_init(cont, ss);
+ tcp_init_cgroup(cont, ss);
return ret;
};
static void kmem_cgroup_destroy(struct cgroup_subsys *ss,
struct cgroup *cont)
{
- mem_cgroup_sockets_destroy(cont, ss);
+ tcp_destroy_cgroup(cont, ss);
}
#else
static int register_kmem_files(struct cgroup *cont, struct cgroup_subsys *ss)
@@ -5093,6 +5086,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
res_counter_init(&memcg->res, &parent->res);
res_counter_init(&memcg->memsw, &parent->memsw);
res_counter_init(&memcg->kmem, &parent->kmem);
+ tcp_create_cgroup(memcg, parent);
/*
* We increment refcnt of the parent to ensure that we can
* safely access it on res_counter_charge/uncharge.
@@ -5104,6 +5098,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont)
res_counter_init(&memcg->res, NULL);
res_counter_init(&memcg->memsw, NULL);
res_counter_init(&memcg->kmem, NULL);
+ tcp_create_cgroup(memcg, NULL);
}
memcg->last_scanned_child = 0;
memcg->last_scanned_node = MAX_NUMNODES;
diff --git a/net/core/sock.c b/net/core/sock.c
index 5de62d3..103f246 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -138,43 +138,6 @@
static DEFINE_RWLOCK(proto_list_lock);
static LIST_HEAD(proto_list);
-#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
-int mem_cgroup_sockets_init(struct cgroup *cgrp, struct cgroup_subsys *ss)
-{
- struct proto *proto;
- int ret = 0;
-
- read_lock(&proto_list_lock);
- list_for_each_entry(proto, &proto_list, node) {
- if (proto->init_cgroup) {
- ret = proto->init_cgroup(cgrp, ss);
- if (ret)
- goto out;
- }
- }
-
- read_unlock(&proto_list_lock);
- return ret;
-out:
- list_for_each_entry_continue_reverse(proto, &proto_list, node)
- if (proto->destroy_cgroup)
- proto->destroy_cgroup(cgrp, ss);
- read_unlock(&proto_list_lock);
- return ret;
-}
-
-void mem_cgroup_sockets_destroy(struct cgroup *cgrp, struct cgroup_subsys *ss)
-{
- struct proto *proto;
-
- read_lock(&proto_list_lock);
- list_for_each_entry_reverse(proto, &proto_list, node)
- if (proto->destroy_cgroup)
- proto->destroy_cgroup(cgrp, ss);
- read_unlock(&proto_list_lock);
-}
-#endif
-
/*
* Each address family might have different locking rules, so we have
* one slock key per address family:
diff --git a/net/ipv4/tcp_memcontrol.c b/net/ipv4/tcp_memcontrol.c
index 171d7b6..1433505 100644
--- a/net/ipv4/tcp_memcontrol.c
+++ b/net/ipv4/tcp_memcontrol.c
@@ -49,7 +49,7 @@ static void memcg_tcp_enter_memory_pressure(struct sock *sk)
}
EXPORT_SYMBOL(memcg_tcp_enter_memory_pressure);
-int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss)
+void tcp_create_cgroup(struct mem_cgroup *memcg, struct mem_cgroup *parent)
{
/*
* The root cgroup does not use res_counters, but rather,
@@ -59,13 +59,11 @@ int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss)
struct res_counter *res_parent = NULL;
struct cg_proto *cg_proto, *parent_cg;
struct tcp_memcontrol *tcp;
- struct mem_cgroup *memcg = mem_cgroup_from_cont(cgrp);
- struct mem_cgroup *parent = parent_mem_cgroup(memcg);
struct net *net = current->nsproxy->net_ns;
cg_proto = tcp_prot.proto_cgroup(memcg);
if (!cg_proto)
- goto create_files;
+ return;
tcp = tcp_from_cgproto(cg_proto);
@@ -87,8 +85,11 @@ int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss)
cg_proto->memory_allocated = &tcp->tcp_memory_allocated;
cg_proto->sockets_allocated = &tcp->tcp_sockets_allocated;
cg_proto->memcg = memcg;
+}
+EXPORT_SYMBOL(tcp_create_cgroup);
-create_files:
+int tcp_init_cgroup(struct cgroup *cgrp, struct cgroup_subsys *ss)
+{
return cgroup_add_files(cgrp, ss, tcp_files,
ARRAY_SIZE(tcp_files));
}
--
1.7.6.4
--
To unsubscribe from this list: send the line "unsubscribe cgroups" 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
* [PATCH 1/2] Move limit definitions outside CONFIG_INET
From: Glauber Costa @ 2011-12-15 9:34 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Glauber Costa, Hiroyouki Kamezawa, Eric Dumazet, Stephen Rothwell
In-Reply-To: <1323941672-14324-1-git-send-email-glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
They need to be available for other protocols as well, since
they are used in sock.c openly
Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
CC: Hiroyouki Kamezawa <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
CC: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
CC: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
CC: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
---
include/linux/memcontrol.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 1513994..9b296ea 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -384,13 +384,13 @@ mem_cgroup_print_bad_page(struct page *page)
}
#endif
-#ifdef CONFIG_INET
enum {
UNDER_LIMIT,
SOFT_LIMIT,
OVER_LIMIT,
};
+#ifdef CONFIG_INET
struct sock;
#ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM
void sock_update_memcg(struct sock *sk);
--
1.7.6.4
--
To unsubscribe from this list: send the line "unsubscribe cgroups" 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
* [PATCH 0/2] Proposed fixes for tcp memory pressure
From: Glauber Costa @ 2011-12-15 9:34 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA
Hi,
I propose the following two fixes for the issues we're having in
linux-next.
The first one just moves the definition out of the CONFIG_INET,
and should fix the compile problems with allnoconfig.
The second one is a bit bigger, and takes away the socket
registration functions. As I've explained in the Changelog,
I believe this to be the saner way to do it. We need to do allocations
in both create and init time.
This was compile tested with 4 different randconfigs, CGROUPS off,
KMEM cgroup off, INET off, all them on, and boot tested with
everything on.
Thanks.
Glauber Costa (2):
Move limit definitions outside CONFIG_INET
Explicitly call tcp creation and init from memcontrol.c
include/linux/memcontrol.h | 2 +-
include/net/sock.h | 2 --
include/net/tcp_memcontrol.h | 19 ++++++++++++++++++-
mm/memcontrol.c | 13 ++++---------
net/core/sock.c | 37 -------------------------------------
net/ipv4/tcp_memcontrol.c | 11 ++++++-----
6 files changed, 29 insertions(+), 55 deletions(-)
--
1.7.6.4
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: mlx4: smatch stuff: saving error codes in u8
From: Yevgeny Petrilin @ 2011-12-15 9:05 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev@vger.kernel.org
In-Reply-To: <20111215084812.GA20924@elgon.mountain>
> Hi Yevgeny,
>
> Smatch complains about some recent changes to the mlx4 driver:
> drivers/net/ethernet/mellanox/mlx4/cmd.c +364 mlx4_slave_cmd(27)
> warn: assigning -22 to unsigned variable 'vhcr->status'
>
> We should be using the mlx4_status_to_errno() function here to
> translate
> the hardware error codes to linux error codes.
>
> Also "ret" here gets passed to the the callers who again save it to
> vhcr_cmd->status = __mlx4_cmd() in mlx4_master_process_vhcr(). The
> __mlx4_cmd() function only returns linux error codes, not hardware
> error
> codes.
>
> Also the mlx4_master_process_vhcr() function sets vhcr_cmd->status to
> linux error codes (which is a mistake) but it doesn't set "ret" on all
> paths so it sometimes returns success even though an error occured
> (which is a second separate mistake).
>
Thanks Dan,
Will send fixes to this ASAP.
^ permalink raw reply
* mlx4: smatch stuff: saving error codes in u8
From: Dan Carpenter @ 2011-12-15 8:48 UTC (permalink / raw)
To: Yevgeny Petrilin; +Cc: netdev
Hi Yevgeny,
Smatch complains about some recent changes to the mlx4 driver:
drivers/net/ethernet/mellanox/mlx4/cmd.c +364 mlx4_slave_cmd(27)
warn: assigning -22 to unsigned variable 'vhcr->status'
361 mlx4_err(dev, "response expected while"
362 "output mailbox is NULL for "
363 "command 0x%x\n", op);
364 vhcr->status = -EINVAL;
^^^^^^^^^^^^^^^^^^^^^^^
This is supposed to store some hardware specific error codes. -EINVAL
should be CMD_STAT_BAD_PARAM. Saving negative numbers to unsigned char
doesn't work.
365 }
366 }
367 ret = vhcr->status;
^^^^^^^^^^^^^^^^^^^
We should be using the mlx4_status_to_errno() function here to translate
the hardware error codes to linux error codes.
Also "ret" here gets passed to the the callers who again save it to
vhcr_cmd->status = __mlx4_cmd() in mlx4_master_process_vhcr(). The
__mlx4_cmd() function only returns linux error codes, not hardware error
codes.
Also the mlx4_master_process_vhcr() function sets vhcr_cmd->status to
linux error codes (which is a mistake) but it doesn't set "ret" on all
paths so it sometimes returns success even though an error occured
(which is a second separate mistake).
regards,
dan carpenter
^ permalink raw reply
* RE: [PATCH 1/1] r8169.c correct MSIEnable register offset
From: hayeswang @ 2011-12-15 8:34 UTC (permalink / raw)
To: 'David Miller', romieu
Cc: cantona, linux-kernel, 'nic_swsd', netdev
In-Reply-To: <20111215.014359.1153990753442293322.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Thursday, December 15, 2011 2:44 PM
> To: romieu@fr.zoreil.com
> Cc: cantona@cantona.no-ip.org; Hayeswang;
> linux-kernel@vger.kernel.org; nic_swsd; netdev@vger.kernel.org
> Subject: Re: [PATCH 1/1] r8169.c correct MSIEnable register offset
>
> From: Francois Romieu <romieu@fr.zoreil.com>
> Date: Wed, 14 Dec 2011 22:37:13 +0100
>
> > Su Kang Yin <cantona@cantona.no-ip.org> :
> >> correct MSIEnable (bit 5) register to Config1 (offset
> 0x52) instead of
> >> Config2 (offset 0x53)
> >
The bit 5 of config1 (0x52) is reserved. And the bit 5 of Config2 (0x53) is
MSIEnable only for 8169 controler series.
> > I wonder where the inspiration for the MSIEnable bit came from.
> > It looks like something was confused with the Message Control word
> > in PCI space.
> >
> > Imho you can simply remove it altogether.
>
> Someone should find out what the real situation is with this.
>
> Maybe it mirrors the PCI config space setting and is read-only, maybe
> not. But it should be determined for sure before changing this. :-)
>
^ permalink raw reply
* Re: TCP fast retransmit
From: Eric Dumazet @ 2011-12-15 8:24 UTC (permalink / raw)
To: Carsten Wolff; +Cc: Yuchung Cheng, Esztermann, Ansgar, netdev@vger.kernel.org
In-Reply-To: <201112150841.08087.carsten@wolffcarsten.de>
Le jeudi 15 décembre 2011 à 08:41 +0100, Carsten Wolff a écrit :
> On Wednesday 14 December 2011, Eric Dumazet wrote:
> > Le mercredi 14 décembre 2011 à 11:00 -0800, Yuchung Cheng a écrit :
> > > I use tcptrace to check the time sequence and I am puzzled:
> > > I see a lot of OOO packets too but how can this happen at a sender-side
> > > trace? unless the trace is taken close to but not exactly at the sender.
> > > I expect on seeing in-sequence packets but a lots of SACKs plus some
> > > spurious retransmists.
> >
> > I understood the trace was a receiver-side one (a linux machine if I am
> > not mistaken, while the sender is AIX powered)
> >
> > (Looking at timings of ACKS, coming a few us after corresponding data
> > packet arrival)
>
> Oh. Right. This also means, that net.ipv4.tcp_reordering is only available at
> the receiver (Linux), which doesn't help, because the reordering robustness
> stuff happens on sender-side. So don't even bother changing that sysctl.
>
Oh well, reading Ansgar mail, it seems this is the other way :
quote :
2.6.37.6 with openSUSE patches in the sender, some version of AIX in the
receiver. The latter seems to be critical: we've never encountered this
problem with any other combination of OSs but AIX & Linux.
I only dont understand how we can receive an ACK so fast (6 us after the
data packet ACKed, even 3us a bit later). This seems not possible, even
with 10Gb infra. (A CISCO firewall was mentioned)
12:18:20.732998 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 284400:287136, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 2736
12:18:20.733004 IP 10.208.9.87.35337 > 134.76.98.13.1500: Flags [.], ack 287136, win 591, options [nop,nop,TS val 627192022 ecr 1327509818], length 0
12:18:20.733048 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 287136:293976, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 6840
12:18:20.733073 IP 10.208.9.87.35337 > 134.76.98.13.1500: Flags [.], ack 293976, win 549, options [nop,nop,TS val 627192022 ecr 1327509818], length 0
12:18:20.733104 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 293976:298080, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 4104
12:18:20.733120 IP 10.208.9.87.35337 > 134.76.98.13.1500: Flags [.], ack 298080, win 522, options [nop,nop,TS val 627192022 ecr 1327509818], length 0
Here next two packets we send are out of order.
12:18:20.733161 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 299448:300816, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 1368
12:18:20.733164 IP 10.208.9.87.35337 > 134.76.98.13.1500: Flags [.], ack 298080, win 522, options [nop,nop,TS val 627192022 ecr 1327509818,nop,nop,sack 1 {299448:300816}], length 0
12:18:20.733166 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 298080:299448, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 1368
12:18:20.733169 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 300816:302184, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 1368
12:18:20.733171 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 303552:304920, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 1368
12:18:20.733173 IP 10.208.9.87.35337 > 134.76.98.13.1500: Flags [.], ack 302184, win 490, options [nop,nop,TS val 627192022 ecr 1327509818,nop,nop,sack 1 {303552:304920}], length 0
12:18:20.733174 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 302184:303552, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 1368
12:18:20.733177 IP 10.208.9.87.35337 > 134.76.98.13.1500: Flags [.], ack 304920, win 469, options [nop,nop,TS val 627192022 ecr 1327509818], length 0
12:18:20.733224 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 304920:310392, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 5472
12:18:20.733228 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 311760:313128, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 1368
12:18:20.733230 IP 10.208.9.87.35337 > 134.76.98.13.1500: Flags [.], ack 310392, win 427, options [nop,nop,TS val 627192022 ecr 1327509818,nop,nop,sack 1 {311760:313128}], length 0
12:18:20.733272 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 313128:315864, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 2736
12:18:20.733276 IP 10.208.9.87.35337 > 134.76.98.13.1500: Flags [.], ack 310392, win 427, options [nop,nop,TS val 627192022 ecr 1327509818,nop,nop,sack 1 {311760:315864}], length 0
12:18:20.733326 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 315864:319968, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 4104
12:18:20.733330 IP 10.208.9.87.35337 > 134.76.98.13.1500: Flags [.], ack 310392, win 427, options [nop,nop,TS val 627192022 ecr 1327509818,nop,nop,sack 1 {311760:319968}], length 0
12:18:20.733332 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 310392:311760, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 1368
12:18:20.733333 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 321336:322704, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 1368
12:18:20.733335 IP 10.208.9.87.35337 > 134.76.98.13.1500: Flags [.], ack 319968, win 353, options [nop,nop,TS val 627192022 ecr 1327509818,nop,nop,sack 1 {321336:322704}], length 0
12:18:20.733372 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 322704:324072, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 1368
12:18:20.733375 IP 10.208.9.87.35337 > 134.76.98.13.1500: Flags [.], ack 319968, win 353, options [nop,nop,TS val 627192022 ecr 1327509818,nop,nop,sack 1 {321336:324072}], length 0
12:18:20.733377 IP 134.76.98.13.1500 > 10.208.9.87.35337: Flags [.], seq 319968:321336, ack 555, win 65280, options [nop,nop,TS val 1327509818 ecr 627192022], length 1368
12:18:20.733381 IP 10.208.9.87.35337 > 134.76.98.13.1500: Flags [.], ack 324072, win 327, options [nop,nop,TS val 627192022 ecr 1327509818], length 0
Really, my feeling is this trace is taken on receiver, and maybe LRO/GRO
is buggy ?
Ansgar, please provide more details, like the NIC you use (hardware,
driver versions...)
^ permalink raw reply
* smatch stuff: qla3xxxx: locking problem in ql_adapter_initialize()
From: Dan Carpenter @ 2011-12-15 8:16 UTC (permalink / raw)
To: Ron Mercer; +Cc: linux-driver, netdev
Hi Ron,
The latest version of Smatch complains about this code which was merged
in 2009: 0f77ca928b "qla3xxx: Don't sleep while holding lock."
drivers/net/ethernet/qlogic/qla3xxx.c +3231 ql_adapter_initialize(221)
error: calling 'spin_unlock_irqrestore()' with bogus flags
> commit 0f77ca928b5d1ea17afc7a95682b6534611a719c
> Author: Ron Mercer <ron.mercer@qlogic.com>
> Date: Tue Jun 23 09:00:02 2009 +0000
>
> qla3xxx: Don't sleep while holding lock.
>
> Signed-off-by: Ron Mercer <ron.mercer@qlogic.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
> index 68be714..3e4b67a 100644
> --- a/drivers/net/qla3xxx.c
> +++ b/drivers/net/qla3xxx.c
> @@ -3142,6 +3142,7 @@ static int ql_adapter_initialize(struct ql3_adapter *qdev)
> (void __iomem *)port_regs;
> u32 delay = 10;
> int status = 0;
> + unsigned long hw_flags = 0;
>
> if(ql_mii_setup(qdev))
> return -1;
> @@ -3351,7 +3352,9 @@ static int ql_adapter_initialize(struct ql3_adapter *qdev)
> value = ql_read_page0_reg(qdev, &port_regs->portStatus);
> if (value & PORT_STATUS_IC)
> break;
> + spin_unlock_irqrestore(&qdev->hw_lock, hw_flags);
^^^^^^^^
This is zero here on the first iteration through the loop. On x86 a
zero here means that it turns off IRQs. (They are already off btw).
> msleep(500);
> + spin_lock_irqsave(&qdev->hw_lock, hw_flags);
^^^^^^^^
This is going save that the IRQs are disabled.
> } while (--delay);
>
> if (delay == 0) {
My guess is that probably the intent was to enable IRQs during the
msleep(). We turn on IRQs again ql_adapter_up() so it doesn't cause a
deadlock but it's still not pretty.
regards,
dan carpetner
^ permalink raw reply
* Re: TCP fast retransmit
From: Carsten Wolff @ 2011-12-15 7:41 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Yuchung Cheng, Esztermann, Ansgar, netdev@vger.kernel.org
In-Reply-To: <1323901909.2631.17.camel@edumazet-laptop>
On Wednesday 14 December 2011, Eric Dumazet wrote:
> Le mercredi 14 décembre 2011 à 11:00 -0800, Yuchung Cheng a écrit :
> > I use tcptrace to check the time sequence and I am puzzled:
> > I see a lot of OOO packets too but how can this happen at a sender-side
> > trace? unless the trace is taken close to but not exactly at the sender.
> > I expect on seeing in-sequence packets but a lots of SACKs plus some
> > spurious retransmists.
>
> I understood the trace was a receiver-side one (a linux machine if I am
> not mistaken, while the sender is AIX powered)
>
> (Looking at timings of ACKS, coming a few us after corresponding data
> packet arrival)
Oh. Right. This also means, that net.ipv4.tcp_reordering is only available at
the receiver (Linux), which doesn't help, because the reordering robustness
stuff happens on sender-side. So don't even bother changing that sysctl.
Carsten
^ permalink raw reply
* Re: Latency guarantees in HFSC rt service curves
From: John A. Sullivan III @ 2011-12-15 7:38 UTC (permalink / raw)
To: Michal Soltys; +Cc: netdev
In-Reply-To: <4EE951E6.4020708@ziu.info>
On Thu, 2011-12-15 at 02:48 +0100, Michal Soltys wrote:
> On 11-12-14 06:16, John A. Sullivan III wrote:
> > I think I understand the technology (although I confess I did not take
> > the time to fully digest how the curves are updated) <snip>
>
> Hmm, imho you can't really skip that part - or part about "why split RT
> into eligible/deadline" to see the mechanics behind RT curves.
<grin> I did eventually realize that which is why I stopped the email in
mid-stream and took several hours to work through it and then deleted
half of what I wrote :)
>
> >
> > <snip>
>
> > Thus, if all the traffic were to be backlogged at m1 rates, we would
> > overrun the circuit.
>
> Curves don't really change that in any way.
Yes, I suppose that was my point just phrased a different way - in other
words, if we are careless or ignorant about curves, we can get ourselves
in trouble!
>
> If you did the above for m1 (or m2) for RT curves, the eligiblity would
> lose the point (leafs would always be eligible), and the whole thing
> would kind-of degenerate into more complex version of LS. There's a
> reason why BSDs won't even let you define RT curves that sum at any
> point to more than 80% (aside keeping LS useful, perhaps also related to
> thier timer resolution [years ago]). Unless they changed it in recent
> versions - I didn't really have any modern BSD under my hands for a
> while.
>
> > and the sum of their m1 curves > circuit capacity because, operating
> > under my false assumption, this is only for that temporary boost. If
> > all five classes receive their first packet at the identical moment,
> > we will fail to meet the guarantees.
>
> I'd say more aggressive eliglibility and earlier deadline - than any
> boost.
Yes, granted. What I'm trying to do in the documentation is translate
the model's mathematical concepts into concepts more germane to system
administrators. A sys admin is not very likely to think in terms of
deadline times but will think, "I've got a momentary boost in bandwidth
to allow me to ensure proper latency for time sensitive traffic." Of
course, that could be where I'm getting in trouble :)
> Which will briefly (if enough leafs are backlogged) turn whole
> carefully designed RT mechanics into dimensionless LS-like thingy. So -
> while that is possible - why do it ? Setup RT that fits the achievable
> speed, and leave the excess bandwidth to LS.
Because doing so would recouple bandwidth and latency, I think - that's
what I'm trying to sort through and will address more fully toward the
end of this reply.
>
> Whole RT design - with eligible/deadline split - is to allow convex
> curves to send "earlier", pushing the deadlines to the "right" - which
> in turn allows newly backlogged class to have brief priority. But it all
> remains under interface limit and over-time fulfills guarantees (even if
> locally they are violated).
To the right? I would have thought to the left on the x axis, i.e., the
deadline time becomes sooner? Ah, unless you are referring to the other
queue's deadline times and mean not literally changing the deadline time
but jumping in front of the ones on the right of the new queue's
deadline time.
>
> > I realize I am babbling in my own context so let me state in another
> > way in case I'm not being clear. My concern was that, if the four
> > classes are continuously backlogged and the fifth class with a concave
> > rt service curve constantly goes idle and then immediately receives a
> > packet, it will always be transmitting at the m1 rate and thus exceed
> > the capacity of the circuit (since the sum of the five m2 curves =
> > capacity and the m1 of the fifth class is greater than the m2 of the
> > fifth class).
>
> Actually it won't. See what I wrote about the eligible/deadline above.
> The 4 classes (suppose they are under convex RT) will be eligible
> earlier than they would normally be (and send more). When the 5th class
> becomes active with its steeper m1, it literally "has a green light" to
> send whenever it's eligible, as the deadlines of the 4 classes are
> further to the right. If all classes remain backlogged from now on, it
> all evens out properly. If the 5th goes idle, other classes will
> "buffer up" again (from a lack of better term).
Right - that was why I put my concern in the past tense. Once I
realized how the curves updated, I realized my concern was not valid. I
left it there to give context to the rest of the email.
>
> > So now I'll put my practical hat back on where practice will violate
> > theory but with no practical deleterious effect except in the most
> > extreme cases. I propose that, from a practical, system administrator
> > perspective, it is feasible and probably ideal to define rt service
> > curves so that the sum of all m2 curves<= circuit
>
> Going above would really make LS pointless, and turn RT into LS-like
> thing (see above).
>
> > curves should be specified to meet latency requirements REGARDLESS OF
> > EXCEEDING CIRCUIT CAPACITY.
>
> Again (see above) - that will not get you anywhere. m1 or m2 (look at
> the curve as a whole, not just its parts) - it just makes RT lose its
> properties and actual meaning behind numbers. Briefly, but still.
Perhaps but here is my thinking (which may be quite wrong) and why I
said earlier, doing what you propose seems to recouple bandwidth and
latency (although I do realize they are ultimately linked and the m1/m2
split is really manipulating early bandwidth to achieve independent
latency guarantees).
Where I am focused (and perhaps stuck) is the idea of decoupling latency
and bandwidth guarantees. ls curves, like the m2 portion of the rt
curves seem to have more to do with sustained bandwidth when excess
available bandwidth is available. I'm assuming in contrast that the m1
portion of the rt curve is for momentarily increasing bandwidth to help
move time sensitive traffic to the head of the queues when the class
first becomes active. On the other hand, I do see that, in almost all
my examples, when I have allocated ls ratios differently from the m2
portion of the rt curve, it has been to allocate bandwidth more
aggressively to the time sensitive applications. Perhaps this is what
you are telling me when you say use ls instead of oversubscribing m1 -
just using different words :)
The thought behind oversubscribing m1 . . . well . . . not intentionally
oversubscribing - just not being very careful about setting m1 to make
sure it is not oversubscribed (perhaps I wasn't clear that the
oversubscription is not intentional) - is that it is not likely that all
queues are continually backlogged thus I can get away with an accidental
over-allocation in most cases as it will quickly sort itself out as soon
as a queue goes idle. As a result, I can calculate m1 solely based upon
the latency requirements of the traffic not accounting for the impact of
the bandwidth momentarily required to do that, i.e., not being too
concerned if I have accidentally oversubscribed m1.
The advantages of doing it via the m1 portion of the rt curve rather
than the ls curve are:
1) It is guaranteed whereas the ls will only work when there is
available bandwidth. Granted, my assumption that it is rare for all
classes to be continually backlogged implies there is always some extra
bandwidth available. And granted that it is not guaranteed if too many
oversubscribed m1's kick in at the same time.
2) It seems less complicated than trying to figure out what my possibly
available ls ratios should be to meet my latency requirements (which
then also recouples bandwidth and latency). m1 is much more direct and
reliable.
This is where you and I seem to differ (and I gladly defer to the fact
that you know 10,000 times more about this than I do!). Is that because
we are prioritizing differently ("how can I do this simply with clear
divisions between latency and bandwidth even if it momentarily violates
the model" versus "how do we preserve the model from momentarily
degrading") or because I have missed the point somewhere and focusing so
obsessively on separating latency and bandwidth guarantees is obscuring
my ability to see how doing this via ls ratios is more advantageous?
>
<snip>
>
> ps.
> Going through other mails will take me far more time I think.
>
No problem; I greatly appreciate all the time you've taken to help me
understand this and hope I am coming across as exploring rather than
being argumentative. I hope the resulting documentation will, in a
small way, help return the favor.
The most important other email by far and away is the "An error in my
HFSC sysadmin documentation" which is fairly short. The long ones are
just the resultant documentation which I should eventually submit to you
in a graphics supporting format anyway.
Thank you very much as always - John
^ permalink raw reply
* Re: [PATCH v9 0/9] Request for inclusion: per-cgroup tcp memory pressure controls
From: Glauber Costa @ 2011-12-15 6:48 UTC (permalink / raw)
To: David Miller
Cc: kamezawa.hiroyu, linux-kernel, paul, lizf, ebiederm, gthelen,
netdev, linux-mm, kirill, avagin, devel, eric.dumazet, cgroups
In-Reply-To: <20111215.004836.402973956281143052.davem@davemloft.net>
On 12/15/2011 09:48 AM, David Miller wrote:
> From: KAMEZAWA Hiroyuki<kamezawa.hiroyu@jp.fujitsu.com>
> Date: Thu, 15 Dec 2011 14:40:19 +0900
>
>> I met this bug at _1st_ run. Please enable _all_ debug options!.
>
> Plus the CONFIG_NET=n and other build failures.
>
> This patch series was seriously rushed, and very poorly handled.
>
> Yet I kept getting so much pressure to review, comment upon, and
> ultimately apply these patches. Never, ever, do this to me ever
> again.
>
> If I don't feel your patches are high priority enough or ready enough
> for me to review, then TOO BAD. Don't ask people to pressure me or
> get my attention. Instead, ask others for help and do testing before
> wasting MY time and crapping up MY tree.
>
> I should have noticed a red flag when I have James Bottomly asking me
> to look at these patches, I should have pushed back. Instead, I
> relented, and now I'm very seriously regretting it.
>
> All the regressions in the net-next tree over the past several days
> have been due to this patch set, and this patch set alone.
>
> This code wasn't ready and needed, at a minimum, several more weeks of
> work before being put in.
>
> Instead, we're going to bandaid patch it up after the fact, rather
> than just letting these changes mature naturally during the review
> process.
Hi Dave,
You are right about all points. I will admit to it, face it, and
apologize it.
I guess the best I can do right now is fix whatever you guys point me to
and not repeat it in the future.
Thanks
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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