From: Ingo Oeser <netdev@axxeo•de>
To: Pavel Emelyanov <xemul@openvz•org>
Cc: Johannes Berg <johannes@sipsolutions•net>,
"John W. Linville" <linville@tuxdriver•com>,
David Miller <davem@davemloft•net>,
linux-wireless@vger•kernel.org,
Linux Netdev List <netdev@vger•kernel.org>
Subject: Re: [PATCH 1/4][MAC80211]: Fix GFP_KERNEL allocation under read lock.
Date: Tue, 6 May 2008 18:40:37 +0200 [thread overview]
Message-ID: <200805061840.37713.netdev@axxeo.de> (raw)
In-Reply-To: <48206F4C.5050105@openvz.org>
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
next prev parent reply other threads:[~2008-05-06 16:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-06 14:46 [PATCH 1/4][MAC80211]: Fix GFP_KERNEL allocation under read lock Pavel Emelyanov
2008-05-06 16:40 ` Ingo Oeser [this message]
2008-05-06 17:46 ` Pavel Emelyanov
[not found] ` <4820997E.1070305-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-05-06 20:40 ` David Miller
2008-05-07 5:54 ` Pavel Emelyanov
2008-05-07 5:59 ` David Miller
2008-05-08 18:51 ` John W. Linville
[not found] ` <20080508185123.GA7250-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
2008-05-08 18:53 ` John W. Linville
[not found] ` <200805061840.37713.netdev-BkyiQQGWkgE@public.gmane.org>
2008-05-06 21:12 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200805061840.37713.netdev@axxeo.de \
--to=netdev@axxeo$(echo .)de \
--cc=davem@davemloft$(echo .)net \
--cc=johannes@sipsolutions$(echo .)net \
--cc=linux-wireless@vger$(echo .)kernel.org \
--cc=linville@tuxdriver$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=xemul@openvz$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox