A gentle reminder.
Any comments are appreciated.
Regards,
Sandeep
> -Original Message-
> From: Singh Sandeep-B37400
> Sent: Wednesday, January 02, 2013 6:55 PM
> To: devicetree-disc...@lists.ozlabs.org; linuxppc-...@ozlabs.org
> Cc: Singh Sandeep-B37400; Aggrwal Poonam-B10812
> Subject: [
We have a mix of decimal and hex here, so lets make them consistently
hex. Also, strace will print them in hex if it can't decode them, so
having them in hex here makes it easier to match up.
No functional change.
Signed-off-by: Michael Neuling
diff --git a/arch/powerpc/include/uapi/asm/ptrace
On Tue, 2013-01-08 at 18:38 -0800, Michel Lespinasse wrote:
>
> Well no fair, the previous patch (for powerpc as well) has 22
> insertions and 93 deletions :)
>
> The benefit is that the new code has lower algorithmic complexity, it
> replaces a per-vma loop with O(N) complexity with an outer loo
On Tue, Jan 08, 2013 at 10:16:46AM -0800, Dmitry Torokhov wrote:
> Hi Yuanhan,
>
> On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
> > The current kfifo API take the kfifo size as input, while it rounds
> > _down_ the size to power of 2 at __kfifo_alloc. This may introduce
> > potent
On Tue, Jan 8, 2013 at 6:15 PM, Benjamin Herrenschmidt
wrote:
> On Tue, 2013-01-08 at 17:28 -0800, Michel Lespinasse wrote:
>> Update the powerpc slice_get_unmapped_area function to make use of
>> vm_unmapped_area() instead of implementing a brute force search.
>>
>> Signed-off-by: Michel Lespinas
On Tue, 2013-01-08 at 17:28 -0800, Michel Lespinasse wrote:
> Update the powerpc slice_get_unmapped_area function to make use of
> vm_unmapped_area() instead of implementing a brute force search.
>
> Signed-off-by: Michel Lespinasse
>
> ---
> arch/powerpc/mm/slice.c | 128 +
Whoops, I was supposed to find a more appropriate subject line before
sending this :]
On Tue, Jan 8, 2013 at 5:28 PM, Michel Lespinasse wrote:
> These patches, which apply on top of v3.8-rc kernels, are to complete the
> VMA gap finding code I introduced (following Rik's initial proposal) in
> v3
Since all architectures have been converted to use vm_unmapped_area(),
there is no remaining use for the free_area_cache.
Signed-off-by: Michel Lespinasse
---
arch/arm/mm/mmap.c |2 --
arch/arm64/mm/mmap.c |2 --
arch/mips/mm/mmap.c |2 --
arch
Update the powerpc slice_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/powerpc/mm/slice.c | 128 +-
1 files changed, 81 insertions(+), 47 deletions
As all other architectures have been converted to use vm_unmapped_area(),
we are about to retire the free_area_cache.
This change simply removes the use of that cache in
slice_get_unmapped_area(), which will most certainly have a
performance cost. Next one will convert that function to use the
vm_
Update the ia64 hugetlb_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/ia64/mm/hugetlbpage.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/ia
Update the ia64 arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/ia64/kernel/sys_ia64.c | 37 -
1 files changed, 12 insertions(+), 25 deletions(-)
diff
Update the frv arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/frv/mm/elf-fdpic.c | 49 --
1 files changed, 17 insertions(+), 32 deletions(-)
Update the alpha arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/alpha/kernel/osf_sys.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/arch/alp
These patches, which apply on top of v3.8-rc kernels, are to complete the
VMA gap finding code I introduced (following Rik's initial proposal) in
v3.8-rc1.
First 5 patches introduce the use of vm_unmapped_area() to replace brute
force searches on parisc, alpha, frv and ia64 architectures (all rela
Update the parisc arch_get_unmapped_area function to make use of
vm_unmapped_area() instead of implementing a brute force search.
Signed-off-by: Michel Lespinasse
---
arch/parisc/kernel/sys_parisc.c | 46 ++
1 files changed, 17 insertions(+), 29 deletions(-
Add an assembly fast path for the syscall audit exit path on
64bit. Some distros enable auditing by default which forces us
through the syscall auditing path even if there are no rules.
With syscall auditing enabled we currently disable interrupts,
check the threadinfo flags then immediately re-e
Add an assembly fast path for the syscall audit entry path on
64bit. Some distros enable auditing by default which forces us
through the syscall auditing path even if there are no rules.
I wrote some test cases to validate the patch:
http://ozlabs.org/~anton/junkcode/audit_tests.tar.gz
And to t
Some distros enable auditing by default which forces us through the
syscall trace path. Remove the static branch prediction in our 64bit
syscall handler and let the hardware do the prediction.
Signed-off-by: Anton Blanchard
---
Index: b/arch/powerpc/kernel/entry_64.S
===
Commit b05d8447e782 (audit: inline audit_syscall_entry to reduce
burden on archs) changed audit_syscall_entry to check for a dummy
context before calling __audit_syscall_entry. Unfortunately the dummy
context state is maintained in __audit_syscall_entry so once set it
never gets cleared, even if t
Dmitry Torokhov wrote:
>Hi Yuanhan,
>
>On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
>> The current kfifo API take the kfifo size as input, while it rounds
>> _down_ the size to power of 2 at __kfifo_alloc. This may introduce
>> potential issue.
>>
>> Take the code at drivers/hid
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code at drivers/hid/hid-logitech-dj.c as example:
if (kfifo_alloc(&djrcv_dev->notif_fifo,
DJ_MAX_NUMBER_
Hi Yuanhan,
On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
> The current kfifo API take the kfifo size as input, while it rounds
> _down_ the size to power of 2 at __kfifo_alloc. This may introduce
> potential issue.
>
> Take the code at drivers/hid/hid-logitech-dj.c as example:
>
23 matches
Mail list logo
