bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #29809] creating a firmlink loop results in memory exhaustion


From: Kalle Olavi Niemitalo
Subject: [bug #29809] creating a firmlink loop results in memory exhaustion
Date: Wed, 7 Sep 2016 19:43:09 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0

Follow-up Comment #3, bug #29809 (project hurd):

Perhaps this could be fixed by adding three parameters to the dir_lookup
routine:
* in max_total_lookups = Total number of directory lookups that may be caused
by this call.  If it needs more, then fail with ELOOP.  If the server thinks
the value of max_total_lookups is unreasonably high, then it can use a smaller
value instead.
* out total_lookups = Total number of directory lookups that the dir_lookup
call caused before succeeding.  If the caller is calling dir_lookup in a loop,
it can add total_lookups to a cumulative total and then compare the sum to its
own max_total_lookups limit.
* in max_lookup_depth = Number of recursion levels permitted during this call.
 If it needs more, then fail with ELOOP.  If the server thinks the value of
max_lookup_depth is unreasonably high, then it can use a smaller value
instead.

Then these would also have to be added to the various functions in
<hurd/lookup.h>, and the translators would have to be changed to propagate
this infomation.  I think it would be straightforward to implement and pretty
easy to understand, and it would reliably give the desired ELOOP result.  On
the other hand, it would need changes in many source files, and it would not
prevent someone from hacking a custom translator to deliberately fake the
values, but then again such a program can flood the system with threads and
RPCs anyway.

I was also thinking about an alternative solution: implement migrating threads
and set a quota on the number of activations per thread; make RPCs fail if
they would exceed the quota. However, that scheme would let users deliberately
consume almost all of the activation quota of a thread and then call a
filesystem server, which would attempt to call a storage server and fail. It
might be difficult for the filesystem server to recover from such errors.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?29809>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]