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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 15 Jul 2019 07:03:16 -0700 From: "Paul E. McKenney" <paulmck@...ux.ibm.com> To: Peter Zijlstra <peterz@...radead.org> Cc: "Theodore Ts'o" <tytso@....edu>, Dmitry Vyukov <dvyukov@...gle.com>, syzbot <syzbot+4bfbbf28a2e50ab07368@...kaller.appspotmail.com>, Andreas Dilger <adilger.kernel@...ger.ca>, David Miller <davem@...emloft.net>, eladr@...lanox.com, Ido Schimmel <idosch@...lanox.com>, Jiri Pirko <jiri@...lanox.com>, John Stultz <john.stultz@...aro.org>, linux-ext4@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>, netdev <netdev@...r.kernel.org>, syzkaller-bugs <syzkaller-bugs@...glegroups.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...nel.org> Subject: Re: INFO: rcu detected stall in ext4_write_checks On Mon, Jul 15, 2019 at 03:39:38PM +0200, Peter Zijlstra wrote: > On Mon, Jul 15, 2019 at 06:01:01AM -0700, Paul E. McKenney wrote: > > Title: Making SCHED_DEADLINE safe for kernel kthreads > > > > Abstract: > > > > Dmitry Vyukov's testing work identified some (ab)uses of sched_setattr() > > that can result in SCHED_DEADLINE tasks starving RCU's kthreads for > > extended time periods, not millisecond, not seconds, not minutes, not even > > hours, but days. Given that RCU CPU stall warnings are issued whenever > > an RCU grace period fails to complete within a few tens of seconds, > > the system did not suffer silently. Although one could argue that people > > should avoid abusing sched_setattr(), people are human and humans make > > mistakes. Responding to simple mistakes with RCU CPU stall warnings is > > all well and good, but a more severe case could OOM the system, which > > is a particularly unhelpful error message. > > > > It would be better if the system were capable of operating reasonably > > despite such abuse. Several approaches have been suggested. > > > > First, sched_setattr() could recognize parameter settings that put > > kthreads at risk and refuse to honor those settings. This approach > > of course requires that we identify precisely what combinations of > > sched_setattr() parameters settings are risky, especially given that there > > are likely to be parameter settings that are both risky and highly useful. > > So we (the people poking at the DEADLINE code) are all aware of this, > and on the TODO list for making DEADLINE available for !priv users is > the item: > > - put limits on deadline/period > > And note that that is both an upper and lower limit. The upper limit > you've just found why we need it, the lower limit is required because > you can DoS the hardware by causing deadlines/periods that are equal (or > shorter) than the time it takes to program the hardware. > > There might have even been some patches that do some of this, but I've > held off because we have bigger problems and they would've established > an ABI while it wasn't clear it was sufficient or the right form. So I should withdraw the proposal? Thanx, Paul
Powered by blists - more mailing lists