* Re: [PATCH RESEND] tipc: avoid possible deadlock while enable and disable bearer
From: Ying Xue @ 2013-08-09 6:39 UTC (permalink / raw)
To: Ding Tianhong
Cc: Jon Maloy, Allan Stephens, David S. Miller, Netdev,
tipc-discussion, wangweidong1
In-Reply-To: <52048CB9.1030203@huawei.com>
On 08/09/2013 02:31 PM, Ding Tianhong wrote:
> We met lockdep warning when enable and disable the bearer for commands such as:
>
> tipc-config -netid=1234 -addr=1.1.3 -be=eth:eth0
> tipc-config -netid=1234 -addr=1.1.3 -bd=eth:eth0
>
> ---------------------------------------------------
>
> [ 327.693595] ======================================================
> [ 327.693994] [ INFO: possible circular locking dependency detected ]
> [ 327.694519] 3.11.0-rc3-wwd-default #4 Tainted: G O
> [ 327.694882] -------------------------------------------------------
> [ 327.695385] tipc-config/5825 is trying to acquire lock:
> [ 327.695754] (((timer))#2){+.-...}, at: [<ffffffff8105be80>] del_timer_sync+0x0/0xd0
> [ 327.696018]
> [ 327.696018] but task is already holding lock:
> [ 327.696018] (&(&b_ptr->lock)->rlock){+.-...}, at: [<ffffffffa02be58d>] bearer_disable+ 0xdd/0x120 [tipc]
> [ 327.696018]
> [ 327.696018] which lock already depends on the new lock.
> [ 327.696018]
> [ 327.696018]
> [ 327.696018] the existing dependency chain (in reverse order) is:
> [ 327.696018]
> [ 327.696018] -> #1 (&(&b_ptr->lock)->rlock){+.-...}:
> [ 327.696018] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
> [ 327.696018] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
> [ 327.696018] [<ffffffff810b4453>] lock_acquire+0x103/0x130
> [ 327.696018] [<ffffffff814d65b1>] _raw_spin_lock_bh+0x41/0x80
> [ 327.696018] [<ffffffffa02c5d48>] disc_timeout+0x18/0xd0 [tipc]
> [ 327.696018] [<ffffffff8105b92a>] call_timer_fn+0xda/0x1e0
> [ 327.696018] [<ffffffff8105bcd7>] run_timer_softirq+0x2a7/0x2d0
> [ 327.696018] [<ffffffff8105379a>] __do_softirq+0x16a/0x2e0
> [ 327.696018] [<ffffffff81053a35>] irq_exit+0xd5/0xe0
> [ 327.696018] [<ffffffff81033005>] smp_apic_timer_interrupt+0x45/0x60
> [ 327.696018] [<ffffffff814df4af>] apic_timer_interrupt+0x6f/0x80
> [ 327.696018] [<ffffffff8100b70e>] arch_cpu_idle+0x1e/0x30
> [ 327.696018] [<ffffffff810a039d>] cpu_idle_loop+0x1fd/0x280
> [ 327.696018] [<ffffffff810a043e>] cpu_startup_entry+0x1e/0x20
> [ 327.696018] [<ffffffff81031589>] start_secondary+0x89/0x90
> [ 327.696018]
> [ 327.696018] -> #0 (((timer))#2){+.-...}:
> [ 327.696018] [<ffffffff810b33fe>] check_prev_add+0x43e/0x4b0
> [ 327.696018] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
> [ 327.696018] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
> [ 327.696018] [<ffffffff810b4453>] lock_acquire+0x103/0x130
> [ 327.696018] [<ffffffff8105bebd>] del_timer_sync+0x3d/0xd0
> [ 327.696018] [<ffffffffa02c5855>] tipc_disc_delete+0x15/0x30 [tipc]
> [ 327.696018] [<ffffffffa02be59f>] bearer_disable+0xef/0x120 [tipc]
> [ 327.696018] [<ffffffffa02be74f>] tipc_disable_bearer+0x2f/0x60 [tipc]
> [ 327.696018] [<ffffffffa02bfb32>] tipc_cfg_do_cmd+0x2e2/0x550 [tipc]
> [ 327.696018] [<ffffffffa02c8c79>] handle_cmd+0x49/0xe0 [tipc]
> [ 327.696018] [<ffffffff8143e898>] genl_family_rcv_msg+0x268/0x340
> [ 327.696018] [<ffffffff8143ed30>] genl_rcv_msg+0x70/0xd0
> [ 327.696018] [<ffffffff8143d4c9>] netlink_rcv_skb+0x89/0xb0
> [ 327.696018] [<ffffffff8143e617>] genl_rcv+0x27/0x40
> [ 327.696018] [<ffffffff8143d21e>] netlink_unicast+0x15e/0x1b0
> [ 327.696018] [<ffffffff8143ddcf>] netlink_sendmsg+0x22f/0x400
> [ 327.696018] [<ffffffff813f7836>] __sock_sendmsg+0x66/0x80
> [ 327.696018] [<ffffffff813f7957>] sock_aio_write+0x107/0x120
> [ 327.696018] [<ffffffff8117f76d>] do_sync_write+0x7d/0xc0
> [ 327.696018] [<ffffffff8117fc56>] vfs_write+0x186/0x190
> [ 327.696018] [<ffffffff811803e0>] SyS_write+0x60/0xb0
> [ 327.696018] [<ffffffff814de852>] system_call_fastpath+0x16/0x1b
> [ 327.696018]
> [ 327.696018] other info that might help us debug this:
> [ 327.696018]
> [ 327.696018] Possible unsafe locking scenario:
> [ 327.696018]
> [ 327.696018] CPU0 CPU1
> [ 327.696018] ---- ----
> [ 327.696018] lock(&(&b_ptr->lock)->rlock);
> [ 327.696018] lock(((timer))#2);
> [ 327.696018] lock(&(&b_ptr->lock)->rlock);
> [ 327.696018] lock(((timer))#2);
> [ 327.696018]
> [ 327.696018] *** DEADLOCK ***
> [ 327.696018]
> [ 327.696018] 5 locks held by tipc-config/5825:
> [ 327.696018] #0: (cb_lock){++++++}, at: [<ffffffff8143e608>] genl_rcv+0x18/0x40
> [ 327.696018] #1: (genl_mutex){+.+.+.}, at: [<ffffffff8143ed66>] genl_rcv_msg+0xa6/0xd0
> [ 327.696018] #2: (config_mutex){+.+.+.}, at: [<ffffffffa02bf889>] tipc_cfg_do_cmd+0x39/ 0x550 [tipc]
> [ 327.696018] #3: (tipc_net_lock){++.-..}, at: [<ffffffffa02be738>] tipc_disable_bearer+ 0x18/0x60 [tipc]
> [ 327.696018] #4: (&(&b_ptr->lock)->rlock){+.-...}, at: [<ffffffffa02be58d>] bearer_disable+0xdd/0x120 [tipc]
> [ 327.696018]
> [ 327.696018] stack backtrace:
> [ 327.696018] CPU: 2 PID: 5825 Comm: tipc-config Tainted: G O 3.11.0-rc3-wwd- default #4
> [ 327.696018] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> [ 327.696018] 00000000ffffffff ffff880037fa77a8 ffffffff814d03dd 0000000000000000
> [ 327.696018] ffff880037fa7808 ffff880037fa77e8 ffffffff810b1c4f 0000000037fa77e8
> [ 327.696018] ffff880037fa7808 ffff880037e4db40 0000000000000000 ffff880037e4e318
> [ 327.696018] Call Trace:
> [ 327.696018] [<ffffffff814d03dd>] dump_stack+0x4d/0xa0
> [ 327.696018] [<ffffffff810b1c4f>] print_circular_bug+0x10f/0x120
> [ 327.696018] [<ffffffff810b33fe>] check_prev_add+0x43e/0x4b0
> [ 327.696018] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
> [ 327.696018] [<ffffffff81087a28>] ? sched_clock_cpu+0xd8/0x110
> [ 327.696018] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
> [ 327.696018] [<ffffffff810b4453>] lock_acquire+0x103/0x130
> [ 327.696018] [<ffffffff8105be80>] ? try_to_del_timer_sync+0x70/0x70
> [ 327.696018] [<ffffffff8105bebd>] del_timer_sync+0x3d/0xd0
> [ 327.696018] [<ffffffff8105be80>] ? try_to_del_timer_sync+0x70/0x70
> [ 327.696018] [<ffffffffa02c5855>] tipc_disc_delete+0x15/0x30 [tipc]
> [ 327.696018] [<ffffffffa02be59f>] bearer_disable+0xef/0x120 [tipc]
> [ 327.696018] [<ffffffffa02be74f>] tipc_disable_bearer+0x2f/0x60 [tipc]
> [ 327.696018] [<ffffffffa02bfb32>] tipc_cfg_do_cmd+0x2e2/0x550 [tipc]
> [ 327.696018] [<ffffffff81218783>] ? security_capable+0x13/0x20
> [ 327.696018] [<ffffffffa02c8c79>] handle_cmd+0x49/0xe0 [tipc]
> [ 327.696018] [<ffffffff8143e898>] genl_family_rcv_msg+0x268/0x340
> [ 327.696018] [<ffffffff8143ed30>] genl_rcv_msg+0x70/0xd0
> [ 327.696018] [<ffffffff8143ecc0>] ? genl_lock+0x20/0x20
> [ 327.696018] [<ffffffff8143d4c9>] netlink_rcv_skb+0x89/0xb0
> [ 327.696018] [<ffffffff8143e608>] ? genl_rcv+0x18/0x40
> [ 327.696018] [<ffffffff8143e617>] genl_rcv+0x27/0x40
> [ 327.696018] [<ffffffff8143d21e>] netlink_unicast+0x15e/0x1b0
> [ 327.696018] [<ffffffff81289d7c>] ? memcpy_fromiovec+0x6c/0x90
> [ 327.696018] [<ffffffff8143ddcf>] netlink_sendmsg+0x22f/0x400
> [ 327.696018] [<ffffffff813f7836>] __sock_sendmsg+0x66/0x80
> [ 327.696018] [<ffffffff813f7957>] sock_aio_write+0x107/0x120
> [ 327.696018] [<ffffffff813fe29c>] ? release_sock+0x8c/0xa0
> [ 327.696018] [<ffffffff8117f76d>] do_sync_write+0x7d/0xc0
> [ 327.696018] [<ffffffff8117fa24>] ? rw_verify_area+0x54/0x100
> [ 327.696018] [<ffffffff8117fc56>] vfs_write+0x186/0x190
> [ 327.696018] [<ffffffff811803e0>] SyS_write+0x60/0xb0
> [ 327.696018] [<ffffffff814de852>] system_call_fastpath+0x16/0x1b
>
> -----------------------------------------------------------------------
>
> The problem is that the tipc_link_delete() will cancel the timer disc_timeout() when
> the b_ptr->lock is hold, but the disc_timeout() still call b_ptr->lock to finish the
> work, so the dead lock occurs.
>
> We should unlock the b_ptr->lock when del the disc_timeout().
>
> Remove link_timeout() still met the same problem, the patch:
>
> http://article.gmane.org/gmane.network.tipc.general/4380
>
> fix the problem, so no need to send patch for fix link_timeout() deadlock warming.
>
> Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> net/tipc/bearer.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
> index cb29ef7..41cad5f 100644
> --- a/net/tipc/bearer.c
> +++ b/net/tipc/bearer.c
> @@ -460,6 +460,7 @@ static void bearer_disable(struct tipc_bearer *b_ptr)
> {
> struct tipc_link *l_ptr;
> struct tipc_link *temp_l_ptr;
> + struct tipc_link_req *temp_req;
>
> pr_info("Disabling bearer <%s>\n", b_ptr->name);
> spin_lock_bh(&b_ptr->lock);
> @@ -468,9 +469,12 @@ static void bearer_disable(struct tipc_bearer *b_ptr)
> list_for_each_entry_safe(l_ptr, temp_l_ptr, &b_ptr->links, link_list) {
> tipc_link_delete(l_ptr);
> }
> - if (b_ptr->link_req)
> - tipc_disc_delete(b_ptr->link_req);
> + temp_req = b_ptr->link_req;
No, here is unsafe for us. Below line should be added:
b_ptr->link_req = NULL;
Otherwise, another oops will be involved!
Regards,
Ying
> spin_unlock_bh(&b_ptr->lock);
> +
> + if (temp_req)
> + tipc_disc_delete(temp_req);
> +
> memset(b_ptr, 0, sizeof(struct tipc_bearer));
> }
>
>
^ permalink raw reply
* [PATCH RESEND] tipc: avoid possible deadlock while enable and disable bearer
From: Ding Tianhong @ 2013-08-09 6:31 UTC (permalink / raw)
To: Jon Maloy, Allan Stephens, David S. Miller, Ying Xue, Netdev,
tipc-discussion, wangweidong1
We met lockdep warning when enable and disable the bearer for commands such as:
tipc-config -netid=1234 -addr=1.1.3 -be=eth:eth0
tipc-config -netid=1234 -addr=1.1.3 -bd=eth:eth0
---------------------------------------------------
[ 327.693595] ======================================================
[ 327.693994] [ INFO: possible circular locking dependency detected ]
[ 327.694519] 3.11.0-rc3-wwd-default #4 Tainted: G O
[ 327.694882] -------------------------------------------------------
[ 327.695385] tipc-config/5825 is trying to acquire lock:
[ 327.695754] (((timer))#2){+.-...}, at: [<ffffffff8105be80>] del_timer_sync+0x0/0xd0
[ 327.696018]
[ 327.696018] but task is already holding lock:
[ 327.696018] (&(&b_ptr->lock)->rlock){+.-...}, at: [<ffffffffa02be58d>] bearer_disable+ 0xdd/0x120 [tipc]
[ 327.696018]
[ 327.696018] which lock already depends on the new lock.
[ 327.696018]
[ 327.696018]
[ 327.696018] the existing dependency chain (in reverse order) is:
[ 327.696018]
[ 327.696018] -> #1 (&(&b_ptr->lock)->rlock){+.-...}:
[ 327.696018] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
[ 327.696018] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
[ 327.696018] [<ffffffff810b4453>] lock_acquire+0x103/0x130
[ 327.696018] [<ffffffff814d65b1>] _raw_spin_lock_bh+0x41/0x80
[ 327.696018] [<ffffffffa02c5d48>] disc_timeout+0x18/0xd0 [tipc]
[ 327.696018] [<ffffffff8105b92a>] call_timer_fn+0xda/0x1e0
[ 327.696018] [<ffffffff8105bcd7>] run_timer_softirq+0x2a7/0x2d0
[ 327.696018] [<ffffffff8105379a>] __do_softirq+0x16a/0x2e0
[ 327.696018] [<ffffffff81053a35>] irq_exit+0xd5/0xe0
[ 327.696018] [<ffffffff81033005>] smp_apic_timer_interrupt+0x45/0x60
[ 327.696018] [<ffffffff814df4af>] apic_timer_interrupt+0x6f/0x80
[ 327.696018] [<ffffffff8100b70e>] arch_cpu_idle+0x1e/0x30
[ 327.696018] [<ffffffff810a039d>] cpu_idle_loop+0x1fd/0x280
[ 327.696018] [<ffffffff810a043e>] cpu_startup_entry+0x1e/0x20
[ 327.696018] [<ffffffff81031589>] start_secondary+0x89/0x90
[ 327.696018]
[ 327.696018] -> #0 (((timer))#2){+.-...}:
[ 327.696018] [<ffffffff810b33fe>] check_prev_add+0x43e/0x4b0
[ 327.696018] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
[ 327.696018] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
[ 327.696018] [<ffffffff810b4453>] lock_acquire+0x103/0x130
[ 327.696018] [<ffffffff8105bebd>] del_timer_sync+0x3d/0xd0
[ 327.696018] [<ffffffffa02c5855>] tipc_disc_delete+0x15/0x30 [tipc]
[ 327.696018] [<ffffffffa02be59f>] bearer_disable+0xef/0x120 [tipc]
[ 327.696018] [<ffffffffa02be74f>] tipc_disable_bearer+0x2f/0x60 [tipc]
[ 327.696018] [<ffffffffa02bfb32>] tipc_cfg_do_cmd+0x2e2/0x550 [tipc]
[ 327.696018] [<ffffffffa02c8c79>] handle_cmd+0x49/0xe0 [tipc]
[ 327.696018] [<ffffffff8143e898>] genl_family_rcv_msg+0x268/0x340
[ 327.696018] [<ffffffff8143ed30>] genl_rcv_msg+0x70/0xd0
[ 327.696018] [<ffffffff8143d4c9>] netlink_rcv_skb+0x89/0xb0
[ 327.696018] [<ffffffff8143e617>] genl_rcv+0x27/0x40
[ 327.696018] [<ffffffff8143d21e>] netlink_unicast+0x15e/0x1b0
[ 327.696018] [<ffffffff8143ddcf>] netlink_sendmsg+0x22f/0x400
[ 327.696018] [<ffffffff813f7836>] __sock_sendmsg+0x66/0x80
[ 327.696018] [<ffffffff813f7957>] sock_aio_write+0x107/0x120
[ 327.696018] [<ffffffff8117f76d>] do_sync_write+0x7d/0xc0
[ 327.696018] [<ffffffff8117fc56>] vfs_write+0x186/0x190
[ 327.696018] [<ffffffff811803e0>] SyS_write+0x60/0xb0
[ 327.696018] [<ffffffff814de852>] system_call_fastpath+0x16/0x1b
[ 327.696018]
[ 327.696018] other info that might help us debug this:
[ 327.696018]
[ 327.696018] Possible unsafe locking scenario:
[ 327.696018]
[ 327.696018] CPU0 CPU1
[ 327.696018] ---- ----
[ 327.696018] lock(&(&b_ptr->lock)->rlock);
[ 327.696018] lock(((timer))#2);
[ 327.696018] lock(&(&b_ptr->lock)->rlock);
[ 327.696018] lock(((timer))#2);
[ 327.696018]
[ 327.696018] *** DEADLOCK ***
[ 327.696018]
[ 327.696018] 5 locks held by tipc-config/5825:
[ 327.696018] #0: (cb_lock){++++++}, at: [<ffffffff8143e608>] genl_rcv+0x18/0x40
[ 327.696018] #1: (genl_mutex){+.+.+.}, at: [<ffffffff8143ed66>] genl_rcv_msg+0xa6/0xd0
[ 327.696018] #2: (config_mutex){+.+.+.}, at: [<ffffffffa02bf889>] tipc_cfg_do_cmd+0x39/ 0x550 [tipc]
[ 327.696018] #3: (tipc_net_lock){++.-..}, at: [<ffffffffa02be738>] tipc_disable_bearer+ 0x18/0x60 [tipc]
[ 327.696018] #4: (&(&b_ptr->lock)->rlock){+.-...}, at: [<ffffffffa02be58d>] bearer_disable+0xdd/0x120 [tipc]
[ 327.696018]
[ 327.696018] stack backtrace:
[ 327.696018] CPU: 2 PID: 5825 Comm: tipc-config Tainted: G O 3.11.0-rc3-wwd- default #4
[ 327.696018] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[ 327.696018] 00000000ffffffff ffff880037fa77a8 ffffffff814d03dd 0000000000000000
[ 327.696018] ffff880037fa7808 ffff880037fa77e8 ffffffff810b1c4f 0000000037fa77e8
[ 327.696018] ffff880037fa7808 ffff880037e4db40 0000000000000000 ffff880037e4e318
[ 327.696018] Call Trace:
[ 327.696018] [<ffffffff814d03dd>] dump_stack+0x4d/0xa0
[ 327.696018] [<ffffffff810b1c4f>] print_circular_bug+0x10f/0x120
[ 327.696018] [<ffffffff810b33fe>] check_prev_add+0x43e/0x4b0
[ 327.696018] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
[ 327.696018] [<ffffffff81087a28>] ? sched_clock_cpu+0xd8/0x110
[ 327.696018] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
[ 327.696018] [<ffffffff810b4453>] lock_acquire+0x103/0x130
[ 327.696018] [<ffffffff8105be80>] ? try_to_del_timer_sync+0x70/0x70
[ 327.696018] [<ffffffff8105bebd>] del_timer_sync+0x3d/0xd0
[ 327.696018] [<ffffffff8105be80>] ? try_to_del_timer_sync+0x70/0x70
[ 327.696018] [<ffffffffa02c5855>] tipc_disc_delete+0x15/0x30 [tipc]
[ 327.696018] [<ffffffffa02be59f>] bearer_disable+0xef/0x120 [tipc]
[ 327.696018] [<ffffffffa02be74f>] tipc_disable_bearer+0x2f/0x60 [tipc]
[ 327.696018] [<ffffffffa02bfb32>] tipc_cfg_do_cmd+0x2e2/0x550 [tipc]
[ 327.696018] [<ffffffff81218783>] ? security_capable+0x13/0x20
[ 327.696018] [<ffffffffa02c8c79>] handle_cmd+0x49/0xe0 [tipc]
[ 327.696018] [<ffffffff8143e898>] genl_family_rcv_msg+0x268/0x340
[ 327.696018] [<ffffffff8143ed30>] genl_rcv_msg+0x70/0xd0
[ 327.696018] [<ffffffff8143ecc0>] ? genl_lock+0x20/0x20
[ 327.696018] [<ffffffff8143d4c9>] netlink_rcv_skb+0x89/0xb0
[ 327.696018] [<ffffffff8143e608>] ? genl_rcv+0x18/0x40
[ 327.696018] [<ffffffff8143e617>] genl_rcv+0x27/0x40
[ 327.696018] [<ffffffff8143d21e>] netlink_unicast+0x15e/0x1b0
[ 327.696018] [<ffffffff81289d7c>] ? memcpy_fromiovec+0x6c/0x90
[ 327.696018] [<ffffffff8143ddcf>] netlink_sendmsg+0x22f/0x400
[ 327.696018] [<ffffffff813f7836>] __sock_sendmsg+0x66/0x80
[ 327.696018] [<ffffffff813f7957>] sock_aio_write+0x107/0x120
[ 327.696018] [<ffffffff813fe29c>] ? release_sock+0x8c/0xa0
[ 327.696018] [<ffffffff8117f76d>] do_sync_write+0x7d/0xc0
[ 327.696018] [<ffffffff8117fa24>] ? rw_verify_area+0x54/0x100
[ 327.696018] [<ffffffff8117fc56>] vfs_write+0x186/0x190
[ 327.696018] [<ffffffff811803e0>] SyS_write+0x60/0xb0
[ 327.696018] [<ffffffff814de852>] system_call_fastpath+0x16/0x1b
-----------------------------------------------------------------------
The problem is that the tipc_link_delete() will cancel the timer disc_timeout() when
the b_ptr->lock is hold, but the disc_timeout() still call b_ptr->lock to finish the
work, so the dead lock occurs.
We should unlock the b_ptr->lock when del the disc_timeout().
Remove link_timeout() still met the same problem, the patch:
http://article.gmane.org/gmane.network.tipc.general/4380
fix the problem, so no need to send patch for fix link_timeout() deadlock warming.
Signed-off-by: Wang Weidong <wangweidong1@huawei.com>
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
---
net/tipc/bearer.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
index cb29ef7..41cad5f 100644
--- a/net/tipc/bearer.c
+++ b/net/tipc/bearer.c
@@ -460,6 +460,7 @@ static void bearer_disable(struct tipc_bearer *b_ptr)
{
struct tipc_link *l_ptr;
struct tipc_link *temp_l_ptr;
+ struct tipc_link_req *temp_req;
pr_info("Disabling bearer <%s>\n", b_ptr->name);
spin_lock_bh(&b_ptr->lock);
@@ -468,9 +469,12 @@ static void bearer_disable(struct tipc_bearer *b_ptr)
list_for_each_entry_safe(l_ptr, temp_l_ptr, &b_ptr->links, link_list) {
tipc_link_delete(l_ptr);
}
- if (b_ptr->link_req)
- tipc_disc_delete(b_ptr->link_req);
+ temp_req = b_ptr->link_req;
spin_unlock_bh(&b_ptr->lock);
+
+ if (temp_req)
+ tipc_disc_delete(temp_req);
+
memset(b_ptr, 0, sizeof(struct tipc_bearer));
}
--
1.8.2.1
^ permalink raw reply related
* Business Mail.
From: Weihua, Ma (DR) - CMB @ 2013-08-09 6:03 UTC (permalink / raw)
Complement of the day from DR. MA WEIHUA, President of China Merchants Bank
Ltd. I need your partnership in a business transaction from my Bank to your
Country.
Thanks,
Dr. Ma Weihua
^ permalink raw reply
* Re: [PATCH net-next v2 0/2] bonding: vlan handling changes
From: David Miller @ 2013-08-09 5:32 UTC (permalink / raw)
To: nikolay; +Cc: netdev, andy, fubar
In-Reply-To: <1375785616-5349-1-git-send-email-nikolay@redhat.com>
From: Nikolay Aleksandrov <nikolay@redhat.com>
Date: Tue, 6 Aug 2013 12:40:14 +0200
> From: Nikolay Aleksandrov <Nikolay Aleksandrov nikolay@redhat.com>
>
> Hi,
> In v2 of these patchset I've dropped the previous patch 01 (vlan 0 fix)
> because it'll be taken care of later and these two patches are not
> dependent on it.
>
> Patch 01 - switches the bonding to the now standard vlan syncing functions
> vlan_vids_add/del_by_dev() and removes the bonding specific ones. In v2
> upon vlan addition failure we fail the enslavement with an error message
> because otherwise we might delete vlans that weren't added by the bonding.
> The only way this may happen is with ENOMEM currently, so we're in trouble
> anyway.
>
> Patch 02 - reverts vlan addition in case of bond_add_vlan failure because
> otherwise we may get bad vlan refcounts in the slaves.
> This patch is queued for net-next because a fix for -net without the list
> conversion would mean taking care of special cases and would be really
> ugly. Since this bug is not critical, I'd rather have the fix for net-next.
> It can happen only with ENOMEM, so again we're already in trouble.
>
> Patches 01 and 02 are not connected and if you decide to drop patch 02
> please leave 01 (if accepted).
>
> v2: See the notes, I've explained the changes together and by patch.
Series applied, thanks.
^ permalink raw reply
* [BUG] mvneta: mirabox ethernet only works if initialized by uboot
From: Ethan Tuttle @ 2013-08-09 5:31 UTC (permalink / raw)
To: Thomas Petazzoni, netdev
I ran into this issue after upgrading my mirabox from the old marvell
kernel to 3.11-rc4. Although ethernet interfaces are present, and
'link up' is reported, it isn't possible to send or receive packets.
I'm using a vanilla kernel with .config from ArchLinuxARM[1].
Jochen De Smet posted a more detailed report[2] and a work-around on
the Fedora ARM list: if an interface is started using the dhcp command
in uboot, ethernet works in linux.
I reproduced the issue on -rc3 and -rc1 as well, so it isn't a recent
regression.
It should be easy to reproduce on a mirabox, even when tftping a
kernel: just try to use the other interface :).
Reporting here because I don't see any other reports to the
maintainers. I'm happy to provide more debug output or test patches
if it will help.
Thanks,
Ethan
[1] https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-mvebu/config
[2] http://www.mail-archive.com/arm@lists.fedoraproject.org/msg05244.html
^ permalink raw reply
* Re: [PATCH v2 net-next] net: add SNMP counters tracking incoming ECN bits
From: David Miller @ 2013-08-09 5:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1375785131.4457.76.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 06 Aug 2013 03:32:11 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> With GRO/LRO processing, there is a problem because Ip[6]InReceives SNMP
> counters do not count the number of frames, but number of aggregated
> segments.
>
> Its probably too late to change this now.
>
> This patch adds four new counters, tracking number of frames, regardless
> of LRO/GRO, and on a per ECN status basis, for IPv4 and IPv6.
>
> Ip[6]NoECTPkts : Number of packets received with NOECT
> Ip[6]ECT1Pkts : Number of packets received with ECT(1)
> Ip[6]ECT0Pkts : Number of packets received with ECT(0)
> Ip[6]CEPkts : Number of packets received with Congestion Experienced
>
> lph37:~# nstat | egrep "Pkts|InReceive"
> IpInReceives 1634137 0.0
> Ip6InReceives 3714107 0.0
> Ip6InNoECTPkts 19205 0.0
> Ip6InECT0Pkts 52651828 0.0
> IpExtInNoECTPkts 33630 0.0
> IpExtInECT0Pkts 15581379 0.0
> IpExtInCEPkts 6 0.0
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/2] tipc: avoid possible deadlock while remove link_timeout()
From: Ying Xue @ 2013-08-09 4:36 UTC (permalink / raw)
To: Ding Tianhong
Cc: Jon Maloy, Allan Stephens, David S. Miller, Netdev,
tipc-discussion
In-Reply-To: <5204641F.60009@huawei.com>
On 08/09/2013 11:38 AM, Ding Tianhong wrote:
> On 2013/8/9 10:39, Ying Xue wrote:
>> On 08/08/2013 06:45 PM, Ding Tianhong wrote:
>
>>>
>>> The problem is that the tipc_link_delete() will cancel the timer l_ptr->timer when
>>> the b_ptr->lock is hold, but the l_ptr->timer still call b_ptr->lock to finish the
>>> work, so the dead lock occurs.
>>>
>>
>> I guess the issue would disappear if you apply below patch:
>>
>> http://article.gmane.org/gmane.network.tipc.general/4380
>>
>> And the patch will be submitted into net-next tree soon.
>>
>> Regards,
>> Ying
>>
>
> yes, I test the patch and fix the 1/2 problem, but the 2/2 problem still occurs, if
> the http://article.gmane.org/gmane.network.tipc.general/4380 and queue for stable, I will resend
> 2/2 patch again and cancel the 1/2 patch.
>
Yes, I know. Just send patch #2.
Regards,
Ying
>
>
>
^ permalink raw reply
* Re: [PATCH 1/2] tipc: avoid possible deadlock while remove link_timeout()
From: Ding Tianhong @ 2013-08-09 3:38 UTC (permalink / raw)
To: Ying Xue
Cc: Jon Maloy, Allan Stephens, David S. Miller, Netdev,
tipc-discussion
In-Reply-To: <5204567E.2050805@windriver.com>
On 2013/8/9 10:39, Ying Xue wrote:
> On 08/08/2013 06:45 PM, Ding Tianhong wrote:
>>
>> The problem is that the tipc_link_delete() will cancel the timer l_ptr->timer when
>> the b_ptr->lock is hold, but the l_ptr->timer still call b_ptr->lock to finish the
>> work, so the dead lock occurs.
>>
>
> I guess the issue would disappear if you apply below patch:
>
> http://article.gmane.org/gmane.network.tipc.general/4380
>
> And the patch will be submitted into net-next tree soon.
>
> Regards,
> Ying
>
yes, I test the patch and fix the 1/2 problem, but the 2/2 problem still occurs, if
the http://article.gmane.org/gmane.network.tipc.general/4380 and queue for stable, I will resend
2/2 patch again and cancel the 1/2 patch.
^ permalink raw reply
* Re: [PATCH] net:ethernet:korina.c Removed IRQF_DISABLED
From: Kumar Gaurav @ 2013-08-09 3:38 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, dan.carpenter, emilio, mugunthanvnm, jg1.han,
hsweeten, netdev, kernel-janitors
In-Reply-To: <1376018881.2087.48.camel@joe-AO722>
On Friday 09 August 2013 08:58 AM, Joe Perches wrote:
> On Fri, 2013-08-09 at 08:30 +0530, Kumar Gaurav wrote:
>> On Friday 09 August 2013 08:24 AM, Joe Perches wrote:
>>> On Fri, 2013-08-09 at 08:15 +0530, Kumar Gaurav wrote:
>>>> On Friday 09 August 2013 08:09 AM, Joe Perches wrote:
>>> []
>>>>> And, maybe it'd be better to use IRQF_TRIGGER_NONE
>>>>> instead of 0.
>>>> I tried googling what to replace IRQF_DISABLED with but found nothing.
>>>> In the patch fixed earlier (not by me) it was replaced with 0 so i did
>>>> same. But from now on I'll use IRQF_TRIGGER_NONE. Thanks
>>> Maybe that's not the right thing to do.
>>> 0 is what's almost exclusively used.
>>> IRQF_TRIGGER_NONE is only used a few times.
>>> It's also a lot longer.
>>>
>> Sorry to poke back. But just want to confirm. I should use
>> IRQF_TRIGGER_NONE and not 0 right?
> Hi again Kumar.
>
> There's no rush to submit these sorts of patches.
> Nothing is going to really be improved because of these
> changes.
>
> Submit an overall rfc patch description to the various
> mailing lists (affected MAINTAINERS generally don't read
> lkml but do read their specific mailing list) with options
> like 0 or IRQF_TRIGGER_NONE to show what the issues are
> and why you're doing this.
>
> Wait at least a week for any comment.
>
> You'll likely get some "useless churn" emails.
> You can generally ignore those.
>
> If you get any real comments, deal with them.
>
> Then after at least that week passes, submit the patches.
>
> cheers, Joe
>
Will surely follow that thanks :)
^ permalink raw reply
* Re: [PATCH] net:ethernet:korina.c Removed IRQF_DISABLED
From: Joe Perches @ 2013-08-09 3:28 UTC (permalink / raw)
To: Kumar Gaurav
Cc: David Miller, dan.carpenter, emilio, mugunthanvnm, jg1.han,
hsweeten, netdev, kernel-janitors
In-Reply-To: <52045B31.9000002@gmail.com>
On Fri, 2013-08-09 at 08:30 +0530, Kumar Gaurav wrote:
> On Friday 09 August 2013 08:24 AM, Joe Perches wrote:
> > On Fri, 2013-08-09 at 08:15 +0530, Kumar Gaurav wrote:
> >> On Friday 09 August 2013 08:09 AM, Joe Perches wrote:
> > []
> >>> And, maybe it'd be better to use IRQF_TRIGGER_NONE
> >>> instead of 0.
> >> I tried googling what to replace IRQF_DISABLED with but found nothing.
> >> In the patch fixed earlier (not by me) it was replaced with 0 so i did
> >> same. But from now on I'll use IRQF_TRIGGER_NONE. Thanks
> > Maybe that's not the right thing to do.
> > 0 is what's almost exclusively used.
> > IRQF_TRIGGER_NONE is only used a few times.
> > It's also a lot longer.
> >
> Sorry to poke back. But just want to confirm. I should use
> IRQF_TRIGGER_NONE and not 0 right?
Hi again Kumar.
There's no rush to submit these sorts of patches.
Nothing is going to really be improved because of these
changes.
Submit an overall rfc patch description to the various
mailing lists (affected MAINTAINERS generally don't read
lkml but do read their specific mailing list) with options
like 0 or IRQF_TRIGGER_NONE to show what the issues are
and why you're doing this.
Wait at least a week for any comment.
You'll likely get some "useless churn" emails.
You can generally ignore those.
If you get any real comments, deal with them.
Then after at least that week passes, submit the patches.
cheers, Joe
^ permalink raw reply
* Re: [PATCH] net:ethernet:korina.c Removed IRQF_DISABLED
From: Joe Perches @ 2013-08-09 3:10 UTC (permalink / raw)
To: Kumar Gaurav
Cc: David Miller, dan.carpenter, emilio, mugunthanvnm, jg1.han,
hsweeten, netdev, kernel-janitors
In-Reply-To: <52045B31.9000002@gmail.com>
On Fri, 2013-08-09 at 08:30 +0530, Kumar Gaurav wrote:
> On Friday 09 August 2013 08:24 AM, Joe Perches wrote:
> > On Fri, 2013-08-09 at 08:15 +0530, Kumar Gaurav wrote:
> >> On Friday 09 August 2013 08:09 AM, Joe Perches wrote:
> > []
> >>> And, maybe it'd be better to use IRQF_TRIGGER_NONE
> >>> instead of 0.
> >> I tried googling what to replace IRQF_DISABLED with but found nothing.
> >> In the patch fixed earlier (not by me) it was replaced with 0 so i did
> >> same. But from now on I'll use IRQF_TRIGGER_NONE. Thanks
> > Maybe that's not the right thing to do.
> > 0 is what's almost exclusively used.
> > IRQF_TRIGGER_NONE is only used a few times.
> > It's also a lot longer.
> >
> Sorry to poke back. But just want to confirm. I should use
> IRQF_TRIGGER_NONE and not 0 right?
I'd probably just use 0 unless someone wants to
chime in otherwise with some compelling argument.
It'd be pretty easy to mechanically change any
request_irq(,, 0,
to
request_irq(,, IRQF_TRIGGER_NONE,
if that's what people want.
(and all the other types of irq requests too)
^ permalink raw reply
* Re: [PATCH] net:ethernet:korina.c Removed IRQF_DISABLED
From: Kumar Gaurav @ 2013-08-09 3:00 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, dan.carpenter, emilio, mugunthanvnm, jg1.han,
hsweeten, netdev, kernel-janitors
In-Reply-To: <1376016864.2087.34.camel@joe-AO722>
On Friday 09 August 2013 08:24 AM, Joe Perches wrote:
> On Fri, 2013-08-09 at 08:15 +0530, Kumar Gaurav wrote:
>> On Friday 09 August 2013 08:09 AM, Joe Perches wrote:
> []
>>> And, maybe it'd be better to use IRQF_TRIGGER_NONE
>>> instead of 0.
>> I tried googling what to replace IRQF_DISABLED with but found nothing.
>> In the patch fixed earlier (not by me) it was replaced with 0 so i did
>> same. But from now on I'll use IRQF_TRIGGER_NONE. Thanks
> Maybe that's not the right thing to do.
> 0 is what's almost exclusively used.
> IRQF_TRIGGER_NONE is only used a few times.
> It's also a lot longer.
>
Sorry to poke back. But just want to confirm. I should use
IRQF_TRIGGER_NONE and not 0 right?
^ permalink raw reply
* Re: [PATCH] net:ethernet:korina.c Removed IRQF_DISABLED
From: Joe Perches @ 2013-08-09 2:54 UTC (permalink / raw)
To: Kumar Gaurav
Cc: David Miller, dan.carpenter, emilio, mugunthanvnm, jg1.han,
hsweeten, netdev, kernel-janitors
In-Reply-To: <520457AD.9060508@gmail.com>
On Fri, 2013-08-09 at 08:15 +0530, Kumar Gaurav wrote:
> On Friday 09 August 2013 08:09 AM, Joe Perches wrote:
[]
> > And, maybe it'd be better to use IRQF_TRIGGER_NONE
> > instead of 0.
> I tried googling what to replace IRQF_DISABLED with but found nothing.
> In the patch fixed earlier (not by me) it was replaced with 0 so i did
> same. But from now on I'll use IRQF_TRIGGER_NONE. Thanks
Maybe that's not the right thing to do.
0 is what's almost exclusively used.
IRQF_TRIGGER_NONE is only used a few times.
It's also a lot longer.
^ permalink raw reply
* Re: [PATCH] net:ethernet:korina.c Removed IRQF_DISABLED
From: Kumar Gaurav @ 2013-08-09 2:45 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, dan.carpenter, emilio, mugunthanvnm, jg1.han,
hsweeten, netdev, kernel-janitors
In-Reply-To: <1376015984.2087.31.camel@joe-AO722>
On Friday 09 August 2013 08:09 AM, Joe Perches wrote:
> On Fri, 2013-08-09 at 07:54 +0530, Kumar Gaurav wrote:
>> On Friday 09 August 2013 03:03 AM, Joe Perches wrote:
>>> On Thu, 2013-08-08 at 14:20 -0700, David Miller wrote:
>>>> So what's the problem again? :-)
>> I'm quite new to kernel development. I saw in one of the patches which
>> fixes IRQF_DISABLED issue by removing so i did.
> Hi Kumar.
>
> No worries, welcome.
>
>>> Wouldn't it be better to do a sed 's/IRQF_DISABLED/0/' instead?
>>> Maybe Kumar wants to/is doing that?
>> Yes i wanted to do the same and i retrieved list of all programs
>> containing IRQF_DISABLED but i didn't wanted to send all of them in one
>> patch. I would be sending them for one program in one patch.
> You should definitely not send a single patch.
>
> $ git grep -w --name-only IRQF_DISABLED | wc -l
> 245
>
> I think that's way too many modified files for a
> single patch.
>
> If you do it, please remember to change bits like
> "(IRQF_<foo> | IRQF_DISABLED)" so that instead of
> "(IRQF_<foo> | 0)", you use just "IRQF_<foo>".
>
> And, maybe it'd be better to use IRQF_TRIGGER_NONE
> instead of 0.
I tried googling what to replace IRQF_DISABLED with but found nothing.
In the patch fixed earlier (not by me) it was replaced with 0 so i did
same. But from now on I'll use IRQF_TRIGGER_NONE. Thanks
> Perhaps you could send patches bundled together
> in sensible chunks, say, second level directories.
>
> Something like:
>
> $ git grep -w --name-only IRQF_DISABLED | cut -f1,2 -d"/" | uniq -c
> 1 Documentation/PCI
> 3 Documentation/scsi
> 62 arch/arm
> 1 arch/avr32
> 14 arch/cris
> 4 arch/frv
> 4 arch/h8300
> 5 arch/ia64
> 1 arch/m32r
> 7 arch/m68k
> 1 arch/microblaze
> 4 arch/mn10300
> 1 arch/score
> 2 arch/sparc
> 6 arch/x86
> 5 drivers/block
> 2 drivers/bus
> 1 drivers/cdrom
> 7 drivers/char
> 12 drivers/clocksource
> 1 drivers/crypto
> 5 drivers/dma
> 3 drivers/edac
> 2 drivers/isdn
> 21 drivers/media
> 2 drivers/misc
> 3 drivers/mtd
> 28 drivers/net
> 1 drivers/pnp
> 24 drivers/scsi
> 1 drivers/staging
> 2 drivers/tty
> 3 drivers/usb
> 2 drivers/w1
> 2 drivers/xen
> 1 include/linux
> 1 include/net
>
>
>
Okay I'll be sending patch on the second level directory.
Regards
Kumar Gaurav
^ permalink raw reply
* Re: [PATCH 1/2] tipc: avoid possible deadlock while remove link_timeout()
From: Ying Xue @ 2013-08-09 2:39 UTC (permalink / raw)
To: Ding Tianhong
Cc: Jon Maloy, Allan Stephens, David S. Miller, Netdev,
tipc-discussion
In-Reply-To: <520376BA.5040509@huawei.com>
On 08/08/2013 06:45 PM, Ding Tianhong wrote:
> We met lockdep warning when enable and disable the bearer for commands such as:
>
> tipc-config -netid=1234 -addr=1.1.3 -be=eth:eth0
> tipc-config -netid=1234 -addr=1.1.3 -bd=eth:eth0
>
> [ 3001.445459] tipc: Established link <1.1.3:eth0-1.1.2:br0> on network plane A
> [ 3029.457875] tipc: Disabling bearer <eth:eth0>
> [ 3029.458066]
> [ 3029.458071] ======================================================
> [ 3029.458075] [ INFO: possible circular locking dependency detected ]
> [ 3029.458080] 3.11.0-rc3-wwd-default #4 Not tainted
> [ 3029.458084] -------------------------------------------------------
> [ 3029.458088] rmmod/7092 is trying to acquire lock:
> [ 3029.458092] (((timer))#3){+.-...}, at: [<ffffffff8105be80>] del_timer_sync+0x0/0xd0
> [ 3029.458107]
> [ 3029.458107] but task is already holding lock:
> [ 3029.458112] (&(&b_ptr->lock)->rlock){+.-...}, at: [<ffffffffa02b94e3>] bearer_disable+0x33/0xd0 [tipc]
> [ 3029.458126]
> [ 3029.458126] which lock already depends on the new lock.
> [ 3029.458126]
> [ 3029.458132]
> [ 3029.458132] the existing dependency chain (in reverse order) is:
> [ 3029.458137]
> [ 3029.458137] -> #2 (&(&b_ptr->lock)->rlock){+.-...}:
> [ 3029.458143] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
> [ 3029.458151] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
> [ 3029.458156] [<ffffffff810b4453>] lock_acquire+0x103/0x130
> [ 3029.458161] [<ffffffff814d65b1>] _raw_spin_lock_bh+0x41/0x80
> [ 3029.458169] [<ffffffffa02b9600>] tipc_bearer_blocked+0x20/0x40 [tipc]
> [ 3029.458176] [<ffffffffa02bf01b>] tipc_link_send_proto_msg+0x35b/0x520 tipc]
> [ 3029.458184] [<ffffffffa02bf83a>] link_state_event+0x33a/0x590 [tipc]
> [ 3029.458191] [<ffffffffa02bfab9>] link_start+0x29/0x40 [tipc]
> [ 3029.458198] [<ffffffffa02bb13f>] process_signal_queue+0x7f/0xc0 [tipc]
> [ 3029.458206] [<ffffffff8105304d>] tasklet_action+0x6d/0xf0
> [ 3029.458214] [<ffffffff8105379a>] __do_softirq+0x16a/0x2e0
> [ 3029.458219] [<ffffffff81053945>] run_ksoftirqd+0x35/0x50
> [ 3029.458224] [<ffffffff8107d042>] smpboot_thread_fn+0x1e2/0x2f0
> [ 3029.458235] [<ffffffff81073c5e>] kthread+0xde/0xf0
> [ 3029.458242] [<ffffffff814de7ac>] ret_from_fork+0x7c/0xb0
> [ 3029.458250]
> [ 3029.458250] -> #1 (&(&n_ptr->lock)->rlock){+.-...}:
> [ 3029.458257] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
> [ 3029.458262] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
> [ 3029.458268] [<ffffffff810b4453>] lock_acquire+0x103/0x130
> [ 3029.458273] [<ffffffff814d65b1>] _raw_spin_lock_bh+0x41/0x80
> [ 3029.458279] [<ffffffffa02bfaec>] link_timeout+0x1c/0x170 [tipc]
> [ 3029.458287] [<ffffffff8105b92a>] call_timer_fn+0xda/0x1e0
> [ 3029.458292] [<ffffffff8105bcd7>] run_timer_softirq+0x2a7/0x2d0
> [ 3029.458298] [<ffffffff8105379a>] __do_softirq+0x16a/0x2e0
> [ 3029.458304] [<ffffffff81053a35>] irq_exit+0xd5/0xe0
> [ 3029.458309] [<ffffffff81033005>] smp_apic_timer_interrupt+0x45/0x60
> [ 3029.458319] [<ffffffff814df4af>] apic_timer_interrupt+0x6f/0x80
> [ 3029.458325] [<ffffffff8100b70e>] arch_cpu_idle+0x1e/0x30
> [ 3029.458332] [<ffffffff810a039d>] cpu_idle_loop+0x1fd/0x280
> [ 3029.458338] [<ffffffff810a043e>] cpu_startup_entry+0x1e/0x20
> [ 3029.458343] [<ffffffff814c8841>] rest_init+0xc1/0xd0
> [ 3029.458349] [<ffffffff81c990fc>] start_kernel+0x3a3/0x451
> [ 3029.458356] [<ffffffff81c984d1>] x86_64_start_reservations+0x1b/0x32
> [ 3029.458362] [<ffffffff81c98622>] x86_64_start_kernel+0x13a/0x141
> [ 3029.458368]
> [ 3029.458368] -> #0 (((timer))#3){+.-...}:
> [ 3029.458375] [<ffffffff810b33fe>] check_prev_add+0x43e/0x4b0
> [ 3029.458380] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
> [ 3029.458386] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
> [ 3029.458391] [<ffffffff810b4453>] lock_acquire+0x103/0x130
> [ 3029.458397] [<ffffffff8105bebd>] del_timer_sync+0x3d/0xd0
> [ 3029.458402] [<ffffffffa02bcc4e>] tipc_link_delete+0x1e/0xb0 [tipc]
> [ 3029.458410] [<ffffffffa02b9528>] bearer_disable+0x78/0xd0 [tipc]
> [ 3029.458417] [<ffffffffa02b95b4>] tipc_bearer_stop+0x34/0x60 [tipc]
> [ 3029.458423] [<ffffffffa02c384b>] tipc_net_stop+0x2b/0x90 [tipc]
> [ 3029.458432] [<ffffffffa02caf49>] tipc_exit+0x9/0xc0 [tipc]
> [ 3029.458439] [<ffffffff810c1a58>] SyS_delete_module+0x198/0x290
> [ 3029.458445] [<ffffffff814de852>] system_call_fastpath+0x16/0x1b
> [ 3029.458451]
> [ 3029.458451] other info that might help us debug this:
> [ 3029.458451]
> [ 3029.458458] Chain exists of:
> [ 3029.458458] ((timer))#3 --> &(&n_ptr->lock)->rlock --> &(&b_ptr->lock)->rlock
> [ 3029.458458]
> [ 3029.458469] Possible unsafe locking scenario:
> [ 3029.458469]
> [ 3029.458474] CPU0 CPU1
> [ 3029.458478] ---- ----
> [ 3029.458481] lock(&(&b_ptr->lock)->rlock);
> [ 3029.458486] lock(&(&n_ptr->lock)->rlock);
> [ 3029.458492] lock(&(&b_ptr->lock)->rlock);
> [ 3029.458497] lock(((timer))#3);
> [ 3029.458502]
> [ 3029.458502] *** DEADLOCK ***
> [ 3029.458502]
> [ 3029.458508] 2 locks held by rmmod/7092:
> [ 3029.458511] #0: (tipc_net_lock){++.-..}, at: [<ffffffffa02c3846>] tipc_net_stop+0x26/0x90 [tipc]
> [ 3029.458523] #1: (&(&b_ptr->lock)->rlock){+.-...}, at: [<ffffffffa02b94e3>]bearer_disable+0x33/0xd0 [tipc]
> [ 3029.458535]
> [ 3029.458535] stack backtrace:
> [ 3029.458541] CPU: 3 PID: 7092 Comm: rmmod Not tainted 3.11.0-rc3-wwd-default #4
> [ 3029.458546] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> [ 3029.458550] 00000000ffffffff ffff88010fd09c08 ffffffff814d03dd 0000000000000000
> [ 3029.458559] ffffffff8205fca0 ffff88010fd09c48 ffffffff810b1c4f 000000000fd09c48
> [ 3029.458566] ffff88010fd09c68 ffff88010e4d4fc0 0000000000000000 ffff88010e4d56f0
> [ 3029.458574] Call Trace:
> [ 3029.458579] [<ffffffff814d03dd>] dump_stack+0x4d/0xa0
> [ 3029.458585] [<ffffffff810b1c4f>] print_circular_bug+0x10f/0x120
> [ 3029.458591] [<ffffffff810b33fe>] check_prev_add+0x43e/0x4b0
> [ 3029.458598] [<ffffffff8100a226>] ? native_sched_clock+0x26/0x90
> [ 3029.458604] [<ffffffff810b3b4d>] validate_chain+0x6dd/0x870
> [ 3029.458612] [<ffffffff81087a28>] ? sched_clock_cpu+0xd8/0x110
> [ 3029.458618] [<ffffffff810b40bb>] __lock_acquire+0x3db/0x670
> [ 3029.458624] [<ffffffff810b4453>] lock_acquire+0x103/0x130
> [ 3029.458629] [<ffffffff8105be80>] ? try_to_del_timer_sync+0x70/0x70
> [ 3029.458635] [<ffffffff8105bebd>] del_timer_sync+0x3d/0xd0
> [ 3029.458641] [<ffffffff8105be80>] ? try_to_del_timer_sync+0x70/0x70
> [ 3029.458649] [<ffffffffa02bcc4e>] tipc_link_delete+0x1e/0xb0 [tipc]
> [ 3029.458656] [<ffffffffa02b9528>] bearer_disable+0x78/0xd0 [tipc]
> [ 3029.458663] [<ffffffffa02b95b4>] tipc_bearer_stop+0x34/0x60 [tipc]
> [ 3029.458671] [<ffffffffa02c384b>] tipc_net_stop+0x2b/0x90 [tipc]
> [ 3029.458679] [<ffffffffa02caf49>] tipc_exit+0x9/0xc0 [tipc]
> [ 3029.458685] [<ffffffff810c1a58>] SyS_delete_module+0x198/0x290
> [ 3029.458691] [<ffffffff814de852>] system_call_fastpath+0x16/0x1b
>
> ----------------------------------------------------------------------
>
> The problem is that the tipc_link_delete() will cancel the timer l_ptr->timer when
> the b_ptr->lock is hold, but the l_ptr->timer still call b_ptr->lock to finish the
> work, so the dead lock occurs.
>
I guess the issue would disappear if you apply below patch:
http://article.gmane.org/gmane.network.tipc.general/4380
And the patch will be submitted into net-next tree soon.
Regards,
Ying
> We should unlock the b_ptr->lock when del the l_ptr->timer.
>
> Reported-by: Wang Weidong <wangweidong1@huawei.com>
> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> ---
> net/tipc/bearer.c | 8 +++++++-
> net/tipc/link.c | 2 ++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/net/tipc/bearer.c b/net/tipc/bearer.c
> index cb29ef7..7687211 100644
> --- a/net/tipc/bearer.c
> +++ b/net/tipc/bearer.c
> @@ -460,14 +460,20 @@ static void bearer_disable(struct tipc_bearer *b_ptr)
> {
> struct tipc_link *l_ptr;
> struct tipc_link *temp_l_ptr;
> + struct list_head list;
>
> pr_info("Disabling bearer <%s>\n", b_ptr->name);
> spin_lock_bh(&b_ptr->lock);
> b_ptr->blocked = 1;
> b_ptr->media->disable_bearer(b_ptr);
> - list_for_each_entry_safe(l_ptr, temp_l_ptr, &b_ptr->links, link_list) {
> + list_replace_init(&b_ptr->links, &list);
> + spin_unlock_bh(&b_ptr->lock);
> +
> + list_for_each_entry_safe(l_ptr, temp_l_ptr, &list, link_list) {
> tipc_link_delete(l_ptr);
> }
> +
> + spin_lock_bh(&b_ptr->lock);
> if (b_ptr->link_req)
> tipc_disc_delete(b_ptr->link_req);
> spin_unlock_bh(&b_ptr->lock);
> diff --git a/net/tipc/link.c b/net/tipc/link.c
> index 0cc3d90..a145718 100644
> --- a/net/tipc/link.c
> +++ b/net/tipc/link.c
> @@ -384,10 +384,12 @@ void tipc_link_delete(struct tipc_link *l_ptr)
> k_cancel_timer(&l_ptr->timer);
>
> tipc_node_lock(l_ptr->owner);
> + spin_lock_bh(&l_ptr->b_ptr->lock);
> tipc_link_reset(l_ptr);
> tipc_node_detach_link(l_ptr->owner, l_ptr);
> tipc_link_stop(l_ptr);
> list_del_init(&l_ptr->link_list);
> + spin_unlock_bh(&l_ptr->b_ptr->lock);
> tipc_node_unlock(l_ptr->owner);
> k_term_timer(&l_ptr->timer);
> kfree(l_ptr);
>
^ permalink raw reply
* Re: [PATCH] net:ethernet:korina.c Removed IRQF_DISABLED
From: Joe Perches @ 2013-08-09 2:39 UTC (permalink / raw)
To: Kumar Gaurav
Cc: David Miller, dan.carpenter, emilio, mugunthanvnm, jg1.han,
hsweeten, netdev, kernel-janitors
In-Reply-To: <520452F4.2070804@gmail.com>
On Fri, 2013-08-09 at 07:54 +0530, Kumar Gaurav wrote:
> On Friday 09 August 2013 03:03 AM, Joe Perches wrote:
> > On Thu, 2013-08-08 at 14:20 -0700, David Miller wrote:
> >> So what's the problem again? :-)
> I'm quite new to kernel development. I saw in one of the patches which
> fixes IRQF_DISABLED issue by removing so i did.
Hi Kumar.
No worries, welcome.
> > Wouldn't it be better to do a sed 's/IRQF_DISABLED/0/' instead?
> > Maybe Kumar wants to/is doing that?
> Yes i wanted to do the same and i retrieved list of all programs
> containing IRQF_DISABLED but i didn't wanted to send all of them in one
> patch. I would be sending them for one program in one patch.
You should definitely not send a single patch.
$ git grep -w --name-only IRQF_DISABLED | wc -l
245
I think that's way too many modified files for a
single patch.
If you do it, please remember to change bits like
"(IRQF_<foo> | IRQF_DISABLED)" so that instead of
"(IRQF_<foo> | 0)", you use just "IRQF_<foo>".
And, maybe it'd be better to use IRQF_TRIGGER_NONE
instead of 0.
Perhaps you could send patches bundled together
in sensible chunks, say, second level directories.
Something like:
$ git grep -w --name-only IRQF_DISABLED | cut -f1,2 -d"/" | uniq -c
1 Documentation/PCI
3 Documentation/scsi
62 arch/arm
1 arch/avr32
14 arch/cris
4 arch/frv
4 arch/h8300
5 arch/ia64
1 arch/m32r
7 arch/m68k
1 arch/microblaze
4 arch/mn10300
1 arch/score
2 arch/sparc
6 arch/x86
5 drivers/block
2 drivers/bus
1 drivers/cdrom
7 drivers/char
12 drivers/clocksource
1 drivers/crypto
5 drivers/dma
3 drivers/edac
2 drivers/isdn
21 drivers/media
2 drivers/misc
3 drivers/mtd
28 drivers/net
1 drivers/pnp
24 drivers/scsi
1 drivers/staging
2 drivers/tty
3 drivers/usb
2 drivers/w1
2 drivers/xen
1 include/linux
1 include/net
^ permalink raw reply
* Re: [PATCH] net:ethernet:korina.c Removed IRQF_DISABLED
From: Kumar Gaurav @ 2013-08-09 2:24 UTC (permalink / raw)
To: Joe Perches
Cc: David Miller, dan.carpenter, emilio, mugunthanvnm, jg1.han,
hsweeten, netdev, kernel-janitors
In-Reply-To: <1375997625.2087.14.camel@joe-AO722>
On Friday 09 August 2013 03:03 AM, Joe Perches wrote:
> On Thu, 2013-08-08 at 14:20 -0700, David Miller wrote:
>> From: Dan Carpenter <dan.carpenter@oracle.com>
>> Date: Fri, 9 Aug 2013 00:09:18 +0300
>>
>>> On Fri, Aug 09, 2013 at 12:50:49AM +0530, Kumar Gaurav wrote:
>>>> Removed IRQF_DISABLED as it's no-op and should be removed
>>>>
>>> What? No, that doesn't sound right.
>> The IRQ layer completely ignores the flag for several releases
>> now, it's a complete no-op as his commit message so adequately
>> states.
>>
>> So what's the problem again? :-)
I'm quite new to kernel development. I saw in one of the patches which
fixes IRQF_DISABLED issue by removing so i did.
> Wouldn't it be better to do a sed 's/IRQF_DISABLED/0/' instead?
> Maybe Kumar wants to/is doing that?
Yes i wanted to do the same and i retrieved list of all programs
containing IRQF_DISABLED but i didn't wanted to send all of them in one
patch. I would be sending them for one program in one patch.
Regards
Kumar Gaurav
^ permalink raw reply
* Re: [PATCH v3 4/4] USBNET: ax88179_178a: enable tso if usb host supports sg dma
From: Ming Lei @ 2013-08-09 1:44 UTC (permalink / raw)
To: Grant Grundler
Cc: Eric Dumazet, David S. Miller, Greg Kroah-Hartman, Oliver Neukum,
Sarah Sharp, netdev, linux-usb, Ben Hutchings, Alan Stern,
Freddy Xin
In-Reply-To: <CANEJEGsqGFCLXBUT_3SEd4Ej9g8XFOYZwm9omscNvJgz7MXUHg@mail.gmail.com>
On Fri, Aug 9, 2013 at 8:18 AM, Grant Grundler <grundler@google.com> wrote:
> Ming,
> We are splitting hairs now. :) I want to be clear I think your changes
> are good and the rest of this conversation is just to learn something
> new.
>
> On Thu, Aug 8, 2013 at 4:48 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> On Fri, Aug 9, 2013 at 1:25 AM, Grant Grundler <grundler@google.com> wrote:
> ...
>>>> I am afraid that PCI network devices' setting still won't survive unbound&
>>>> re-probed, will they?
>>>
>>> Correct - but PCI isn't as prone to "dropping off the bus" like USB
>>
>> As far as I know, USB device still won't be disconnected easily, and
>> reset is possible, but we can make setting survive reset by implementing
>> .pre_reset() and .post_reset() callback. Or do you have other situation
>> of USB 'dropping off the bus'?
>
> So far only older USB core bugs like this one:
> https://codereview.chromium.org/4687002/show
This happens in configuration change situation, which is seldom
triggered, and also not "randomly" happen per your standpoint,
just like rmmod/modprobe , :-)
> I agree USB won't be disconnected easily.
>
>>> is. Master aborts on some PCI systems is a "Fatal Exception" and AFAIK
>>> that's never been true for any USB device.
>>
>> I mean rmmod & modprobe still can reset setting of one PCI network
>> device after powering on the device, can't it?
>
> Definitely. But this isn't something that will "randomly" happen and
> will leave tracks all over the place of it happening. So I'm not
> worried about trying to debug this scenario.
Thanks,
--
Ming Lei
^ permalink raw reply
* [ 19/25] sctp: fully initialize sctp_outq in sctp_outq_init
From: Greg Kroah-Hartman @ 2013-08-09 1:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Neil Horman,
West, Steve (NSN - US/Fort Worth), Vlad Yasevich, David S. Miller,
netdev
In-Reply-To: <20130809013649.057678051@linuxfoundation.org>
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Neil Horman <nhorman@tuxdriver.com>
[ Upstream commit c5c7774d7eb4397891edca9ebdf750ba90977a69 ]
In commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86
(refactor sctp_outq_teardown to insure proper re-initalization)
we modified sctp_outq_teardown to use sctp_outq_init to fully re-initalize the
outq structure. Steve West recently asked me why I removed the q->error = 0
initalization from sctp_outq_teardown. I did so because I was operating under
the impression that sctp_outq_init would properly initalize that value for us,
but it doesn't. sctp_outq_init operates under the assumption that the outq
struct is all 0's (as it is when called from sctp_association_init), but using
it in __sctp_outq_teardown violates that assumption. We should do a memset in
sctp_outq_init to ensure that the entire structure is in a known state there
instead.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: "West, Steve (NSN - US/Fort Worth)" <steve.west@nsn.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: netdev@vger.kernel.org
CC: davem@davemloft.net
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sctp/outqueue.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -205,6 +205,8 @@ static inline int sctp_cacc_skip(struct
*/
void sctp_outq_init(struct sctp_association *asoc, struct sctp_outq *q)
{
+ memset(q, 0, sizeof(struct sctp_outq));
+
q->asoc = asoc;
INIT_LIST_HEAD(&q->out_chunk_list);
INIT_LIST_HEAD(&q->control_chunk_list);
@@ -212,13 +214,7 @@ void sctp_outq_init(struct sctp_associat
INIT_LIST_HEAD(&q->sacked);
INIT_LIST_HEAD(&q->abandoned);
- q->fast_rtx = 0;
- q->outstanding_bytes = 0;
q->empty = 1;
- q->cork = 0;
-
- q->malloced = 0;
- q->out_qlen = 0;
}
/* Free the outqueue structure and any related pending chunks.
^ permalink raw reply
* [ 17/22] sctp: fully initialize sctp_outq in sctp_outq_init
From: Greg Kroah-Hartman @ 2013-08-09 1:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Neil Horman,
West, Steve (NSN - US/Fort Worth), Vlad Yasevich, David S. Miller,
netdev
In-Reply-To: <20130809013949.226228694@linuxfoundation.org>
3.0-stable review patch. If anyone has any objections, please let me know.
------------------
From: Neil Horman <nhorman@tuxdriver.com>
[ Upstream commit c5c7774d7eb4397891edca9ebdf750ba90977a69 ]
In commit 2f94aabd9f6c925d77aecb3ff020f1cc12ed8f86
(refactor sctp_outq_teardown to insure proper re-initalization)
we modified sctp_outq_teardown to use sctp_outq_init to fully re-initalize the
outq structure. Steve West recently asked me why I removed the q->error = 0
initalization from sctp_outq_teardown. I did so because I was operating under
the impression that sctp_outq_init would properly initalize that value for us,
but it doesn't. sctp_outq_init operates under the assumption that the outq
struct is all 0's (as it is when called from sctp_association_init), but using
it in __sctp_outq_teardown violates that assumption. We should do a memset in
sctp_outq_init to ensure that the entire structure is in a known state there
instead.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: "West, Steve (NSN - US/Fort Worth)" <steve.west@nsn.com>
CC: Vlad Yasevich <vyasevich@gmail.com>
CC: netdev@vger.kernel.org
CC: davem@davemloft.net
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/sctp/outqueue.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
--- a/net/sctp/outqueue.c
+++ b/net/sctp/outqueue.c
@@ -205,6 +205,8 @@ static inline int sctp_cacc_skip(struct
*/
void sctp_outq_init(struct sctp_association *asoc, struct sctp_outq *q)
{
+ memset(q, 0, sizeof(struct sctp_outq));
+
q->asoc = asoc;
INIT_LIST_HEAD(&q->out_chunk_list);
INIT_LIST_HEAD(&q->control_chunk_list);
@@ -212,13 +214,7 @@ void sctp_outq_init(struct sctp_associat
INIT_LIST_HEAD(&q->sacked);
INIT_LIST_HEAD(&q->abandoned);
- q->fast_rtx = 0;
- q->outstanding_bytes = 0;
q->empty = 1;
- q->cork = 0;
-
- q->malloced = 0;
- q->out_qlen = 0;
}
/* Free the outqueue structure and any related pending chunks.
^ permalink raw reply
* Re: [PATCH] net:ethernet:korina.c Removed IRQF_DISABLED
From: Jingoo Han @ 2013-08-09 0:59 UTC (permalink / raw)
To: 'David Miller'
Cc: dan.carpenter, kumargauravgupta3, emilio, mugunthanvnm, hsweeten,
netdev, kernel-janitors, Jingoo Han
In-Reply-To: <20130808.142054.1541424422807503741.davem@davemloft.net>
On Friday, August 09, 2013 6:21 AM, David Miller wrote:
> On Fri, 9 Aug 2013 00:09:18 +0300, Dan Carpenter wrote:
> > On Fri, Aug 09, 2013 at 12:50:49AM +0530, Kumar Gaurav wrote:
> >> Removed IRQF_DISABLED as it's no-op and should be removed
> >>
> >
> > What? No, that doesn't sound right.
>
> The IRQ layer completely ignores the flag for several releases
> now, it's a complete no-op as his commit message so adequately
> states.
Yes, you're right. :-)
Currently, 'IRQF_DISABLED' is deprecated as below.
(include/linux/interrupt.h)
* IRQF_DISABLED - keep irqs disabled when calling the action handler.
* DEPRECATED. This flag is a NOOP and scheduled to be removed
Best regards,
Jingoo Han
>
> So what's the problem again? :-)
^ permalink raw reply
* Re: [PATCH] tcp: add server ip to encrypt cookie in fast open
From: Neal Cardwell @ 2013-08-09 0:48 UTC (permalink / raw)
To: Yuchung Cheng; +Cc: David Miller, Eric Dumazet, Netdev
In-Reply-To: <1375995982-17862-1-git-send-email-ycheng@google.com>
On Thu, Aug 8, 2013 at 5:06 PM, Yuchung Cheng <ycheng@google.com> wrote:
> Encrypt the cookie with both server and client IPv4 addresses,
> such that multi-homed server will grant different cookies
> based on both the source and destination IPs. No client change
> is needed since cookie is opaque to the client.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> ---
> include/net/tcp.h | 3 ++-
> net/ipv4/tcp_fastopen.c | 13 ++++++-------
> net/ipv4/tcp_ipv4.c | 10 +++++++---
> 3 files changed, 15 insertions(+), 11 deletions(-)
Acked-by: Neal Cardwell <ncardwell@google.com>
^ permalink raw reply
* Re: [PATCH v3 4/4] USBNET: ax88179_178a: enable tso if usb host supports sg dma
From: Grant Grundler @ 2013-08-09 0:18 UTC (permalink / raw)
To: Ming Lei
Cc: Eric Dumazet, David S. Miller, Greg Kroah-Hartman, Oliver Neukum,
Sarah Sharp, netdev, linux-usb, Ben Hutchings, Alan Stern,
Freddy Xin
In-Reply-To: <CACVXFVMWWcf5duqU9_NB6QMzN1mxE6HfHJ6Aco1u3+4+x7u8JA@mail.gmail.com>
Ming,
We are splitting hairs now. :) I want to be clear I think your changes
are good and the rest of this conversation is just to learn something
new.
On Thu, Aug 8, 2013 at 4:48 PM, Ming Lei <ming.lei@canonical.com> wrote:
> On Fri, Aug 9, 2013 at 1:25 AM, Grant Grundler <grundler@google.com> wrote:
...
>>> I am afraid that PCI network devices' setting still won't survive unbound&
>>> re-probed, will they?
>>
>> Correct - but PCI isn't as prone to "dropping off the bus" like USB
>
> As far as I know, USB device still won't be disconnected easily, and
> reset is possible, but we can make setting survive reset by implementing
> .pre_reset() and .post_reset() callback. Or do you have other situation
> of USB 'dropping off the bus'?
So far only older USB core bugs like this one:
https://codereview.chromium.org/4687002/show
I agree USB won't be disconnected easily.
>> is. Master aborts on some PCI systems is a "Fatal Exception" and AFAIK
>> that's never been true for any USB device.
>
> I mean rmmod & modprobe still can reset setting of one PCI network
> device after powering on the device, can't it?
Definitely. But this isn't something that will "randomly" happen and
will leave tracks all over the place of it happening. So I'm not
worried about trying to debug this scenario.
thanks,
grant
>
>
> Thanks,
> --
> Ming Lei
^ permalink raw reply
* Re: [PATCH v2 net-next] net: Add low-latency/polling support for UDP multicast
From: Eric Dumazet @ 2013-08-08 23:55 UTC (permalink / raw)
To: Eliezer Tamir; +Cc: Shawn Bohrer, davem, netdev, Amir Vadai, tomk
In-Reply-To: <52035AD9.30703@linux.intel.com>
On Thu, 2013-08-08 at 11:46 +0300, Eliezer Tamir wrote:
> On 07/08/2013 23:22, Eric Dumazet wrote:
> > On Tue, 2013-08-06 at 14:51 -0500, Shawn Bohrer wrote:
> >> Set the napi id for each socket in the multicast path to enable
> >> low-latency/polling support.
> >>
> >> Signed-off-by: Shawn Bohrer <sbohrer@rgmadvisors.com>
> >> ---
> >> v2 include ipv6 support
> >
> > This might help your workload, but I doubt it is generic enough.
> >
> > One UDP socket is supposed to receive traffic from many endpoints,
> > so we have no guarantee all the received traffic will end on a single RX
> > queue on the NIC.
> >
> > That's the same logic than RFS here.
> >
> > sk_mark_napi_id() in UDP are wrong IMHO.
> >
> > It should be guarded by the following test in
> > __udp_queue_rcv_skb()
> >
> > if (inet_sk(sk)->inet_daddr) {
> > sock_rps_save_rxhash(sk, skb);
> > sk_mark_napi_id(sk, skb);
> > }
> >
> > (To occur only for connected UDP sockets, where we are 100% sure all
> > packets will use this same rxhash/rx queue)
>
> This would also be safe if there is only one NIC and said NIC was
> programmed to always place this socket's data on the same queue.
>
> I don't have a good suggestion on how to detect this.
Well, this stuff relies on flows being correctly steered.
TCP stack performs much better if we avoid reorders ;)
^ permalink raw reply
* Re: [PATCH v3 4/4] USBNET: ax88179_178a: enable tso if usb host supports sg dma
From: Ming Lei @ 2013-08-08 23:48 UTC (permalink / raw)
To: Grant Grundler
Cc: Eric Dumazet, David S. Miller, Greg Kroah-Hartman, Oliver Neukum,
Sarah Sharp, netdev, linux-usb, Ben Hutchings, Alan Stern,
Freddy Xin
In-Reply-To: <CANEJEGvvxi83=b+NGTzsVpJw5fE5nb-R0BRWRJ2gz7bF5-H5AA@mail.gmail.com>
On Fri, Aug 9, 2013 at 1:25 AM, Grant Grundler <grundler@google.com> wrote:
> On Tue, Aug 6, 2013 at 5:41 PM, Ming Lei <ming.lei@canonical.com> wrote:
>> On Wed, Aug 7, 2013 at 1:09 AM, Grant Grundler <grundler@google.com> wrote:
> ...
>>> Following that logic, shouldn't all the features/hw_features settings
>>> be removed from reset code path?
>>
>> This patch won't touch other settings because that isn't related with
>> this patch.
>
> Sorry - I didn't mean to imply your patch should do this. I was hoping
> for a yes/no answer from you, Eric, or Dave.
>
> ...
>>> I'll note that any "hiccup" in the USB side that causes the device to
>>> get dropped and re-probed will cause the same symptom. There is
>>
>> I am afraid that PCI network devices' setting still won't survive unbound&
>> re-probed, will they?
>
> Correct - but PCI isn't as prone to "dropping off the bus" like USB
As far as I know, USB device still won't be disconnected easily, and
reset is possible, but we can make setting survive reset by implementing
.pre_reset() and .post_reset() callback. Or do you have other situation
of USB 'dropping off the bus'?
> is. Master aborts on some PCI systems is a "Fatal Exception" and AFAIK
> that's never been true for any USB device.
I mean rmmod & modprobe still can reset setting of one PCI network
device after powering on the device, can't it?
Thanks,
--
Ming Lei
^ 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