[PATCH] mm/vmscan.c: drop all inode/dentry cache from LRU

[PATCH] mm/vmscan.c: drop all inode/dentry cache from LRU

[Sahitya Tummala]

This is important for the scenario where FBE (file based encryption)
is enabled. With FBE, the encryption context needed to en/decrypt a file
will be stored in inode and any inode that is left in the cache after
drop_caches is done will be a problem. For ex, in Android, drop_caches
will be used when switching work profiles.

Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
---
 mm/vmscan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index d96c547..b48926f 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -730,7 +730,7 @@ void drop_slab_node(int nid)
 		do {
 			freed += shrink_slab(GFP_KERNEL, nid, memcg, 0);
 		} while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL);
-	} while (freed > 10);
+	} while (freed != 0);
 }
 
 void drop_slab(void)
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH] mm/vmscan.c: drop all inode/dentry cache from LRU

[Yafang Shao]

On Fri, May 24, 2019 at 4:06 PM Sahitya Tummala <stummala@codeaurora.org> wrote:
>
> This is important for the scenario where FBE (file based encryption)
> is enabled. With FBE, the encryption context needed to en/decrypt a file
> will be stored in inode and any inode that is left in the cache after
> drop_caches is done will be a problem. For ex, in Android, drop_caches
> will be used when switching work profiles.
>
> Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
> ---
>  mm/vmscan.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index d96c547..b48926f 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -730,7 +730,7 @@ void drop_slab_node(int nid)
>                 do {
>                         freed += shrink_slab(GFP_KERNEL, nid, memcg, 0);
>                 } while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL);
> -       } while (freed > 10);
> +       } while (freed != 0);
>  }

Perhaps that is not enough, because the shrink may stop when scan
count is less than SHRINK_BATCH.
Pls. see do_shrink_slab.

What about set shrinker->batch to 1 in this case ?

Thanks
Yafang

Re: [PATCH] mm/vmscan.c: drop all inode/dentry cache from LRU

[Yafang Shao]

On Fri, May 24, 2019 at 4:06 PM Sahitya Tummala <stummala@codeaurora.org> wrote:
>
> This is important for the scenario where FBE (file based encryption)
> is enabled. With FBE, the encryption context needed to en/decrypt a file
> will be stored in inode and any inode that is left in the cache after
> drop_caches is done will be a problem. For ex, in Android, drop_caches
> will be used when switching work profiles.
>
> Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
> ---
>  mm/vmscan.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index d96c547..b48926f 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -730,7 +730,7 @@ void drop_slab_node(int nid)
>                 do {
>                         freed += shrink_slab(GFP_KERNEL, nid, memcg, 0);
>                 } while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL);
> -       } while (freed > 10);
> +       } while (freed != 0);
>  }

Perhaps that is not enough, because the shrink may stop when scan
count is less than SHRINK_BATCH.
Pls. see do_shrink_slab.

What about set shrinker->batch to 1 in this case ?

Thanks
Yafang

Re: [PATCH] mm/vmscan.c: drop all inode/dentry cache from LRU

[Theodore Ts'o]

On Fri, May 24, 2019 at 01:36:01PM +0530, Sahitya Tummala wrote:
> This is important for the scenario where FBE (file based encryption)
> is enabled. With FBE, the encryption context needed to en/decrypt a file
> will be stored in inode and any inode that is left in the cache after
> drop_caches is done will be a problem. For ex, in Android, drop_caches
> will be used when switching work profiles.
> 
> Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>

Instead of making a change to vmscan.c, it's probably better to
migrate to the new fscrypt key-management framework, which solves this
problem with an explicit FS_IOC_REMOVE_ENCRYPTION_KEY ioctl.  This
allows the system to remove all inodes that were made available via a
single key without having nuking all other inodes --- this would make
it much faster after a user logs out of ChromeOS, for example:

See:

	https://patchwork.kernel.org/patch/10952019/

							- Ted