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
