Re: [RFC PATCH] mm: silence soft lockups from unlock_page
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Michal Hocko <mhocko@xxxxxxxxxx>
- Subject: Re: [RFC PATCH] mm: silence soft lockups from unlock_page
- From: Chris Down <chris@xxxxxxxxxxxxxx>
- Date: Tue, 21 Jul 2020 15:17:49 +0100
- Cc: linux-mm@xxxxxxxxx, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>, Tim Chen <tim.c.chen@xxxxxxxxxxxxxxx>, Michal Hocko <mhocko@xxxxxxxx>
- In-reply-to: <20200721063258.17140-1-mhocko@kernel.org>
- References: <20200721063258.17140-1-mhocko@kernel.org>
- User-agent: Mutt/1.14.6 (2020-07-11)
I understand the pragmatic considerations here, but I'm quite concerned about
the maintainability and long-term ability to reason about a patch like this.
For example, how do we know when this patch is safe to remove? Also, what other
precedent does this set for us covering for poor userspace behaviour?
Speaking as a systemd maintainer, if udev could be doing something better on
these machines, we'd be more than receptive to help fix it. In general I am
against explicit watchdog tweaking here because a.) there's potential to mask
other problems, and b.) it seems like the kind of one-off trivia nobody is
going to remember exists when doing complex debugging in future.
Is there anything preventing this being remedied in udev, instead of the
kernel?
[Index of Archives]
[Linux ARM Kernel]
[Linux ARM]
[Linux Omap]
[Fedora ARM]
[IETF Annouce]
[Bugtraq]
[Linux OMAP]
[Linux MIPS]
[eCos]
[Asterisk Internet PBX]
[Linux API]