[prev in list] [next in list] [prev in thread] [next in thread]
List: olpc-linux-mm-cc
Subject: Re: [linux-mm-cc] [PATCH] Fix integer overflow bug (was: module
From: "John McCabe-Dansted" <gmatht () gmail ! com>
Date: 2008-04-29 7:08:30
Message-ID: fd87b6160804290008s27397cccudbec2c804e73f62b () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Apr 29, 2008 at 12:30 PM, Nitin Gupta <nitingupta910@gmail.com>
wrote:
>
> > We could probably eliminate the need for compcache.size by going direct
> from
> > _kbytes to num_pages, allowing ~4TB devices. Using only num_pages would
> > increase the max size of compcache to ~16TB and simplify the compcache
> code
> > somewhat. Unfortunately it seem hard to get at PAGE_SIZE from
> userspace.
>
> There are lot more issues with increasing size to such huge values.
> For e.g. table[] is currently a simple array
I was thinking that this should be converted to an array of void*. All extra
information could be stored in the tlsf allocated chunk. However this won't
do much good until we are able to page out to disk.
> which will eat all memory
> for such large
> compcache device sizes
Not necessarily. Current AMD processors support 256 exabytes of physical
ram, (rather than the mere 1TB of early AMD64 processors). On such machines
these sizes could be feasible.
In any case there is an integer overflow that can cause the compcache module
to become broken. I have attached a patch that will cap the compcache size
to avoid integer overflow.
--
An confusing and perhaps amusing fact:
linux-headers-2.6.24-16/include/linux/reiserfs_fs.h
contains:
#define MAX_UL_INT 0xffffffff
#define MAX_INT 0x7ffffff
#define MAX_US_INT 0xffff
I don't know why reiserfs sets MAX_INT to 0x7ffffff. Is it meant to be
portable to 28-bit architectures or what?
--
John C. McCabe-Dansted
PhD Student
University of Western Australia
[Attachment #5 (text/html)]
<br><div class="gmail_quote">On Tue, Apr 29, 2008 at 12:30 PM, Nitin Gupta <<a \
href="mailto:nitingupta910@gmail.com">nitingupta910@gmail.com</a>> \
wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, \
204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="Ih2E3d">> We \
could probably eliminate the need for compcache.size by going direct from<br> > \
_kbytes to num_pages, allowing ~4TB devices. Using only num_pages would<br> \
> increase the max size of compcache to ~16TB and simplify the compcache code<br> \
> somewhat. Unfortunately it seem hard to get at PAGE_SIZE from \
userspace.<br> <br>
</div>There are lot more issues with increasing size to such huge values.<br>
For e.g. table[] is currently a simple array</blockquote><div><br>I was thinking that \
this should be converted to an array of void*. All extra information could be stored \
in the tlsf allocated chunk. However this won't do much good until we are able to \
page out to disk.<br> </div><blockquote class="gmail_quote" style="border-left: \
1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> which \
will eat all memory<br> for such large<br>
compcache device sizes</blockquote><div><br>Not necessarily. Current AMD processors \
support 256 exabytes of physical ram, (rather than the mere 1TB of early AMD64 \
processors). On such machines these sizes could be feasible.<br></div></div><br>In \
any case there is an integer overflow that can cause the compcache module to become \
broken. I have attached a patch that will cap the compcache size to avoid integer \
overflow.<br clear="all"> <br>--<br><br>An confusing and perhaps amusing \
fact:<br>linux-headers-2.6.24-16/include/linux/reiserfs_fs.h<br>contains:<br><br>#define \
MAX_UL_INT 0xffffffff<br>#define MAX_INT 0x7ffffff<br>#define \
MAX_US_INT 0xffff<br> <br>I don't know why reiserfs sets MAX_INT to \
0x7ffffff. Is it meant to be portable to 28-bit architectures or what?<br><br>-- \
<br>John C. McCabe-Dansted<br>PhD Student<br>University of Western Australia
["fix_compcachesize_overflow.patch" (text/x-diff)]
Index: compcache.c
===================================================================
--- compcache.c (revision 95)
+++ compcache.c (working copy)
@@ -283,6 +283,12 @@
compcache_size_kbytes = ((DEFAULT_COMPCACHE_PERCENT *
i.totalram) / 100) << (PAGE_SHIFT - 10);
}
+
+ if (compcache_size_kbytes > MAX_COMPCACHE_SIZE_KBYTES) {
+ pr_info(C "Reducing compressed swap size from requested %lu KB"
+ " to maximum supported size.\n", compcache_size_kbytes);
+ compcache_size_kbytes = MAX_COMPCACHE_SIZE_KBYTES;
+ }
CC_DEBUG2("compcache_size_kbytes=%lu\n", compcache_size_kbytes);
compcache.size = compcache_size_kbytes << 10;
Index: compcache.h
===================================================================
--- compcache.h (revision 95)
+++ compcache.h (working copy)
@@ -21,6 +21,11 @@
#define SECTORS_PER_PAGE_SHIFT (PAGE_SHIFT - SECTOR_SHIFT)
#define SECTORS_PER_PAGE (1 << SECTORS_PER_PAGE_SHIFT)
+#define MAX_UL_INT ((unsigned long int)0xffffffff)
+
+#define MAX_COMPCACHE_SIZE (MAX_UL_INT-PAGE_SIZE+1)
+#define MAX_COMPCACHE_SIZE_KBYTES (K(MAX_COMPCACHE_SIZE))
+
/*-- Configurable parameters */
/* Default compcache size: 25% of total RAM */
#define DEFAULT_COMPCACHE_PERCENT 25
_______________________________________________
linux-mm-cc mailing list
linux-mm-cc@lists.laptop.org
http://lists.laptop.org/listinfo/linux-mm-cc
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic