Skip to content
Projects
Groups
Snippets
Help
This project
Loading...
Sign in / Register
Toggle navigation
L
lxc
Project
Overview
Details
Activity
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Charts
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Chen Yisong
lxc
Commits
e3f0e436
Unverified
Commit
e3f0e436
authored
Feb 10, 2018
by
Christian Brauner
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
lxclock: remove pthread_atfork_handlers
They shouldn't be needed anymore. Signed-off-by:
Christian Brauner
<
christian.brauner@ubuntu.com
>
parent
5b9912ab
Show whitespace changes
Inline
Side-by-side
Showing
2 changed files
with
3 additions
and
23 deletions
+3
-23
attach.c
src/lxc/attach.c
+3
-6
lxclock.c
src/lxc/lxclock.c
+0
-17
No files found.
src/lxc/attach.c
View file @
e3f0e436
...
@@ -1242,13 +1242,10 @@ int lxc_attach(const char *name, const char *lxcpath,
...
@@ -1242,13 +1242,10 @@ int lxc_attach(const char *name, const char *lxcpath,
return
-
1
;
return
-
1
;
}
}
/* Create intermediate subprocess, three reasons:
/* Create intermediate subprocess, two reasons:
* 1. Runs all pthread_atfork handlers and the child will no
* 1. We can't setns() in the child itself, since we want to make
* longer be threaded (we can't properly setns() in a threaded
* process).
* 2. We can't setns() in the child itself, since we want to make
* sure we are properly attached to the pidns.
* sure we are properly attached to the pidns.
*
3
. Also, the initial thread has to put the attached process
*
2
. Also, the initial thread has to put the attached process
* into the cgroup, which we can only do if we didn't already
* into the cgroup, which we can only do if we didn't already
* setns() (otherwise, user namespaces will hate us).
* setns() (otherwise, user namespaces will hate us).
*/
*/
...
...
src/lxc/lxclock.c
View file @
e3f0e436
...
@@ -317,23 +317,6 @@ void process_unlock(void)
...
@@ -317,23 +317,6 @@ void process_unlock(void)
unlock_mutex
(
&
thread_mutex
);
unlock_mutex
(
&
thread_mutex
);
}
}
/* One thread can do fork() while another one is holding a mutex.
* There is only one thread in child just after the fork(), so no one will ever release that mutex.
* We setup a "child" fork handler to unlock the mutex just after the fork().
* For several mutex types, unlocking an unlocked mutex can lead to undefined behavior.
* One way to deal with it is to setup "prepare" fork handler
* to lock the mutex before fork() and both "parent" and "child" fork handlers
* to unlock the mutex.
* This forbids doing fork() while explicitly holding the lock.
*/
#ifdef HAVE_PTHREAD_ATFORK
__attribute__
((
constructor
))
static
void
process_lock_setup_atfork
(
void
)
{
pthread_atfork
(
process_lock
,
process_unlock
,
process_unlock
);
}
#endif
int
container_mem_lock
(
struct
lxc_container
*
c
)
int
container_mem_lock
(
struct
lxc_container
*
c
)
{
{
return
lxclock
(
c
->
privlock
,
0
);
return
lxclock
(
c
->
privlock
,
0
);
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment