DLPX-83701 Make the kernel function mnt_add_count() traceable #16

don-brady · 2022-12-07T22:32:09Z

Background

Some of the kernel functions in the unmount path are not traceable which makes it harder to debug busy unmounts.

Problem

To help with diagnosing busy unmounts we should allow tracing of mnt_add_count() and do_umount() in bpftrace probes.

Solution

Augment these functions with noinline and __noclone (disables the "-fipa-sra" compilation optimization to keep the compiler from optimizing the function signatures).

Testing Done

Confirm these function symbols are traceable:

delphix@ip-10-110-220-172:~$ sudo bpftrace -l '*mnt_add_count'
kprobe:mnt_add_count
delphix@ip-10-110-220-172:~$ sudo bpftrace -l '*do_umount'
kprobe:do_umount

Also used them with a bpftrace script that watches mnt_add_count calls that decrement the mount reference after a busy unmount occurred.

…g the sock BugLink: https://bugs.launchpad.net/bugs/2003914 [ Upstream commit 3cf7203 ] There is a race condition in vxlan that when deleting a vxlan device during receiving packets, there is a possibility that the sock is released after getting vxlan_sock vs from sk_user_data. Then in later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got NULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3 Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh Fix this by waiting for all sk_user_data reader to finish before releasing the sock. Reported-by: Jianlin Shi <jishi@redhat.com> Suggested-by: Jakub Sitnicki <jakub@cloudflare.com> Fixes: 6a93cc9 ("udp-tunnel: Add a few more UDP tunnel APIs") Signed-off-by: Hangbin Liu <liuhangbin@gmail.com> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2023230 [ Upstream commit 4e264be ] When a system with E810 with existing VFs gets rebooted the following hang may be observed. Pid 1 is hung in iavf_remove(), part of a network driver: PID: 1 TASK: ffff965400e5a340 CPU: 24 COMMAND: "systemd-shutdow" #0 [ffffaad04005fa50] __schedule at ffffffff8b3239cb #1 [ffffaad04005fae8] schedule at ffffffff8b323e2d #2 [ffffaad04005fb00] schedule_hrtimeout_range_clock at ffffffff8b32cebc #3 [ffffaad04005fb80] usleep_range_state at ffffffff8b32c930 #4 [ffffaad04005fbb0] iavf_remove at ffffffffc12b9b4c [iavf] #5 [ffffaad04005fbf0] pci_device_remove at ffffffff8add7513 #6 [ffffaad04005fc10] device_release_driver_internal at ffffffff8af08baa #7 [ffffaad04005fc40] pci_stop_bus_device at ffffffff8adcc5fc #8 [ffffaad04005fc60] pci_stop_and_remove_bus_device at ffffffff8adcc81e #9 [ffffaad04005fc70] pci_iov_remove_virtfn at ffffffff8adf9429 #10 [ffffaad04005fca8] sriov_disable at ffffffff8adf98e4 #11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice] #12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe [ice] #13 [ffffaad04005fd38] ice_shutdown at ffffffffc0477946 [ice] #14 [ffffaad04005fd50] pci_device_shutdown at ffffffff8add58f1 #15 [ffffaad04005fd70] device_shutdown at ffffffff8af05386 #16 [ffffaad04005fd98] kernel_restart at ffffffff8a92a870 #17 [ffffaad04005fda8] __do_sys_reboot at ffffffff8a92abd6 #18 [ffffaad04005fee0] do_syscall_64 at ffffffff8b317159 #19 [ffffaad04005ff08] __context_tracking_enter at ffffffff8b31b6fc #20 [ffffaad04005ff18] syscall_exit_to_user_mode at ffffffff8b31b50d #21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169 #22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe at ffffffff8b40009b RIP: 00007f1baa5c13d7 RSP: 00007fffbcc55a98 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1baa5c13d7 RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead RBP: 00007fffbcc55ca0 R8: 0000000000000000 R9: 00007fffbcc54e90 R10: 00007fffbcc55050 R11: 0000000000000202 R12: 0000000000000005 R13: 0000000000000000 R14: 00007fffbcc55af0 R15: 0000000000000000 ORIG_RAX: 00000000000000a9 CS: 0033 SS: 002b During reboot all drivers PM shutdown callbacks are invoked. In iavf_shutdown() the adapter state is changed to __IAVF_REMOVE. In ice_shutdown() the call chain above is executed, which at some point calls iavf_remove(). However iavf_remove() expects the VF to be in one of the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If that's not the case it sleeps forever. So if iavf_shutdown() gets invoked before iavf_remove() the system will hang indefinitely because the adapter is already in state __IAVF_REMOVE. Fix this by returning from iavf_remove() if the state is __IAVF_REMOVE, as we already went through iavf_shutdown(). Fixes: 9745780 ("iavf: Add waiting so the port is initialized in remove") Fixes: a841733 ("iavf: Fix race condition between iavf_shutdown and iavf_remove") Reported-by: Marius Cornea <mcornea@redhat.com> Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Luke Nowakowski-Krijger <luke.nowakowskikrijger@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2076435 commit be346c1a6eeb49d8fda827d2a9522124c2f72f36 upstream. The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents. Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem. To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written(). Heming Zhao said: ------ PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error" PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2] #11 dio_complete at ffffffff8c2b9fa7 #12 do_blockdev_direct_IO at ffffffff8c2bc09f #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write at ffffffff8c1dcf14 #15 __generic_file_write_iter at ffffffff8c1dd07b #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2] #17 aio_write at ffffffff8c2cc72e #18 kmem_cache_alloc at ffffffff8c248dde #19 do_io_submit at ffffffff8c2ccada #20 do_syscall_64 at ffffffff8c004984 #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba Link: https://lkml.kernel.org/r/20240617095543.6971-1-jack@suse.cz Link: https://lkml.kernel.org/r/20240614145243.8837-1-jack@suse.cz Fixes: c15471f ("ocfs2: fix sparse file & data ordering issue in direct io") Signed-off-by: Jan Kara <jack@suse.cz> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Reviewed-by: Heming Zhao <heming.zhao@suse.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Portia Stephens <portia.stephens@canonical.com> Signed-off-by: Roxana Nicolescu <roxana.nicolescu@canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2097575 commit d0e806b0cc6260b59c65e606034a63145169c04c upstream. During the migration of Soundwire runtime stream allocation from the Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845 soundcard was forgotten. At this point any playback attempt or audio daemon startup, for instance on sdm845-db845c (Qualcomm RB3 board), will result in stream pointer NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000 [0000000000000020] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP Modules linked in: ... CPU: 5 UID: 0 PID: 1198 Comm: aplay Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty #18 Hardware name: Thundercomm Dragonboard 845c (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus] lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus] sp : ffff80008a2035c0 x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000 x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800 x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003 x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000 x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003 x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8 Call trace: sdw_stream_add_slave+0x44/0x380 [soundwire_bus] wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x] snd_soc_dai_hw_params+0x3c/0xa4 __soc_pcm_hw_params+0x230/0x660 dpcm_be_dai_hw_params+0x1d0/0x3f8 dpcm_fe_dai_hw_params+0x98/0x268 snd_pcm_hw_params+0x124/0x460 snd_pcm_common_ioctl+0x998/0x16e8 snd_pcm_ioctl+0x34/0x58 __arm64_sys_ioctl+0xac/0xf8 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xe0 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x190/0x194 Code: aa0403fb f9418400 9100e000 9400102f (f8420f22) ---[ end trace 0000000000000000 ]--- 0000000000006108 <sdw_stream_add_slave>: 6108: d503233f paciasp 610c: a9b97bfd stp x29, x30, [sp, #-112]! 6110: 910003fd mov x29, sp 6114: a90153f3 stp x19, x20, [sp, #16] 6118: a9025bf5 stp x21, x22, [sp, #32] 611c: aa0103f6 mov x22, x1 6120: 2a0303f5 mov w21, w3 6124: a90363f7 stp x23, x24, [sp, #48] 6128: aa0003f8 mov x24, x0 612c: aa0203f7 mov x23, x2 6130: a9046bf9 stp x25, x26, [sp, #64] 6134: aa0403f9 mov x25, x4 <-- x4 copied to x25 6138: a90573fb stp x27, x28, [sp, #80] 613c: aa0403fb mov x27, x4 6140: f9418400 ldr x0, [x0, #776] 6144: 9100e000 add x0, x0, #0x38 6148: 94000000 bl 0 <mutex_lock> 614c: f8420f22 ldr x2, [x25, #32]! <-- offset 0x44 ^^^ This is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave() where data abort happens. wsa881x_hw_params() is called with stream = NULL and passes it further in register x4 (5th argument) to sdw_stream_add_slave() without any checks. Value from x4 is copied to x25 and finally it aborts on trying to load a value from address in x25 plus offset 32 (in dec) which corresponds to master_list member in struct sdw_stream_runtime: struct sdw_stream_runtime { const char * name; /* 0 8 */ struct sdw_stream_params params; /* 8 12 */ enum sdw_stream_state state; /* 20 4 */ enum sdw_stream_type type; /* 24 4 */ /* XXX 4 bytes hole, try to pack */ here-> struct list_head master_list; /* 32 16 */ int m_rt_count; /* 48 4 */ /* size: 56, cachelines: 1, members: 6 */ /* sum members: 48, holes: 1, sum holes: 4 */ /* padding: 4 */ /* last cacheline: 56 bytes */ Fix this by adding required calls to qcom_snd_sdw_startup() and sdw_release_stream() to startup and shutdown routines which restores the previous correct behaviour when ->set_stream() method is called to set a valid stream runtime pointer on playback startup. Reproduced and then fix was tested on db845c RB3 board. Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: stable@vger.kernel.org Fixes: 15c7fab ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> # Lenovo Yoga C630 Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://patch.msgid.link/20241009213922.999355-1-alexey.klimov@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Manuel Diewald <manuel.diewald@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>

