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.
