From: Sven Eckelmann <sven@narfation.org>
To: Marek Lindner <mareklindner@neomailbox.ch>,
Vladislav Efanov <VEfanov@ispras.ru>
Cc: Vladislav Efanov <VEfanov@ispras.ru>,
Antonio Quartulli <a@unstable.cc>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
b.a.t.m.a.n@lists.open-mesh.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org
Subject: Re: [PATCH] batman-adv: Broken sync while rescheduling delayed work
Date: Fri, 26 May 2023 18:49:21 +0200 [thread overview]
Message-ID: <5834562.MhkbZ0Pkbq@bentobox> (raw)
In-Reply-To: <20230526161632.1460753-1-VEfanov@ispras.ru>
[-- Attachment #1: Type: text/plain, Size: 877 bytes --]
On Friday, 26 May 2023 18:16:32 CEST Vladislav Efanov wrote:
> The reason for these issues is the lack of synchronization. Delayed
> work (batadv_dat_purge) schedules new timer/work while the device
> is being deleted. As the result new timer/delayed work is set after
> cancel_delayed_work_sync() was called. So after the device is freed
> the timer list contains pointer to already freed memory.
You are most likely right but could you please point out what in the worker is
checked by the workqueue code that prevents it from being scheduled again?
(and which seems to be overwritten as your patch seems to suggest)
I think __cancel_work_timer marked the work as canceling but
batadv_dat_start_timer reinitialized the worked (thus removing this important
state). Would be nice if you could either correct me or confirm what I think to
remember.
Kind regards,
Sven
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-05-26 16:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-26 16:16 [PATCH] batman-adv: Broken sync while rescheduling delayed work Vladislav Efanov
2023-05-26 16:49 ` Sven Eckelmann [this message]
2023-05-26 17:35 ` Vlad Efanov
2023-05-26 20:30 ` Sven Eckelmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5834562.MhkbZ0Pkbq@bentobox \
--to=sven@narfation.org \
--cc=VEfanov@ispras.ru \
--cc=a@unstable.cc \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lvc-project@linuxtesting.org \
--cc=mareklindner@neomailbox.ch \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).