aboutsummaryrefslogtreecommitdiff
path: root/lib/mpi/mpi-internal.h
diff options
context:
space:
mode:
authorMukesh Ojha <[email protected]>2022-09-13 18:20:24 +0530
committerGreg Kroah-Hartman <[email protected]>2022-09-24 14:01:40 +0200
commit01daccf748323dfc61112f474cf2ba81015446b0 (patch)
tree5ea44971a79f19e65441394df406efa1a72f3520 /lib/mpi/mpi-internal.h
parentb8de524ce46ef59889600bc29019c5ed4ccd6687 (diff)
devcoredump : Serialize devcd_del work
In following scenario(diagram), when one thread X running dev_coredumpm() adds devcd device to the framework which sends uevent notification to userspace and another thread Y reads this uevent and call to devcd_data_write() which eventually try to delete the queued timer that is not initialized/queued yet. So, debug object reports some warning and in the meantime, timer is initialized and queued from X path. and from Y path, it gets reinitialized again and timer->entry.pprev=NULL and try_to_grab_pending() stucks. To fix this, introduce mutex and a boolean flag to serialize the behaviour. cpu0(X) cpu1(Y) dev_coredump() uevent sent to user space device_add() ======================> user space process Y reads the uevents writes to devcd fd which results into writes to devcd_data_write() mod_delayed_work() try_to_grab_pending() del_timer() debug_assert_init() INIT_DELAYED_WORK() schedule_delayed_work() debug_object_fixup() timer_fixup_assert_init() timer_setup() do_init_timer() /* Above call reinitializes the timer to timer->entry.pprev=NULL and this will be checked later in timer_pending() call. */ timer_pending() !hlist_unhashed_lockless(&timer->entry) !h->pprev /* del_timer() checks h->pprev and finds it to be NULL due to which try_to_grab_pending() stucks. */ Link: https://lore.kernel.org/lkml/[email protected]/ Signed-off-by: Mukesh Ojha <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Diffstat (limited to 'lib/mpi/mpi-internal.h')
0 files changed, 0 insertions, 0 deletions