of-dev/v1.7.1

Kkubevirt-botvirt-handler: Fix Potenial panic

8bcab0e3创建于 2025年11月3日历史提交

文件	最后提交记录	最后更新时间
BUILD.bazel	hack: Run bazel-race Signed-off-by: Lee Yarwood <lyarwood@redhat.com>	8 个月前
cache.go	Clean socket paths Safepath is not handling "//". As we had used this pattern of path before we need to clean all saved paths. Signed-off-by: Luboslav Pivarc <lpivarc@redhat.com>	10 个月前
cache_suite_test.go	Add license header linter for virt-handler under pkg/ Signed-off-by: avlitman <alitman@redhat.com>	9 个月前
cache_test.go	virt-handler: domain watcher to trust sockets from ghost record only Signed-off-by: Igor Bezukh <ibezukh@redhat.com>	10 个月前
domain-watcher.go	virt-handler: domain watcher to trust sockets from ghost record only Signed-off-by: Igor Bezukh <ibezukh@redhat.com>	10 个月前
domain-watcher_test.go	virt-handler: domain watcher to trust sockets from ghost record only Signed-off-by: Igor Bezukh <ibezukh@redhat.com>	10 个月前
maps.go	virt-handler: Fix Potenial panic Race condition: CloseLauncherClient can be called from multiple places simultaneously during VMI cleanup: 1. migration-target.go:404 - deferred in finalCleanup() 2. migration-target.go:508 - when VMI becomes final during execute() 3. vm.go:1530 - from main VM controller processVmCleanup Since those happen in different go routines, and the code is not thread safe, a panic occurs. VirtualMachineController.processVmCleanup finished, and closed the channel DomainPipeStopChan. {"component":"virt-handler","controller":"vm","kind":"Domain","level":"info","msg":"Removing domain from cache during final cleanup","name":"testvmi-8z88p","namespace":"kubevirt-test-alternative3","pos":"vm.go:1537","timestamp":"2025-10-30T18:42:46.822834Z","uid":""} MigrationTargetController.execute() seeing VMI in final state and calls CloseLauncherClient again E1030 18:42:46.823075 8385 chan.go:422] "Observed a panic" panic="close of closed channel" panicGoValue="\"close of closed channel\"" stacktrace=< goroutine 326 [running]: kubevirt.io/kubevirt/vendor/k8s.io/apimachinery/pkg/util/runtime.logPanic({0x2c53810, 0xc003f1d8f0}, {0x240dd60, 0x2c1a240}) vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:132 +0xbc kubevirt.io/kubevirt/vendor/k8s.io/apimachinery/pkg/util/runtime.handleCrash({0x2c53cf8, 0xc00039e540}, {0x240dd60, 0x2c1a240}, {0x0, 0x0, 0xc002407730?}) vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:107 +0x116 kubevirt.io/kubevirt/vendor/k8s.io/apimachinery/pkg/util/runtime.HandleCrashWithContext({0x2c53cf8, 0xc00039e540}, {0x0, 0x0, 0x0}) vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:78 +0x5a panic({0x240dd60?, 0x2c1a240?}) GOROOT/src/runtime/panic.go:792 +0x132 kubevirt.io/kubevirt/pkg/virt-handler/launcher-clients.(*launcherClientsManager).CloseLauncherClient(0xc00028a640, 0xc0046ff208) pkg/virt-handler/launcher-clients/launcher-clients.go:143 +0x69 kubevirt.io/kubevirt/pkg/virt-handler.(*MigrationTargetController).execute(0xc0002a0460, {0xc004b8d7a0, 0x28}) pkg/virt-handler/migration-target.go:508 +0x28e Fix it by making sure CloseLauncherClient is thread safe (by protecting it with sync.Once) https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/15983/pull-kubevirt-e2e-k8s-1.34-sig-compute-migrations/1983892566344470528 Assisted-by: Cursor Signed-off-by: Or Shoval <oshoval@redhat.com>	7 个月前