fix(usbgadget): add lock for logWithSupression

[ym]

#651

[Copilot]

Pull Request Overview

This PR introduces a mutex to protect the logSuppressionCounter map in UsbGadget, ensuring thread-safe updates.

• Added a sync.Mutex field (logSuppressionLock) to the UsbGadget struct.
• Wrapped logWithSupression and resetLogSuppressionCounter in lock/unlock calls.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
internal/usbgadget/utils.go	Wrapped counter access in logWithSupression and resetLogSuppressionCounter with a mutex
internal/usbgadget/usbgadget.go	Added logSuppressionLock sync.Mutex to UsbGadget

Comments suppressed due to low confidence (1)

internal/usbgadget/utils.go:84

• There are no tests covering concurrent use of logWithSupression and resetLogSuppressionCounter. Please add test cases that simulate concurrent calls to verify thread-safety and correct suppression behavior.

func (u *UsbGadget) logWithSupression(counterName string, every int, logger *zerolog.Logger, err error, msg string, args ...interface{}) {

[Copilot]

In resetLogSuppressionCounter, you only set the counter to zero when the key is missing. To truly reset the counter, assign u.logSuppressionCounter[counterName] = 0 unconditionally (remove the if check).

Suggested change

	if _, ok := u.logSuppressionCounter[counterName]; !ok {
	u.logSuppressionCounter[counterName] = 0
	}
	u.logSuppressionCounter[counterName] = 0

[Copilot]

[nitpick] The mutex is held for the entire logWithSupression call, including the actual logging I/O. Consider narrowing the lock scope to just the map reads/writes before releasing it, so you don't block other goroutines during logging.

Suggested change

	u.logSuppressionLock.Lock()
	defer u.logSuppressionLock.Unlock()
	var counter int
	u.logSuppressionLock.Lock()