@@ -323,7 +323,7 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,}spin_lock_init(&p->tcfa_lock);idr_preload(GFP_KERNEL);-spin_lock_bh(&idrinfo->lock);+spin_lock(&idrinfo->lock);/* user doesn't specify an index */if(!index){index=1;
From: Cong Wang <hidden> Date: 2018-05-19 02:59:44
On Fri, May 18, 2018 at 8:45 AM, Vlad Buslov [off-list ref] wrote:
Underlying implementation of action map has changed and doesn't require
disabling bh anymore. Replace all action idr spinlock usage with regular
calls that do not disable bh.
Please explain explicitly why it is not required, don't let people
dig, this would save everyone's time.
Also, this should be targeted for net-next, right?
Thanks.
On Sat 19 May 2018 at 02:59, Cong Wang [off-list ref] wrote:
On Fri, May 18, 2018 at 8:45 AM, Vlad Buslov [off-list ref] wrote:
quoted
Underlying implementation of action map has changed and doesn't require
disabling bh anymore. Replace all action idr spinlock usage with regular
calls that do not disable bh.
Please explain explicitly why it is not required, don't let people
dig, this would save everyone's time.
Underlying implementation of actions lookup has changed from hashtable
to idr. Every current action implementation just calls act_api lookup
function instead of implementing its own lookup. I asked author of idr
change if there is a reason to continue to use _bh versions and he
replied that he just left them as-is.
Also, this should be targeted for net-next, right?
On Sat 19 May 2018 at 02:59, Cong Wang [off-list ref] wrote:
quoted
On Fri, May 18, 2018 at 8:45 AM, Vlad Buslov [off-list ref] wrote:
quoted
Underlying implementation of action map has changed and doesn't require
disabling bh anymore. Replace all action idr spinlock usage with regular
calls that do not disable bh.
Please explain explicitly why it is not required, don't let people
dig, this would save everyone's time.
Underlying implementation of actions lookup has changed from hashtable
to idr. Every current action implementation just calls act_api lookup
function instead of implementing its own lookup. I asked author of idr
change if there is a reason to continue to use _bh versions and he
replied that he just left them as-is.
A detailed analysis of the locking requirements both before and
after the IDR changes needs to be in you commit message.
Nobody who reads this from scratch understands all of this background
material, so how can anyone reading your patch review it properly and
understand it?
Initial net_device implementation used ingress_lock spinlock to synchronize
ingress path of device. This lock was used in both process and bh context.
In some code paths action map lock was obtained while holding ingress_lock.
Commit e1e992e52faa ("[NET_SCHED] protect action config/dump from irqs")
modified actions to always disable bh, while using action map lock, in
order to prevent deadlock on ingress_lock in softirq. This lock was removed
from net_device, so disabling bh, while accessing action map, is no longer
necessary.
Replace all action idr spinlock usage with regular calls that do not
disable bh.
Signed-off-by: Vlad Buslov <redacted>
---
net/sched/act_api.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
@@ -323,7 +323,7 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,}spin_lock_init(&p->tcfa_lock);idr_preload(GFP_KERNEL);-spin_lock_bh(&idrinfo->lock);+spin_lock(&idrinfo->lock);/* user doesn't specify an index */if(!index){index=1;
From: Jamal Hadi Salim <jhs@mojatatu.com> Date: 2018-05-22 12:50:13
On 21/05/18 04:03 PM, Vlad Buslov wrote:
Initial net_device implementation used ingress_lock spinlock to synchronize
ingress path of device. This lock was used in both process and bh context.
In some code paths action map lock was obtained while holding ingress_lock.
Commit e1e992e52faa ("[NET_SCHED] protect action config/dump from irqs")
modified actions to always disable bh, while using action map lock, in
order to prevent deadlock on ingress_lock in softirq. This lock was removed
from net_device, so disabling bh, while accessing action map, is no longer
necessary.
Replace all action idr spinlock usage with regular calls that do not
disable bh.
Signed-off-by: Vlad Buslov <redacted>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
cheers,
jamal
From: Cong Wang <hidden> Date: 2018-05-23 01:10:51
On Mon, May 21, 2018 at 1:03 PM, Vlad Buslov [off-list ref] wrote:
Initial net_device implementation used ingress_lock spinlock to synchronize
ingress path of device. This lock was used in both process and bh context.
In some code paths action map lock was obtained while holding ingress_lock.
Commit e1e992e52faa ("[NET_SCHED] protect action config/dump from irqs")
modified actions to always disable bh, while using action map lock, in
order to prevent deadlock on ingress_lock in softirq. This lock was removed
from net_device, so disabling bh, while accessing action map, is no longer
necessary.
Replace all action idr spinlock usage with regular calls that do not
disable bh.
While your patch is probably fine, the above justification seems not.
In the past, tc actions could be released in BH context because tc
filters use call_rcu(). However, I moved them to a workqueue recently.
So before my change I don't think you can remove the BH protection,
otherwise race with idr_remove()...
On Wed 23 May 2018 at 01:10, Cong Wang [off-list ref] wrote:
On Mon, May 21, 2018 at 1:03 PM, Vlad Buslov [off-list ref] wrote:
quoted
Initial net_device implementation used ingress_lock spinlock to synchronize
ingress path of device. This lock was used in both process and bh context.
In some code paths action map lock was obtained while holding ingress_lock.
Commit e1e992e52faa ("[NET_SCHED] protect action config/dump from irqs")
modified actions to always disable bh, while using action map lock, in
order to prevent deadlock on ingress_lock in softirq. This lock was removed
from net_device, so disabling bh, while accessing action map, is no longer
necessary.
Replace all action idr spinlock usage with regular calls that do not
disable bh.
While your patch is probably fine, the above justification seems not.
Sorry if I missed something. My justification is based on commit
description that added bh disable in subject code.
In the past, tc actions could be released in BH context because tc
filters use call_rcu(). However, I moved them to a workqueue recently.
So before my change I don't think you can remove the BH protection,
otherwise race with idr_remove()...
Found commit series that you described. Will modify commit message
accordingly.
Thanks,
Vlad
Mon, May 21, 2018 at 10:03:04PM CEST, vladbu@mellanox.com wrote:
Initial net_device implementation used ingress_lock spinlock to synchronize
ingress path of device. This lock was used in both process and bh context.
In some code paths action map lock was obtained while holding ingress_lock.
Commit e1e992e52faa ("[NET_SCHED] protect action config/dump from irqs")
modified actions to always disable bh, while using action map lock, in
order to prevent deadlock on ingress_lock in softirq. This lock was removed
from net_device, so disabling bh, while accessing action map, is no longer
necessary.
Replace all action idr spinlock usage with regular calls that do not
disable bh.
Signed-off-by: Vlad Buslov <redacted>
Please add my tag to v3, with the description changes requested by Cong.
Acked-by: Jiri Pirko <redacted>
Thanks!
Initial net_device implementation used ingress_lock spinlock to synchronize
ingress path of device. This lock was used in both process and bh context.
In some code paths action map lock was obtained while holding ingress_lock.
Commit e1e992e52faa ("[NET_SCHED] protect action config/dump from irqs")
modified actions to always disable bh, while using action map lock, in
order to prevent deadlock on ingress_lock in softirq. This lock was removed
in commit 555353cfa1ae ("netdev: The ingress_lock member is no longer
needed.").
Another reason to disable bh was filters delete code, that released actions
in rcu callback. This code was changed to release actions from workqueue
context in patch set "net_sched: close the race between call_rcu() and
cleanup_net()".
With these changes it is no longer necessary to continue disable bh while
accessing action map.
Replace all action idr spinlock usage with regular calls that do not
disable bh.
Acked-by: Jiri Pirko <redacted>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: Vlad Buslov <redacted>
---
Changes from V2 to V3:
- Expanded commit message.
Changes from V1 to V2:
- Expanded commit message.
net/sched/act_api.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
@@ -323,7 +323,7 @@ int tcf_idr_create(struct tc_action_net *tn, u32 index, struct nlattr *est,}spin_lock_init(&p->tcfa_lock);idr_preload(GFP_KERNEL);-spin_lock_bh(&idrinfo->lock);+spin_lock(&idrinfo->lock);/* user doesn't specify an index */if(!index){index=1;
From: Cong Wang <hidden> Date: 2018-05-23 23:15:18
On Wed, May 23, 2018 at 1:52 AM, Vlad Buslov [off-list ref] wrote:
Initial net_device implementation used ingress_lock spinlock to synchronize
ingress path of device. This lock was used in both process and bh context.
In some code paths action map lock was obtained while holding ingress_lock.
Commit e1e992e52faa ("[NET_SCHED] protect action config/dump from irqs")
modified actions to always disable bh, while using action map lock, in
order to prevent deadlock on ingress_lock in softirq. This lock was removed
in commit 555353cfa1ae ("netdev: The ingress_lock member is no longer
needed.").
Another reason to disable bh was filters delete code, that released actions
in rcu callback. This code was changed to release actions from workqueue
context in patch set "net_sched: close the race between call_rcu() and
cleanup_net()".
With these changes it is no longer necessary to continue disable bh while
accessing action map.
Replace all action idr spinlock usage with regular calls that do not
disable bh.
Looks much better now!
I _guess_ we perhaps can even get rid of this spinlock since most of
the callers hold RTNL lock, not sure about the dump() path where
RTNL might be removed recently.
Anyway,
Acked-by: Cong Wang <redacted>
On Wed 23 May 2018 at 23:14, Cong Wang [off-list ref] wrote:
On Wed, May 23, 2018 at 1:52 AM, Vlad Buslov [off-list ref] wrote:
quoted
Initial net_device implementation used ingress_lock spinlock to synchronize
ingress path of device. This lock was used in both process and bh context.
In some code paths action map lock was obtained while holding ingress_lock.
Commit e1e992e52faa ("[NET_SCHED] protect action config/dump from irqs")
modified actions to always disable bh, while using action map lock, in
order to prevent deadlock on ingress_lock in softirq. This lock was removed
in commit 555353cfa1ae ("netdev: The ingress_lock member is no longer
needed.").
Another reason to disable bh was filters delete code, that released actions
in rcu callback. This code was changed to release actions from workqueue
context in patch set "net_sched: close the race between call_rcu() and
cleanup_net()".
With these changes it is no longer necessary to continue disable bh while
accessing action map.
Replace all action idr spinlock usage with regular calls that do not
disable bh.
Looks much better now!
I _guess_ we perhaps can even get rid of this spinlock since most of
the callers hold RTNL lock, not sure about the dump() path where
RTNL might be removed recently.
Actually, this change is a result of discussion in code review of my
patch set that removes RTNL dependency from TC rules update path.