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

On 3/18/2021 10:29 PM, Uladzislau Rezki wrote: > On Thu, Mar 18, 2021 at 03:38:25PM +0530, vji...@codeaurora.org wrote: >> From: Vijayanand Jitta >> >> A potential use after free can occur in _vm_unmap_aliases >> where an already freed vmap_area could be accessed

Re: linux-next: build warning after merge of the akpm tree

ble stack depot") > > Interestingly, we have 2 declarations of kstrtobool - one in > linux/kernel.h (which has __must_check) and one in linux/strings.h > (which doesn't). > I have sent out the fix to lkml, Copied it below for your reference. Please Feel free to apply or squash it to t

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

On 1/22/2021 5:55 AM, Minchan Kim wrote: > On Mon, Jan 18, 2021 at 03:26:42PM +0530, vji...@codeaurora.org wrote: >> From: Vijayanand Jitta >> >> Add a kernel parameter stack_depot_disable to disable >> stack depot. So that stack hash table doesn't consume >

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

; will just waste 8M memory without any customer. > Sure, will update the commit text as suggested. Thanks, Vijay >> >> Signed-off-by: Yogesh Lal >> Signed-off-by: Vinayak Menon >> Signed-off-by: Vijayanand Jitta > Reviewed-by: Minchan Kim > -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

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

significant overhead. >> >> Signed-off-by: Yogesh Lal >> Signed-off-by: Vinayak Menon >> Signed-off-by: Vijayanand Jitta > > Hi, > > Did you see > https://lore.kernel.org/lkml/202101050729.cwtd47yw-...@intel.com/ > > It seems that arch/arc/ does n

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

On 1/5/2021 2:54 PM, Vijayanand Jitta wrote: > > > On 1/5/2021 4:42 AM, Andrew Morton wrote: >> On Wed, 30 Dec 2020 18:15:30 +0530 vji...@codeaurora.org wrote: >> >>> Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE. >>> >>> Aim is

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

On 1/7/2021 3:14 PM, Alexander Potapenko wrote: > On Wed, Dec 30, 2020 at 1:46 PM wrote: >> >> From: Yogesh Lal >> >> Use STACK_HASH_ORDER_SHIFT to configure STACK_HASH_SIZE. > I think "ORDER_SHIFT" is somewhat redundant, as "SMTH_ORDER" already > means this is a power of two we'll be using

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

On 1/5/2021 4:42 AM, Andrew Morton wrote: > On Wed, 30 Dec 2020 18:15:30 +0530 vji...@codeaurora.org wrote: > >> 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

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

On 12/23/2020 8:10 PM, Alexander Potapenko wrote: >> >> Michan, We would still need config option so that we can reduce the >> memory consumption on low ram devices using config. >> >> Alex, On this, >> "I also suppose device vendors may prefer setting a fixed (maybe >> non-default) hash size

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

On 12/22/2020 1:59 AM, Minchan Kim wrote: > On Mon, Dec 21, 2020 at 04:04:09PM +0100, Alexander Potapenko wrote: >> On Mon, Dec 21, 2020 at 12:15 PM Vijayanand Jitta >> wrote: >>> >>> >>> >>> On 12/18/2020 2:10 PM, Vijayanand Jitta wro

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

On 12/18/2020 2:10 PM, Vijayanand Jitta wrote: > > > On 12/17/2020 4:24 PM, Alexander Potapenko wrote: >>>> Can you provide an example of a use case in which the user wants to >>>> use the stack depot of a smaller size without disabling it completely, >&g

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

On 12/17/2020 4:24 PM, Alexander Potapenko wrote: >>> Can you provide an example of a use case in which the user wants to >>> use the stack depot of a smaller size without disabling it completely, >>> and that size cannot be configured statically? >>> As far as I understand, for the page owner

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

On 12/16/2020 7:04 PM, Alexander Potapenko wrote: >>> To reiterate, I think you don't need a tunable stack_hash_order >>> parameter if the only use case is to disable the stack depot. >>> Maybe it is enough to just add a boolean flag? >> >> There are multiple users of stackdepot they might

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

On 12/16/2020 6:41 PM, Alexander Potapenko wrote: > On Wed, Dec 16, 2020 at 2:06 PM Vijayanand Jitta > wrote: >> >> >> >> On 12/16/2020 1:56 PM, Alexander Potapenko wrote: >>> On Wed, Dec 16, 2020 at 4:43 AM Vijayanand Jitta >>> wrote: >&

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

On 12/16/2020 1:56 PM, Alexander Potapenko wrote: > On Wed, Dec 16, 2020 at 4:43 AM Vijayanand Jitta > wrote: >> >> >> >> On 12/14/2020 4:02 PM, Vijayanand Jitta wrote: >>> >>> >>> On 12/14/2020 3:04 PM, Alexander Potapenko wro

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

On 12/14/2020 4:02 PM, Vijayanand Jitta wrote: > > > On 12/14/2020 3:04 PM, Alexander Potapenko wrote: >> On Mon, Dec 14, 2020 at 5:02 AM Vijayanand Jitta >> wrote: >>> >>> >>> >>> On 12/11/2020 6:55 PM, Alexander Potapenko wro

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

