summaryrefslogtreecommitdiff
path: root/open_issues/resource_management_problems.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/resource_management_problems.mdwn')
-rw-r--r--open_issues/resource_management_problems.mdwn51
1 files changed, 48 insertions, 3 deletions
diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn
index 8f752d6..daf9795 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