On Thu, 13. Jun 16:41, Baoquan He wrote:
On 06/12/24 at 01:27pm, Uladzislau Rezki wrote:
On Wed, Jun 12, 2024 at 10:00:14AM +0800, Zhaoyang Huang wrote:
On Wed, Jun 12, 2024 at 2:16 AM Uladzislau Rezki urezki@gmail.com wrote:
Sorry to bother you again. Are there any other comments or new patch on this which block some test cases of ANDROID that only accept ACKed one on its tree.
I have just returned from vacation. Give me some time to review your patch. Meanwhile, do you have a reproducer? So i would like to see how i can trigger an issue that is in question.
This bug arises from an system wide android test which has been reported by many vendors. Keep mount/unmount an erofs partition is supposed to be a simple reproducer. IMO, the logic defect is obvious enough to be found by code review.
Baoquan, any objection about this v4?
Your proposal about inserting a new vmap-block based on it belongs to, i.e. not per-this-cpu, should fix an issue. The problem is that such way does __not__ pre-load a current CPU what is not good.
With my understand, when we start handling to insert vb to vbq->xa and vbq->free, the vmap_area allocation has been done, it doesn't impact the CPU preloading when adding it into which CPU's vbq->free, does it?
Not sure if I miss anything about the CPU preloading.
IIUC, if vb put by hashing funcation. and the following scenario may occur:
A kthread limit on CPU_x and continuously calls vm_map_ram() The 1 call vm_map_ram(): no vb in cpu_x->free, so CPU_0->vb CPU_1 ... CPU_x
The 2 call vm_map_ram(): no vb in cpu_x->free, so CPU_0->vb CPU_1->vb ... CPU_x
-- help you, help me, Hailong.