On Wed, Oct 24, 2007 at 03:21:06PM +0200, Florian Weimer wrote:I don't. Strings should never be as long as 2GB. To put this in perspective, the *entire* Encyclopaedia Britannica (all 32 volumes) is estimated at being 1GB of text. While it would be a fair criticism that I haven't put a check for overrunning 2GB in the code, the implementation relies on a single continuous buffer from kmalloc, and that's currently limited to 33554432 bytes (32MB). I don't foresee kmalloc's maximum size going up by 7 orders of magnitude -- and if it did, fragmentation would prevent you from ever getting it. So, I might consider a change to set -E2BIG instead of -ENOMEM if we pass KMALLOC_MAX_SIZE, but I do think this criticism is rather straining at gnats. Also, 'alloc' can be an errno, and that is signalled by a negative number. Yes, we could do something like if (sb->alloc > (unsigned)-4095) like the mmap code does, but given the points above, it's just not worth doing. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Linus Torvalds | Linux 2.6.27-rc5 |
| Ingo Molnar | [announce] "kill the Big Kernel Lock (BKL)" tree |
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Ben Hutchings | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH iproute2] Re: HTB accuracy for high speed |
