lkml.org 
[lkml]   [2022]   [Apr]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectPossible race in dev_coredumpm()-del_timer() path
Hi All,

We are hitting one race due to which try_to_grab_pending() is stuck .
In following scenario, while running (p1)dev_coredumpm() devcd device is
added to
the framework and uevent notification sent to userspace that result in
the call to (p2) devcd_data_write()
which eventually try to delete the queued timer which in the racy
scenario timer is not queued yet.
So, debug object report some warning and in the meantime timer is
initialized and queued from p1 path.
and from p2 path it gets overriden again timer->entry.pprev=NULL and
try_to_grab_pending() stuck
as del_timer() always return 0 as timer_pending() return false.

P1 P2(X)


     dev_coredumpm()

                                          Uevent notification sent to
userspace
                                          for device addition

            device_add() ========================>                
Process X reads this uevents
notification and do write call
that results in call to

devcd_data_write()
mod_delayed_work()
try_to_grab_pending()
del_timer()
debug_assert_init()

            INIT_DELAYED_WORK
                   (&devcd->del_wk, devcd_del);
            schedule_delayed_work(&devcd->del_wk,
                   DEVCD_TIMEOUT);

debug_object_fixup()
timer_fixup_assert_init()
timer_setup()
do_init_timer()   ==> reinitialized the timer to timer->entry.pprev=NULL

timer_pending()
!hlist_unhashed_lockless(&timer->entry)
!h->pprev



Thanks.
Mukesh

\
 
 \ /
  Last update: 2022-04-13 08:14    [W:0.158 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site