allnoconfig gcc-13.2.0
arc allyesconfig gcc-13.2.0
arc defconfig gcc-13.2.0
arc randconfig-001-20240628 gcc-13.2.0
arc randconfig-002-20240628 gcc-13.2.0
arm
Hi Xiang,
On 2024/6/28 15:39, Gao Xiang wrote:
Hi Baokun,
On 2024/6/28 14:29, libao...@huaweicloud.com wrote:
From: Baokun Li
Hi all!
This is the third version of this patch series, in which another
patch set
is subsumed into this one to avoid confusing the two patch sets.
(https://patchw
Hi Baokun,
On 2024/6/28 14:29, libao...@huaweicloud.com wrote:
From: Baokun Li
Hi all!
This is the third version of this patch series, in which another patch set
is subsumed into this one to avoid confusing the two patch sets.
(https://patchwork.kernel.org/project/linux-fsdevel/list/?series=8
On 2024/6/28 14:29, libao...@huaweicloud.com wrote:
From: Baokun Li
In cachefiles_check_volume_xattr(), the error returned by vfs_getxattr()
is not passed to ret, so it ends up returning -ESTALE, which leads to an
endless loop as follows:
cachefiles_acquire_volume
retry:
ret = cachefiles
On 2024/6/28 14:29, libao...@huaweicloud.com wrote:
From: Hou Tao
When queuing ondemand_object_worker() to re-open the object,
cachefiles_object is not pinned. The cachefiles_object may be freed when
the pending read request is completed intentionally and the related
erofs is umounted. If on
On 2024/6/28 14:29, libao...@huaweicloud.com wrote:
From: Baokun Li
Because after an object is dropped, requests for that object are useless,
cancel them to avoid causing other problems.
This prepares for the later addition of cancel_work_sync(). After the
reopen requests is generated, canc
