Warn whenever a local variable or type declaration shadows another
variable, parameter, type, class member (in C++), or instance variable
(in Objective-C) or whenever a built-in function is shadowed.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
If we call lxc-freeze multiple times for an already frozen container, LXC
triggers useless freezing by writing into the "freezer.state" cgroup file.
This is the same when we call lxc-unfreeze multiple times.
Checking the current state with a LXC_CMD_GET_STATE
(calling c->state) would permit to check if the container is FROZEN
or not.
Signed-off-by: Rachid Koucha <rachid.koucha@gmail.com>
We need to strip the prefix from the container's source path before
trying to update the file.
Closes#2380.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This is modeled after LXD's API extension checks. This allows API users
to query the given LXC instance whether a given API extension is
supported.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
The on-disk config file is not altered and the in-memory config isn't
altered so no need for locking.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
The on-disk config file is not altered and the in-memory config isn't
altered so no need for locking.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This reverts commit 2fb7cf0b32.
The problem wasn't caused by the reverted commit and was fixed in
commit 0c9b1f826d ("macro: calculate buffer lengths correctly")
The full explanation can be taken from the following irc excerpt from
the #lxc-dev channel:
│19:54:47 brauner | there was a bug in one of the standard macros we used
│19:55:01 brauner | and the changes by INTTYPE_TO_STRLEN() caused the issue to surface
│19:55:03 brauner | which is good
│19:55:16 brauner | i sent a branch and stgraber merged it that fixes it
│19:57:56 Blub\0 | so...
│19:58:31 Blub\0 | still doesn't explain how it was the sizeof() patch
│20:07:14 brauner | Blub\0: so here's the long explanation
│20:07:35 brauner | Blub\0: stgraber bumped pid_max on our jenkins test builders
│20:07:53 brauner | Blub\0: because we're running *a lot* of containers
│20:07:56 brauner | in any case
│20:08:06 brauner | there was a buffer
│20:08:12 brauner | LXC_LSMATTRLEN
│20:08:59 brauner | it used to be
│20:09:03 brauner | -/* /proc/pid-to-str/attr/current = (5 + INTTYPE_TO_STRLEN(pid_t) + 7 + 1) */
│20:09:03 brauner | -#define LXC_LSMATTRLEN (5 + INTTYPE_TO_STRLEN(pid_t) + 7 + 1)
│20:09:14 brauner | which one can see is wrong
│20:09:21 brauner | before the INTTYPE patchset
│20:09:40 brauner | INTTYPE_TO_STRLEN(pid_t) was LXC_NUMSTRLEN64
│20:09:45 brauner | which gave you 21 chars
│20:09:57 brauner | so it accounted for the missing parts
│20:10:03 brauner | because the correct macro should've been
│20:10:17 brauner | +/* /proc/ = 6
│20:10:17 brauner | + * +
│20:10:17 brauner | + * <pid-as-str> = INTTYPE_TO_STRLEN(pid_t)
│20:10:17 brauner | + * +
│20:10:17 brauner | + * /attr/ = 6
│20:10:17 brauner | + * +
│20:10:17 brauner | + * /current = 8
│20:10:17 brauner | + * +
│20:10:17 brauner | + * \0 = 1
│20:10:17 brauner | + */
│20:10:17 brauner | +#define LXC_LSMATTRLEN (6 + INTTYPE_TO_STRLEN(pid_t) + 6 + 8 + 1)
│20:10:24 Blub\0 | still
│20:10:31 brauner | the issue was only seen
│20:10:39 brauner | when the pid number hit a specific maximum
│20:10:50 Blub\0 | the sizeof patch only changed instances of actual char buf[A_FIXED_NUMBER] + snprintf(buf, A_FIXED_NUMBER, ...)
│20:10:54 brauner | aka exceeded the newly shortened buffer
│20:11:42 brauner | your patch was a red herring
│20:12:03 Blub\0 | I guess
│20:12:06 brauner | it didn't cause it
│20:12:14 brauner | it just surfaced at the same time it was merged
│20:12:25 Blub\0 | so we can revert the revert then? :)
│20:12:35 brauner | yes, that was th eplan all along
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This reverts commit 81a3bb64b4.
This commit broke all builders running with pid_max > 32768.
Reverting for now so we can bring the build farm back online.
Signed-off-by: Stéphane Graber <stgraber@ubuntu.com>
When we check whether an open file description lock has been taken on a file we
need to set the l_pid field to 0 otherwise the kernel will send back EINVAL.
Additionally, the kernel will not do pid translation and simply set the l_pid
value to -1.
Fixes https://discuss.linuxcontainers.org/t/container-deleted-or-stopped-when-lxc-ls-executed-concurrently/2439
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This introduces a new config key lxc.rootfs.managed which can be used to
indicate whether this LXC instance is managing the container storage. If LXC is
not managing the storage then LXC will not modify the container storage.
For example, an API call to c->destroy(c) will then run any destroy hooks but
will not destroy the actual rootfs (Unless, of course, the hook does so behind
LXC's back.).
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
CC: Wolfgang Bumiller <w.bumiller@proxmox.com>
CC: Stéphane Graber <stgraber@ubuntu.com>
CC: Serge Hallyn <serge@hallyn.com>
CC: 2xsec <dh48.jeong@samsung.com>
