Experimental Physics and
Industrial Control System

In my opinion (which is biased as this change was driven by myself
and my colleagues) the current implementation is just fine and no
change is required.

These would be my arguments:

- it doesn't make much sense to use RT scheduling w/o memory locking
  as this would hurt determinism. Thus, selectively disabling mlockall()
  is a poor work-around.

- the code uses these features (RT scheduling + mlockall) *only* if you

  code assumes you want it to use them.

In any normal scenario EPICS is run as a normal user who by default
(on any common distro) does not have the privilege to use RT.

We set up our systems to grant the necessary users with a sufficient
hard limit but keep the soft limit (ulimit) zero. Thus, such a user can
selectively raise the ulimit and start a RT process.

- running an EPICS ioc as root (setuid) is what is causing the problem
  for the poster. I would contend that this is not the common scenario.

IMHO better approaches to solving Gerry's problems would be:

- use capabilities(7) to grant the executable iopl permission. This is
  less drastic than setuid. (setcap cap_sys_rawio)

- make sure root privilege is dropped before setscheduler/mlockall are
  attempted.

Let's see: We are talking about introducing a special hack (setenv xxx) to
be necessary for memory locking while you already are able to use SCHED_FIFO
and all of this because you want to be able to run EPICS as setuid? Really?

If anything I'd add a variable which is the run-time equivalent of
USE_POSIX_THREAD_PRIORITY_SCHEDULING and default it to NO.

- Till

On 01/29/2016 12:55 PM, Andrew Johnson wrote:

On 01/28/2016 08:43 AM, Ralph Lange wrote:

However, this is the second time that we hear of trouble because people
are running client applications (i.e. CA clients) in real-time context.
In those cases, the memory locking might not be intended nor useful.
There is no way for the OS abstraction layer (where the memlock happens)
to know if the caller is an IOC type or a client type application.
We already began to reconsider the automatic activation feature.

I think it would be reasonable to require those that want the mlockall()
behaviour to configure it. The main question would be whether this
should be configurable at build-time, or if it can require a run-time
setting. The simplest fix would be something like this:

=== modified file 'src/libCom/osi/os/posix/osdThread.c'
--- src/libCom/osi/os/posix/osdThread.c 2015-03-19 15:22:15 +0000
+++ src/libCom/osi/os/posix/osdThread.c 2016-01-29 20:41:08 +0000
@@ -362,7 +362,8 @@
          fprintf(stderr, "LRT: min priority: %d max priority %d\n",
              pcommonAttr->minPriority, pcommonAttr->maxPriority);
      }
-    if (pcommonAttr->maxPriority > pcommonAttr->minPriority) {
+    if (getenv("EPICS_RT_MLOCKALL") &&
+        pcommonAttr->maxPriority > pcommonAttr->minPriority) {
          status = mlockall(MCL_CURRENT | MCL_FUTURE);
          if(status) {
              fprintf(stderr, "Unable to lock the virtual address space
using mlockall\n");

That would require IOCs that need the memory locking to have set the
EPICS_RT_MLOCKALL environment variable before they are executed. A
slightly more complicated solution would allow locking to be turned on
at build-time in the configure/CONFIG_SITE_ENV file, but it could be
turned off again at run-time with an environment variable.

If you currently rely on the current mlockall() behaviour of Base and
wish to influence our decision, please speak up before we commit any
changes.

- Andrew

Replies:

RE: set-user-id root and EPICS 3.15 Mark Rivers

Re: set-user-id root and EPICS 3.15 Michael Davidsaver

Re: set-user-id root and EPICS 3.15 J. Lewis Muir

References:

set-user-id root and EPICS 3.15 Gerry Swislow

RE: set-user-id root and EPICS 3.15 Mark Rivers

Re: set-user-id root and EPICS 3.15 Ralph Lange

Re: set-user-id root and EPICS 3.15 Andrew Johnson

Navigate by Date:

Prev: RE: set-user-id root and EPICS 3.15 Jemian, Pete R.

Next: RE: set-user-id root and EPICS 3.15 Mark Rivers

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <2016>  2017  2018  2019  2020  2021  2022  2023  2024 

Navigate by Thread:

Prev: RE: set-user-id root and EPICS 3.15 Jemian, Pete R.

Next: RE: set-user-id root and EPICS 3.15 Mark Rivers

Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <2016>  2017  2018  2019  2020  2021  2022  2023  2024