[PATCH] urxvtd, getopt and mlock

[Russell Harmon]

On Thu, Jan 29, 2009 at 05:57, Marc Lehmann <schmorp at schmorp.de> wrote:
> On Tue, Jan 27, 2009 at 04:55:24AM -0500, Russell Harmon <russ at eatnumber1.com> wrote:
>> > There has never been a "2.5-20" release of glibc, glibc doesn't use this
>> > klind of versioning scheme. This looks like redhat-specific thing, and I
>> > don't think it makes sense to require usage of redhat?
>> Hmm... what should I do then? I've been running with a patched urxvtd
>> for a few weeks now without problems and i'm running Gentoo with
>> glibc-2.9_p20081201-r1 (so if it is fixed, i've probably got the fix).
>
> I guess the right way to proceed is to ignore the glibc version, compile
> it always in (when ENABLE_FRILLS and available) and just mention the bug
> in the manpage.
Ok, I updated the patch. I removed the rename of --opendisplay to
--open-display, added a BUGS section in the manpage which mentions the
glibc bug, and changed the test to the following:

#if defined(ENABLE_FRILLS) && defined(_POSIX_MEMLOCK) && _POSIX_MEMLOCK > 0

-Russ H

diff --git a/doc/rxvtd.1.pod b/doc/rxvtd.1.pod
index 60c54d3..e53cb70 100644
--- a/doc/rxvtd.1.pod
+++ b/doc/rxvtd.1.pod
@@ -4,7 +4,7 @@

 =head1 SYNOPSIS

-B<@@RXVT_NAME@@d> [-q|--quiet] [-o|--opendisplay] [-f|--fork]
+B<@@RXVT_NAME@@d> [-q|--quiet] [-o|--opendisplay] [-f|--fork] [-m|--mlock]

 B<@@RXVT_NAME@@d> -q -o -f    # for .xsession use

@@ -54,6 +54,15 @@ B<@@RXVT_NAME@@d> will be killed automatically.
 This makes B<@@RXVT_NAME@@d> fork after it has bound itself to its control
 socket.

+=item B<-m>, B<--mlock>
+
+This makes B<@@RXVT_NAME@@d> call mlockall(2) on itself. This locks
+B<@@RXVT_NAME@@d> in RAM and prevents it from being swapped out to disk.
+
+Note: In order to use this feature, your system administrator must have set
+your user's RLIMIT_MEMLOCK to a size greater than or equal to the size of the
+B<@@RXVT_NAME@@d> binary (or to unlimited). See /etc/security/limits.conf
+
 =back

 =head1 EXAMPLES
@@ -85,6 +94,12 @@ valid X display name.

 =back

+=head1 BUGS
+
+There is a known bug with gcc versions above 2.5 where calloc while mlocked
+returns non-zeroed memory. If you experience crashes or other odd behaviour
+while using --mlock, try it without it.
+
 =head1 SEE ALSO

 @@RXVT_NAME@@(7), @@RXVT_NAME@@c(1)
diff --git a/src/rxvtd.C b/src/rxvtd.C
index 5642827..91779f9 100644
--- a/src/rxvtd.C
+++ b/src/rxvtd.C
@@ -33,6 +33,14 @@
 #include <sys/socket.h>
 #include <sys/un.h>

+#if defined(ENABLE_FRILLS) && defined(_POSIX_MEMLOCK) && _POSIX_MEMLOCK > 0
+#define ENABLE_MLOCK
+#endif
+
+#ifdef ENABLE_MLOCK
+#include <sys/mman.h>
+#endif
+
 #include <cerrno>

 #include "rxvt.h"
@@ -217,6 +225,9 @@ void server::read_cb (ev::io &w, int revents)
 }

 int opt_fork, opt_opendisplay, opt_quiet;
+#ifdef ENABLE_MLOCK
+int opt_lock;
+#endif

 int
 main (int argc, const char *const *argv)
@@ -231,6 +242,10 @@ main (int argc, const char *const *argv)
         opt_opendisplay = 1;
       else if (!strcmp (argv [i], "-q") || !strcmp (argv [i], "--quiet"))
         opt_quiet = 1;
+#ifdef ENABLE_MLOCK
+      else if (!strcmp (argv [i], "-m") || !strcmp (argv [i], "--mlock"))
+        opt_lock = 1;
+#endif
       else
         {
           rxvt_log ("%s: unknown option '%s', aborting.\n", argv [0],
argv [i]);
@@ -256,10 +271,21 @@ main (int argc, const char *const *argv)

   free (sockname);

+  pid_t pid = 0;
   if (opt_fork)
     {
-      pid_t pid = fork ();
+      pid = fork ();
+    }

+#ifdef ENABLE_MLOCK
+  // Optionally preform a mlockall so this process does not get swapped out.
+  if (opt_lock && pid == 0)
+    if (mlockall(MCL_CURRENT | MCL_FUTURE) == -1)
+      perror("unable to lock into ram");
+#endif
+
+  if (opt_fork)
+    {
       if (pid < 0)
         {
           rxvt_log ("unable to fork daemon, aborting.\n");
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rxvt-unicode_mlock.patch
Type: application/octet-stream
Size: 2797 bytes
Desc: not available
URL: <http://lists.schmorp.de/pipermail/rxvt-unicode/attachments/20090129/26d3912f/attachment.obj>