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@xxxxxxxxx> 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.
