headers
Berkhan, Enrik (GE Infra, Oil & Gas | 1 Jul 2009 10:29
Picon
Favicon

Re: corebld (dma_memcpy() variant) does not work with CONFIG_ACCESS_CHECK

Mike Frysinger wrote:
> does the 2009R1 branch itself not work ?  i can commit a different
> (simpler) fix if that is not the case.

No, the 2009R1 branch does not work with a dma_memcpy() based corebld. 
I have just re-checked it without my patches. All Core B L1 regions
are denied by access_ok. Would be nice to have that fixed, too.

Meanwhile, I had a chance to check the -trunk kernel and found it to be 
working besides one bug: the call of in_mem_const_off() from in_mem_const() 
in arch/blackfin/kernel/process.c seems to have args 2 and 3 (size, offset) 
swapped. After fixing that, -trunk works fine for my use case.

Enrik
--

-- 
Enrik Berkhan
Electronics Design Engineer
GE Oil & Gas
PII Pipeline Solutions

T +49 7244 732 476
F +49 7244 732 304
E enrik.berkhan <at> ge.com

PII Pipetronix GmbH, Lorenzstraße 10, 76297 Stutensee, Deutschland
Geschäftsführer: David Allen, Werner van Wickeren
Sitz der Gesellschaft: Stutensee
Amtsgericht Mannheim HRB 702297
USt-ID: DE 244323981, Steuer-Nr.: 5930/0173
Deutsche Bank Karlsruhe, BLZ 660 700 04, Kto: 1 435 700 00
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mike Frysinger | 1 Jul 2009 14:02
Favicon

Blackfin kernel building

Summary:

   Building svn-trunk (32e202ab)
### BF518F-EZBRD_defconfig: OK
### BF526-EZBRD_defconfig: OK
### BF527-EZKIT_defconfig: OK
### BF533-EZKIT_defconfig
###### BF531: FAIL
###### BF532: FAIL
###### BF533: FAIL
### BF533-STAMP_defconfig
###### BF531: FAIL
###### BF532: FAIL
###### BF533: FAIL
### BF537-STAMP_defconfig: OK
### BF538-EZKIT_defconfig
###### BF538: FAIL
###### BF539: FAIL
### BF548-EZKIT_defconfig
###### BF542: FAIL
###### BF544: FAIL
###### BF547: FAIL
###### BF549: FAIL
###### BF548: FAIL
### BF561-EZKIT_defconfig
###### BF561: FAIL
### BlackStamp_defconfig
###### BF531: FAIL
###### BF532: FAIL
###### BF533: FAIL
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Howells | 1 Jul 2009 14:08
Picon
Favicon

[PATCH] FDPIC: Ignore the loader's PT_GNU_STACK when calculating the stack size

Ignore the loader's PT_GNU_STACK when calculating the stack size, and only
consider the executable's PT_GNU_STACK, assuming the executable has one.

Currently the behaviour is to take the largest stack size and use that, but
that means you can't reduce the stack size in the executable.  The loader's
stack size should probably only be used when executing the loader directly.

WARNING: This patch is slightly dangerous - it may render a system inoperable
if the loader's stack size is larger than that of important executables, and
the system relies unknowingly on this increasing the size of the stack.

Signed-off-by: David Howells <dhowells <at> redhat.com>
---

 fs/binfmt_elf_fdpic.c |   19 +++++++++++--------
 1 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 81ca047..58c49fa 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
 <at>  <at>  -283,20 +283,23  <at>  <at>  static int load_elf_fdpic_binary(struct linux_binprm *bprm,
 	}

 	stack_size = exec_params.stack_size;
-	if (stack_size < interp_params.stack_size)
-		stack_size = interp_params.stack_size;
-
 	if (exec_params.flags & ELF_FDPIC_FLAG_EXEC_STACK)
 		executable_stack = EXSTACK_ENABLE_X;
(Continue reading)

Permalink | Reply | 30 comments |
headers
Mike Frysinger | 1 Jul 2009 17:04
Picon

Re: corebld (dma_memcpy() variant) does not work with CONFIG_ACCESS_CHECK

On Wed, Jul 1, 2009 at 04:29, Berkhan, Enrik wrote:
> Mike Frysinger wrote:
>> does the 2009R1 branch itself not work ?  i can commit a different
>> (simpler) fix if that is not the case.
>
> No, the 2009R1 branch does not work with a dma_memcpy() based corebld.
> I have just re-checked it without my patches. All Core B L1 regions
> are denied by access_ok. Would be nice to have that fixed, too.

should be fixed now

> Meanwhile, I had a chance to check the -trunk kernel and found it to be
> working besides one bug: the call of in_mem_const_off() from in_mem_const()
> in arch/blackfin/kernel/process.c seems to have args 2 and 3 (size, offset)
> swapped. After fixing that, -trunk works fine for my use case.

thanks, ive added that fix
-mike

_______________________________________________
Uclinux-dist-devel mailing list
Uclinux-dist-devel <at> blackfin.uclinux.org
https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
Permalink | Reply | 1 comment |
headers
Mike Frysinger | 1 Jul 2009 18:02
Picon

Re: [PATCH] FDPIC: Ignore the loader's PT_GNU_STACK when calculating the stack size

On Wed, Jul 1, 2009 at 08:08, David Howells wrote:
> WARNING: This patch is slightly dangerous - it may render a system inoperable
> if the loader's stack size is larger than that of important executables, and
> the system relies unknowingly on this increasing the size of the stack.

every toolchain ive seen sets the stack size in the linker to the
default value, and the only way to change that is to manually set the
size yourself with the relevant command line option.  so it's only
going to break people who have been doing it wrong themselves --
setting the stack size to a smaller option than is acceptable.

> -       else
> +       else

this change just adds trailing whitespace ...

otherwise, just tested it and it works for me, thanks
Signed-off-by: Mike Frysinger <vapier <at> gentoo.org>
-mike
Permalink | Reply | 0 comments |
headers
David Howells | 1 Jul 2009 18:48
Picon
Favicon

[PATCH] FDPIC: Ignore the loader's PT_GNU_STACK when calculating the stack size [ver #2]

Ignore the loader's PT_GNU_STACK when calculating the stack size, and only
consider the executable's PT_GNU_STACK, assuming the executable has one.

Currently the behaviour is to take the largest stack size and use that, but
that means you can't reduce the stack size in the executable.  The loader's
stack size should probably only be used when executing the loader directly.

WARNING: This patch is slightly dangerous - it may render a system inoperable
if the loader's stack size is larger than that of important executables, and
the system relies unknowingly on this increasing the size of the stack.

Signed-off-by: David Howells <dhowells <at> redhat.com>
---

 fs/binfmt_elf_fdpic.c |   17 ++++++++++-------
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 81ca047..a1e6365 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
 <at>  <at>  -283,20 +283,23  <at>  <at>  static int load_elf_fdpic_binary(struct linux_binprm *bprm,
 	}

 	stack_size = exec_params.stack_size;
-	if (stack_size < interp_params.stack_size)
-		stack_size = interp_params.stack_size;
-
 	if (exec_params.flags & ELF_FDPIC_FLAG_EXEC_STACK)
 		executable_stack = EXSTACK_ENABLE_X;
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Howells | 1 Jul 2009 18:49
Picon
Favicon

Re: [PATCH] FDPIC: Ignore the loader's PT_GNU_STACK when calculating the stack size

Mike Frysinger <vapier.adi <at> gmail.com> wrote:

> this change just adds trailing whitespace ...

Fixed.

> Signed-off-by: Mike Frysinger <vapier <at> gentoo.org>

Oops.  Should've added that.

David
Permalink | Reply | 0 comments |
headers
David Howells | 1 Jul 2009 18:49
Picon
Favicon

[PATCH] FDPIC: Ignore the loader's PT_GNU_STACK when calculating the stack size [ver #2]

Ignore the loader's PT_GNU_STACK when calculating the stack size, and only
consider the executable's PT_GNU_STACK, assuming the executable has one.

Currently the behaviour is to take the largest stack size and use that, but
that means you can't reduce the stack size in the executable.  The loader's
stack size should probably only be used when executing the loader directly.

WARNING: This patch is slightly dangerous - it may render a system inoperable
if the loader's stack size is larger than that of important executables, and
the system relies unknowingly on this increasing the size of the stack.

Signed-off-by: David Howells <dhowells <at> redhat.com>
Signed-off-by: Mike Frysinger <vapier <at> gentoo.org>
---

 fs/binfmt_elf_fdpic.c |   17 ++++++++++-------
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index 81ca047..a1e6365 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
 <at>  <at>  -283,20 +283,23  <at>  <at>  static int load_elf_fdpic_binary(struct linux_binprm *bprm,
 	}

 	stack_size = exec_params.stack_size;
-	if (stack_size < interp_params.stack_size)
-		stack_size = interp_params.stack_size;
-
 	if (exec_params.flags & ELF_FDPIC_FLAG_EXEC_STACK)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Frysinger | 1 Jul 2009 20:26
Picon
Favicon
Gravatar

[PATCH] FLAT: use IS_ERR_VALUE() helper macro

There is a common macro now for testing mixed pointer/errno values, so use
that rather than handling the casts ourself.

Signed-off-by: Mike Frysinger <vapier <at> gentoo.org>
---
 fs/binfmt_flat.c |   22 ++++++++++------------
 1 files changed, 10 insertions(+), 12 deletions(-)

diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
index 697f6b5..f22b312 100644
--- a/fs/binfmt_flat.c
+++ b/fs/binfmt_flat.c
 <at>  <at>  -278,8 +278,6  <at>  <at>  static int decompress_exec(
 		ret = bprm->file->f_op->read(bprm->file, buf, LBUFSIZE, &fpos);
 		if (ret <= 0)
 			break;
-		if (ret >= (unsigned long) -4096)
-			break;
 		len -= ret;

 		strm.next_in = buf;
 <at>  <at>  -335,7 +333,7  <at>  <at>  calc_reloc(unsigned long r, struct lib_info *p, int curid, int internalp)
 					"(%d != %d)", (unsigned) r, curid, id);
 			goto failed;
 		} else if ( ! p->lib_list[id].loaded &&
-				load_flat_shared_library(id, p) > (unsigned long) -4096) {
+				IS_ERR_VALUE(load_flat_shared_library(id, p))) {
 			printk("BINFMT_FLAT: failed to load library %d", id);
 			goto failed;
 		}
(Continue reading)

Permalink | Reply | 8 comments |
headers
David McCullough | 2 Jul 2009 01:54

Re: [PATCH] FLAT: use IS_ERR_VALUE() helper macro


Jivin Mike Frysinger lays it down ...
> There is a common macro now for testing mixed pointer/errno values, so use
> that rather than handling the casts ourself.
> 
> Signed-off-by: Mike Frysinger <vapier <at> gentoo.org>

Acked-by: David McCullough <david_mccullough <at> securecomputing.com>

Cheers,
Davidm

> ---
>  fs/binfmt_flat.c |   22 ++++++++++------------
>  1 files changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/fs/binfmt_flat.c b/fs/binfmt_flat.c
> index 697f6b5..f22b312 100644
> --- a/fs/binfmt_flat.c
> +++ b/fs/binfmt_flat.c
>  <at>  <at>  -278,8 +278,6  <at>  <at>  static int decompress_exec(
>  		ret = bprm->file->f_op->read(bprm->file, buf, LBUFSIZE, &fpos);
>  		if (ret <= 0)
>  			break;
> -		if (ret >= (unsigned long) -4096)
> -			break;
>  		len -= ret;
>  
>  		strm.next_in = buf;
>  <at>  <at>  -335,7 +333,7  <at>  <at>  calc_reloc(unsigned long r, struct lib_info *p, int curid, int internalp)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane