* Re: [PATCH net-next] net/cadence: depend on HAS_IOMEM
From: Nicolas Ferre @ 2012-10-29 14:48 UTC (permalink / raw)
To: Joachim Eastwood; +Cc: davem, fengguang.wu, netdev
In-Reply-To: <1351339823-24987-1-git-send-email-manabian@gmail.com>
On 10/27/2012 02:10 PM, Joachim Eastwood :
> Fixes the following build failure on S390:
> In file included from drivers/net/ethernet/cadence/at91_ether.c:35:0:
> drivers/net/ethernet/cadence/macb.h: In function 'macb_is_gem':
> drivers/net/ethernet/cadence/macb.h:563:2: error: implicit declaration of function '__raw_readl' [-Werror=implicit-function-declaration]
> drivers/net/ethernet/cadence/at91_ether.c: In function 'update_mac_address':
> drivers/net/ethernet/cadence/at91_ether.c:119:2: error: implicit declaration of function '__raw_writel' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/net/ethernet/cadence/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/ethernet/cadence/Kconfig b/drivers/net/ethernet/cadence/Kconfig
> index 40172d1..ceb0de0 100644
> --- a/drivers/net/ethernet/cadence/Kconfig
> +++ b/drivers/net/ethernet/cadence/Kconfig
> @@ -4,6 +4,7 @@
>
> config NET_CADENCE
> bool "Cadence devices"
> + depends on HAS_IOMEM
> default y
> ---help---
> If you have a network (Ethernet) card belonging to this class, say Y.
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH v7 15/16] openvswitch: use new hashtable implementation
From: Mathieu Desnoyers @ 2012-10-29 13:29 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, tj, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, axboe, agk, dm-devel, neilb, ccaulfie, teigland,
Trond.Myklebust, bfields, fweisbec, jesse, venkat.x.venkatsubra,
ejt, snitzer, edumazet, linux-nfs, dev, rds-devel, lw
In-Reply-To: <1351450948-15618-15-git-send-email-levinsasha928@gmail.com>
* Sasha Levin (levinsasha928@gmail.com) wrote:
[...]
> -static struct hlist_head *hash_bucket(struct net *net, const char *name)
> -{
> - unsigned int hash = jhash(name, strlen(name), (unsigned long) net);
> - return &dev_table[hash & (VPORT_HASH_BUCKETS - 1)];
> -}
> -
> /**
> * ovs_vport_locate - find a port that has already been created
> *
> @@ -84,13 +76,12 @@ static struct hlist_head *hash_bucket(struct net *net, const char *name)
> */
> struct vport *ovs_vport_locate(struct net *net, const char *name)
> {
> - struct hlist_head *bucket = hash_bucket(net, name);
> struct vport *vport;
> struct hlist_node *node;
> + int key = full_name_hash(name, strlen(name));
>
> - hlist_for_each_entry_rcu(vport, node, bucket, hash_node)
> - if (!strcmp(name, vport->ops->get_name(vport)) &&
> - net_eq(ovs_dp_get_net(vport->dp), net))
> + hash_for_each_possible_rcu(dev_table, vport, node, hash_node, key)
Is applying hash_32() on top of full_name_hash() needed and expected ?
Thanks,
Mathieu
> + if (!strcmp(name, vport->ops->get_name(vport)))
> return vport;
>
> return NULL;
> @@ -174,7 +165,8 @@ struct vport *ovs_vport_add(const struct vport_parms *parms)
>
> for (i = 0; i < ARRAY_SIZE(vport_ops_list); i++) {
> if (vport_ops_list[i]->type == parms->type) {
> - struct hlist_head *bucket;
> + int key;
> + const char *name;
>
> vport = vport_ops_list[i]->create(parms);
> if (IS_ERR(vport)) {
> @@ -182,9 +174,9 @@ struct vport *ovs_vport_add(const struct vport_parms *parms)
> goto out;
> }
>
> - bucket = hash_bucket(ovs_dp_get_net(vport->dp),
> - vport->ops->get_name(vport));
> - hlist_add_head_rcu(&vport->hash_node, bucket);
> + name = vport->ops->get_name(vport);
> + key = full_name_hash(name, strlen(name));
> + hash_add_rcu(dev_table, &vport->hash_node, key);
> return vport;
> }
> }
> @@ -225,7 +217,7 @@ void ovs_vport_del(struct vport *vport)
> {
> ASSERT_RTNL();
>
> - hlist_del_rcu(&vport->hash_node);
> + hash_del_rcu(&vport->hash_node);
>
> vport->ops->destroy(vport);
> }
> --
> 1.7.12.4
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v7 14/16] net,rds: use new hashtable implementation
From: Mathieu Desnoyers @ 2012-10-29 13:25 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tj-DgEjT+Ai2ygdnm+yROfE0A, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, rostedt-nx8X9YLhiw1AfugRpC6u6w,
mingo-X9Un+BFzKDI, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w, axboe-tSWWG44O7X1aa/9Udqfwiw,
agk-H+wXaHxf7aLQT0dZR+AlfA, dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
neilb-l3A5Bk7waGM, ccaulfie-H+wXaHxf7aLQT0dZR+AlfA,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <1351450948-15618-14-git-send-email-levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
* Sasha Levin (levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) wrote:
> Switch rds to use the new hashtable implementation. This reduces the amount of
> generic unrelated code in rds.
>
> Signed-off-by: Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> net/rds/bind.c | 28 +++++++++-----
> net/rds/connection.c | 102 +++++++++++++++++++++++----------------------------
> 2 files changed, 63 insertions(+), 67 deletions(-)
>
> diff --git a/net/rds/bind.c b/net/rds/bind.c
> index 637bde5..79d65ce 100644
> --- a/net/rds/bind.c
> +++ b/net/rds/bind.c
> @@ -36,16 +36,16 @@
> #include <linux/if_arp.h>
> #include <linux/jhash.h>
> #include <linux/ratelimit.h>
> +#include <linux/hashtable.h>
> #include "rds.h"
>
> -#define BIND_HASH_SIZE 1024
> -static struct hlist_head bind_hash_table[BIND_HASH_SIZE];
> +#define BIND_HASH_BITS 10
> +static DEFINE_HASHTABLE(bind_hash_table, BIND_HASH_BITS);
> static DEFINE_SPINLOCK(rds_bind_lock);
>
> -static struct hlist_head *hash_to_bucket(__be32 addr, __be16 port)
> +static u32 rds_hash(__be32 addr, __be16 port)
> {
> - return bind_hash_table + (jhash_2words((u32)addr, (u32)port, 0) &
> - (BIND_HASH_SIZE - 1));
> + return jhash_2words((u32)addr, (u32)port, 0);
> }
>
> static struct rds_sock *rds_bind_lookup(__be32 addr, __be16 port,
> @@ -53,12 +53,12 @@ static struct rds_sock *rds_bind_lookup(__be32 addr, __be16 port,
> {
> struct rds_sock *rs;
> struct hlist_node *node;
> - struct hlist_head *head = hash_to_bucket(addr, port);
> + u32 key = rds_hash(addr, port);
> u64 cmp;
> u64 needle = ((u64)be32_to_cpu(addr) << 32) | be16_to_cpu(port);
>
> rcu_read_lock();
> - hlist_for_each_entry_rcu(rs, node, head, rs_bound_node) {
> + hash_for_each_possible_rcu(bind_hash_table, rs, node, rs_bound_node, key) {
here too, key will be hashed twice:
- once by jhash_2words,
- once by hash_32(),
is this intended ?
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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
* Re: [PATCH v7 13/16] lockd: use new hashtable implementation
From: Mathieu Desnoyers @ 2012-10-29 13:23 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tj-DgEjT+Ai2ygdnm+yROfE0A, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, rostedt-nx8X9YLhiw1AfugRpC6u6w,
mingo-X9Un+BFzKDI, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w, axboe-tSWWG44O7X1aa/9Udqfwiw,
agk-H+wXaHxf7aLQT0dZR+AlfA, dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
neilb-l3A5Bk7waGM, ccaulfie-H+wXaHxf7aLQT0dZR+AlfA,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <1351450948-15618-13-git-send-email-levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
* Sasha Levin (levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) wrote:
> Switch lockd to use the new hashtable implementation. This reduces the amount of
> generic unrelated code in lockd.
>
> Signed-off-by: Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> fs/lockd/svcsubs.c | 66 +++++++++++++++++++++++++++++-------------------------
> 1 file changed, 36 insertions(+), 30 deletions(-)
>
> diff --git a/fs/lockd/svcsubs.c b/fs/lockd/svcsubs.c
> index 0deb5f6..d223a1f 100644
> --- a/fs/lockd/svcsubs.c
> +++ b/fs/lockd/svcsubs.c
> @@ -20,6 +20,7 @@
> #include <linux/lockd/share.h>
> #include <linux/module.h>
> #include <linux/mount.h>
> +#include <linux/hashtable.h>
>
> #define NLMDBG_FACILITY NLMDBG_SVCSUBS
>
> @@ -28,8 +29,7 @@
> * Global file hash table
> */
> #define FILE_HASH_BITS 7
> -#define FILE_NRHASH (1<<FILE_HASH_BITS)
> -static struct hlist_head nlm_files[FILE_NRHASH];
> +static DEFINE_HASHTABLE(nlm_files, FILE_HASH_BITS);
> static DEFINE_MUTEX(nlm_file_mutex);
>
> #ifdef NFSD_DEBUG
> @@ -68,7 +68,7 @@ static inline unsigned int file_hash(struct nfs_fh *f)
> int i;
> for (i=0; i<NFS2_FHSIZE;i++)
> tmp += f->data[i];
> - return tmp & (FILE_NRHASH - 1);
> + return tmp;
> }
>
> /*
> @@ -86,17 +86,17 @@ nlm_lookup_file(struct svc_rqst *rqstp, struct nlm_file **result,
> {
> struct hlist_node *pos;
> struct nlm_file *file;
> - unsigned int hash;
> + unsigned int key;
> __be32 nfserr;
>
> nlm_debug_print_fh("nlm_lookup_file", f);
>
> - hash = file_hash(f);
> + key = file_hash(f);
>
> /* Lock file table */
> mutex_lock(&nlm_file_mutex);
>
> - hlist_for_each_entry(file, pos, &nlm_files[hash], f_list)
> + hash_for_each_possible(nlm_files, file, pos, f_list, file_hash(f))
we have a nice example of weirdness about key vs hash here:
1) "key" is computed from file_hash(f)
2) file_hash(f) is computed again and again in hash_for_each_possible()
> if (!nfs_compare_fh(&file->f_handle, f))
> goto found;
>
> @@ -123,7 +123,7 @@ nlm_lookup_file(struct svc_rqst *rqstp, struct nlm_file **result,
> goto out_free;
> }
>
> - hlist_add_head(&file->f_list, &nlm_files[hash]);
> + hash_add(nlm_files, &file->f_list, key);
3) then we use "key" as parameter to hash_add.
Moreover, we're adding dispersion to the file_hash() with the hash_32()
called under the hook within hashtable.h. Is it an intended behavior ?
This should at the very least be documented in the changelog.
[...]
> +static int __init nlm_init(void)
> +{
> + hash_init(nlm_files);
Useless.
Thanks,
Mathieu
> + return 0;
> +}
> +
> +module_init(nlm_init);
> --
> 1.7.12.4
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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
* Re: [PATCH v7 10/16] dlm: use new hashtable implementation
From: Mathieu Desnoyers @ 2012-10-29 13:07 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, tj, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, axboe, agk, dm-devel, neilb, ccaulfie, teigland,
Trond.Myklebust, bfields, fweisbec, jesse, venkat.x.venkatsubra,
ejt, snitzer, edumazet, linux-nfs, dev, rds-devel, lw
In-Reply-To: <20121029124655.GD11733@Krystal>
* Mathieu Desnoyers (mathieu.desnoyers@efficios.com) wrote:
> * Sasha Levin (levinsasha928@gmail.com) wrote:
> [...]
> > @@ -158,34 +159,21 @@ static int dlm_allow_conn;
> > static struct workqueue_struct *recv_workqueue;
> > static struct workqueue_struct *send_workqueue;
> >
> > -static struct hlist_head connection_hash[CONN_HASH_SIZE];
> > +static struct hlist_head connection_hash[CONN_HASH_BITS];
> > static DEFINE_MUTEX(connections_lock);
> > static struct kmem_cache *con_cache;
> >
> > static void process_recv_sockets(struct work_struct *work);
> > static void process_send_sockets(struct work_struct *work);
> >
> > -
> > -/* This is deliberately very simple because most clusters have simple
> > - sequential nodeids, so we should be able to go straight to a connection
> > - struct in the array */
> > -static inline int nodeid_hash(int nodeid)
> > -{
> > - return nodeid & (CONN_HASH_SIZE-1);
> > -}
>
> There is one thing I dislike about this change: you remove a useful
> comment. It's good to be informed of the reason why a direct mapping
> "value -> hash" without any dispersion function is preferred here.
And now that I come to think of it: you're changing the behavior : you
will now use a dispersion function on the key, which goes against the
intent expressed in this comment.
It might be good to change hash_add(), hash_add_rcu(),
hash_for_each_possible*() key parameter for a "hash" parameter, and let
the caller provide the hash value computed by the function they like as
parameter, rather than enforcing hash_32/hash_64.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v7 11/16] net,l2tp: use new hashtable implementation
From: Mathieu Desnoyers @ 2012-10-29 13:04 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, tj, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, axboe, agk, dm-devel, neilb, ccaulfie, teigland,
Trond.Myklebust, bfields, fweisbec, jesse, venkat.x.venkatsubra,
ejt, snitzer, edumazet, linux-nfs, dev, rds-devel, lw
In-Reply-To: <1351450948-15618-11-git-send-email-levinsasha928@gmail.com>
* Sasha Levin (levinsasha928@gmail.com) wrote:
[...]
> -/* Session hash global list for L2TPv3.
> - * The session_id SHOULD be random according to RFC3931, but several
> - * L2TP implementations use incrementing session_ids. So we do a real
> - * hash on the session_id, rather than a simple bitmask.
> - */
> -static inline struct hlist_head *
> -l2tp_session_id_hash_2(struct l2tp_net *pn, u32 session_id)
> -{
> - return &pn->l2tp_session_hlist[hash_32(session_id, L2TP_HASH_BITS_2)];
> -
> -}
I understand that you removed this hash function, as well as
"l2tp_session_id_hash" below, but is there any way we could leave those
comments in place ? They look useful.
> -/* Session hash list.
> - * The session_id SHOULD be random according to RFC2661, but several
> - * L2TP implementations (Cisco and Microsoft) use incrementing
> - * session_ids. So we do a real hash on the session_id, rather than a
> - * simple bitmask.
Ditto.
> - */
> -static inline struct hlist_head *
> -l2tp_session_id_hash(struct l2tp_tunnel *tunnel, u32 session_id)
> -{
> - return &tunnel->session_hlist[hash_32(session_id, L2TP_HASH_BITS)];
> -}
> -
> /* Lookup a session by id
> */
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: 3.7-rc3 oops on reboot
From: Roland Stigge @ 2012-10-29 12:49 UTC (permalink / raw)
To: Alexandre Pereira da Silva
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel
In-Reply-To: <CAAAP30E-g3YdXOMvfueDQZREZ+_Adi2uhxgLeqKixkupU+QNhA@mail.gmail.com>
On 10/29/2012 01:08 PM, Alexandre Pereira da Silva wrote:
> I am getting oops on 3.7-rc3 at reboot.
>
> This is an LPC32XX machine. This problem only happens when I connect
> the ethernet cable and get an IP address.
>
> Here are the kernel messages.
> [ 38.570000] Unable to handle kernel paging request at virtual
> address a0000014
> [ 38.570000] pgd = c1730000
> [ 38.580000] [a0000014] *pgd=00000000
> [ 38.580000] Internal error: Oops: 5 [#1] PREEMPT ARM
> [ 38.580000] Modules linked in:
> [ 38.580000] CPU: 0 Not tainted (3.7.0-rc3 #4)
> [ 38.580000] PC is at trie_firstleaf+0xc/0x2c
> [ 38.580000] LR is at fib_table_flush+0x1c/0x170
> [ 38.580000] pc : [<c029659c>] lr : [<c0298dec>] psr: a0000013
> [ 38.580000] sp : c1719d50 ip : c1719d60 fp : c1719d5c
> [ 38.580000] r10: 00000000 r9 : 00000000 r8 : c16341e0
> [ 38.580000] r7 : c09d2c24 r6 : 00000001 r5 : a0000000 r4 : 000003fc
> [ 38.580000] r3 : c18dac00 r2 : c09c6fc0 r1 : c09c6fc0 r0 : a0000014
> [ 38.580000] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> [ 38.580000] Control: 0005317f Table: 81730000 DAC: 00000015
> [ 38.580000] Process ifconfig (pid: 396, stack limit = 0xc17181b8)
> [ 38.580000] Stack: (0xc1719d50 to 0xc171a000)
> [ 38.580000] 9d40: c1719d9c
> c1719d60 c0298dec c02965a0
> [ 38.580000] 9d60: c170f308 c14d42e0 00000000 a0000014 c16341e0
> 000003fc a0000000 00000001
> [ 38.580000] 9d80: c09d2c24 c16341e0 00000000 00000000 c1719dbc
> c1719da0 c0294244 c0298de0
> [ 38.580000] 9da0: c160f800 c160f800 ffffffff 00000000 c1719dd4
> c1719dc0 c0294294 c0294224
> [ 38.580000] 9dc0: 00000000 c16341e0 c1719dec c1719dd8 c0294bf0
> c0294284 00000002 00000000
> [ 38.580000] 9de0: c1719e14 c1719df0 c003e810 c0294b60 ffffffff
> c09d4698 ffffffff c16341e0
> [ 38.580000] 9e00: 00000002 00000000 c1719e3c c1719e18 c003ea9c
> c003e7e0 00000000 c1719e28
> [ 38.580000] 9e20: c16341e0 00000000 00000000 c16341e0 c1719e54
> c1719e40 c003ead4 c003ea5c
> [ 38.580000] 9e40: 00000000 00000000 c1719e8c c1719e58 c028b9bc
> c003eac4 00000000 c145edec
> [ 38.580000] 9e60: c1719e8c c16341e0 00000000 c160f800 c145ede0
> c145edec 00000000 00000000
> [ 38.580000] 9e80: c1719ea4 c1719e90 c028ba94 c028b828 00000000
> c09d2c24 c1719f14 c1719ea8
> [ 38.580000] 9ea0: c028d278 c028ba88 c003d890 00000000 00008916
> bef74c18 30687465 00000000
> [ 38.580000] 9ec0: 00000000 00000000 00000002 00000000 00000001
> 00084a10 00000002 00000000
> [ 38.580000] 9ee0: 00000001 00084a10 00001000 00008914 bef74c18
> bef74c18 00008916 00000003
> [ 38.580000] 9f00: c1718000 00000000 c1719f2c c1719f18 c028e284
> c028cf18 c1404420 00008916
> [ 38.580000] 9f20: c1719f4c c1719f30 c022ed8c c028e1c4 c022eb6c
> 00000003 bef74c18 bef74c18
> [ 38.580000] 9f40: c1719f74 c1719f50 c009e5e8 c022eb7c 000ac000
> 000ad000 bef74c18 00008916
> [ 38.580000] 9f60: c14dcbe0 00000000 c1719fa4 c1719f78 c009e66c
> c009e304 c0080184 00000000
> [ 38.580000] 9f80: b6f73ee4 bef74c18 00008916 00000003 00000036
> c000e224 00000000 c1719fa8
> [ 38.580000] 9fa0: c000e0c0 c009e638 bef74c18 00008916 00000003
> 00008916 bef74c18 00000000
> [ 38.580000] 9fc0: bef74c18 00008916 00000003 00000036 00085a28
> 00000000 000859a8 00000000
> [ 38.580000] 9fe0: b6f2bde4 bef74bc0 0000ddb4 b6f2be28 60000010
> 00000003 00000000 00000000
> [ 38.580000] Backtrace:
> [ 38.580000] [<c0296590>] (trie_firstleaf+0x0/0x2c) from
> [<c0298dec>] (fib_table_flush+0x1c/0x170)
> [ 38.580000] [<c0298dd0>] (fib_table_flush+0x0/0x170) from
> [<c0294244>] (fib_flush.clone.27+0x30/0x60)
> [ 38.580000] [<c0294214>] (fib_flush.clone.27+0x0/0x60) from
> [<c0294294>] (fib_disable_ip+0x20/0x38)
> [ 38.580000] r7:00000000 r6:ffffffff r5:c160f800 r4:c160f800
> [ 38.580000] [<c0294274>] (fib_disable_ip+0x0/0x38) from
> [<c0294bf0>] (fib_inetaddr_event+0xa0/0xb4)
> [ 38.580000] r4:c16341e0 r3:00000000
> [ 38.580000] [<c0294b50>] (fib_inetaddr_event+0x0/0xb4) from
> [<c003e810>] (notifier_call_chain+0x40/0x70)
> [ 38.580000] r5:00000000 r4:00000002
> [ 38.580000] [<c003e7d0>] (notifier_call_chain+0x0/0x70) from
> [<c003ea9c>] (__blocking_notifier_call_chain+0x50/0x68)
> [ 38.580000] r8:00000000 r7:00000002 r6:c16341e0 r5:ffffffff r4:c09d4698
> r3:ffffffff
> [ 38.580000] [<c003ea4c>] (__blocking_notifier_call_chain+0x0/0x68)
> from [<c003ead4>] (blocking_notifier_call_chain+0x20/0x28)
> [ 38.580000] r7:c16341e0 r6:00000000 r5:00000000 r4:c16341e0
> [ 38.580000] [<c003eab4>] (blocking_notifier_call_chain+0x0/0x28)
> from [<c028b9bc>] (__inet_del_ifa+0x1a4/0x260)
> [ 38.580000] [<c028b818>] (__inet_del_ifa+0x0/0x260) from
> [<c028ba94>] (inet_del_ifa+0x1c/0x24)
> [ 38.580000] [<c028ba78>] (inet_del_ifa+0x0/0x24) from [<c028d278>]
> (devinet_ioctl+0x370/0x634)
> [ 38.580000] [<c028cf08>] (devinet_ioctl+0x0/0x634) from
> [<c028e284>] (inet_ioctl+0xd0/0x110)
> [ 38.580000] [<c028e1b4>] (inet_ioctl+0x0/0x110) from [<c022ed8c>]
> (sock_ioctl+0x220/0x278)
> [ 38.580000] r4:00008916 r3:c1404420
> [ 38.580000] [<c022eb6c>] (sock_ioctl+0x0/0x278) from [<c009e5e8>]
> (do_vfs_ioctl+0x2f4/0x334)
> [ 38.580000] r6:bef74c18 r5:bef74c18 r4:00000003 r3:c022eb6c
> [ 38.580000] [<c009e2f4>] (do_vfs_ioctl+0x0/0x334) from [<c009e66c>]
> (sys_ioctl+0x44/0x64)
> [ 38.580000] r5:00000000 r4:c14dcbe0
> [ 38.580000] [<c009e628>] (sys_ioctl+0x0/0x64) from [<c000e0c0>]
> (ret_fast_syscall+0x0/0x2c)
> [ 38.580000] r8:c000e224 r7:00000036 r6:00000003 r5:00008916 r4:bef74c18
> [ 38.580000] Code: e89da810 e1a0c00d e92dd800 e24cb004 (e5900000)
> [ 39.040000] ---[ end trace 1e122706a9f64743 ]---
>
> Do anybody have any idea what may have happened there?
I just tried both on a PHY3250 reference machine, and on a custom board
and couldn't reproduce sth. like this. Booted the kernel and connected
the ethernet cable later on, as well as with cable connected on boot.
Any related patches applied? Can you reproduce this on a reference
machine? Can you provide a .config for this? Any more detail about how
this could be reproduced?
Thanks in advance,
Roland
^ permalink raw reply
* Re: [PATCH v7 10/16] dlm: use new hashtable implementation
From: Mathieu Desnoyers @ 2012-10-29 12:46 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tj-DgEjT+Ai2ygdnm+yROfE0A, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, rostedt-nx8X9YLhiw1AfugRpC6u6w,
mingo-X9Un+BFzKDI, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w, axboe-tSWWG44O7X1aa/9Udqfwiw,
agk-H+wXaHxf7aLQT0dZR+AlfA, dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
neilb-l3A5Bk7waGM, ccaulfie-H+wXaHxf7aLQT0dZR+AlfA,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <1351450948-15618-10-git-send-email-levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
* Sasha Levin (levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) wrote:
[...]
> @@ -158,34 +159,21 @@ static int dlm_allow_conn;
> static struct workqueue_struct *recv_workqueue;
> static struct workqueue_struct *send_workqueue;
>
> -static struct hlist_head connection_hash[CONN_HASH_SIZE];
> +static struct hlist_head connection_hash[CONN_HASH_BITS];
> static DEFINE_MUTEX(connections_lock);
> static struct kmem_cache *con_cache;
>
> static void process_recv_sockets(struct work_struct *work);
> static void process_send_sockets(struct work_struct *work);
>
> -
> -/* This is deliberately very simple because most clusters have simple
> - sequential nodeids, so we should be able to go straight to a connection
> - struct in the array */
> -static inline int nodeid_hash(int nodeid)
> -{
> - return nodeid & (CONN_HASH_SIZE-1);
> -}
There is one thing I dislike about this change: you remove a useful
comment. It's good to be informed of the reason why a direct mapping
"value -> hash" without any dispersion function is preferred here.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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
* Re: [PATCH v7 09/16] SUNRPC/cache: use new hashtable implementation
From: Mathieu Desnoyers @ 2012-10-29 12:42 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, tj, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, axboe, agk, dm-devel, neilb, ccaulfie, teigland,
Trond.Myklebust, bfields, fweisbec, jesse, venkat.x.venkatsubra,
ejt, snitzer, edumazet, linux-nfs, dev, rds-devel, lw
In-Reply-To: <1351450948-15618-9-git-send-email-levinsasha928@gmail.com>
* Sasha Levin (levinsasha928@gmail.com) wrote:
> Switch cache to use the new hashtable implementation. This reduces the amount of
> generic unrelated code in the cache implementation.
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> ---
> net/sunrpc/cache.c | 20 +++++++++-----------
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/net/sunrpc/cache.c b/net/sunrpc/cache.c
> index fc2f7aa..0490546 100644
> --- a/net/sunrpc/cache.c
> +++ b/net/sunrpc/cache.c
> @@ -28,6 +28,7 @@
> #include <linux/workqueue.h>
> #include <linux/mutex.h>
> #include <linux/pagemap.h>
> +#include <linux/hashtable.h>
> #include <asm/ioctls.h>
> #include <linux/sunrpc/types.h>
> #include <linux/sunrpc/cache.h>
> @@ -524,19 +525,18 @@ EXPORT_SYMBOL_GPL(cache_purge);
> * it to be revisited when cache info is available
> */
>
> -#define DFR_HASHSIZE (PAGE_SIZE/sizeof(struct list_head))
> -#define DFR_HASH(item) ((((long)item)>>4 ^ (((long)item)>>13)) % DFR_HASHSIZE)
> +#define DFR_HASH_BITS 9
If we look at a bit of history, mainly commit:
commit 1117449276bb909b029ed0b9ba13f53e4784db9d
Author: NeilBrown <neilb@suse.de>
Date: Thu Aug 12 17:04:08 2010 +1000
sunrpc/cache: change deferred-request hash table to use hlist.
we'll notice that the only reason why the prior DFR_HASHSIZE was using
(PAGE_SIZE/sizeof(struct list_head))
instead of
(PAGE_SIZE/sizeof(struct hlist_head))
is because it has been forgotten in that commit. The intent there is to
make the hash table array fit the page size.
By defining DFR_HASH_BITS arbitrarily to "9", this indeed fulfills this
purpose on architectures with 4kB page size and 64-bit pointers, but not
on some powerpc configurations, and Tile architectures, which have more
exotic 64kB page size, and of course on the far less exotic 32-bit
pointer architectures.
So defining e.g.:
#include <linux/log2.h>
#define DFR_HASH_BITS (PAGE_SHIFT - ilog2(BITS_PER_LONG))
would keep the intended behavior in all cases: use one page for the hash
array.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH v3 6/6] USB: forbid memory allocation with I/O during bus reset
From: Ming Lei @ 2012-10-29 12:24 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei
In-Reply-To: <1351513440-9286-1-git-send-email-ming.lei@canonical.com>
If one storage interface or usb network interface(iSCSI case)
exists in current configuration, memory allocation with
GFP_KERNEL during usb_device_reset() might trigger I/O transfer
on the storage interface itself and cause deadlock because
the 'us->dev_mutex' is held in .pre_reset() and the storage
interface can't do I/O transfer when the reset is triggered
by other interface, or the error handling can't be completed
if the reset is triggered by the storage itself(error handling path).
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
v3:
- check usbnet device or usb mass storage device by
'dev->power.memalloc_noio_resume' as suggested by Alan Stern
---
drivers/usb/core/hub.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 5b131b6..5aea807 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5044,6 +5044,8 @@ int usb_reset_device(struct usb_device *udev)
{
int ret;
int i;
+ unsigned int uninitialized_var(noio_flag);
+ bool noio_set = false;
struct usb_host_config *config = udev->actconfig;
if (udev->state == USB_STATE_NOTATTACHED ||
@@ -5053,6 +5055,17 @@ int usb_reset_device(struct usb_device *udev)
return -EINVAL;
}
+ /*
+ * Don't allocate memory with GFP_KERNEL in current
+ * context to avoid possible deadlock if usb mass
+ * storage interface or usbnet interface(iSCSI case)
+ * is included in current configuration.
+ */
+ if (pm_runtime_get_memalloc_noio(&udev->dev)) {
+ memalloc_noio_save(noio_flag);
+ noio_set = true;
+ }
+
/* Prevent autosuspend during the reset */
usb_autoresume_device(udev);
@@ -5097,6 +5110,8 @@ int usb_reset_device(struct usb_device *udev)
}
usb_autosuspend_device(udev);
+ if (noio_set)
+ memalloc_noio_restore(noio_flag);
return ret;
}
EXPORT_SYMBOL_GPL(usb_reset_device);
--
1.7.9.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v3 5/6] PM / Runtime: force memory allocation with no I/O during runtime_resume callbcack
From: Ming Lei @ 2012-10-29 12:23 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei
In-Reply-To: <1351513440-9286-1-git-send-email-ming.lei@canonical.com>
This patch applies the introduced memalloc_noio_save() and
memalloc_noio_restore() to force memory allocation with no I/O
during runtime_resume callback on device which is marked as
memalloc_noio_resume.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
drivers/base/power/runtime.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 9fa6ea7..c9e26b9 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -575,6 +575,7 @@ static int rpm_resume(struct device *dev, int rpmflags)
int (*callback)(struct device *);
struct device *parent = NULL;
int retval = 0;
+ unsigned int noio_flag;
trace_rpm_resume(dev, rpmflags);
@@ -724,7 +725,20 @@ static int rpm_resume(struct device *dev, int rpmflags)
if (!callback && dev->driver && dev->driver->pm)
callback = dev->driver->pm->runtime_resume;
- retval = rpm_callback(callback, dev);
+ /*
+ * Deadlock might be caused if memory allocation with GFP_KERNEL
+ * happens inside runtime_resume callback of one block device's
+ * ancestor or the block device itself. Network device might be
+ * thought as part of iSCSI block device, so network device and
+ * its ancestor should be marked as memalloc_noio_resume.
+ */
+ if (dev->power.memalloc_noio_resume) {
+ memalloc_noio_save(noio_flag);
+ retval = rpm_callback(callback, dev);
+ memalloc_noio_restore(noio_flag);
+ } else {
+ retval = rpm_callback(callback, dev);
+ }
if (retval) {
__update_runtime_status(dev, RPM_SUSPENDED);
pm_runtime_cancel_pending(dev);
--
1.7.9.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v3 4/6] net/core: apply pm_runtime_set_memalloc_noio on network devices
From: Ming Lei @ 2012-10-29 12:23 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei, Eric Dumazet,
David Decotigny, Tom Herbert, Ingo Molnar
In-Reply-To: <1351513440-9286-1-git-send-email-ming.lei@canonical.com>
Deadlock might be caused by allocating memory with GFP_KERNEL in
runtime_resume callback of network devices in iSCSI situation, so
mark network devices and its ancestor as 'memalloc_noio_resume'
with the introduced pm_runtime_set_memalloc_noio().
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Decotigny <david.decotigny@google.com>
Cc: Tom Herbert <therbert@google.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
net/core/net-sysfs.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index bcf02f6..9aba5be 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -22,6 +22,7 @@
#include <linux/vmalloc.h>
#include <linux/export.h>
#include <linux/jiffies.h>
+#include <linux/pm_runtime.h>
#include <net/wext.h>
#include "net-sysfs.h"
@@ -1386,6 +1387,8 @@ void netdev_unregister_kobject(struct net_device * net)
remove_queue_kobjects(net);
+ pm_runtime_set_memalloc_noio(dev, false);
+
device_del(dev);
}
@@ -1411,6 +1414,8 @@ int netdev_register_kobject(struct net_device *net)
*groups++ = &netstat_group;
#endif /* CONFIG_SYSFS */
+ pm_runtime_set_memalloc_noio(dev, true);
+
error = device_add(dev);
if (error)
return error;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 3/6] block/genhd.c: apply pm_runtime_set_memalloc_noio on block devices
From: Ming Lei @ 2012-10-29 12:23 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei
In-Reply-To: <1351513440-9286-1-git-send-email-ming.lei@canonical.com>
This patch applyes the introduced pm_runtime_set_memalloc_noio on
block device so that PM core will teach mm to not allocate memory with
GFP_IOFS when calling the runtime_resume callback for block devices.
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
block/genhd.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/block/genhd.c b/block/genhd.c
index 9e02cd6..c5f10ea 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -18,6 +18,7 @@
#include <linux/mutex.h>
#include <linux/idr.h>
#include <linux/log2.h>
+#include <linux/pm_runtime.h>
#include "blk.h"
@@ -519,6 +520,12 @@ static void register_disk(struct gendisk *disk)
dev_set_name(ddev, disk->disk_name);
+ /* avoid probable deadlock caused by allocate memory with
+ * GFP_KERNEL in runtime_resume callback of its all ancestor
+ * deivces
+ */
+ pm_runtime_set_memalloc_noio(ddev, true);
+
/* delay uevents, until we scanned partition table */
dev_set_uevent_suppress(ddev, 1);
@@ -661,6 +668,7 @@ void del_gendisk(struct gendisk *disk)
disk->driverfs_dev = NULL;
if (!sysfs_deprecated)
sysfs_remove_link(block_depr, dev_name(disk_to_dev(disk)));
+ pm_runtime_set_memalloc_noio(disk_to_dev(disk), false);
device_del(disk_to_dev(disk));
}
EXPORT_SYMBOL(del_gendisk);
--
1.7.9.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v3 2/6] PM / Runtime: introduce pm_runtime_set[get]_memalloc_noio()
From: Ming Lei @ 2012-10-29 12:23 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei
In-Reply-To: <1351513440-9286-1-git-send-email-ming.lei@canonical.com>
The patch introduces the flag of memalloc_noio_resume in
'struct dev_pm_info' to help PM core to teach mm not allocating
memory with GFP_KERNEL flag for avoiding probable deadlock
problem.
As explained in the comment, any GFP_KERNEL allocation inside
runtime_resume on any one of device in the path from one block
or network device to the root device in the device tree may cause
deadlock, the introduced pm_runtime_set_memalloc_noio() sets or
clears the flag on device of the path recursively.
This patch also introduces pm_runtime_get_memalloc_noio() because
the flag may be accessed in block device's error handling path
(for example, usb device reset)
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
v3:
- introduce pm_runtime_get_memalloc_noio()
- hold one global lock on pm_runtime_set_memalloc_noio
- hold device power lock when accessing memalloc_noio_resume
flag suggested by Alan Stern
- implement pm_runtime_set_memalloc_noio without recursion
suggested by Alan Stern
v2:
- introduce pm_runtime_set_memalloc_noio()
---
drivers/base/power/runtime.c | 72 ++++++++++++++++++++++++++++++++++++++++++
include/linux/pm.h | 1 +
include/linux/pm_runtime.h | 5 +++
3 files changed, 78 insertions(+)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 3148b10..9fa6ea7 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -124,6 +124,78 @@ unsigned long pm_runtime_autosuspend_expiration(struct device *dev)
}
EXPORT_SYMBOL_GPL(pm_runtime_autosuspend_expiration);
+/*
+ * pm_runtime_get_memalloc_noio - Get a device's memalloc_noio flag.
+ * @dev: Device to handle.
+ *
+ * Return the device's memalloc_noio flag.
+ *
+ * The device power lock is held because bitfield is not SMP-safe.
+ */
+bool pm_runtime_get_memalloc_noio(struct device *dev)
+{
+ bool ret;
+ spin_lock_irq(&dev->power.lock);
+ ret = dev->power.memalloc_noio_resume;
+ spin_unlock_irq(&dev->power.lock);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(pm_runtime_get_memalloc_noio);
+
+static int dev_memalloc_noio(struct device *dev, void *data)
+{
+ return pm_runtime_get_memalloc_noio(dev);
+}
+
+/*
+ * pm_runtime_set_memalloc_noio - Set a device's memalloc_noio flag.
+ * @dev: Device to handle.
+ * @enable: True for setting the flag and False for clearing the flag.
+ *
+ * Set the flag for all devices in the path from the device to the
+ * root device in the device tree if @enable is true, otherwise clear
+ * the flag for devices in the path which sibliings don't set the flag.
+ *
+ * The function should only be called by block device, or network
+ * device driver for solving the deadlock problem during runtime
+ * resume:
+ * if memory allocation with GFP_KERNEL is called inside runtime
+ * resume callback of any one of its ancestors(or the block device
+ * itself), the deadlock may be triggered inside the memory
+ * allocation since it might not complete until the block device
+ * becomes active and the involed page I/O finishes. The situation
+ * is pointed out first by Alan Stern. Network device are involved
+ * in iSCSI kind of situation.
+ *
+ * The lock of dev_hotplug_mutex is held in the function for handling
+ * hotplug race because pm_runtime_set_memalloc_noio() may be called
+ * in async probe().
+ */
+void pm_runtime_set_memalloc_noio(struct device *dev, bool enable)
+{
+ static DEFINE_MUTEX(dev_hotplug_mutex);
+
+ mutex_lock(&dev_hotplug_mutex);
+ while (dev) {
+ /* hold power lock since bitfield is not SMP-safe. */
+ spin_lock_irq(&dev->power.lock);
+ dev->power.memalloc_noio_resume = enable;
+ spin_unlock_irq(&dev->power.lock);
+
+ dev = dev->parent;
+
+ /* only clear the flag for one device if all
+ * children of the device don't set the flag.
+ */
+ if (!dev || (!enable &&
+ device_for_each_child(dev, NULL,
+ dev_memalloc_noio)))
+ break;
+ }
+ mutex_unlock(&dev_hotplug_mutex);
+}
+EXPORT_SYMBOL_GPL(pm_runtime_set_memalloc_noio);
+
/**
* rpm_check_suspend_allowed - Test whether a device may be suspended.
* @dev: Device to test.
diff --git a/include/linux/pm.h b/include/linux/pm.h
index 03d7bb1..d104579 100644
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -538,6 +538,7 @@ struct dev_pm_info {
unsigned int irq_safe:1;
unsigned int use_autosuspend:1;
unsigned int timer_autosuspends:1;
+ unsigned int memalloc_noio_resume:1;
enum rpm_request request;
enum rpm_status runtime_status;
int runtime_error;
diff --git a/include/linux/pm_runtime.h b/include/linux/pm_runtime.h
index f271860..b522b09 100644
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -47,6 +47,8 @@ extern void pm_runtime_set_autosuspend_delay(struct device *dev, int delay);
extern unsigned long pm_runtime_autosuspend_expiration(struct device *dev);
extern void pm_runtime_update_max_time_suspended(struct device *dev,
s64 delta_ns);
+extern bool pm_runtime_get_memalloc_noio(struct device *dev);
+extern void pm_runtime_set_memalloc_noio(struct device *dev, bool enable);
static inline bool pm_children_suspended(struct device *dev)
{
@@ -149,6 +151,9 @@ static inline void pm_runtime_set_autosuspend_delay(struct device *dev,
int delay) {}
static inline unsigned long pm_runtime_autosuspend_expiration(
struct device *dev) { return 0; }
+static inline bool pm_runtime_get_memalloc_noio(struct device *dev) { return false; }
+static inline void pm_runtime_set_memalloc_noio(struct device *dev,
+ bool enable){}
#endif /* !CONFIG_PM_RUNTIME */
--
1.7.9.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v3 1/6] mm: teach mm by current context info to not do I/O during memory allocation
From: Ming Lei @ 2012-10-29 12:23 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm, Ming Lei, Jiri Kosina,
Mel Gorman, KAMEZAWA Hiroyuki, Michal Hocko, Ingo Molnar,
Peter Zijlstra
In-Reply-To: <1351513440-9286-1-git-send-email-ming.lei@canonical.com>
This patch introduces PF_MEMALLOC_NOIO on process flag('flags' field of
'struct task_struct'), so that the flag can be set by one task
to avoid doing I/O inside memory allocation in the task's context.
The patch trys to solve one deadlock problem caused by block device,
and the problem may happen at least in the below situations:
- during block device runtime resume, if memory allocation with
GFP_KERNEL is called inside runtime resume callback of any one
of its ancestors(or the block device itself), the deadlock may be
triggered inside the memory allocation since it might not complete
until the block device becomes active and the involed page I/O finishes.
The situation is pointed out first by Alan Stern. It is not a good
approach to convert all GFP_KERNEL[1] in the path into GFP_NOIO because
several subsystems may be involved(for example, PCI, USB and SCSI may
be involved for usb mass stoarage device, network devices involved too
in the iSCSI case)
- during error handling of usb mass storage deivce, USB bus reset
will be put on the device, so there shouldn't have any
memory allocation with GFP_KERNEL during USB bus reset, otherwise
the deadlock similar with above may be triggered. Unfortunately, any
usb device may include one mass storage interface in theory, so it
requires all usb interface drivers to handle the situation. In fact,
most usb drivers don't know how to handle bus reset on the device
and don't provide .pre_set() and .post_reset() callback at all, so
USB core has to unbind and bind driver for these devices. So it
is still not practical to resort to GFP_NOIO for solving the problem.
Also the introduced solution can be used by block subsystem or block
drivers too, for example, set the PF_MEMALLOC_NOIO flag before doing
actual I/O transfer.
It is not a good idea to convert all these GFP_KERNEL in the
affected path into GFP_NOIO because these functions doing that may be
implemented as library and will be called in many other contexts.
In fact, memalloc_noio() can convert some of current static GFP_NOIO
allocation into GFP_KERNEL back in other non-affected contexts, at least
almost all GFP_NOIO in USB subsystem can be converted into GFP_KERNEL
after applying the approach and make allocation with GFP_IO
only happen in runtime resume/bus reset/block I/O transfer contexts
generally.
[1], several GFP_KERNEL allocation examples in runtime resume path
- pci subsystem
acpi_os_allocate
<-acpi_ut_allocate
<-ACPI_ALLOCATE_ZEROED
<-acpi_evaluate_object
<-__acpi_bus_set_power
<-acpi_bus_set_power
<-acpi_pci_set_power_state
<-platform_pci_set_power_state
<-pci_platform_power_transition
<-__pci_complete_power_transition
<-pci_set_power_state
<-pci_restore_standard_config
<-pci_pm_runtime_resume
- usb subsystem
usb_get_status
<-finish_port_resume
<-usb_port_resume
<-generic_resume
<-usb_resume_device
<-usb_resume_both
<-usb_runtime_resume
- some individual usb drivers
usblp, uvc, gspca, most of dvb-usb-v2 media drivers, cpia2, az6007, ....
That is just what I have found. Unfortunately, this allocation can
only be found by human being now, and there should be many not found
since any function in the resume path(call tree) may allocate memory
with GFP_KERNEL.
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Oliver Neukum <oneukum@suse.de>
Cc: Jiri Kosina <jiri.kosina@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
---
v3:
- no change
v2:
- remove changes on 'may_writepage' and 'may_swap' because that
isn't related with the patchset, and can't introduce I/O in
allocation path if GFP_IOFS is unset, so handing 'may_swap'
and may_writepage on GFP_NOIO or GFP_NOFS should be a
mm internal thing, and let mm guys deal with that, :-).
Looks clearing the two may_XXX flag only excludes dirty pages
and anon pages for relaiming, and the behaviour should be decided
by GFP FLAG, IMO.
- unset GFP_IOFS in try_to_free_pages() path since
alloc_page_buffers()
and dma_alloc_from_contiguous may drop into the path, as
pointed by KAMEZAWA Hiroyuki
v1:
- take Minchan's change to avoid the check in alloc_page hot
path
- change the helpers' style into save/restore as suggested by
Alan Stern
---
include/linux/sched.h | 10 ++++++++++
mm/page_alloc.c | 10 +++++++++-
mm/vmscan.c | 12 ++++++++++++
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index fb27acd..283fe86 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1805,6 +1805,7 @@ extern void thread_group_times(struct task_struct *p, cputime_t *ut, cputime_t *
#define PF_FROZEN 0x00010000 /* frozen for system suspend */
#define PF_FSTRANS 0x00020000 /* inside a filesystem transaction */
#define PF_KSWAPD 0x00040000 /* I am kswapd */
+#define PF_MEMALLOC_NOIO 0x00080000 /* Allocating memory without IO involved */
#define PF_LESS_THROTTLE 0x00100000 /* Throttle me less: I clean memory */
#define PF_KTHREAD 0x00200000 /* I am a kernel thread */
#define PF_RANDOMIZE 0x00400000 /* randomize virtual address space */
@@ -1842,6 +1843,15 @@ extern void thread_group_times(struct task_struct *p, cputime_t *ut, cputime_t *
#define tsk_used_math(p) ((p)->flags & PF_USED_MATH)
#define used_math() tsk_used_math(current)
+#define memalloc_noio() (current->flags & PF_MEMALLOC_NOIO)
+#define memalloc_noio_save(flag) do { \
+ (flag) = current->flags & PF_MEMALLOC_NOIO; \
+ current->flags |= PF_MEMALLOC_NOIO; \
+} while (0)
+#define memalloc_noio_restore(flag) do { \
+ current->flags = (current->flags & ~PF_MEMALLOC_NOIO) | flag; \
+} while (0)
+
/*
* task->jobctl flags
*/
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 45c916b..548d41c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2634,10 +2634,18 @@ retry_cpuset:
page = get_page_from_freelist(gfp_mask|__GFP_HARDWALL, nodemask, order,
zonelist, high_zoneidx, alloc_flags,
preferred_zone, migratetype);
- if (unlikely(!page))
+ if (unlikely(!page)) {
+ /*
+ * Resume, block IO and its error handling path
+ * can deadlock because I/O on the device might not
+ * complete.
+ */
+ if (unlikely(memalloc_noio()))
+ gfp_mask &= ~GFP_IOFS;
page = __alloc_pages_slowpath(gfp_mask, order,
zonelist, high_zoneidx, nodemask,
preferred_zone, migratetype);
+ }
trace_mm_page_alloc(page, order, gfp_mask, migratetype);
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 10090c8..035088a 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2304,6 +2304,12 @@ unsigned long try_to_free_pages(struct zonelist *zonelist, int order,
.gfp_mask = sc.gfp_mask,
};
+ if (unlikely(memalloc_noio())) {
+ gfp_mask &= ~GFP_IOFS;
+ sc.gfp_mask = gfp_mask;
+ shrink.gfp_mask = sc.gfp_mask;
+ }
+
throttle_direct_reclaim(gfp_mask, zonelist, nodemask);
/*
@@ -3304,6 +3310,12 @@ static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order)
};
unsigned long nr_slab_pages0, nr_slab_pages1;
+ if (unlikely(memalloc_noio())) {
+ gfp_mask &= ~GFP_IOFS;
+ sc.gfp_mask = gfp_mask;
+ shrink.gfp_mask = sc.gfp_mask;
+ }
+
cond_resched();
/*
* We need to be able to allocate from the reserves for RECLAIM_SWAP
--
1.7.9.5
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [PATCH v3 0/6] solve deadlock caused by memory allocation with I/O
From: Ming Lei @ 2012-10-29 12:23 UTC (permalink / raw)
To: linux-kernel
Cc: Alan Stern, Oliver Neukum, Minchan Kim, Greg Kroah-Hartman,
Rafael J. Wysocki, Jens Axboe, David S. Miller, Andrew Morton,
netdev, linux-usb, linux-pm, linux-mm
This patchset try to solve one deadlock problem which might be caused
by memory allocation with block I/O during runtime resume and block device
error handling path. Traditionly, the problem is addressed by passing
GFP_NOIO statically to mm, but that is not a effective solution, see
detailed description in patch 1's commit log.
This patch set introduces one process flag and trys to fix one deadlock
problem on block device/network device during runtime resume or usb bus reset.
The 1st one is the change on include/sched.h and mm.
The 2nd patch introduces the flag of memalloc_noio_resume on 'dev_pm_info',
and pm_runtime_set_memalloc_noio(), so that PM Core can teach mm to not
allocate mm with GFP_IOFS during the runtime_resume callback only on
device with the flag set.
The following 2 patches apply the introduced pm_runtime_set_memalloc_noio()
to mark all devices as memalloc_noio_resume in the path from the block or
network device to the root device in device tree.
The last 2 patches are applied again PM and USB subsystem to demonstrate
how to use the introduced mechanism to fix the deadlock problem.
V3:
- patch 2/6 and 5/6 changed, see their commit log
- remove RFC from title since several guys have expressed that
it is a reasonable solution
V2:
- remove changes on 'may_writepage' and 'may_swap'(1/6)
- unset GFP_IOFS in try_to_free_pages() path(1/6)
- introduce pm_runtime_set_memalloc_noio()
- only apply the meachnism on block/network device and its ancestors
for runtime resume context
V1:
- take Minchan's change to avoid the check in alloc_page hot path
- change the helpers' style into save/restore as suggested by Alan
- memory allocation with no io in usb bus reset path for all devices
as suggested by Greg and Oliver
block/genhd.c | 8 ++++
drivers/base/power/runtime.c | 88 +++++++++++++++++++++++++++++++++++++++++-
drivers/usb/core/hub.c | 15 +++++++
include/linux/pm.h | 1 +
include/linux/pm_runtime.h | 5 +++
include/linux/sched.h | 10 +++++
mm/page_alloc.c | 10 ++++-
mm/vmscan.c | 12 ++++++
net/core/net-sysfs.c | 5 +++
9 files changed, 152 insertions(+), 2 deletions(-)
Thanks,
--
Ming Lei
^ permalink raw reply
* Re: [PATCH v7 08/16] block,elevator: use new hashtable implementation
From: Mathieu Desnoyers @ 2012-10-29 12:20 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
tj-DgEjT+Ai2ygdnm+yROfE0A, akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, rostedt-nx8X9YLhiw1AfugRpC6u6w,
mingo-X9Un+BFzKDI, ebiederm-aS9lmoZGLiVWk0Htik3J/w,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, josh-iaAMLnmF4UmaiuxdJuQwMA,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w, axboe-tSWWG44O7X1aa/9Udqfwiw,
agk-H+wXaHxf7aLQT0dZR+AlfA, dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
neilb-l3A5Bk7waGM, ccaulfie-H+wXaHxf7aLQT0dZR+AlfA,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <1351450948-15618-8-git-send-email-levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
* Sasha Levin (levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) wrote:
[...]
> @@ -96,6 +97,8 @@ struct elevator_type
> struct list_head list;
> };
>
> +#define ELV_HASH_BITS 6
> +
> /*
> * each queue has an elevator_queue associated with it
> */
> @@ -105,7 +108,7 @@ struct elevator_queue
> void *elevator_data;
> struct kobject kobj;
> struct mutex sysfs_lock;
> - struct hlist_head *hash;
> + DECLARE_HASHTABLE(hash, ELV_HASH_BITS);
> unsigned int registered:1;
Hrm, so this is moving "registered" out of the elevator_queue first
cache-line by turning the pointer into a 256 or 512 bytes hash table.
Maybe we should consider moving "registered" before the "hash" field ?
Thanks,
Mathieu
> };
>
> --
> 1.7.12.4
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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
* Re: [PATCH v7 07/16] net, 9p: use new hashtable implementation
From: Mathieu Desnoyers @ 2012-10-29 12:15 UTC (permalink / raw)
To: Sasha Levin
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, rostedt-nx8X9YLhiw1AfugRpC6u6w,
lw-BthXqXjhjHXQFUHtdCDX3A, teigland-H+wXaHxf7aLQT0dZR+AlfA,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, tj-DgEjT+Ai2ygdnm+yROfE0A,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1351450948-15618-7-git-send-email-levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
* Sasha Levin (levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) wrote:
> Switch 9p error table to use the new hashtable implementation. This reduces the amount of
> generic unrelated code in 9p.
>
> Signed-off-by: Sasha Levin <levinsasha928-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> net/9p/error.c | 21 ++++++++++-----------
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/net/9p/error.c b/net/9p/error.c
> index 2ab2de7..a5cc7dd 100644
> --- a/net/9p/error.c
> +++ b/net/9p/error.c
> @@ -34,7 +34,7 @@
> #include <linux/jhash.h>
> #include <linux/errno.h>
> #include <net/9p/9p.h>
> -
> +#include <linux/hashtable.h>
missing newline.
> /**
> * struct errormap - map string errors from Plan 9 to Linux numeric ids
> * @name: string sent over 9P
> @@ -50,8 +50,8 @@ struct errormap {
> struct hlist_node list;
> };
>
> -#define ERRHASHSZ 32
> -static struct hlist_head hash_errmap[ERRHASHSZ];
> +#define ERR_HASH_BITS 5
> +static DEFINE_HASHTABLE(hash_errmap, ERR_HASH_BITS);
>
> /* FixMe - reduce to a reasonable size */
> static struct errormap errmap[] = {
> @@ -193,18 +193,17 @@ static struct errormap errmap[] = {
> int p9_error_init(void)
> {
> struct errormap *c;
> - int bucket;
> + u32 hash;
>
> /* initialize hash table */
> - for (bucket = 0; bucket < ERRHASHSZ; bucket++)
> - INIT_HLIST_HEAD(&hash_errmap[bucket]);
> + hash_init(hash_errmap);
As for most of the other patches in this series, the hash_init is
redundant for a statically defined hash table.
Thanks,
Mathieu
>
> /* load initial error map into hash table */
> for (c = errmap; c->name != NULL; c++) {
> c->namelen = strlen(c->name);
> - bucket = jhash(c->name, c->namelen, 0) % ERRHASHSZ;
> + hash = jhash(c->name, c->namelen, 0);
> INIT_HLIST_NODE(&c->list);
> - hlist_add_head(&c->list, &hash_errmap[bucket]);
> + hash_add(hash_errmap, &c->list, hash);
> }
>
> return 1;
> @@ -223,13 +222,13 @@ int p9_errstr2errno(char *errstr, int len)
> int errno;
> struct hlist_node *p;
> struct errormap *c;
> - int bucket;
> + u32 hash;
>
> errno = 0;
> p = NULL;
> c = NULL;
> - bucket = jhash(errstr, len, 0) % ERRHASHSZ;
> - hlist_for_each_entry(c, p, &hash_errmap[bucket], list) {
> + hash = jhash(errstr, len, 0);
> + hash_for_each_possible(hash_errmap, c, p, list, hash) {
> if (c->namelen == len && !memcmp(c->name, errstr, len)) {
> errno = c->val;
> break;
> --
> 1.7.12.4
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* 3.7-rc3 oops on reboot
From: Alexandre Pereira da Silva @ 2012-10-29 12:08 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, linux-kernel,
Roland Stigge
Hi,
I am getting oops on 3.7-rc3 at reboot.
This is an LPC32XX machine. This problem only happens when I connect
the ethernet cable and get an IP address.
Here are the kernel messages.
[ 38.570000] Unable to handle kernel paging request at virtual
address a0000014
[ 38.570000] pgd = c1730000
[ 38.580000] [a0000014] *pgd=00000000
[ 38.580000] Internal error: Oops: 5 [#1] PREEMPT ARM
[ 38.580000] Modules linked in:
[ 38.580000] CPU: 0 Not tainted (3.7.0-rc3 #4)
[ 38.580000] PC is at trie_firstleaf+0xc/0x2c
[ 38.580000] LR is at fib_table_flush+0x1c/0x170
[ 38.580000] pc : [<c029659c>] lr : [<c0298dec>] psr: a0000013
[ 38.580000] sp : c1719d50 ip : c1719d60 fp : c1719d5c
[ 38.580000] r10: 00000000 r9 : 00000000 r8 : c16341e0
[ 38.580000] r7 : c09d2c24 r6 : 00000001 r5 : a0000000 r4 : 000003fc
[ 38.580000] r3 : c18dac00 r2 : c09c6fc0 r1 : c09c6fc0 r0 : a0000014
[ 38.580000] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 38.580000] Control: 0005317f Table: 81730000 DAC: 00000015
[ 38.580000] Process ifconfig (pid: 396, stack limit = 0xc17181b8)
[ 38.580000] Stack: (0xc1719d50 to 0xc171a000)
[ 38.580000] 9d40: c1719d9c
c1719d60 c0298dec c02965a0
[ 38.580000] 9d60: c170f308 c14d42e0 00000000 a0000014 c16341e0
000003fc a0000000 00000001
[ 38.580000] 9d80: c09d2c24 c16341e0 00000000 00000000 c1719dbc
c1719da0 c0294244 c0298de0
[ 38.580000] 9da0: c160f800 c160f800 ffffffff 00000000 c1719dd4
c1719dc0 c0294294 c0294224
[ 38.580000] 9dc0: 00000000 c16341e0 c1719dec c1719dd8 c0294bf0
c0294284 00000002 00000000
[ 38.580000] 9de0: c1719e14 c1719df0 c003e810 c0294b60 ffffffff
c09d4698 ffffffff c16341e0
[ 38.580000] 9e00: 00000002 00000000 c1719e3c c1719e18 c003ea9c
c003e7e0 00000000 c1719e28
[ 38.580000] 9e20: c16341e0 00000000 00000000 c16341e0 c1719e54
c1719e40 c003ead4 c003ea5c
[ 38.580000] 9e40: 00000000 00000000 c1719e8c c1719e58 c028b9bc
c003eac4 00000000 c145edec
[ 38.580000] 9e60: c1719e8c c16341e0 00000000 c160f800 c145ede0
c145edec 00000000 00000000
[ 38.580000] 9e80: c1719ea4 c1719e90 c028ba94 c028b828 00000000
c09d2c24 c1719f14 c1719ea8
[ 38.580000] 9ea0: c028d278 c028ba88 c003d890 00000000 00008916
bef74c18 30687465 00000000
[ 38.580000] 9ec0: 00000000 00000000 00000002 00000000 00000001
00084a10 00000002 00000000
[ 38.580000] 9ee0: 00000001 00084a10 00001000 00008914 bef74c18
bef74c18 00008916 00000003
[ 38.580000] 9f00: c1718000 00000000 c1719f2c c1719f18 c028e284
c028cf18 c1404420 00008916
[ 38.580000] 9f20: c1719f4c c1719f30 c022ed8c c028e1c4 c022eb6c
00000003 bef74c18 bef74c18
[ 38.580000] 9f40: c1719f74 c1719f50 c009e5e8 c022eb7c 000ac000
000ad000 bef74c18 00008916
[ 38.580000] 9f60: c14dcbe0 00000000 c1719fa4 c1719f78 c009e66c
c009e304 c0080184 00000000
[ 38.580000] 9f80: b6f73ee4 bef74c18 00008916 00000003 00000036
c000e224 00000000 c1719fa8
[ 38.580000] 9fa0: c000e0c0 c009e638 bef74c18 00008916 00000003
00008916 bef74c18 00000000
[ 38.580000] 9fc0: bef74c18 00008916 00000003 00000036 00085a28
00000000 000859a8 00000000
[ 38.580000] 9fe0: b6f2bde4 bef74bc0 0000ddb4 b6f2be28 60000010
00000003 00000000 00000000
[ 38.580000] Backtrace:
[ 38.580000] [<c0296590>] (trie_firstleaf+0x0/0x2c) from
[<c0298dec>] (fib_table_flush+0x1c/0x170)
[ 38.580000] [<c0298dd0>] (fib_table_flush+0x0/0x170) from
[<c0294244>] (fib_flush.clone.27+0x30/0x60)
[ 38.580000] [<c0294214>] (fib_flush.clone.27+0x0/0x60) from
[<c0294294>] (fib_disable_ip+0x20/0x38)
[ 38.580000] r7:00000000 r6:ffffffff r5:c160f800 r4:c160f800
[ 38.580000] [<c0294274>] (fib_disable_ip+0x0/0x38) from
[<c0294bf0>] (fib_inetaddr_event+0xa0/0xb4)
[ 38.580000] r4:c16341e0 r3:00000000
[ 38.580000] [<c0294b50>] (fib_inetaddr_event+0x0/0xb4) from
[<c003e810>] (notifier_call_chain+0x40/0x70)
[ 38.580000] r5:00000000 r4:00000002
[ 38.580000] [<c003e7d0>] (notifier_call_chain+0x0/0x70) from
[<c003ea9c>] (__blocking_notifier_call_chain+0x50/0x68)
[ 38.580000] r8:00000000 r7:00000002 r6:c16341e0 r5:ffffffff r4:c09d4698
r3:ffffffff
[ 38.580000] [<c003ea4c>] (__blocking_notifier_call_chain+0x0/0x68)
from [<c003ead4>] (blocking_notifier_call_chain+0x20/0x28)
[ 38.580000] r7:c16341e0 r6:00000000 r5:00000000 r4:c16341e0
[ 38.580000] [<c003eab4>] (blocking_notifier_call_chain+0x0/0x28)
from [<c028b9bc>] (__inet_del_ifa+0x1a4/0x260)
[ 38.580000] [<c028b818>] (__inet_del_ifa+0x0/0x260) from
[<c028ba94>] (inet_del_ifa+0x1c/0x24)
[ 38.580000] [<c028ba78>] (inet_del_ifa+0x0/0x24) from [<c028d278>]
(devinet_ioctl+0x370/0x634)
[ 38.580000] [<c028cf08>] (devinet_ioctl+0x0/0x634) from
[<c028e284>] (inet_ioctl+0xd0/0x110)
[ 38.580000] [<c028e1b4>] (inet_ioctl+0x0/0x110) from [<c022ed8c>]
(sock_ioctl+0x220/0x278)
[ 38.580000] r4:00008916 r3:c1404420
[ 38.580000] [<c022eb6c>] (sock_ioctl+0x0/0x278) from [<c009e5e8>]
(do_vfs_ioctl+0x2f4/0x334)
[ 38.580000] r6:bef74c18 r5:bef74c18 r4:00000003 r3:c022eb6c
[ 38.580000] [<c009e2f4>] (do_vfs_ioctl+0x0/0x334) from [<c009e66c>]
(sys_ioctl+0x44/0x64)
[ 38.580000] r5:00000000 r4:c14dcbe0
[ 38.580000] [<c009e628>] (sys_ioctl+0x0/0x64) from [<c000e0c0>]
(ret_fast_syscall+0x0/0x2c)
[ 38.580000] r8:c000e224 r7:00000036 r6:00000003 r5:00008916 r4:bef74c18
[ 38.580000] Code: e89da810 e1a0c00d e92dd800 e24cb004 (e5900000)
[ 39.040000] ---[ end trace 1e122706a9f64743 ]---
Do anybody have any idea what may have happened there?
Thanks.
^ permalink raw reply
* [PATCH net] cxgb4: Fix unable to get UP event from the LLD
From: Vipul Pandya @ 2012-10-29 12:02 UTC (permalink / raw)
To: netdev; +Cc: davem, divy, dm, Vipul Pandya, Jay Hernandez
If T4 configuration file gets loaded from the /lib/firmware/cxgb4/ directory
then offload capabilities of the cards were getting disabled during
initialization. Hence ULDs do not get an UP event from the LLD.
Signed-off-by: Jay Hernandez <jay@chelsio.com>
Signed-off-by: Vipul Pandya <vipul@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 10 ----------
1 files changed, 0 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index c1cde11..0df1284 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -3416,16 +3416,6 @@ static int adap_init0_config(struct adapter *adapter, int reset)
finicsum, cfcsum);
/*
- * If we're a pure NIC driver then disable all offloading facilities.
- * This will allow the firmware to optimize aspects of the hardware
- * configuration which will result in improved performance.
- */
- caps_cmd.ofldcaps = 0;
- caps_cmd.iscsicaps = 0;
- caps_cmd.rdmacaps = 0;
- caps_cmd.fcoecaps = 0;
-
- /*
* And now tell the firmware to use the configuration we just loaded.
*/
caps_cmd.op_to_write =
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/2] drivers/net/ethernet/nxp/lpc_eth.c: Call mdiobus_unregister before mdiobus_free
From: Alexandre Pereira da Silva @ 2012-10-29 11:58 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: davem, stigge, edumazet, djduanjiong, netdev, linux-kernel,
kernel-janitors
In-Reply-To: <1351440721-9121-1-git-send-email-peter.senna@gmail.com>
On Sun, Oct 28, 2012 at 2:12 PM, Peter Senna Tschudin
<peter.senna@gmail.com> wrote:
> Based on commit b27393aecf66199f5ddad37c302d3e0cfadbe6c0
>
> Calling mdiobus_free without calling mdiobus_unregister causes
> BUG_ON(). This patch fixes the issue.
>
> The semantic patch that found this issue(http://coccinelle.lip6.fr/):
> // <smpl>
> @@
> expression E;
> @@
> ... when != mdiobus_unregister(E);
>
> + mdiobus_unregister(E);
> mdiobus_free(E);
> // </smpl>
>
> Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
> ---
Tested-by: Alexandre Pereira da Silva <aletes.xgr@gmail.com>
^ permalink raw reply
* Re: Information about napi_struct and net_device
From: Javier Domingo @ 2012-10-29 11:49 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
In-Reply-To: <20121028231300.GA27196@electric-eye.fr.zoreil.com>
Hi Francois,
I have been reading the code you recommended, and I think I must have
misexplained myself. I am not developing a driver, I am updating a
patch that we use at our research group, in which we modify linux to
make our custom packet processing, getting all the packets from the
NICs into a custom queue for processing.
It will obviously not going to be integrated in the linux kernel,
because its way to work is just useful to us, thought when we have
something that works, we have planned to distribute it.
I work with net_device, because I mainly use its fields, but I provide
functions to enable/disable capturing from a specific net_device. Now,
as napi_struct has appeared, I can't no longer use the
netif_rx_disable/enable functions, but I still need to know how to get
the already created napi_struct from my net_device pointers.
I think I have been looking in a too low level,
Regards,
Javier Domingo
2012/10/29 Francois Romieu <romieu@fr.zoreil.com>:
> Javier Domingo <javierdo1@gmail.com> :
> [...]
>> inside of the net_device structure, I know I can take
>> the net_device pointer as documented in [3], but how may I obtain the
>> napi_struct from the netdevice? or I am doing it the wrong way?
>
> You are doing it the wrong way. The napi_struct you need is not embedded
> here. See
>
> $ less +/napi drivers/net/ethernet/realtek/8139cp.c
>
> (first match in struct cp_private).
>
> You should really read one of the existing drivers.
>
> --
> Ueimor
^ permalink raw reply
* Re: [PATCH net-next] sctp: support per-association stats via a new SCTP_GET_ASSOC_STATS call
From: Neil Horman @ 2012-10-29 11:37 UTC (permalink / raw)
To: Thomas Graf
Cc: Michele Baldessari, linux-sctp, Vlad Yasevich, David S. Miller,
netdev
In-Reply-To: <20121029084143.GA17442@casper.infradead.org>
On Mon, Oct 29, 2012 at 08:41:43AM +0000, Thomas Graf wrote:
> On 10/26/12 at 10:37am, Neil Horman wrote:
> > We already have files in /proc/net/sctp to count snmp system-wide totals,
> > per-endpoint totals, and per association totals. Why do these stats differently
> > instead of just adding them the per-association file? I get that solaris does
> > this, but its not codified in any of the RFC's or other standards. I would
> > really rather see something like this go into the interfaces we have, rather
> > than creating a new one.
>
> I really dislike to grow the procfs interface. I would favour a
> netlink inteface but we already export all the statistics via
> the socket interface so this is the most consistent choice.
>
I'm not sure what statistics you are referring to here. The only stats I see
exported (save for association setting exported via SCTP_STATUS on the socket
interface), are done via proc. I agree that proc stinks out loud, but my first
though when seeing stats exported via an interface in which you need to provide
process specific data (in this case the socket and association id), is that the
very next thing that someone will ask for is the ability for these stats to be
visible from outside the process, so an external tool can monitor them. I guess
I'm ok with this approach, since its more efficient than polling proc (as per
your needs below), but maybe its time to start looking at implementing a
NETLINK_STATS interface so that we can have the best of both worlds.
> > And the max observed rto stat is just odd. Each
> > transport has an rto value, not each association, and you cal already see the
> > individual transport rto values in /proc/net/sctp/remaddr.
>
> It's true that this is not found in any RFC and the request seems to
> be based on the fact that Solaris provides this information already.
> Recording the largest observed RTO is critical for latency sensitive
> use cases. Looking at RTO in remaddr doesn't really help to figure out
> the MAX(RTO) even with a very high polling frequency, something you
> don't want to do on a procfs file.
>
Hm, ok, looking for the maximum rto seen is definately more efficient that a
high polling rate on the remaddr file. Still can't say I really like it as a
statistic though. While it helps in diagnosing a very specific type of problem
(applications that have a maximum allowable latency), its really not useful, and
potentially misleading, in the general case. Specificaly it may show a very
large RTO even if that RTO was an erroneous spike in behavior earlier in the
lifetime of a given transport, even if that RTO is not representative of the
current behavior of the association. It seems to me like this stat might be
better collected using a stap script or by adding a trace point to
sctp_transport_update_rto. If the application needs to know this information
internally during its operation to take corrective action, you can already get
it via the SCTP_GET_PEER_ADDR_INFO socket option on a per transport basis just
as efficiently.
> >
> > > + if (q->asoc)
> > > + q->asoc->rtxpackets++;
> > > +
> > > +
> > This seems incorrect to me. The packet being assembled here may have new chunks
> > in it (either control or data). Counting a packet as being retransmitted just
> > because it has a retransmitted chunk in it seems wrong. At the very least its a
> > misleading/vague statistic.
>
> I agree, this can't be done 100% accurate. I'm fine with leaving this
> out and have userspace create the sum of SCTP_MIB_*_RETRANSMITS.
>
Thank you, I agree.
> > > + if (chunk->asoc)
> > > + chunk->asoc->outseqtsns++;
> > This just seems wrong. The definition states that this is counting the last TSN
> > recevied (despite being name outseqtsns), yet this looks like you're:
> > 1) just incrementing a counter, rather than recording the TSN value itself
> > (which may or may not be what you meant, but seems to contradict what the
> > comments at the definition)
> > 2) Only incremanting it if the TSN is out of range, which makes very little
> > sense to me.
>
> As Vlad pointed out the name could be improved but the description
> seems correct. The statistic counts the number of chunks where
> TSN > expected.
>
I'll look at it again, but the comments really suggested to me that this was
mean to be a counter of the last transmitted tsn value, not the number of tsn's
that were received out of the windowed range.
Neil
^ permalink raw reply
* Re: [PATCH v7 06/16] tracepoint: use new hashtable implementation
From: Mathieu Desnoyers @ 2012-10-29 11:35 UTC (permalink / raw)
To: Sasha Levin
Cc: torvalds, tj, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
rostedt, mingo, ebiederm, aarcange, ericvh, netdev, josh,
eric.dumazet, axboe, agk, dm-devel, neilb, ccaulfie, teigland,
Trond.Myklebust, bfields, fweisbec, jesse, venkat.x.venkatsubra,
ejt, snitzer, edumazet, linux-nfs, dev, rds-devel, lw
In-Reply-To: <1351450948-15618-6-git-send-email-levinsasha928@gmail.com>
* Sasha Levin (levinsasha928@gmail.com) wrote:
> Switch tracepoints to use the new hashtable implementation. This reduces the amount of
> generic unrelated code in the tracepoints.
>
> Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> ---
> kernel/tracepoint.c | 27 +++++++++++----------------
> 1 file changed, 11 insertions(+), 16 deletions(-)
>
> diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
> index d96ba22..854df92 100644
> --- a/kernel/tracepoint.c
> +++ b/kernel/tracepoint.c
> @@ -26,6 +26,7 @@
> #include <linux/slab.h>
> #include <linux/sched.h>
> #include <linux/static_key.h>
> +#include <linux/hashtable.h>
>
> extern struct tracepoint * const __start___tracepoints_ptrs[];
> extern struct tracepoint * const __stop___tracepoints_ptrs[];
> @@ -49,8 +50,7 @@ static LIST_HEAD(tracepoint_module_list);
> * Protected by tracepoints_mutex.
> */
> #define TRACEPOINT_HASH_BITS 6
> -#define TRACEPOINT_TABLE_SIZE (1 << TRACEPOINT_HASH_BITS)
> -static struct hlist_head tracepoint_table[TRACEPOINT_TABLE_SIZE];
> +static DEFINE_HASHTABLE(tracepoint_table, TRACEPOINT_HASH_BITS);
>
[...]
>
> @@ -722,6 +715,8 @@ struct notifier_block tracepoint_module_nb = {
>
> static int init_tracepoints(void)
> {
> + hash_init(tracepoint_table);
> +
> return register_module_notifier(&tracepoint_module_nb);
> }
> __initcall(init_tracepoints);
So we have a hash table defined in .bss (therefore entirely initialized
to NULL), and you add a call to "hash_init", which iterates on the whole
array and initialize it to NULL (again) ?
This extra initialization is redundant. I think it should be removed
from here, and hashtable.h should document that hash_init() don't need
to be called on zeroed memory (which includes static/global variables,
kzalloc'd memory, etc).
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH RFC] pkt_sched: enable QFQ to support TSO/GSO
From: Cong Wang @ 2012-10-29 11:31 UTC (permalink / raw)
To: Paolo Valente
Cc: jhs, davem, shemminger, linux-kernel, netdev, rizzo, fchecconi
In-Reply-To: <508E6783.2080403@unimore.it>
On 10/29/2012 07:24 PM, Paolo Valente wrote:
> Il 29/10/2012 12:08, Cong Wang ha scritto:
>>
>> Please respect people who helps you to test it:
>>
>> Tested-by: Cong Wang <amwang@redhat.com>
> Oops, really sorry about that. I did not mean to hide your contribution.
> I am just not familiar with the process.
No problem. :)
> Thanks, I will integrate this and possible other suggestions in a new
> version of the patch.
While you are on it, please check your patch with
./scripts/checkpatch.pl, it complains there are some trailing
whitespaces in your patch. ;)
^ 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