On Tue, Aug 23, 2016 at 02:00:06PM -0700, Laura Abbott wrote:
> It's pretty harsh because the users of Ion need a less than subtle hint
> that something is broken. From experience, warning and leaking memory
> just leads to a system that limps along and warnings that get ignored.
> At long as Ion i
On 08/23/2016 11:43 AM, Johanna Abrahamsson wrote:
On Mon, Aug 22, 2016 at 09:58:40AM -0700, Laura Abbott wrote:
The validate and BUG_ON are checking two slightly different things.
The BUG_ON is trying to catch blatantly wrong kernel users while the
validate is designed to catch races.
I still
On Mon, Aug 22, 2016 at 09:58:40AM -0700, Laura Abbott wrote:
> The validate and BUG_ON are checking two slightly different things.
> The BUG_ON is trying to catch blatantly wrong kernel users while the
> validate is designed to catch races.
I still think BUG is a fairly harsh way to "catch" blata
On 08/22/2016 03:26 AM, Johanna Abrahamsson wrote:
The ion_free() and ion_free_nolock() functions should not BUG on a
handle client mismatch. It is not necessary to explicitly check for that
mismatch when ion_handle_validate is used.
The validate and BUG_ON are checking two slightly different
The ion_free() and ion_free_nolock() functions should not BUG on a
handle client mismatch. It is not necessary to explicitly check for that
mismatch when ion_handle_validate is used.
Signed-off-by: Johanna Abrahamsson
---
drivers/staging/android/ion/ion.c | 4
1 file changed, 4 deletions(-)
