[Openswan dev] saref subtable allocate
Michael Richardson
mcr at sandelman.ca
Wed Jun 30 09:21:56 EDT 2010
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>>>>> "Bart" == Bart Trojanowski <bart at vault.xelerance.com> writes:
Bart> convert allocation of saref subtables to
Bart> kmalloc/GFP_ATOMIC
Bart> previously we used vmalloc() which resulted in a call to
Bart> vmalloc() under spin_lock_bh() after 16k sarefs have been
Bart> given out. vmalloc() calls BUG() when called with preemption
Bart> disabled -- which is bad.
Correct me if I'm wrong, but this means that we are allocating
contiguous physical memory, correct? We really do not need it... kernel
virtual memory is just fine.
Is there another way? AFAIK, we only ever allocate when we create an
SA, which only ever do on the PFKEY path.
Why do we have to do that under spin_lock_bh()? I can see that
accessing some structures requires that we lock against the forwarding
path, but once we know that we have to allocate a new subtable, I'd
think we could release those things, do the allocation of the subtable,
and then spin_lock_bh() again.
- --
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr at sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Finger me for keys
iQEVAwUBTCtE8oCLcPvd0N1lAQLKIwf9G8RpGPvAfzAr8Aw0LEqK8N2nLYeHYBsM
PP3DbLIBKsGZzGnGwFKqIA+00fq4G5cgOCsJoW6Q+vWkYaIVPcChgNk8W/URxLo7
2mnaXBeNbUuwqTeO2wh+VV/vc9gQwb34VuTDEUG9JYtDRVcIaSWEhuy8wnG8S3IP
oKD0b/rfJfUVthGBhsmf0UigxtljrFKCEGzpOGudl8vch/r368RM1Qmn/vJQ50je
LL4dD/kW60XBVvZx4QHd+uGd0e/njYqTCwXkVzYQD5WSSGtqpyMk1l+aQsDfcJwN
/eEkGlkjppT8e2R1JF/77wizh+p3LuZGIPXxwZn7svg0jHEt4g6Xmg==
=aRh+
-----END PGP SIGNATURE-----
More information about the Dev
mailing list