On Thu, Sep 6, 2018 at 1:53 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Thu 06-09-18 20:40:34, Tetsuo Handa wrote: >> On 2018/09/06 20:23, Michal Hocko wrote: >> > On Thu 06-09-18 19:58:25, Tetsuo Handa wrote: >> > [...] >> >> >From 18876f287dd69a7c33f65c91cfcda3564233f55e Mon Sep 17 00:00:00 2001 >> >> From: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> >> >> Date: Thu, 6 Sep 2018 19:53:18 +0900 >> >> Subject: [PATCH] mm, oom: Introduce time limit for dump_tasks duration. >> >> >> >> Since printk() is slow, printing one line takes nearly 0.01 second. >> >> As a result, syzbot is stalling for 52 seconds trying to dump 5600 >> >> tasks at for_each_process() under RCU. Since such situation is almost >> >> inflight fork bomb attack (the OOM killer will print similar tasks for >> >> so many times), it makes little sense to print all candidate tasks. >> >> Thus, this patch introduces 3 seconds limit for printing. >> >> >> >> Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> >> >> Cc: Dmitry Vyukov <dvyukov@xxxxxxxxxx> >> > >> > You really love timeout based solutions with randomly chosen timeouts, >> > don't you. This is just ugly as hell. We already have means to disable >> > tasks dumping (see /proc/sys/vm/oom_dump_tasks). >> >> I know /proc/sys/vm/oom_dump_tasks . Showing some entries while not always >> printing all entries might be helpful. > > Not really. It could be more confusing than helpful. The main purpose of > the listing is to double check the list to understand the oom victim > selection. If you have a partial list you simply cannot do that. > > If the iteration takes too long and I can imagine it does with zillions > of tasks then the proper way around it is either release the lock > periodically after N tasks is processed or outright skip the whole thing > if there are too many tasks. The first option is obviously tricky to > prevent from duplicate entries or other artifacts. So does anybody know if it can live lock picking up new tasks all the time? That's what it looks like at first glance. I also don't remember seeing anything similar in the past. If it's a live lock and we resolve it, then we don't need to solve the problem of too many tasks here.
