lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ac949d08-72ff-edf6-6526-fdc9ad602631@csgroup.eu>
Date:   Sat, 24 Apr 2021 14:21:11 +0200
From:   Christophe Leroy <christophe.leroy@...roup.eu>
To:     Peter Enderborg <peter.enderborg@...y.com>,
        Wim Van Sebroeck <wim@...ux-watchdog.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-watchdog@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, Shakeel Butt <shakeelb@...gle.com>
Subject: Re: [RFC PATCH] watchdog: Adding softwatchdog



Le 24/04/2021 à 12:25, Peter Enderborg a écrit :
> This is not a rebooting watchdog. It's function is to take other
> actions than a hard reboot. On many complex system there is some
> kind of manager that monitor and take action on slow systems.
> Android has it's lowmemorykiller (lmkd), desktops has earlyoom.
> This watchdog can be used to help monitor to preform some basic
> action to keep the monitor running.
> 
> It can also be used standalone. This add a policy that is
> killing the process with highest oom_score_adj and using
> oom functions to it quickly. I think it is a good usecase
> for the patch. Memory siuations can be problematic for
> software that monitor system, but other prolicys can
> should also be possible. Like picking tasks from a memcg, or
> specific UID's or what ever is low priority.


I'm nore sure I understand the reasoning behind the choice of oom logic to decide which task to kill.

Usually a watchdog will detect if a task is using 100% of the CPU time. If such a task exists, it is 
the one running, not another one that has huge amount of memory allocated by spends like 1% of CPU time.

So if there is a task to kill by a watchdog, I would say it is the current task.


Another remark: you are using regular timers as far as I understand. I remember having problems with 
that in the past, it required the use of hrtimers. I can't remember the details exactly but you can 
look at commit https://github.com/linuxppc/linux/commit/1ff688209

Christophe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