Kir,
Please find attached simple fixes for upstream containers. The first one is a
compiler warning for recently introduced code, while the last two together
fixes bugs with parsing and applying beancounter configuration. Patch #2 fixes
a bug only present in versions compiled with the
Signed-off-by: Glauber Costa glom...@openvz.org
---
src/lib/hooks_ct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/lib/hooks_ct.c b/src/lib/hooks_ct.c
index 03a18e7..63af536 100644
--- a/src/lib/hooks_ct.c
+++ b/src/lib/hooks_ct.c
@@ -247,7 +247,7 @@ static int
From: Glauber Costa glom...@parallels.com
Commit c9d9170b0 fixed a bug by not including the ub functions if VZ support
was not present in the running kernel, and replacing them with empty stubs.
This approach, however, proved to be too aggressive. We need to at least be
able to read and write
Currently, vps_setup_res() have an explicit test for state != VPS_STARTING
before applying beancounter limits. This means that we can set limits without
further problems when the container is running, but will fail to do so when the
container is starting. In fact, hooks_vz have an explicit call
The kernel memory controller cannot flip states from unlimited to limited if
there are already tasks in it. Therefore, we always have to run with *some*
value of kmem enabled. If we don't do it, we can't start unlimited and then use
the set command to set any beancounters. We write the maximum
Kir,
Please review the following patchset. The main difference from last version is
that
we support running with userns disabled even if it is present. This effectively
means
that containers that were already created and owned by root will keep working.
It is
also possible to explicitly
From: Glauber Costa glom...@parallels.com
When running with an upstream Linux kernel that supports user namespaces,
we will run the container using an unprivileged user in the system. That
can be any user, and it serves as base to a 1:1 mapping between users in
the container and users in the
From: Glauber Costa glom...@parallels.com
We need to pass more information to fs_create. Instead of adding arguments, it
is preferred to pass the whole vps_p structure and unfold it inside the callee.
Signed-off-by: Glauber Costa glom...@parallels.com
---
src/lib/create.c | 12 +++-
1
Upstream containers running on kernels that support user namespaces would
benefit from being able to have early access to the container configuration.
This is because we would like user namespaces support to be either enabled or
disabled, and a lot of the actions we take can be potentially
From: Glauber Costa glom...@parallels.com
This patch allows the execution of unprivileged containers running ontop
of an upstream Linux Kernel. We will run at whatever UID is found in the
configuration file (so far empty, thus disabled).
Signed-off-by: Glauber Costa glom...@parallels.com
---
From: Glauber Costa glom...@parallels.com
In theory, we won't be able to run if our private area is not owned by
ourselves. We could, if it have very wide open security permissions, but we
should never set up a container like that.
Aside from a basic sanity check, this is intended to catch
From: Glauber Costa glom...@parallels.com
If we are running upstream with user namespaces, we need to create the
container filesystem not with the ownership preserved, but reflecting the
mapping we need to apply. Note that according to our documentation, we should
ignore this if the user
From: Glauber Costa glom...@parallels.com
The chosen architecture to deal with --ipadd with upstream containers is to
create a veth pair and add the host side information to a bridge called venet0.
This way, all the code that expects venet0 to exist can still work without
modifications, (or with
From: Glauber Costa glom...@parallels.com
We will need that infrastucture when running with Linux upstream, since some
support is very unlikely to ever land in the Kernel. We need to do things like
account for the fact that udev may kick in and destroy all the setup we have
done for /dev. Since
On Tue, May 07, 2013 at 02:42:12PM +0800, Igor Podlesny wrote:
1) Macro MAX_OF(a, b) introduced;
2) FILE *fd init when declaring;
3) When comparing variable to const, put const first, then variable
-- to reduce typo risk of unintended assignment;
4) Buffer moved into closer scope.
---
On Tue, May 07, 2013 at 06:17:17PM +0800, Igor M Podlesny wrote:
- if ((fd = fopen(PROCCPU, r)) == NULL) {
+ if (NULL == fd) {
Pls, follow the current coding style.
if (fd === NULL)
Somebody suffers from too much PHP, too much, doesn't he? )
WTF? Look at
On 30 April 2013 13:16, Glauber Costa glom...@openvz.org wrote:
From: Glauber Costa glom...@parallels.com
To work around that, we can employ a trick to allow container creation right
now, as well as to avoid compatibility problems: we will resort to LD_PRELOAD
to load a schim that captures
On 30 April 2013 13:16, Glauber Costa glom...@openvz.org wrote:
@@ -576,7 +765,9 @@ int ct_do_open(vps_handler *h, vps_param *param)
{
int ret;
char path[STR_SIZE];
+ char upath[STR_SIZE];
struct stat st;
+ unsigned long *local_uid =
On 30 April 2013 11:46, Glauber Costa glom...@openvz.org wrote:
Currently, vps_setup_res() have an explicit test for state != VPS_STARTING
before applying beancounter limits. This means that we can set limits without
further problems when the container is running, but will fail to do so when
19 matches
Mail list logo
