> > > > Ok that's bad - so you hit the WARN_ON there? How that? We should fix > > that too? > > > Yes, hit this WARN_ON in the test of direct connection between mobile > phones and PC. Here is the log: > [ 2741.982362] -----------[ cut here ]----------- > [ 2741.982446] WARNING: CPU: 6 PID: 2175 at net/wireless/scan.c:1496 cfg80211_update_assoc_bss_entry+0x350/0x378 [cfg80211] Right, so you can reproduce that - can you find a fix for it? > I don't know why this is happening yet. OK ... We have some basic kunit infrastructure, maybe you can work out something there. > > > this bss->rbn will continue to hold > > > expired data, such as __rd_parent_color. > > > > Does that matter in any way? > > > It caused a null pointer issue in rb_erase: Well, OK, so the thing isn't about it holding a color or 'expired' data or whatever, it's about it being still on the rbtree, no? > > > And this bss still in rdev->bss_list, maybe double erase in > > > __cfg80211_bss_expire later. > > > Double erase a rbtree node(with expired parent and color data) maybe > > > corrupt rbtree, so add a in_rbtree flag to fix this issue. > > > > This seems overly complex - couldn't we just remove it from the list too > > or something? It's already a case that "should never happen" so ... not > > sure we need to do something "good"? > > > Will remove it from list when re-insert fail cause confusion in it's > refcount? Which could lead to leakage or use-after-free? > > It's a warn-on anyway, better we leak it than crash? johannes
