[PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000
default value of vmalloc_min was set 0xf000 for ARM by commit
0536bdf3. But actually vmalloc_min is 0xef80 not 0xf000.
VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
0xff00 - 0x0f00 - 0x0080 = 0xef80
In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
allocated. Kernel log also print out warning message as below.
"Truncating RAM at 8000-afff to -af7f (vmalloc region overlap)."
Although it could be solved by state "vmalloc=size" in cmdline but i think
it would be better to change default value to 232 from 240.
Signed-off-by: Yongtaek Lee
---
arch/arm/mm/mmu.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8348ed6..9a1bab4 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1040,12 +1040,12 @@ void __init debug_ll_io_init(void)
#endif
static void * __initdata vmalloc_min =
- (void *)(VMALLOC_END - (240 << 20) - VMALLOC_OFFSET);
+ (void *)(VMALLOC_END - (232 << 20) - VMALLOC_OFFSET);
/*
* vmalloc=size forces the vmalloc area to be exactly 'size'
* bytes. This can be used to increase (or decrease) the vmalloc
- * area - the default is 240m.
+ * area - the default is 232m.
*/
static int __init early_vmalloc(char *arg)
{
--
1.7.9
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: fix bug which lowmem size is limited to 760MB
default value of VMALLOC_START was set 0xf000 for ARM by commit
0536bdf3. It leads lowmem end address 0xef80 not 0xf000.
VMALLOC_END - (240 << 20) - VMALLOC_OFFSET)
0xff00 - 0x0f00 - 0x0080 = 0xef80
In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be
allocated. Kernel log also print out warning message as below.
"Truncating RAM at 8000-afff to -af7f (vmalloc region overlap)."
Although it could be solved by state "vmalloc=size" in cmdline but i think
it would be better to change default value to 232 from 240.
Signed-off-by: Yongtaek Lee
---
arch/arm/mm/mmu.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 8348ed6..9a1bab4 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1040,12 +1040,12 @@ void __init debug_ll_io_init(void)
#endif
static void * __initdata vmalloc_min =
- (void *)(VMALLOC_END - (240 << 20) - VMALLOC_OFFSET);
+ (void *)(VMALLOC_END - (232 << 20) - VMALLOC_OFFSET);
/*
* vmalloc=size forces the vmalloc area to be exactly 'size'
* bytes. This can be used to increase (or decrease) the vmalloc
- * area - the default is 240m.
+ * area - the default is 232m.
*/
static int __init early_vmalloc(char *arg)
{
--
1.7.9
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000
> On Thu, Sep 03, 2015 at 11:24:47AM +0900, Yongtaek Lee wrote: > > default value of vmalloc_min was set 0xf000 for ARM by commit > > 0536bdf3. But actually vmalloc_min is 0xef80 not 0xf000. > > > > VMALLOC_END - (240 << 20) - VMALLOC_OFFSET) > > 0xff00 - 0x0f00 - 0x0080 = 0xef80 > > > > In case of 768MB ram without CONFIG_HIGHMEM=y, last 8MB could not be > > allocated. Kernel log also print out warning message as below. > > "Truncating RAM at 8000-afff to -af7f (vmalloc region overlap)." > > > > Although it could be solved by state "vmalloc=size" in cmdline but i think > > it would be better to change default value to 232 from 240. > > > > Signed-off-by: Yongtaek Lee > > I fail to see what the problem is here. You're adjusting the size of the > vmalloc space to accomodate the size of RAM you have. That's not a bug. I will explain more about problem. It could happened with 768MB RAM device and CONFIG_HIGHMEN is not set. "vmalloc=size" also not stated so that default value of vmalloc_min will be used to calculate lowmem end address. before applying patch. [0.00] [0:swapper:0] [c0] Truncating RAM at 8000-afff to -af7f (vmalloc region overlap). [0.00] [0:swapper:0] [c0] Memory: 106MB 652MB = 758MB total [0.00] [0:swapper:0] [c0] Memory: 669892k/669892k available, 108348k reserved, 0K highmem [0.00] [0:swapper:0] [c0] Virtual kernel memory layout: [0.00] [0:swapper:0] vector : 0x - 0x1000 ( 4 kB) [0.00] [0:swapper:0] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] [0:swapper:0] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] [0:swapper:0] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] [0:swapper:0] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] [0:swapper:0] .text : 0xc0008000 - 0xc09bbee0 (9936 kB) [0.00] [0:swapper:0] .init : 0xc09bc000 - 0xc0a2b740 ( 446 kB) [0.00] [0:swapper:0] .data : 0xc0a2c000 - 0xc0ac4088 ( 609 kB) [0.00] [0:swapper:0].bss : 0xc0ac4088 - 0xc0d3e7b4 (2538 kB) after applying patch. [0.00] [0:swapper:0] [c0] Memory: 106MB 660MB = 766MB total [0.00] [0:swapper:0] [c0] Memory: 678004k/678004k available, 108428k reserved, 0K highmem [0.00] [0:swapper:0] [c0] Virtual kernel memory layout: [0.00] [0:swapper:0] vector : 0x - 0x1000 ( 4 kB) [0.00] [0:swapper:0] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] [0:swapper:0] vmalloc : 0xf080 - 0xff00 ( 232 MB) [0.00] [0:swapper:0] lowmem : 0xc000 - 0xf000 ( 768 MB) [0.00] [0:swapper:0] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] [0:swapper:0] .text : 0xc0008000 - 0xc09bbee0 (9936 kB) [0.00] [0:swapper:0] .init : 0xc09bc000 - 0xc0a2b740 ( 446 kB) [0.00] [0:swapper:0] .data : 0xc0a2c000 - 0xc0ac4088 ( 609 kB) [0.00] [0:swapper:0].bss : 0xc0ac4088 - 0xc0d3e7b4 (2538 kB) As i know "vmalloc=size" is not mandatory so that i think default value of vmalloc_min is wrong. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: [PATCH] ARM: fix bug which VMALLOC_START is lowwer than 0xf0000000
> So, if we go and apply your logic to a 1GB system we should resize the > vmalloc area to 0 bytes in order to avoid RAM truncation without > CONFIG_HIGHMEM? As you already know, CONFIG_HIGHMEM option is necessary if RAM is more than 1GB. So no need to resize vmalloc area to 0. > Sorry, but the only sane options here are to either live with the > truncation, enable CONFIG_HIGHMEM, or set vmalloc size manually. > Changing a default value that affects everyone for the benefit of your > specific use-case isn't a sane option. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: fix bug which lowmem size is limited to 760MB
> Wrong, there is no such "rule". > If we apply that rule, then if you have 1GB of RAM, it will fill from > 0xc000 to 0x inclusive. There will be _zero_ bytes of > vmalloc space. There will be _zero_ bytes of IO mappings. There won't > even be a vectors page, so the kernel _will_ crash on the first exception. > The "rule" you think exists doesn't because it is wrong. I am sorry disturb you again. I am confusing after reading your comment. So i summarize my opinion again. Current status. 768MB, no CONFIG_HIGHMEM and no vmalloc=size lowmem : 0MB ~ 760MB vmalloc : 768MB ~ VMALLOC_END => waste 8MB because 760MB ~ 768MB is hole 1GB, no CONFIG_HIGHMEM and no vmalloc=size lowmem : 0MB ~ 760MB vmalloc : 768MB ~ VMALLOC_END => waste 264MB, so we need to enable CONFIG_HIGHMEM to use full memory. highmem : 264MB if enable CONFIG_HIGHMEM after applying patch. 768MB, no CONFIG_HIGHMEM and no vmalloc=size lowmem : 0MB ~ 768MB vmalloc : 776MB ~ VMALLOC_END => use 768MB fully 1GB, no CONFIG_HIGHMEM and no vmalloc=size lowmem : 0MB ~ 768MB vmalloc : 776MB ~ VMALLOC_END => waste 256MB, so we need to enable CONFIG_HIGHMEM to use full memory. highmem : 256MB if enable CONFIG_HIGHMEM => it will not fill from 0xc000 to 0x My opinion is not that vmalloc area size should be changed for all cases(512M, 768M, 1GB, 2GB, etc.). If we change default value from 240MB to 232MB, it could covor all cases without any other changes so that i have suggested this patch. As we already talked there are 3 cases with 768MB 1. live with the truncation => waste 8MB so that it will not be acceptable. 2. enable CONFIG_HIGHMEM => mm point of view it could make overhead because there is only 8MB(very small) in highmem. 3. set vmalloc size manually => I already mentioned it could fix issue but if default value is suitable then it is needless. Anyway please think again which size is more efficient for all cases. If you still think this patch is not acceptable i will accept your decision. Thank you for your comment. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: evdev - Fix incorrect kfree of err_free_client after vzalloc
This bug was introduced by commit 92eb77d ("Input: evdev - fall back
to vmalloc for client event buffer").
vzalloc is used to alloc memory as fallback in case of failure
of kzalloc. But err_free_client was not considered on below case.
1. kzalloc fail
2. vzalloc success
3. evdev_open_device fail
4. kfree
So that address checking is needed to call correct free function.
Signed-off-by: Yongtaek Lee
Reviewed-by: Daniel Stone
Reviewed-by: David Herrmann
Acked-by: David Rientjes
---
drivers/input/evdev.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index ce953d8..f60daa0 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -422,7 +422,10 @@ static int evdev_open(struct inode *inode, struct file
*file)
err_free_client:
evdev_detach_client(evdev, client);
- kfree(client);
+ if (is_vmalloc_addr(client))
+ vfree(client);
+ else
+ kfree(client);
return error;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: evdev - Fix incorrect kfree of err_free_client after vzalloc
This bug was introduced by commit 92eb77d ("Input: evdev - fall back
to vmalloc for client event buffer").
vzalloc is used to alloc memory as fallback in case of failure
of kzalloc. But err_free_client was not considered on below case.
1. kzalloc fail
2. vzalloc success
3. evdev_open_device fail
4. kfree
So that address checking is needed to call correct free function.
Signed-off-by: Yongtaek Lee
Reviewed-by: Daniel Stone
---
drivers/input/evdev.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index ce953d8..f60daa0 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -422,7 +422,10 @@ static int evdev_open(struct inode *inode, struct file
*file)
err_free_client:
evdev_detach_client(evdev, client);
- kfree(client);
+ if (is_vmalloc_addr(client))
+ vfree(client);
+ else
+ kfree(client);
return error;
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
