> > > KOSAKI Motohiro wrote: > > > > > fs/binfmt_elf.c: > > > > > 77 #define BAD_ADDR(x) ((unsigned long)(x) >= TASK_SIZE) > > > > Can do_brk() return BAD_ADDR() _and_ !IS_ERR_VALUE() value? when? > > > > > > For example, arch/mips/include/asm/processor.h has below definitions > > > which is smaller than INT_MAX > > > > > > 47 #ifdef CONFIG_32BIT > > > (...snipped...) > > > 52 #define TASK_SIZE 0x7fff8000UL > > > (...snipped...) > > > 63 #endif > > > 64 > > > 65 #ifdef CONFIG_64BIT > > > (...snipped...) > > > 74 #define TASK_SIZE 0x10000000000UL > > > (...snipped...) > > > 91 #endif > > > > > > Also, several architectures define TASK_SIZE as > > > > > > #define TASK_SIZE PAGE_OFFSET > > > > > > and PAGE_OFFSET could be 0 if CONFIG_KERNEL_RAM_BASE_ADDRESS is not defined. > > > > > > include/asm-generic/page.h > > > 68 #ifdef CONFIG_KERNEL_RAM_BASE_ADDRESS > > > 69 #define PAGE_OFFSET (CONFIG_KERNEL_RAM_BASE_ADDRESS) > > > 70 #else > > > 71 #define PAGE_OFFSET (0) > > > 72 #endif > > > > > > If TASK_SIZE == 0, BAD_ADDR(x) is always true and !IS_ERR_VALUE(x) can be true. > > > Although I don't know which combination makes such environment, > > > I think "BAD_ADDR() _and_ !IS_ERR_VALUE()" can happen. > > > > I think you should read do_brk() itself. the spec is > > > > success case: > > return addr argument > > > > error case: > > return error code > > > > When does it return invalid address? > > Does this makes a bit cleanups? > > > > From 5f5556d30ac1876ec2211a2eae77e8372183a9b1 Mon Sep 17 00:00:00 2001 > From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx> > Date: Fri, 15 Oct 2010 05:13:40 +0900 > Subject: [cleanup][PATCH] elf: kill BAD_ADDR() macro > > BAD_ADDR() macro is useless because 1) do_brk() and do_mmap() return > only either valid pointer or error code 2) when kernel and userland have > perfectly different address space (such as old 4G:4G separation), to > compare TASK_SIZE has no good meaning. > > Then, this patch change it to use IS_ERR_VALUE instead (as other a lot > of places). > But, this is theorical issue. this patch doesn't have functional change. Ouch, this patch is completely corrupted. please ignore it. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