On 12/14/2020 3:04 PM, Alexander Potapenko wrote: > On Mon, Dec 14, 2020 at 5:02 AM Vijayanand Jitta > wrote: >> >> >> >> On 12/11/2020 6:55 PM, Alexander Potapenko wrote: >>> On Fri, Dec 11, 2020 at 1:45 PM Vijayanand Jitta >>> wrote: >

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

On 12/11/2020 6:55 PM, Alexander Potapenko wrote: > On Fri, Dec 11, 2020 at 1:45 PM Vijayanand Jitta > wrote: >> >> >> >> On 12/11/2020 2:06 PM, Alexander Potapenko wrote: >>> On Thu, Dec 10, 2020 at 6:01 AM wrote: >>>> >>>> From

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

On 12/11/2020 2:06 PM, Alexander Potapenko wrote: > On Thu, Dec 10, 2020 at 6:01 AM wrote: >> >> 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

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

On 11/4/2020 3:59 PM, Vijayanand Jitta wrote: > > > On 11/4/2020 4:57 AM, Minchan Kim wrote: >> Sorry if this mail corrupts the mail thread or had heavy mangling >> since I lost this mail from my mailbox so I am sending this mail by >> web gmail. >> >>

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

ot to consume 8MB of static memory. >> Making it configurable and use lower value helps to enable features like >> CONFIG_PAGE_OWNER without any significant overhead. >> >> Signed-off-by: Yogesh Lal >> Signed-off-by: Vinayak Menon >> Signed-off-by: Vijayanand J

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

On 9/30/2020 1:14 PM, vji...@codeaurora.org wrote: > 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

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

On 9/30/2020 1:14 PM, vji...@codeaurora.org wrote: > 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 th

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

On 9/28/2020 6:11 PM, Vijayanand Jitta wrote: > > > On 9/18/2020 8:11 PM, Robin Murphy wrote: >> On 2020-08-20 13:49, vji...@codeaurora.org wrote: >>> From: Vijayanand Jitta >>> >>> When ever an iova alloc request fails we free the iova >

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

On 9/18/2020 7:48 PM, Robin Murphy wrote: > On 2020-08-20 13:49, vji...@codeaurora.org wrote: >> 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 >>

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

On 9/18/2020 8:11 PM, Robin Murphy wrote: > On 2020-08-20 13:49, vji...@codeaurora.org wrote: >> 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 th

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

On 8/28/2020 1:01 PM, Vijayanand Jitta wrote: > > > On 8/20/2020 6:19 PM, vji...@codeaurora.org wrote: >> From: Vijayanand Jitta >> >> When ever a new iova alloc request comes iova is always searched >> from the cached node and the nodes which are pre

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

On 8/20/2020 6:19 PM, vji...@codeaurora.org wrote: > 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 th

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

On 8/12/2020 8:46 PM, Joerg Roedel wrote: > On Mon, Aug 03, 2020 at 03:30:48PM +0530, Vijayanand Jitta wrote: >> ping? > > Please repost when v5.9-rc1 is released and add > > Robin Murphy > > on your Cc list. > > Thanks, > > Joerg >

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

On 7/3/2020 7:47 PM, vji...@codeaurora.org wrote: > 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

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

On 7/3/2020 7:47 PM, vji...@codeaurora.org wrote: > 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 th

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

On 5/11/2020 4:34 PM, vji...@codeaurora.org wrote: > 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 th

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

On 5/9/2020 12:25 AM, Vijayanand Jitta wrote: > > > On 5/7/2020 6:54 PM, Robin Murphy wrote: >> On 2020-05-06 9:01 pm, vji...@codeaurora.org wrote: >>> From: Vijayanand Jitta >>> >>> When ever a new iova alloc request comes iova is always searched &g

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

On 5/7/2020 6:54 PM, Robin Murphy wrote: > On 2020-05-06 9:01 pm, vji...@codeaurora.org wrote: >> 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 >>

Re: [PATCH 1/3] mm: introduce NR_INDIRECTLY_RECLAIMABLE_BYTES

On 4/13/2018 5:43 PM, vinayak menon wrote: > On Thu, Apr 12, 2018 at 8:27 PM, Roman Gushchin wrote: >> On Thu, Apr 12, 2018 at 08:52:52AM +0200, Vlastimil Babka wrote: >>> On 04/11/2018 03:56 PM, Roman Gushchin wrote: On Wed, Apr 11, 2018 at 03:16:08PM +0200, Vlastimil Babka

Re: [PATCH 1/3] mm: introduce NR_INDIRECTLY_RECLAIMABLE_BYTES

On 4/13/2018 5:43 PM, vinayak menon wrote: > On Thu, Apr 12, 2018 at 8:27 PM, Roman Gushchin wrote: >> On Thu, Apr 12, 2018 at 08:52:52AM +0200, Vlastimil Babka wrote: >>> On 04/11/2018 03:56 PM, Roman Gushchin wrote: On Wed, Apr 11, 2018 at 03:16:08PM +0200, Vlastimil Babka wrote: >