From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: arisawa In-Reply-To: <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> Date: Wed, 28 Jan 2015 09:10:50 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0F748B67-FB11-464C-84FA-66B4E0B29918@9.offblast.org> <44900c0d4896622fa8a9411b05efe730@brasstown.quanstro.net> <7A132462-4747-471A-A4BF-D9381E38A4EA@ar.aichi-u.ac.jp> <4c37cf728d5b0e7ae4ebd3c2e0c2cee4@brasstown.quanstro.net> <3a6fb8671dae34eb5b4e0ebe3992bcfd@brasstown.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] protection against resource exhaustion Topicbox-Message-UUID: 3cb85df8-ead9-11e9-9d60-3106f5b1d025 we don=E2=80=99t have perfect solution. nevertheless, we must protect system. if we search ideal (or nearly ideal) solution, we should assign limited = resource to each user. however this is a big job, I believe. current plan9 system is running under shared resource model. under this model, it is very hard to protect system from evil-minded = users. keeping this model, we can do something that is, of course, imperfect = (but easy to implement, I believe). for example: (a) select processes that should keep running. (with resrcwait flag, for = example) (b) kill processe that failed to be allocated resource if it doesn=E2=80=99= t has resrcwait flag. this strategy has following problems: (1) innocent processes may be killed. the probability is small if the origin is careless program, but can be = large by evil-mined program. (2) error return from malloc() and fork() are disabled. > 2015/01/27 23:10=E3=80=81erik quanstrom = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 >>> i think it will go the same way with fork protection. how do you = tell which program >>> is at fault? how do you tell a program forking at high frequency, = with short lived >>> children from a fork bomb? (such as a busy web server.) >>=20 >> only system administrator knows which processes should keep running. >=20 > do you wake him up in the middle of the night if this happens to = arbitrate? > this knowledge of what should be preserved may only be post facto = knowledge. > "i'll know what to kill off once i see what's running." which assumes = a working > fork, at least for the administrator. >=20 > in any event, i'd be interested in code that does do a good job, = especially > if it passes tests other than the trivial fork bomb, such as many = users contributing > to exhaustion. >=20 >> I have beeb writing codes believing those error return is working. >=20 > do you have tests? did you write a test malloc that will fail when = called > at every location, and ensure sane behavior? >=20 > - erik >=20