Hi,
We can get rid of a memset in
arch/powerpc/platforms/cell/spufs/lscsa_alloc.c::spu_alloc_lscsa_std() by
using vzalloc() rather than vmalloc()+memset().
Completely untested patch below since I have no hardware nor tools to
compile this.
Signed-off-by: Jesper Juhl
---
lscsa_alloc.c |
Hi,
If memory is tight and a dynamic allocation fails there's no reason to
make a bad situation worse by leaking memory.
mf_getSrcHistory potentially leaks pages[0-3]. I believe the right thing
to do is to free that memory again before returning -ENOMEM - which is
what this patch does.
I real
Hi,
I have a G4 that has 1.25 G of ram. Under Linux I only get 768M?
Anyone know why? It is a GiGE with a dual 7455 PowerLogix cpu upgrade.
Kernel is 2.6.28.
Thanks!
kevin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs
On Saturday 30 October 2010, Jesper Juhl wrote:
> We can get rid of a memset in
> arch/powerpc/platforms/cell/spufs/lscsa_alloc.c::spu_alloc_lscsa_std() by
> using vzalloc() rather than vmalloc()+memset().
>
> Completely untested patch below since I have no hardware nor tools to
> compile this.
Jesper,
> We can get rid of a memset in
> arch/powerpc/platforms/cell/spufs/lscsa_alloc.c::spu_alloc_lscsa_std() by
> using vzalloc() rather than vmalloc()+memset().
Looks good to me.
Acked-By: Jeremy Kerr
Ben, could you apply this to the powerpc tree?
Cheers,
Jeremy
___
Coalesce long formats.
Align arguments.
Add missing newlines.
Signed-off-by: Joe Perches
---
arch/powerpc/kernel/hw_breakpoint.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/hw_breakpoint.c
b/arch/powerpc/kernel/hw_breakpoint.c
index 5ecd040..d
WARN uses sometimes use KERN_ but mostly don't
have any prefix.
Change the WARN macros and the warn_slowpath function to preface
KERN_WARNING and remove all the KERN_ uses from WARN sites.
Neatening clean up of include/asm-generic/bug.h
Update WARN macros
Add KERN_WARNING to WARN output
Remove a
On Sat, 2010-10-30 at 13:52 +0200, LEROY christophe wrote:
> Hello,
>
> When I build a kernel with DEBUG_LOCK_ALLOC set, I get a kernel which
> has __bss_stop above the C080 limit, and then I get a bad page
> exception during the zeroize of the __bss at startup, because the
> initial MMU on
On 30.10.2010, at 11:55, Vasiliy Kulikov wrote:
> Structure kvm_ppc_pvinfo is copied to userland with "flags" and "pad"
> fields unitialized. It leads to leaking of contents of kernel stack
> memory. We have to initialize them to zero.
>
> In patch v1 Jan Kiszka suggested to fill reserved fiel
Structure kvm_ppc_pvinfo is copied to userland with "flags" and "pad"
fields unitialized. It leads to leaking of contents of kernel stack
memory. We have to initialize them to zero.
In patch v1 Jan Kiszka suggested to fill reserved fields with zeros
instead of memset'ting the whole struct. It m
Hello,
When I build a kernel with DEBUG_LOCK_ALLOC set, I get a kernel which
has __bss_stop above the C080 limit, and then I get a bad page
exception during the zeroize of the __bss at startup, because the
initial MMU only maps the first 8Mbytes.
What can I do to fix that ?
Regards
C. L
Structure kvm_ppc_pvinfo is copied to userland with flags and
pad fields unitialized. It leads to leaking of contents of
kernel stack memory.
Signed-off-by: Vasiliy Kulikov
---
I cannot compile this driver, so it is not tested at all.
arch/powerpc/kvm/powerpc.c |1 +
1 files changed, 1 in
12 matches
Mail list logo