[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200805061840.37713.netdev@axxeo.de>
Date: Tue, 6 May 2008 18:40:37 +0200
From: Ingo Oeser <netdev@...eo.de>
To: Pavel Emelyanov <xemul@...nvz.org>
Cc: Johannes Berg <johannes@...solutions.net>,
"John W. Linville" <linville@...driver.com>,
David Miller <davem@...emloft.net>,
linux-wireless@...r.kernel.org,
Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/4][MAC80211]: Fix GFP_KERNEL allocation under read lock.
Hi Pavel,
regarding:
[PATCH 1/4][MAC80211]: Fix GFP_KERNEL allocation under read lock
[PATCH 2/4][MAC80211]: Fix not checked kmalloc() result
Pavel Emelyanov schrieb:
> The mesh_path_add() read-locks the pathtbl_resize_lock and calls
> kmalloc with GFP_KERNEL mask.
>
> Fix it and move the endadd2 label lower. It should be _before_ the
> if() beyond, but it makes no sense for it being there, so I move it
> right after this if().
What about doing both allocations in succession to local variables,
share the failure path if an error occours an kfree them unconditionally
like this?
new_node = kmalloc(sizeof(struct mpath_node), GFP_KERNEL);
new_mpath = kzalloc(sizeof(struct mesh_path), GFP_KERNEL);
if (!new_node || !new_mpath) {
kfree(new_mpath);
kfree(new_node);
atomic_dec(&sdata->u.sta.mpaths);
err = -ENOMEM;
goto endadd2;
}
...
read_lock(...);
...
Rationale: Allocations are always likely to fail/succeed in close succession.
Best Regards
Ingo Oeser
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists