On Sun, Apr 25, 2021 at 6:02 AM Jeffrey Walton wrote:
>
> On Sun, Apr 25, 2021 at 7:09 AM John Wood wrote:
> >
> > I'm working in a LSM to detect and mitigate fork brute force attacks
> > against vulnerable userspace applications. Now, to fine tuning the
> > detection I want to detect a network
I think there can be a situation like:
processA: processB:
0ns: if (!exiting)
1ns:exiting = 1;
2ns:del_timer
3ns: mod_timer
so spinlock seems better for this.
On Tue, May 04, 2021 at 12:35:06PM -0400, Valdis Klētnieks wrote:
> On Tue, 04 May 2021 12:17:56 -0400, "Valdis KlD tnieks" said:
>
> > void __exit timer_exit(void) {
> > exiting = 1;
>
> -ENOCAFFEINE
>
> That still needs a few memory barriers. See Documentation/memory_barriers.txt
>
okay, there can be optimization when reading exiting variable.
then is memory barrier is enough as Valdis Klētnieks said,
or spinlock is better choice?
2021년 5월 5일 (수) 오전 1:36, Hyeonggon Yoo <42.hye...@gmail.com>님이 작성:
>
> Valdis Klētnieks, Thank you for your kind explanation.
>
>
> Okay, so
Valdis Klētnieks, Thank you for your kind explanation.
Okay, so 'timer is running' means it is not expired yet.
and when timer is expired (as specified in 'expires' field),
the timer_callback is called.
and there can be race condition in running timer_callback.
so locking is needed before
On Tue, 04 May 2021 12:17:56 -0400, "Valdis KlD tnieks" said:
> void __exit timer_exit(void) {
> exiting = 1;
-ENOCAFFEINE
That still needs a few memory barriers. See Documentation/memory_barriers.txt
for the gory details.
pgp_TgzDbFoJ9.pgp
Description: PGP signature
On Tue, May 04, 2021 at 12:17:56PM -0400, Valdis Klētnieks wrote:
> On Tue, 04 May 2021 23:59:12 +0900, Hyeonggon Yoo said:
> > Does del_timer work well for timers that re-registers itself?
> > what if the timer is currently running, and del_timer is called,
> > and the running timer re-registers
On Tue, 04 May 2021 23:59:12 +0900, Hyeonggon Yoo said:
> Does del_timer work well for timers that re-registers itself?
> what if the timer is currently running, and del_timer is called,
> and the running timer re-registers itself?
Minor nit: while the timer is running, there's no problem.
When
Does del_timer work well for timers that re-registers itself?
what if the timer is currently running, and del_timer is called,
and the running timer re-registers itself?
how should I handle it?
Below is my simple kernel timer example.
timer.c
#include
#include
#include
#define MODULE_NAME
