From: Linus Torvalds <torvalds@linux-foundation.org> Date: Thu, 24 Jul 2008 14:13:42 -0700 (PDT)Actually in the old code this precondition didn't hold, which explains how it is. The old code looked like: if (newlen >= ksize(ct->ext)) { new = kmalloc(newlen, gfp); if (!new) return NULL; ... ct->ext = new; } ct->ext->offset[id] = newoff; ct->ext->len = newlen; memset((void *)ct->ext + newoff, 0, newlen - newoff); return (void *)ct->ext + newoff; and in that context 'new' is only assigned in the "newlen >=" guarded code block. Anyways, it does seem that we should indeed only update the new larger length only after we've initialized the contents. Note that we could make krealloc() and friends clear out the trailing bits of the new buffer, and therefore the caller wouldn't even need to be mindful of such things. I don't know if that's desirable in general, probably it isn't. --
| David Miller | Re: [GIT]: Networking |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| Arjan van de Ven | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Paul E. McKenney | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
