Re: [PATCH 4/8] cachefiles: Clear invalid cache data in advance

From: David Howells
Date: Thu Oct 10 2024 - 07:17:08 EST


Zizhi Wo <wozizhi@xxxxxxxxxx> wrote:

> In the current on-demand loading scenario, when umount is called, the
> cachefiles_commit_tmpfile() is invoked. When checking the inode
> corresponding to object->file is inconsistent with the dentry,
> cachefiles_unlink() is called to perform cleanup to prevent invalid data
> from occupying space.
>
> The above operation does not apply to the first mount, because the cache
> dentry generated by the first mount must be negative. Moreover, there is no
> need to clear it during the first umount because this part of the data may
> be reusable in the future. But the problem is that, the clean operation can
> currently only be called through cachefiles_withdraw_cookie(), in other
> words the redundant data does not cleaned until the second umount. This
> means that during the second mount, the old cache data generated from the
> first mount still occupies space. So if the user does not manually clean up
> the previous cache before the next mount, it may return insufficient space
> during the second mount phase.
>
> This patch adds an additional cleanup process in the cachefiles_open_file()
> function. When the auxdata check fails, the remaining old cache data is no
> longer needed, the file and dentry corresponding to the object are also
> put. As there is no need to clear it until umount, we can directly clear it
> during the mount process.
>
> Signed-off-by: Zizhi Wo <wozizhi@xxxxxxxxxx>

Okay, I think this is reasonable as it's done from a worker thread. I wonder
if instead, though, cachefiles_create_file() should be called and then linked
over the top:

https://lore.kernel.org/all/cover.1580251857.git.osandov@xxxxxx/

though AT_LINK_REPLACE seemed to get stuck.

Note that we can't just truncate the file to nothing instead because I/O might
be in progress on it.

David