memleak tool misjudge memory leak because of the hardware interrupt

Hi all,

We use memleak tool, and find out some problems in the hardware interrupt environment.

Command
```
memleak --combined-only -z 64 -Z 64
```
And it said there are memory leaks in the USB driver
```
640 bytes in 10 allocations from stack
--
__kmalloc+0x178 [kernel]
__kmalloc+0x178 [kernel]
xhci_urb_enqueue+0x140 [kernel]
usb_hcd_submit_urb+0x5e0 [kernel]
usb_submit_urb+0x3e4 [kernel]
usb_start_wait_urb+0x54 [kernel]
usb_control_msg+0xb4 [kernel]
```
But we find out it's misjudged by memleak tool after our debugging.
Debug patch
```
diff --git a/tools/memleak.py b/tools/memleak.py
index 5399019..1aa45fd 100755
--- a/tools/memleak.py
+++ b/tools/memleak.py
@@ -226,6 +226,8 @@ static inline int gen_alloc_exit(struct pt_regs *ctx) {
static inline int gen_free_enter(struct pt_regs *ctx, void *address) {
u64 addr = (u64)address;
struct alloc_info_t *info = allocs.lookup(&addr);
+
+ bpf_trace_printk("Edward:free address:%x\\n", address);
if (info == 0)
return 0;
```
**Leak part:**
Allocate memory e2379a00
```
RTW_CMD_THREAD-1984 [000] .... 681.302707: kmalloc: call_site=c0779cdc ptr=e2379a00 bytes_req=40 bytes_alloc=64 gfp_flags=GFP_NOIO|__GFP_ZERO
```
Free memory e2379a00
```
HTTPREQUEST_MAN-9090 [002] ...2 681.302707: tracing_mark_write: Edward:free address:e94ff480
HTTPREQUEST_MAN-9090 [002] ...2 681.302714: tracing_mark_write: Edward:free address:e956a600
HTTPREQUEST_MAN-9090 [002] ...2 681.302721: tracing_mark_write: Edward:free address:ecac50c0
HTTPREQUEST_MAN-9090 [002] ...2 681.302727: tracing_mark_write: Edward:free address:edb9b6c0
HTTPREQUEST_MAN-9090 [002] d.h6 681.302727: xhci_urb_free_priv <-xhci_irq
HTTPREQUEST_MAN-9090 [002] d.h5 681.302727: xhci_urb_free_priv: Edward:xhci_urb_free_priv:1906 free priv
HTTPREQUEST_MAN-9090 [002] d.h5 681.302727: kfree: call_site=c077da78 ptr=e2379a00
HTTPREQUEST_MAN-9090 [002] d.h5 681.302727: kfree: call_site=c077da80 ptr=e29f6f40
```
You can see there is no any "tracing_mark_write" after kfree event, it doesn't call the attached function gen_free_enter.
Because at 681.302727 timestamps, gen_free_enter is not finished but interrupted by xhci_irq.
Therefore kfree event during xhci_irq which won't call gen_free_enter().

It causes the incorrect result.

Please tell me if I have any misunderstanding.

Thanks!

Start in tools/memleak.py, focusing on gen_free_enter and the interaction shown between kfree and xhci_irq. Reproduce with memleak --combined-only -z 64 -Z 64 and inspect whether frees occurring during the interrupt are tracked. Done means the USB allocation is not reported as leaked when the corresponding kfree event occurs.

Written by the indexing model from the issue text.