[PATCH 1/7][MAC8021]: Fix one more call to synchronize_rcu in atomic context.

[PATCH 1/7][MAC8021]: Fix one more call to synchronize_rcu in atomic context.

[Pavel Emelyanov]

(This set applies OK without the previous one of 4 patches,
 but with some fuzz in the 7th one)


The mesh_path_node_free() does so under hashwlock.

But, this one is called
1. from mesh_path_add() after an old hash is hidden and
   synchronize_rcu() is calld
2. mesh_pathtbl_unregister(), when the module is being
   unloaded and no devices exist to mess with this hash.

So, it seems to me, that simply removing the call is OK.

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>

---
 net/mac80211/mesh_pathtbl.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index 7097ef9..0b6c4bf 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -458,7 +458,6 @@ static void mesh_path_node_free(struct hlist_node *p, bool free_leafs)
 	struct mpath_node *node = hlist_entry(p, struct mpath_node, list);
 	mpath = node->mpath;
 	hlist_del_rcu(p);
-	synchronize_rcu();
 	if (free_leafs)
 		kfree(mpath);
 	kfree(node);
-- 
1.5.3.4

Re: [PATCH 1/7][MAC8021]: Fix one more call to synchronize_rcu in atomic context.

[Pavel Emelyanov]

Hi, John. 

Sorry for bothering you, I guess that you're very busy now, 
but what are you plans about this set?

After I saw my first set included in some wireless git update,
I thought this one would be in some of the next ones (since
this set fixes some bugs in mesh tables), and started waiting.

Here's a new wireless git update and this set is still not in.
Shall I resubmit one?

Thanks,
Pavel

> (This set applies OK without the previous one of 4 patches,
>  but with some fuzz in the 7th one)
> 
> 
> The mesh_path_node_free() does so under hashwlock.
> 
> But, this one is called
> 1. from mesh_path_add() after an old hash is hidden and
>    synchronize_rcu() is calld
> 2. mesh_pathtbl_unregister(), when the module is being
>    unloaded and no devices exist to mess with this hash.
> 
> So, it seems to me, that simply removing the call is OK.
> 
> Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
> 
> ---
>  net/mac80211/mesh_pathtbl.c |    1 -
>  1 files changed, 0 insertions(+), 1 deletions(-)
> 
> diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
> index 7097ef9..0b6c4bf 100644
> --- a/net/mac80211/mesh_pathtbl.c
> +++ b/net/mac80211/mesh_pathtbl.c
> @@ -458,7 +458,6 @@ static void mesh_path_node_free(struct hlist_node *p, bool free_leafs)
>  	struct mpath_node *node = hlist_entry(p, struct mpath_node, list);
>  	mpath = node->mpath;
>  	hlist_del_rcu(p);
> -	synchronize_rcu();
>  	if (free_leafs)
>  		kfree(mpath);
>  	kfree(node);

Re: [PATCH 1/7][MAC8021]: Fix one more call to synchronize_rcu in atomic context.

[John W. Linville]

On Fri, May 16, 2008 at 03:05:36PM +0400, Pavel Emelyanov wrote:

> Sorry for bothering you, I guess that you're very busy now, 
> but what are you plans about this set?
> 
> After I saw my first set included in some wireless git update,
> I thought this one would be in some of the next ones (since
> this set fixes some bugs in mesh tables), and started waiting.
> 
> Here's a new wireless git update and this set is still not in.
> Shall I resubmit one?

Pavel,

I still have your patchset.  I'm still working on clearing my
backlog, as well as waiting for some fixes to make the round-trip
net-2.6->linux-2.6->net-next-2.6.  The combination of that and the
fact that your patch hit locking and "the usual suspects" had not
yet commented on it made me decide to wait until the next round.

If you are desperate to see them sooner, I could probably put them
in the -testing tree early?  Let me know if you would like that.

John
-- 
John W. Linville
linville@tuxdriver.com

Re: [PATCH 1/7][MAC8021]: Fix one more call to synchronize_rcu in atomic context.

[Pavel Emelyanov]

John W. Linville wrote:
> On Fri, May 16, 2008 at 03:05:36PM +0400, Pavel Emelyanov wrote:
> 
>> Sorry for bothering you, I guess that you're very busy now, 
>> but what are you plans about this set?
>>
>> After I saw my first set included in some wireless git update,
>> I thought this one would be in some of the next ones (since
>> this set fixes some bugs in mesh tables), and started waiting.
>>
>> Here's a new wireless git update and this set is still not in.
>> Shall I resubmit one?
> 
> Pavel,
> 
> I still have your patchset.  I'm still working on clearing my
> backlog, as well as waiting for some fixes to make the round-trip
> net-2.6->linux-2.6->net-next-2.6.  The combination of that and the
> fact that your patch hit locking and "the usual suspects" had not
> yet commented on it made me decide to wait until the next round.
> 
> If you are desperate to see them sooner, I could probably put them
> in the -testing tree early?  Let me know if you would like that.

No, this is not critical for me. You may keep this set in any
place in your queue. I just wanted to make sure, that this set
didn't get accidentally lost and no additional help from me is
required (at least for now).

> John

Thanks,
Pavel