[PATCH] mm: vmalloc: Prevent use after free in _vm_unmap_aliases

From: Vijayanand Jitta A potential use after free can occur in _vm_unmap_aliases where an already freed vmap_area could be accessed, Consider the following scenario: Process 1 Process 2 __vm_unmap_aliases

[PATCH] lib: stackdepot: fix ignoring return value warning

From: Vijayanand Jitta fix the below ignoring return value warning for kstrtobool in is_stack_depot_disabled function. lib/stackdepot.c: In function 'is_stack_depot_disabled': lib/stackdepot.c:154:2: warning: ignoring return value of 'kstrtobool' declared with attribute 'warn_unused_result'

[PATCH v6 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE

From: Yogesh Lal Use CONFIG_STACK_HASH_ORDER to configure STACK_HASH_SIZE. Aim is to have configurable value for STACK_HASH_SIZE, so depend on use case one can configure it. One example is of Page Owner, CONFIG_PAGE_OWNER works only if page_owner=on via kernel parameter on CONFIG_PAGE_OWNER

[PATCH v6 2/2] lib: stackdepot: Add support to disable stack depot

From: Vijayanand Jitta Add a kernel parameter stack_depot_disable to disable stack depot. So that stack hash table doesn't consume any memory when stack depot is disabled. The usecase is CONFIG_PAGE_OWNER without page_owner=on. Without this patch, stackdepot will consume the memory for the

[PATCH v5 2/2] lib: stackdepot: Add support to disable stack depot

From: Vijayanand Jitta Add a kernel parameter stack_depot_disable to disable stack depot. So that stack hash table doesn't consume any memory when stack depot is disabled. Signed-off-by: Vinayak Menon Signed-off-by: Vijayanand Jitta --- include/linux/stackdepot.h | 1 + init/main.c

[PATCH v5 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE

From: Yogesh Lal Use CONFIG_STACK_HASH_ORDER to configure STACK_HASH_SIZE. Aim is to have configurable value for STACK_HASH_SIZE, so depend on use case one can configure it. One example is of Page Owner, default value of STACK_HASH_SIZE lead stack depot to consume 8MB of static memory. Making

[PATCH v4 2/2] lib: stackdepot: Add support to disable stack depot

From: Vijayanand Jitta Add a kernel parameter stack_depot_disable to disable stack depot. So that stack hash table doesn't consume any memory when stack depot is disabled. Signed-off-by: Vinayak Menon Signed-off-by: Vijayanand Jitta --- lib/stackdepot.c | 31 +--

[PATCH v4 1/2] lib: stackdepot: Add support to configure STACK_HASH_SIZE

From: Yogesh Lal Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE. Aim is to have configurable value for STACK_HASH_SIZE, so depend on use case one can configure it. One example is of Page Owner, default value of STACK_HASH_SIZE lead stack depot to consume 8MB of static memory. Making

[PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE

From: Yogesh Lal Add a kernel parameter stack_hash_order to configure STACK_HASH_SIZE. Aim is to have configurable value for STACK_HASH_SIZE, so that one can configure it depending on usecase there by reducing the static memory overhead. One example is of Page Owner, default value of

[PATCH v2] lib: stackdepot: Add support to configure STACK_HASH_SIZE

From: Yogesh Lal Add a kernel parameter stack_hash_order to configure STACK_HASH_SIZE. Aim is to have configurable value for STACK_HASH_SIZE, so that one can configure it depending on usecase there by reducing the static memory overhead. One example is of Page Owner, default value of

[PATCH] lib: stackdepot: Add support to configure STACK_HASH_SIZE

From: Yogesh Lal Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE. Aim is to have configurable value for STACK_HASH_SIZE, so depend on use case one can configure it. One example is of Page Owner, default value of STACK_HASH_SIZE lead stack depot to consume 8MB of static memory. Making

[PATCH v5 2/2] iommu/iova: Free global iova rcache on iova alloc failure

From: Vijayanand Jitta When ever an iova alloc request fails we free the iova ranges present in the percpu iova rcaches and then retry but the global iova rcache is not freed as a result we could still see iova alloc failure even after retry as global rcache is holding the iova's which can cause

[PATCH v5 1/2] iommu/iova: Retry from last rb tree node if iova search fails

From: Vijayanand Jitta When ever a new iova alloc request comes iova is always searched from the cached node and the nodes which are previous to cached node. So, even if there is free iova space available in the nodes which are next to the cached node iova allocation can still fail because of

[PATCH v4 2/2] iommu/iova: Free global iova rcache on iova alloc failure

From: Vijayanand Jitta When ever an iova alloc request fails we free the iova ranges present in the percpu iova rcaches and then retry but the global iova rcache is not freed as a result we could still see iova alloc failure even after retry as global rcache is holding the iova's which can cause

[PATCH v4 1/2] iommu/iova: Retry from last rb tree node if iova search fails

From: Vijayanand Jitta When ever a new iova alloc request comes iova is always searched from the cached node and the nodes which are previous to cached node. So, even if there is free iova space available in the nodes which are next to the cached node iova allocation can still fail because of

[PATCH v3 2/2] iommu/iova: Free global iova rcache on iova alloc failure

From: Vijayanand Jitta When ever an iova alloc request fails we free the iova ranges present in the percpu iova rcaches and then retry but the global iova rcache is not freed as a result we could still see iova alloc failure even after retry as global rcache is holding the iova's which can cause

[PATCH v3 1/2] iommu/iova: Retry from last rb tree node if iova search fails

From: Vijayanand Jitta When ever a new iova alloc request comes iova is always searched from the cached node and the nodes which are previous to cached node. So, even if there is free iova space available in the nodes which are next to the cached node iova allocation can still fail because of

[PATCH v2 1/2] iommu/iova: Retry from last rb tree node if iova search fails

From: Vijayanand Jitta When ever a new iova alloc request comes iova is always searched from the cached node and the nodes which are previous to cached node. So, even if there is free iova space available in the nodes which are next to the cached node iova allocation can still fail because of

[PATCH v2 2/2] iommu/iova: Free global iova rcache on iova alloc failure

From: Vijayanand Jitta When ever an iova alloc request fails we free the iova ranges present in the percpu iova rcaches and then retry but the global iova rcache is not freed as a result we could still see iova alloc failure even after retry as global rcache is holding the iova's which can cause

[PATCH 2/2] iommu/iova: Free global iova rcache on iova alloc failure

From: Vijayanand Jitta When ever an iova alloc request fails we free the iova ranges present in the percpu iova rcaches and then retry but the global iova rcache is not freed as a result we could still see iova alloc failure even after retry as global rcache is holding the iova's which can cause

[PATCH 1/2] iommu/iova: Retry from last rb tree node if iova search fails

From: Vijayanand Jitta When ever a new iova alloc request comes iova is always searched from the cached node and the nodes which are previous to cached node. So, even if there is free iova space available in the nodes which are next to the cached node iova allocation can still fail because of

[PATCH] iommu/iova: Free global iova rcache on iova alloc failure

From: Vijayanand Jitta When ever an iova alloc request fails we free the iova ranges present in the percpu iova rcaches and then retry but the global iova rcache is not freed as a result we could still see iova alloc failure even after retry as global rcache is still holding the iova's which can

[PATCH v2] iommu/iova: Retry from last rb tree node if iova search fails

From: Vijayanand Jitta When ever a new iova alloc request comes iova is always searched from the cached node and the nodes which are previous to cached node. So, even if there is free iova space available in the nodes which are next to the cached node iova allocation can still fail because of

[PATCH] iommu/iova: Retry from last rb tree node if iova search fails

From: Vijayanand Jitta When ever a new iova alloc request comes iova is always searched from the cached node and the nodes which are previous to cached node. So, even if there is free iova space available in the nodes which are next to the cached node iova allocation can still fail because of

Re: [PATCH] ion: Consider ion pool pages as indirectly reclaimable

On 2018-04-27 10:40, vji...@codeaurora.org wrote: On 2018-04-25 21:17, Laura Abbott wrote: On 04/24/2018 08:43 PM, vji...@codeaurora.org wrote: From: Vijayanand Jitta An issue is observed where mallocs are failing due to overcommit failure. The failure happens when

Re: [PATCH] ion: Consider ion pool pages as indirectly reclaimable

On 2018-04-27 10:40, vji...@codeaurora.org wrote: On 2018-04-25 21:17, Laura Abbott wrote: On 04/24/2018 08:43 PM, vji...@codeaurora.org wrote: From: Vijayanand Jitta An issue is observed where mallocs are failing due to overcommit failure. The failure happens when there is high ION page

Re: [PATCH] ion: Consider ion pool pages as indirectly reclaimable

On 2018-04-25 21:17, Laura Abbott wrote: On 04/24/2018 08:43 PM, vji...@codeaurora.org wrote: From: Vijayanand Jitta An issue is observed where mallocs are failing due to overcommit failure. The failure happens when there is high ION page pool since ION page pool is

Re: [PATCH] ion: Consider ion pool pages as indirectly reclaimable

On 2018-04-25 21:17, Laura Abbott wrote: On 04/24/2018 08:43 PM, vji...@codeaurora.org wrote: From: Vijayanand Jitta An issue is observed where mallocs are failing due to overcommit failure. The failure happens when there is high ION page pool since ION page pool is not considered

[PATCH] ion: Consider ion pool pages as indirectly reclaimable

From: Vijayanand Jitta An issue is observed where mallocs are failing due to overcommit failure. The failure happens when there is high ION page pool since ION page pool is not considered reclaimable by the overcommit calculation code. This change considers ion pool pages

[PATCH] ion: Consider ion pool pages as indirectly reclaimable

From: Vijayanand Jitta An issue is observed where mallocs are failing due to overcommit failure. The failure happens when there is high ION page pool since ION page pool is not considered reclaimable by the overcommit calculation code. This change considers ion pool pages as indirectly

[PATCH] iommu/arm-smmu: Use context bank TLBSTATUS registers

From: Vijayanand Jitta There are TLBSTATUS registers in SMMU global register space as well as context bank register space. Currently we're polling the global TLBSTATUS registers after TLB invalidation, even when using the TLB invalidation registers from context bank

[PATCH] iommu/arm-smmu: Use context bank TLBSTATUS registers

From: Vijayanand Jitta There are TLBSTATUS registers in SMMU global register space as well as context bank register space. Currently we're polling the global TLBSTATUS registers after TLB invalidation, even when using the TLB invalidation registers from context bank address space. This