DLPX-83701 Make function mnt_add_count() traceable

f7c70d3

pcd1193182 approved these changes Dec 7, 2022

View reviewed changes

tonynguien approved these changes Dec 9, 2022

View reviewed changes

don-brady merged commit 6cff5d4 into delphix:6.0/stage Dec 9, 2022

don-brady deleted the dlpx-83701-generic branch December 9, 2022 23:21

delphix-devops-bot pushed a commit that referenced this pull request Dec 15, 2022

DLPX-83701 Make function mnt_add_count() traceable (#16)

c10e315

delphix-devops-bot pushed a commit that referenced this pull request Jan 7, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

56d0f67

delphix-devops-bot pushed a commit that referenced this pull request Jan 16, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

8c02c75

delphix-devops-bot pushed a commit that referenced this pull request Feb 15, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

14e479d

delphix-devops-bot pushed a commit that referenced this pull request Mar 4, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

899acde

prakashsurya pushed a commit that referenced this pull request Mar 14, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

ef7be3b

prakashsurya pushed a commit that referenced this pull request Mar 14, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

d6d66c2

delphix-devops-bot pushed a commit that referenced this pull request Mar 30, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

830a275

delphix-devops-bot pushed a commit that referenced this pull request Apr 20, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

ffa7443

delphix-devops-bot pushed a commit that referenced this pull request Apr 20, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

ce6f336

delphix-devops-bot pushed a commit that referenced this pull request Apr 28, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

423715f

delphix-devops-bot pushed a commit that referenced this pull request May 26, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

a2060b9

delphix-devops-bot pushed a commit that referenced this pull request Jun 3, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

3f9d1b2

delphix-devops-bot pushed a commit that referenced this pull request Jun 4, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

e0df5e9

delphix-devops-bot pushed a commit that referenced this pull request Jun 5, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

d1e2c6d

prakashsurya pushed a commit that referenced this pull request Aug 8, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

590e30b

delphix-devops-bot pushed a commit that referenced this pull request Aug 24, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

54f9cbf

delphix-devops-bot pushed a commit that referenced this pull request Aug 25, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

474036d

delphix-devops-bot pushed a commit that referenced this pull request Aug 26, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

98e9f37

delphix-devops-bot pushed a commit that referenced this pull request Aug 27, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

5f0c1e4

delphix-devops-bot pushed a commit that referenced this pull request Aug 28, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

100eb01

delphix-devops-bot pushed a commit that referenced this pull request Aug 30, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

8c8bb47

delphix-devops-bot pushed a commit that referenced this pull request Aug 31, 2023

DLPX-83701 Make function mnt_add_count() traceable (#16)

c18154b

delphix-devops-bot pushed a commit that referenced this pull request Dec 27, 2024

DLPX-83701 Make function mnt_add_count() traceable (#16)

268fed8

delphix-devops-bot pushed a commit that referenced this pull request Dec 28, 2024

DLPX-83701 Make function mnt_add_count() traceable (#16)

060bf00

delphix-devops-bot pushed a commit that referenced this pull request Dec 29, 2024

DLPX-83701 Make function mnt_add_count() traceable (#16)

9cfcb80

delphix-devops-bot pushed a commit that referenced this pull request Dec 30, 2024

DLPX-83701 Make function mnt_add_count() traceable (#16)

53e1495

delphix-devops-bot pushed a commit that referenced this pull request Dec 31, 2024

DLPX-83701 Make function mnt_add_count() traceable (#16)

ff67992

delphix-devops-bot pushed a commit that referenced this pull request Jan 1, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

e30e521

delphix-devops-bot pushed a commit that referenced this pull request Jan 2, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

35157c8

delphix-devops-bot pushed a commit that referenced this pull request Jan 3, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

c1d56c9

delphix-devops-bot pushed a commit that referenced this pull request Jan 4, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

685d76b

delphix-devops-bot pushed a commit that referenced this pull request Jan 5, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

666cdeb

delphix-devops-bot pushed a commit that referenced this pull request Jan 6, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

3000967

delphix-devops-bot pushed a commit that referenced this pull request Jan 7, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

c2a2586

delphix-devops-bot pushed a commit that referenced this pull request Jan 30, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

d3856d6

delphix-devops-bot pushed a commit that referenced this pull request Jan 31, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

05465a4

sebroy pushed a commit that referenced this pull request Apr 23, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

47bdb64

delphix-devops-bot pushed a commit that referenced this pull request May 8, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

2eec3e4

delphix-devops-bot pushed a commit that referenced this pull request May 9, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

9af0434

delphix-devops-bot pushed a commit that referenced this pull request May 10, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

e6109cd

delphix-devops-bot pushed a commit that referenced this pull request May 11, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

a025001

delphix-devops-bot pushed a commit that referenced this pull request May 12, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

4ccd0cd

delphix-devops-bot pushed a commit that referenced this pull request May 13, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

5dcd7f7

delphix-devops-bot pushed a commit that referenced this pull request May 14, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

a7c4a77

delphix-devops-bot pushed a commit that referenced this pull request May 15, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

5cbdeec

delphix-devops-bot pushed a commit that referenced this pull request May 17, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

0b345b9

delphix-devops-bot pushed a commit that referenced this pull request May 18, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

ba97da2

delphix-devops-bot pushed a commit that referenced this pull request May 19, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

1f8add1

delphix-devops-bot pushed a commit that referenced this pull request May 20, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

26ac844

delphix-devops-bot pushed a commit that referenced this pull request Jun 21, 2025

DLPX-83701 Make function mnt_add_count() traceable (#16)

5f945fd

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

DLPX-83701 Make the kernel function mnt_add_count() traceable #16

DLPX-83701 Make the kernel function mnt_add_count() traceable #16

Uh oh!

don-brady commented Dec 7, 2022

Uh oh!

Uh oh!

DLPX-83701 Make the kernel function mnt_add_count() traceable #16

DLPX-83701 Make the kernel function mnt_add_count() traceable #16

Uh oh!

Conversation

don-brady commented Dec 7, 2022

Background

Problem

Solution

Testing Done

Uh oh!

Uh oh!