From eccdd13dd3c812b8f0b3d046ef9d8738df00562a Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <tschwinge@gnu.org>
Date: Wed, 25 Sep 2013 21:45:38 +0200
Subject: IRC.

---
 open_issues/resource_management_problems.mdwn | 51 +++++++++++++++++++++++++--
 1 file changed, 48 insertions(+), 3 deletions(-)

(limited to 'open_issues/resource_management_problems.mdwn')

diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn
index 8f752d61..daf97954 100644
--- a/open_issues/resource_management_problems.mdwn
+++ b/open_issues/resource_management_problems.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation,
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2013 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -61,7 +61,8 @@ This is, of course, non-trivial to implement, and also requires changing the
 SPLICE_F_GIFT
 flag](http://www.kernel.org/doc/man-pages/online/pages/man2/vmsplice.2.html#DESCRIPTION).)
 
-IRC, freenode, #hurd, 2011-07-31
+
+## IRC, freenode, #hurd, 2011-07-31
 
     < braunr> one of the biggest problems on the hurd is that, when a client
       makes a call, kernel (and other) resources are allocated on behalf of the
@@ -75,6 +76,20 @@ IRC, freenode, #hurd, 2011-07-31
       attempts)
 
 
+## IRC, freenode, #hurd, 2013-08-13
+
+In context of <https://teythoon.cryptobitch.de/posts/my-worst-week-yet/>.
+
+    <braunr> teythoon: actually, thread migration isn't required for resource
+      accounting
+
+[[Mach_migrating_threads]].
+
+    <teythoon> braunr: but it solves it for free, doesn't it?
+    <braunr> teythoon: no
+    <braunr> it's really more complicated than that
+
+
 # Further Examples
 
   * [[hurd/critique]]
@@ -83,4 +98,34 @@ IRC, freenode, #hurd, 2011-07-31
 
   * [[translators_set_up_by_untrusted_users]], and [[pagers]]
 
-  * [[configure max command line length]]
+  * [[configure_max_command_line_length]]
+
+
+## [[hurd/translator/exec]] server
+
+### IRC, freenode, #hurd, 2013-08-05
+
+    <teythoon> unzipping stuff in the exec server enables a dos on filesystem
+      translators
+    <teythoon> https://teythoon.cryptobitch.de/gsoc/heap/hello-1g.bz2 is
+      /hurd/hello padded with a gig of zeros, compressed with bzip2
+    <teythoon> if set as an passive translator, it stalls other requests to the
+      filesystem, at least it does if ext2fs is used
+    <braunr> teythoon: ?
+    <braunr> teythoon: what's the dos here ?
+    <teythoon> I can prevent you from doing anything with the root filesystem
+    <teythoon> I'm kind of surprised myself, maybe a lock is held during the
+      exec of the translator?
+    <teythoon> the filesystem the hello-1g.bz2 translator is bound to is
+      affected
+    <braunr> teythoon: i don't understand
+    <braunr> have you tried starting something from another file system ?
+    <braunr> the lock may simply be in the exec server itself
+    <teythoon> no, starting other things works fine
+    <teythoon> but on the other hand, a find / is stalled
+    <braunr> :/
+    <braunr> *sigh*
+    <teythoon> don't worry
+    <teythoon> there is a solution :p
+    <braunr> :)
+    <teythoon> and it only requires deleting code
-- 
cgit v1.2.3