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
give it sufficient privilege to use them. If it has the privileges
then the
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
|