Re: Problem with atomic accesses in pstore on some ARM CPUs

On Mon, Aug 15, 2016 at 3:15 PM, Mark Rutland wrote: > On Tue, Aug 16, 2016 at 08:02:53AM -0700, Guenter Roeck wrote: >> On Tue, Aug 16, 2016 at 6:21 AM, Will Deacon wrote: >> > On Tue, Aug 16, 2016 at 06:14:53AM -0700, Guenter Roeck wrote: >> >> On

Re: Problem with atomic accesses in pstore on some ARM CPUs

On Mon, Aug 15, 2016 at 3:15 PM, Mark Rutland wrote: > On Tue, Aug 16, 2016 at 08:02:53AM -0700, Guenter Roeck wrote: >> On Tue, Aug 16, 2016 at 6:21 AM, Will Deacon wrote: >> > On Tue, Aug 16, 2016 at 06:14:53AM -0700, Guenter Roeck wrote: >> >> On Tue, Aug 16, 2016 at 3:32 AM, Robin Murphy

Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

On Wed, Jul 13, 2016 at 11:21 AM, Tejun Heo wrote: > (cc'ing Oleg) > > Hello, > > On Tue, Jul 12, 2016 at 05:00:04PM -0700, John Stultz wrote: >> So Dmitry Shmidt recently noticed that with 4.4 based systems we're >> seeing quite a bit of performance overhead from >>

Re: Severe performance regression w/ 4.4+ on Android due to cgroup locking changes

On Wed, Jul 13, 2016 at 11:21 AM, Tejun Heo wrote: > (cc'ing Oleg) > > Hello, > > On Tue, Jul 12, 2016 at 05:00:04PM -0700, John Stultz wrote: >> So Dmitry Shmidt recently noticed that with 4.4 based systems we're >> seeing quite a bit of performance overhead from >> __cgroup_procs_write(). >>

Re: [PATCH] ion: scatterlist offset not used for buffer map

On Thu, Apr 7, 2016 at 11:56 PM, John Einar Reitan wrote: > On Thu, Apr 07, 2016 at 12:37:50PM -0700, Laura Abbott wrote: >> On 04/07/2016 04:29 AM, John Einar Reitan wrote: >> > ion's default user/kernel page mapping code don't honor the offset >> > option for

Re: [PATCH] ion: scatterlist offset not used for buffer map

On Thu, Apr 7, 2016 at 11:56 PM, John Einar Reitan wrote: > On Thu, Apr 07, 2016 at 12:37:50PM -0700, Laura Abbott wrote: >> On 04/07/2016 04:29 AM, John Einar Reitan wrote: >> > ion's default user/kernel page mapping code don't honor the offset >> > option for scatterlists. It uses sg_page and

VM_GROWSDOWN and fixed size stacks

I recently came across some Android userspace code that jumps through some strange hoops to produce a fixed size stack on the main stack (https://android.googlesource.com/platform/art/+/db1f7dac02f6dcecac3e032f10abbcdbf3cf4331/runtime/thread.cc#543). ART (the Android runtime) uses a unified stack

VM_GROWSDOWN and fixed size stacks

I recently came across some Android userspace code that jumps through some strange hoops to produce a fixed size stack on the main stack (https://android.googlesource.com/platform/art/+/db1f7dac02f6dcecac3e032f10abbcdbf3cf4331/runtime/thread.cc#543). ART (the Android runtime) uses a unified stack

Re: [PATCH] proc: revert /proc//maps [stack:TID] annotation

On Mon, Jan 25, 2016 at 3:14 PM, Kirill A. Shutemov wrote: > On Mon, Jan 25, 2016 at 01:30:00PM -0800, Colin Cross wrote: >> On Tue, Jan 19, 2016 at 3:30 PM, Kirill A. Shutemov >> wrote: >> > On Tue, Jan 19, 2016 at 02:14:30PM -0800, Andrew Morton wrote: >> >>

Re: [PATCH] proc: revert /proc//maps [stack:TID] annotation

On Tue, Jan 19, 2016 at 3:30 PM, Kirill A. Shutemov wrote: > On Tue, Jan 19, 2016 at 02:14:30PM -0800, Andrew Morton wrote: >> On Tue, 19 Jan 2016 13:02:39 -0500 Johannes Weiner >> wrote: >> >> > b764375 ("procfs: mark thread stack correctly in proc//maps") >> > added [stack:TID] annotation to

Re: [PATCH] proc: revert /proc//maps [stack:TID] annotation

On Tue, Jan 19, 2016 at 3:30 PM, Kirill A. Shutemov wrote: > On Tue, Jan 19, 2016 at 02:14:30PM -0800, Andrew Morton wrote: >> On Tue, 19 Jan 2016 13:02:39 -0500 Johannes Weiner >> wrote: >> >> > b764375 ("procfs: mark thread stack correctly in

Re: [PATCH] proc: revert /proc//maps [stack:TID] annotation

On Mon, Jan 25, 2016 at 3:14 PM, Kirill A. Shutemov <kir...@shutemov.name> wrote: > On Mon, Jan 25, 2016 at 01:30:00PM -0800, Colin Cross wrote: >> On Tue, Jan 19, 2016 at 3:30 PM, Kirill A. Shutemov >> <kir...@shutemov.name> wrote: >> > On Tue, Jan 19, 201

Re: [PATCH] staging: ion: fix corruption of ion_import_dma_buf

On Wed, Sep 9, 2015 at 10:19 AM, Laura Abbott wrote: > (adding Colin and John) > > > On 09/09/2015 12:41 AM, Shawn Lin wrote: >> >> we found this issue but still exit in lastest kernel. Simply >> keep ion_handle_create under mutex_lock to avoid this race. >> >> WARNING: CPU: 2 PID: 2648 at

Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Wed, Sep 9, 2015 at 1:35 PM, Rafael J. Wysocki wrote: > > On Wednesday, September 09, 2015 11:20:25 AM Alan Stern wrote: > > On Wed, 9 Sep 2015, Rafael J. Wysocki wrote: > > > > > > The best example and actually the very specific problem we want to > > > > solve is handling touchscreens on a

Re: [PATCH] staging: ion: fix corruption of ion_import_dma_buf

On Wed, Sep 9, 2015 at 10:19 AM, Laura Abbott wrote: > (adding Colin and John) > > > On 09/09/2015 12:41 AM, Shawn Lin wrote: >> >> we found this issue but still exit in lastest kernel. Simply >> keep ion_handle_create under mutex_lock to avoid this race. >> >> WARNING: CPU: 2

Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

On Wed, Sep 9, 2015 at 1:35 PM, Rafael J. Wysocki wrote: > > On Wednesday, September 09, 2015 11:20:25 AM Alan Stern wrote: > > On Wed, 9 Sep 2015, Rafael J. Wysocki wrote: > > > > > > The best example and actually the very specific problem we want to > > > > solve is handling

Re: [PATCH v2 2/2] staging: ion: chunk_heap: use %pad for printing dma_addr_t's

On Mon, May 4, 2015 at 1:22 AM, Dan Carpenter wrote: > On Thu, Apr 09, 2015 at 06:10:04PM -0700, Mitchel Humpherys wrote: >> We're currently using %lu and %ld to print some variables of type >> dma_addr_t, which results in the following warning when dma_addr_t is >> 64-bits wide: >> >>

Re: [PATCH v2 2/2] staging: ion: chunk_heap: use %pad for printing dma_addr_t's

On Mon, May 4, 2015 at 1:22 AM, Dan Carpenter dan.carpen...@oracle.com wrote: On Thu, Apr 09, 2015 at 06:10:04PM -0700, Mitchel Humpherys wrote: We're currently using %lu and %ld to print some variables of type dma_addr_t, which results in the following warning when dma_addr_t is 64-bits wide:

Re: [RFC v3] debug: prevent entering debug mode on errors

On Thu, Nov 27, 2014 at 1:49 AM, Daniel Thompson wrote: > On 26/11/14 17:45, Colin Cross wrote: >> The original patch was more useful as it allowed re-enabling break on >> panic on specific devices where you were trying to debug a >> reproducible issue. What about using a

Re: [RFC v3] debug: prevent entering debug mode on errors

On Thu, Nov 27, 2014 at 1:49 AM, Daniel Thompson daniel.thomp...@linaro.org wrote: On 26/11/14 17:45, Colin Cross wrote: The original patch was more useful as it allowed re-enabling break on panic on specific devices where you were trying to debug a reproducible issue. What about using

Re: [RFC v3] debug: prevent entering debug mode on errors

On Wed, Nov 26, 2014 at 1:14 AM, Kiran Raparthy wrote: > From: Colin Cross > > debug: prevent entering debug mode on errors > > On non-developer devices kgdb prevents CONFIG_PANIC_TIMEOUT from rebooting the > device after a panic. > > In case of panics

Re: [RFC v3] debug: prevent entering debug mode on errors

On Wed, Nov 26, 2014 at 1:14 AM, Kiran Raparthy kiran.ku...@linaro.org wrote: From: Colin Cross ccr...@android.com debug: prevent entering debug mode on errors On non-developer devices kgdb prevents CONFIG_PANIC_TIMEOUT from rebooting the device after a panic. In case of panics

Re: [PATCH] ARM: b.L: fix unmet dependency for CPU_PM

On Thu, Nov 13, 2014 at 10:10 PM, Pankaj Dubey wrote: > +CC: Colin Cross, James Hogan > > On Thursday, November 13, 2014 11:30 PM, Nicolas Pitre wrote: >> To: Russell King - ARM Linux >> Cc: Pankaj Dubey; linux-arm-ker...@lists.infradead.org; linux- >> ker...@vge

Re: [PATCH] ARM: b.L: fix unmet dependency for CPU_PM

On Thu, Nov 13, 2014 at 10:10 PM, Pankaj Dubey pankaj.du...@samsung.com wrote: +CC: Colin Cross, James Hogan On Thursday, November 13, 2014 11:30 PM, Nicolas Pitre wrote: To: Russell King - ARM Linux Cc: Pankaj Dubey; linux-arm-ker...@lists.infradead.org; linux- ker...@vger.kernel.org

Re: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order

On Tue, Oct 7, 2014 at 9:07 AM, PINTU KUMAR wrote: > - Original Message - >> From: Colin Cross >> To: pint...@samsung.com >> Cc: Laura Abbott ; Heesub Shin >> ; "a...@linux-foundation.org" >> ; "gre...@linuxfoundation.org" >

Re: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order

On Tue, Oct 7, 2014 at 9:07 AM, PINTU KUMAR pint...@samsung.com wrote: - Original Message - From: Colin Cross ccr...@android.com To: pint...@samsung.com Cc: Laura Abbott lau...@codeaurora.org; Heesub Shin heesub.s...@samsung.com; a...@linux-foundation.org a...@linux-foundation.org

Re: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order

On Mon, Oct 6, 2014 at 9:26 AM, PINTU KUMAR wrote: > > Hi, > > > > From: Laura Abbott > >To: Heesub Shin ; Pintu Kumar > >; a...@linux-foundation.org; > >gre...@linuxfoundation.org; john.stu...@linaro.org; rebe...@android.com; > >ccr...@android.com;

Re: Re: [PATCH 1/1] [ion]: system-heap use PAGE_ALLOC_COSTLY_ORDER for high order

On Mon, Oct 6, 2014 at 9:26 AM, PINTU KUMAR pint...@samsung.com wrote: Hi, From: Laura Abbott lau...@codeaurora.org To: Heesub Shin heesub.s...@samsung.com; Pintu Kumar pint...@samsung.com; a...@linux-foundation.org; gre...@linuxfoundation.org;

Re: staging: Unwritten function for ion_carveout_heap.c

On Wed, Jul 23, 2014 at 1:04 PM, Nick Krause wrote: > Hey Greg and others. > Sorry for another email but it seems the function, > ion_carveout_heap_unmap_dma is > just returning and not doing anything useful. Furthermore I am new so > I don't known how > to write this function but this may be

Re: staging: Unwritten function for ion_carveout_heap.c

On Wed, Jul 23, 2014 at 1:04 PM, Nick Krause xerofo...@gmail.com wrote: Hey Greg and others. Sorry for another email but it seems the function, ion_carveout_heap_unmap_dma is just returning and not doing anything useful. Furthermore I am new so I don't known how to write this function but

Re: [PATCH] drivers: staging: android: ion: Kconfig: Let it also depend on HAS_DMA

ds on HAVE_MEMBLOCK && HAS_DMA > select GENERIC_ALLOCATOR > select DMA_SHARED_BUFFER > ---help--- > -- > 1.9.2.459.g68773ac Acked-by: Colin Cross -- 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: [PATCH] drivers: staging: android: ion: Kconfig: Let it also depend on HAS_DMA

--- -- 1.9.2.459.g68773ac Acked-by: Colin Cross ccr...@android.com -- 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

Re: [PATCH] ARM64: implement TASK_SIZE_OF

On Fri, Jun 20, 2014 at 1:25 AM, Will Deacon wrote: > Hi Colin, > > On Wed, Jun 18, 2014 at 09:10:09PM +0100, Colin Cross wrote: >> include/linux/sched.h implements TASK_SIZE_OF as TASK_SIZE if it >> is not set by the architecture headers. TASK_SIZE uses the >> current

Re: [PATCH] ARM64: implement TASK_SIZE_OF

On Fri, Jun 20, 2014 at 1:25 AM, Will Deacon will.dea...@arm.com wrote: Hi Colin, On Wed, Jun 18, 2014 at 09:10:09PM +0100, Colin Cross wrote: include/linux/sched.h implements TASK_SIZE_OF as TASK_SIZE if it is not set by the architecture headers. TASK_SIZE uses the current task

Re: [REPOST PATCH 4/8] android: convert sync to fence api, v5

On Thu, Jun 19, 2014 at 5:28 AM, Daniel Vetter wrote: > On Thu, Jun 19, 2014 at 1:48 PM, Thierry Reding > wrote: >>> > With these changes, can we pull the android sync logic out of >>> > drivers/staging/ now? >>> >>> Afaik the google guys never really looked at this and acked it. So I'm not >>>

Re: [REPOST PATCH 4/8] android: convert sync to fence api, v5

move_callback in sync_fence_free if not all fences have >> > fired. >> > v3: >> > - Merge Colin Cross' bugfixes, and the android fence merge optimization. >> > v4: >> > - Merge with the upstream fixes. >> > v5: >> > - Fix small sty

Re: [REPOST PATCH 4/8] android: convert sync to fence api, v5

to maintain a separate api for synchronization. I've left the android trace events in place, but the core fence events should already be sufficient for debugging. v2: - Call fence_remove_callback in sync_fence_free if not all fences have fired. v3: - Merge Colin Cross' bugfixes

Re: [REPOST PATCH 4/8] android: convert sync to fence api, v5

On Thu, Jun 19, 2014 at 5:28 AM, Daniel Vetter dan...@ffwll.ch wrote: On Thu, Jun 19, 2014 at 1:48 PM, Thierry Reding thierry.red...@gmail.com wrote: With these changes, can we pull the android sync logic out of drivers/staging/ now? Afaik the google guys never really looked at this and

[PATCH] ARM64: implement TASK_SIZE_OF

to return EOF when it reads past 0x. Implement TASK_SIZE_OF exactly the same as TASK_SIZE with test_tsk_thread_flag instead of test_thread_flag. Cc: sta...@vger.kernel.org Signed-off-by: Colin Cross --- arch/arm64/include/asm/memory.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch

[PATCH] ARM64: implement TASK_SIZE_OF

to return EOF when it reads past 0x. Implement TASK_SIZE_OF exactly the same as TASK_SIZE with test_tsk_thread_flag instead of test_thread_flag. Cc: sta...@vger.kernel.org Signed-off-by: Colin Cross ccr...@android.com --- arch/arm64/include/asm/memory.h | 2 ++ 1 file changed, 2 insertions

Re: [PATCH] staging: ion: WARN when the handle kmap_cnt is going to wrap around

, > hosted by The Linux Foundation > > To unsubscribe from this group and stop receiving emails from it, send an > email to kernel-team+unsubscr...@android.com. Acked-by: Colin Cross -- 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: [PATCH] staging: ion: WARN when the handle kmap_cnt is going to wrap around

...@android.com. Acked-by: Colin Cross ccr...@android.com -- 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: [RFC v3 1/9] sysrq: Implement __handle_sysrq_nolock to avoid recursive locking in kdb

On Tue, Apr 29, 2014 at 1:59 AM, Daniel Thompson wrote: > On 28/04/14 18:44, Colin Cross wrote: >>>> Is that case documented somewhere in the code comments? >>> >>> Perhaps not near enough to the _nolock but the primary bit of comment is >>> here (and

Re: [RFC v3 1/9] sysrq: Implement __handle_sysrq_nolock to avoid recursive locking in kdb

On Tue, Apr 29, 2014 at 1:59 AM, Daniel Thompson daniel.thomp...@linaro.org wrote: On 28/04/14 18:44, Colin Cross wrote: Is that case documented somewhere in the code comments? Perhaps not near enough to the _nolock but the primary bit of comment is here (and in same file as kdb_sr). --- cut

Re: [RFC v3 1/9] sysrq: Implement __handle_sysrq_nolock to avoid recursive locking in kdb

On Mon, Apr 28, 2014 at 3:24 AM, Daniel Thompson wrote: > On 25/04/14 17:45, Steven Rostedt wrote: >> On Fri, 25 Apr 2014 17:29:22 +0100 >> Daniel Thompson wrote: >> >>> If kdb is triggered using SysRq-g then any use of the sr command results >>> in the SysRq key table lock being recursively

Re: [RFC v3 1/9] sysrq: Implement __handle_sysrq_nolock to avoid recursive locking in kdb

On Mon, Apr 28, 2014 at 3:24 AM, Daniel Thompson daniel.thomp...@linaro.org wrote: On 25/04/14 17:45, Steven Rostedt wrote: On Fri, 25 Apr 2014 17:29:22 +0100 Daniel Thompson daniel.thomp...@linaro.org wrote: If kdb is triggered using SysRq-g then any use of the sr command results in the

Re: [PATCH] staging/android: Remove ram_console.h

LATFORM_DATA_RAM_CONSOLE_H_ */ > -- > 1.7.9.5 > > > -- > 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 r

Re: [PATCH] staging/android: Remove ram_console.h

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/ Acked-by: Colin Cross ccr...@android.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: [PATCH] staging : android : uapi : fix coding style

(resending without the html) On Wed, Apr 16, 2014 at 9:36 AM, John Stultz wrote: > > On 04/16/2014 07:39 AM, Joe Perches wrote: > > On Wed, 2014-04-16 at 23:27 +0900, Seunghun Lee wrote: > >> This patch fix checkpatch.pl warnings and errors. > > [] > >> diff --git

Re: [PATCH] staging : android : uapi : fix coding style

(resending without the html) On Wed, Apr 16, 2014 at 9:36 AM, John Stultz john.stu...@linaro.org wrote: On 04/16/2014 07:39 AM, Joe Perches wrote: On Wed, 2014-04-16 at 23:27 +0900, Seunghun Lee wrote: This patch fix checkpatch.pl warnings and errors. [] diff --git

Re: [PATCH] dma-buf: avoid using IS_ERR_OR_NULL

On Fri, Feb 7, 2014 at 8:43 AM, Greg Kroah-Hartman wrote: > On Sat, Dec 21, 2013 at 07:42:17AM -0500, Rob Clark wrote: >> On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross wrote: >> > dma_buf_map_attachment and dma_buf_vmap can return NULL or >> > ERR_PTR on a error. Thi

Re: [PATCH] dma-buf: avoid using IS_ERR_OR_NULL

On Fri, Feb 7, 2014 at 8:43 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Sat, Dec 21, 2013 at 07:42:17AM -0500, Rob Clark wrote: On Fri, Dec 20, 2013 at 7:43 PM, Colin Cross ccr...@android.com wrote: dma_buf_map_attachment and dma_buf_vmap can return NULL or ERR_PTR on a error

[PATCH] security: select correct default LSM_MMAP_MIN_ADDR on arm on arm64

Binaries compiled for arm may run on arm64 if CONFIG_COMPAT is selected. Set LSM_MMAP_MIN_ADDR to 32768 if ARM64 && COMPAT to prevent selinux failures launching 32-bit static executables that are mapped at 0x8000. Signed-off-by: Colin Cross --- security/Kconfig | 2 +- 1 file ch

[PATCH] security: select correct default LSM_MMAP_MIN_ADDR on arm on arm64

Binaries compiled for arm may run on arm64 if CONFIG_COMPAT is selected. Set LSM_MMAP_MIN_ADDR to 32768 if ARM64 COMPAT to prevent selinux failures launching 32-bit static executables that are mapped at 0x8000. Signed-off-by: Colin Cross ccr...@android.com --- security/Kconfig | 2 +- 1 file

Re: [PATCH 1/7] sched: allow try_to_wake_up to be used internally outside of core.c

On Mon, Jan 13, 2014 at 4:31 AM, Maarten Lankhorst wrote: > The kernel fence implementation doesn't use event queues, but needs > to perform the same wake up. The symbol is not exported, since the > fence implementation is not built as a module. > > Signed-off-by: Maarten Lankhorst > --- >

Re: [PATCH 1/7] sched: allow try_to_wake_up to be used internally outside of core.c

On Mon, Jan 13, 2014 at 4:31 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: The kernel fence implementation doesn't use event queues, but needs to perform the same wake up. The symbol is not exported, since the fence implementation is not built as a module. Signed-off-by:

Re: [PATCH] arm: mm: add memory type for inner-writeback

On Tue, Jan 7, 2014 at 7:09 AM, Catalin Marinas wrote: > On Fri, Dec 27, 2013 at 04:58:48AM +, Mark Zhang wrote: >> From: Colin Cross >> >> For streaming-style operations (e.g., software rendering of graphics >> surfaces shared with non-coherent DMA devices), t

Re: [PATCH] arm: mm: add memory type for inner-writeback

On Tue, Jan 7, 2014 at 7:09 AM, Catalin Marinas catalin.mari...@arm.com wrote: On Fri, Dec 27, 2013 at 04:58:48AM +, Mark Zhang wrote: From: Colin Cross ccr...@android.com For streaming-style operations (e.g., software rendering of graphics surfaces shared with non-coherent DMA devices

[PATCH] dma-buf: avoid using IS_ERR_OR_NULL

check for NULL, and would have dereferenced an ERR_PTR and panic'd if one was ever returned. This is not consistent with the rest of the dma buf APIs, but matches the expectations of all of the callers. Signed-off-by: Colin Cross --- drivers/base/dma-buf.c | 18

[PATCH] dma-buf: avoid using IS_ERR_OR_NULL

check for NULL, and would have dereferenced an ERR_PTR and panic'd if one was ever returned. This is not consistent with the rest of the dma buf APIs, but matches the expectations of all of the callers. Signed-off-by: Colin Cross ccr...@android.com --- drivers/base/dma-buf.c

Re: [PATCH] ion_test: Add compat_ioctl support (v2)

t; Changes in v2: > - Add a padding int rather then making write a u64 > > Cc: Colin Cross > Cc: Greg KH > Cc: Android Kernel Team > Signed-off-by: John Stultz > --- > drivers/staging/android/ion/ion_test.c | 1 + > drivers/staging/android/uapi/ion_test.h | 1 + &g

Re: [PATCH] ion_test: Add compat_ioctl support

On Thu, Dec 19, 2013 at 3:30 PM, John Stultz wrote: > On 12/19/2013 02:52 PM, Colin Cross wrote: >> On Thu, Dec 19, 2013 at 2:40 PM, John Stultz wrote: >>> Prior to subitting this, Colin reworked the compat_ioctl support >>> for the ion_test driver, moving the st

Re: [PATCH] ion_test: Add compat_ioctl support

his does affect the ABI for 32bit users, its only > the ABI for the ion_test driver, not ion itself. > > Cc: Colin Cross > Cc: Greg KH > Cc: Android Kernel Team > Signed-off-by: John Stultz > --- > drivers/staging/android/ion/ion_test.c | 1 + > drivers/staging/and

Re: [PATCH] ion_test: Add compat_ioctl support

users, its only the ABI for the ion_test driver, not ion itself. Cc: Colin Cross ccr...@android.com Cc: Greg KH gre...@linuxfoundation.org Cc: Android Kernel Team kernel-t...@android.com Signed-off-by: John Stultz john.stu...@linaro.org --- drivers/staging/android/ion/ion_test.c | 1

Re: [PATCH] ion_test: Add compat_ioctl support

On Thu, Dec 19, 2013 at 3:30 PM, John Stultz john.stu...@linaro.org wrote: On 12/19/2013 02:52 PM, Colin Cross wrote: On Thu, Dec 19, 2013 at 2:40 PM, John Stultz john.stu...@linaro.org wrote: Prior to subitting this, Colin reworked the compat_ioctl support for the ion_test driver, moving

Re: [PATCH] ion_test: Add compat_ioctl support (v2)

int rather then making write a u64 Cc: Colin Cross ccr...@android.com Cc: Greg KH gre...@linuxfoundation.org Cc: Android Kernel Team kernel-t...@android.com Signed-off-by: John Stultz john.stu...@linaro.org --- drivers/staging/android/ion/ion_test.c | 1 + drivers/staging/android/uapi

Re: [PATCH v3] staging: ion: Avoid using rt_mutexes directly

as a general heap lock." > > Thus this patch converts the rt_mutex usage to a spinlock and > renames the lock free_lock to be more clear as to its use. > > I also had to change a bit of logic in ion_heap_freelist_drain() > to safely avoid list corruption. > > Cc: Colin Cross

Re: [PATCH v3] staging: ion: Avoid using rt_mutexes directly

the rt_mutex usage to a spinlock and renames the lock free_lock to be more clear as to its use. I also had to change a bit of logic in ion_heap_freelist_drain() to safely avoid list corruption. Cc: Colin Cross ccr...@android.com Cc: Android Kernel Team kernel-t...@android.com Cc: Greg KH gre

Re: [PATCH 3/3] staging: ion: Avoid using rt_mutexes directly.

re if its the mixing of list traversal methods causing the issue? > Thoughts would be appreciated. list_for_each_entry_safe just stores the next pointer to allow deleting the current pointer, but that isn't safe if you follow my suggestion to drop the lock because the next pointer could also becom

Re: [PATCH 1/3] staging: ion: Add HAVE_MEMBLOCK config dependency

Acked-by: Colin Cross On Mon, Dec 16, 2013 at 9:07 PM, John Stultz wrote: > The kbuild test robot reported a build issue w/ ION on m68k: > > drivers/staging/android/ion/ion.c: In function 'ion_reserve': > drivers/staging/android/ion/ion.c:1526:4: error: implicit declaration of

Re: [PATCH 2/3] staging: ion: Fix possible null pointer dereference

loc goes unchecked for failure. > > This patch checks the return for NULL, and reworks the logic, as > suggested by Colin, so we allocate the page_info structure first. > > Cc: Colin Cross > Cc: Greg KH > Cc: Android Kernel Team > Cc: kbuild test robot > Reported-by: kb

Re: [RFC][PATCH 3/3] staging: ion: Avoid using rt_mutexes directly.

On Mon, Dec 16, 2013 at 5:22 PM, John Stultz wrote: > On 12/16/2013 04:17 PM, Colin Cross wrote: >> The lock is only used to protect the heap's free_list and >> free_list_size members, and is not held for any long or sleeping >> operations. Converting to a spinlock sh

[PATCH] ion: remove ion_user_handle_t from ion_test.h

: note: previous declaration of 'ion_user_handle_t' was here Reported-by: Andrew Morton Signed-off-by: Colin Cross --- drivers/staging/android/uapi/ion_test.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/android/uapi/ion_test.h b/drivers/staging/android/uapi/ion_test.h

Re: [RFC][PATCH 2/3] staging: ion: Fix possible null pointer dereference

On Mon, Dec 16, 2013 at 1:32 PM, John Stultz wrote: > The kbuild test robot reported: > > drivers/staging/android/ion/ion_system_heap.c:122 alloc_largest_available() > error: potential null dereference 'info'. (kmalloc returns null) > > Where the pointer returned from kmalloc goes unchecked for

Re: [RFC][PATCH 3/3] staging: ion: Avoid using rt_mutexes directly.

On Mon, Dec 16, 2013 at 1:32 PM, John Stultz wrote: > RT_MUTEXES can be configured out of the kernel, causing compile > problems with ION. > > Since there is no documentation as to why directly using rt_mutexes > is necessary (and very few drivers directly use rt_mutexes), simply > convert the

Re: [RFC][PATCH 3/3] staging: ion: Avoid using rt_mutexes directly.

On Mon, Dec 16, 2013 at 1:32 PM, John Stultz john.stu...@linaro.org wrote: RT_MUTEXES can be configured out of the kernel, causing compile problems with ION. Since there is no documentation as to why directly using rt_mutexes is necessary (and very few drivers directly use rt_mutexes), simply

Re: [RFC][PATCH 2/3] staging: ion: Fix possible null pointer dereference

On Mon, Dec 16, 2013 at 1:32 PM, John Stultz john.stu...@linaro.org wrote: The kbuild test robot reported: drivers/staging/android/ion/ion_system_heap.c:122 alloc_largest_available() error: potential null dereference 'info'. (kmalloc returns null) Where the pointer returned from kmalloc

[PATCH] ion: remove ion_user_handle_t from ion_test.h

: note: previous declaration of 'ion_user_handle_t' was here Reported-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Colin Cross ccr...@android.com --- drivers/staging/android/uapi/ion_test.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/android/uapi/ion_test.h b

Re: [RFC][PATCH 3/3] staging: ion: Avoid using rt_mutexes directly.

On Mon, Dec 16, 2013 at 5:22 PM, John Stultz john.stu...@linaro.org wrote: On 12/16/2013 04:17 PM, Colin Cross wrote: The lock is only used to protect the heap's free_list and free_list_size members, and is not held for any long or sleeping operations. Converting to a spinlock should prevent

Re: [PATCH 1/3] staging: ion: Add HAVE_MEMBLOCK config dependency

Acked-by: Colin Cross ccr...@android.com On Mon, Dec 16, 2013 at 9:07 PM, John Stultz john.stu...@linaro.org wrote: The kbuild test robot reported a build issue w/ ION on m68k: drivers/staging/android/ion/ion.c: In function 'ion_reserve': drivers/staging/android/ion/ion.c:1526:4: error

Re: [PATCH 2/3] staging: ion: Fix possible null pointer dereference

goes unchecked for failure. This patch checks the return for NULL, and reworks the logic, as suggested by Colin, so we allocate the page_info structure first. Cc: Colin Cross ccr...@android.com Cc: Greg KH gre...@linuxfoundation.org Cc: Android Kernel Team kernel-t...@android.com Cc: kbuild

Re: [PATCH 3/3] staging: ion: Avoid using rt_mutexes directly.

. list_for_each_entry_safe just stores the next pointer to allow deleting the current pointer, but that isn't safe if you follow my suggestion to drop the lock because the next pointer could also become invalid, so the while loop is necessary. Cc: Colin Cross ccr...@android.com Cc: Android Kernel Team kernel

Re: [PATCH 1/2] ion: Don't allow building ION as a module.

On Sat, Dec 14, 2013 at 2:19 PM, John Stultz wrote: > On 12/14/2013 01:48 PM, Greg KH wrote: >> On Sat, Dec 14, 2013 at 12:06:45PM -0800, John Stultz wrote: >>> ION doesn't export the proper symbols for it to be a module. This >>> causes build issues when ION is configured as a module. >>> >>>

Re: [PATCH 001/115] gpu: ion: Add ION Memory Manager

On Sat, Dec 14, 2013 at 1:44 PM, Greg KH wrote: > On Sat, Dec 14, 2013 at 01:10:38PM -0800, Colin Cross wrote: >> On Sat, Dec 14, 2013 at 8:52 AM, Greg KH wrote: >> > On Fri, Dec 13, 2013 at 02:23:35PM -0800, John Stultz wrote: >> >> + idev->debug_root

Re: [PATCH 001/115] gpu: ion: Add ION Memory Manager

On Sat, Dec 14, 2013 at 8:52 AM, Greg KH wrote: > On Fri, Dec 13, 2013 at 02:23:35PM -0800, John Stultz wrote: >> + idev->debug_root = debugfs_create_dir("ion", NULL); >> + if (IS_ERR_OR_NULL(idev->debug_root)) >> + pr_err("ion: failed to create debug files.\n"); > > There's

Re: [PATCH 001/115] gpu: ion: Add ION Memory Manager

On Sat, Dec 14, 2013 at 8:52 AM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Dec 13, 2013 at 02:23:35PM -0800, John Stultz wrote: + idev-debug_root = debugfs_create_dir(ion, NULL); + if (IS_ERR_OR_NULL(idev-debug_root)) + pr_err(ion: failed to create debug files.\n);

Re: [PATCH 001/115] gpu: ion: Add ION Memory Manager

On Sat, Dec 14, 2013 at 1:44 PM, Greg KH gre...@linuxfoundation.org wrote: On Sat, Dec 14, 2013 at 01:10:38PM -0800, Colin Cross wrote: On Sat, Dec 14, 2013 at 8:52 AM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Dec 13, 2013 at 02:23:35PM -0800, John Stultz wrote: + idev

Re: [PATCH 1/2] ion: Don't allow building ION as a module.

On Sat, Dec 14, 2013 at 2:19 PM, John Stultz john.stu...@linaro.org wrote: On 12/14/2013 01:48 PM, Greg KH wrote: On Sat, Dec 14, 2013 at 12:06:45PM -0800, John Stultz wrote: ION doesn't export the proper symbols for it to be a module. This causes build issues when ION is configured as a

[PATCH] ioprio: move userspace api into uapi

Move the userspace interface described in Documentation/block/ioprio.txt from include/linux/ioprio.h to include/uapi/linux/ioprio.h. Signed-off-by: Colin Cross --- include/linux/ioprio.h | 42 + include/uapi/linux/ioprio.h | 46

[PATCH] ioprio: move userspace api into uapi

Move the userspace interface described in Documentation/block/ioprio.txt from include/linux/ioprio.h to include/uapi/linux/ioprio.h. Signed-off-by: Colin Cross ccr...@android.com --- include/linux/ioprio.h | 42 + include/uapi/linux/ioprio.h | 46

Re: [PATCH v1 9/9] staging: android: binder: Add binder compat layer

On Wed, Dec 4, 2013 at 4:02 PM, Greg KH wrote: > On Wed, Dec 04, 2013 at 02:22:13PM -0800, Colin Cross wrote: >> On Wed, Dec 4, 2013 at 2:02 PM, Greg KH wrote: >> > On Wed, Dec 04, 2013 at 01:55:34PM -0800, Colin Cross wrote: >> >> On Wed, Dec 4, 2013 at

Re: [PATCH v1 9/9] staging: android: binder: Add binder compat layer

On Wed, Dec 4, 2013 at 3:21 PM, One Thousand Gnomes wrote: > On Wed, 4 Dec 2013 10:35:54 -0800 > Greg KH wrote: > >> On Wed, Dec 04, 2013 at 06:09:41PM +, Serban Constantinescu wrote: >> > +#define size_helper(x) ({ \ >> > + size_t __size;

Re: [PATCH v1 9/9] staging: android: binder: Add binder compat layer

On Wed, Dec 4, 2013 at 2:02 PM, Greg KH wrote: > On Wed, Dec 04, 2013 at 01:55:34PM -0800, Colin Cross wrote: >> On Wed, Dec 4, 2013 at 1:43 PM, Greg KH wrote: >> > On Wed, Dec 04, 2013 at 12:46:42PM -0800, Colin Cross wrote: >> >> On Wed, Dec 4, 2013 at 1

Re: [PATCH v1 9/9] staging: android: binder: Add binder compat layer

On Wed, Dec 4, 2013 at 1:43 PM, Greg KH wrote: > On Wed, Dec 04, 2013 at 12:46:42PM -0800, Colin Cross wrote: >> On Wed, Dec 4, 2013 at 10:35 AM, Greg KH wrote: >> >> >> > And finally, is this all really needed? Why not just fix the structures >> >

Re: [PATCH v1 9/9] staging: android: binder: Add binder compat layer

On Wed, Dec 4, 2013 at 10:35 AM, Greg KH wrote: > And finally, is this all really needed? Why not just fix the structures > to be "correct", and then fix userspace to use the correct structures as > well, thereby not needing a compat layer at all? Some of the binder ioctls take userspace

Re: [PATCH v1 9/9] staging: android: binder: Add binder compat layer

On Wed, Dec 4, 2013 at 10:35 AM, Greg KH gre...@linuxfoundation.org wrote: snip And finally, is this all really needed? Why not just fix the structures to be correct, and then fix userspace to use the correct structures as well, thereby not needing a compat layer at all? Some of the binder

Re: [PATCH v1 9/9] staging: android: binder: Add binder compat layer

On Wed, Dec 4, 2013 at 1:43 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Dec 04, 2013 at 12:46:42PM -0800, Colin Cross wrote: On Wed, Dec 4, 2013 at 10:35 AM, Greg KH gre...@linuxfoundation.org wrote: snip And finally, is this all really needed? Why not just fix the structures

Re: [PATCH v1 9/9] staging: android: binder: Add binder compat layer

On Wed, Dec 4, 2013 at 2:02 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Dec 04, 2013 at 01:55:34PM -0800, Colin Cross wrote: On Wed, Dec 4, 2013 at 1:43 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Dec 04, 2013 at 12:46:42PM -0800, Colin Cross wrote: On Wed, Dec 4, 2013

Re: [PATCH v1 9/9] staging: android: binder: Add binder compat layer

On Wed, Dec 4, 2013 at 3:21 PM, One Thousand Gnomes gno...@lxorguk.ukuu.org.uk wrote: On Wed, 4 Dec 2013 10:35:54 -0800 Greg KH gre...@linuxfoundation.org wrote: On Wed, Dec 04, 2013 at 06:09:41PM +, Serban Constantinescu wrote: +#define size_helper(x) ({

Re: [PATCH v1 9/9] staging: android: binder: Add binder compat layer

On Wed, Dec 4, 2013 at 4:02 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Dec 04, 2013 at 02:22:13PM -0800, Colin Cross wrote: On Wed, Dec 4, 2013 at 2:02 PM, Greg KH gre...@linuxfoundation.org wrote: On Wed, Dec 04, 2013 at 01:55:34PM -0800, Colin Cross wrote: On Wed, Dec 4, 2013

  1   2   3   4   5   >