The returns_twice attribute tells the compiler that a function may return more
than one time. The compiler will ensure that all registers are dead before
calling such a function and will emit a warning about the variables that may be
clobbered after the second return from the function. Examples of such functions
are setjmp and vfork. The longjmp-like counterpart of such function, if any,
might need to be marked with the noreturn attribute.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Felix Abecassis [Tue, 16 Apr 2019 21:40:03 +0000 (14:40 -0700)]
conf: do lxc.mount.entry mounts right after lxc.mount.fstab
These configuration options use the same syntax and therefore it seems
more intuitive to have the same behavior for both of them, which is
not the case today since mount hooks and autodev mounts are called
between the two.
See: https://github.com/lxc/lxc/issues/2932
Signed-off-by: Felix Abecassis <fabecassis@nvidia.com>
Change zfs arguments. This also works with older zfs versions, tested with
zfs 0.7.9-3 on Ubuntu 18.10.
Closes #2916.
Signed-off-by: Paul Gauret <pgauret@yahoo.com>
[christian.brauner@ubuntu.com: adapt commit message and add Signed-off-by for Paul] Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
The child_path variable is initialized very late in the function so jumping to
the on_error label would cause a nullderef. With the cleanup macros we can
simplify this function to simply do direct returns and avoid that whole issue.
Closes #2935.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
This hardens multi-threaded C. Without it, the implementation of thread
cancellation handlers (introduced by pthread_cleanup_push) uses a completely
unprotected function pointer on the stack. This function pointer can simplify
the exploitation of stack-based buffer overflows even if the thread in question
is never canceled.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Apparently the name received from the tree walk is not guaranteed to have \0
byte at the end. So let's make sure we append one.
Note that this is only an issue if there are any subvolumes in the container's
rootfs.
Closes 2826.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Callers such as LXD run post-stop hooks to perform cleanup operations on
shutdown. This can involve umount and other things. To avoid surprises with
lingering namespace references we should close all our namespace-preserving
file descriptors. We don't need them at this point anymore anyway.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
liblxc has always been meant to be LGPLv2.1+ as reflected by the many
downstreams projects and bindings which are themselves under LGPLv2.1+ or other
licenses which would be incompatible with linking against a GPLv2+ library.
It's pretty normal for a library to be LGPL while binaries are GPL as a GPL
library would only ever be usable by other GPL-only projects, which isn't the
case for very many of the liblxc downstreams.
The issue here is really carelessness. None of those GPL headers were put there
intentionally, instead being wrongly copy/pasted from other parts of the
codebase which is indeed intended to be GPLv2+. This is also made clear in our
CONTRIBUTING file in this repository:
Licensing for new files:
------------------------
LXC is made of files shipped under a few different licenses.
Anything that ends up being part of the LXC library needs to be released
under LGPLv2.1+ or a license compatible with it (though the latter will
only be accepted for cases where the code originated elsewhere and was
imported into LXC).
Language bindings for the libraries need to be released under LGPLv2.1+.
Anything else (non-libraries) needs to be Free Software and needs to be
allowed to link with LGPLv2.1+ code (if needed). LXC upstream prefers
LGPLv2.1+ or GPLv2 for those.
When introducing a new file into the project, please make sure it has a
copyright header making clear under which license it's being released
and if it doesn't match the criteria described above, please explain
your decision on the lxc-devel mailing-list when submitting your patch.
This is intended to switch over files to LGPLv2.1+ to which end we have
collected ACKs from relevant people.
/* Affected People */
Christian Brauner <christian.brauner@ubuntu.com>
Donghwa Jeong <dh48.jeong@samsung.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Donghwa Jeong <dh48.jeong@samsung.com>
liblxc has always been meant to be LGPLv2.1+ as reflected by the many
downstreams projects and bindings which are themselves under LGPLv2.1+ or other
licenses which would be incompatible with linking against a GPLv2+ library.
It's pretty normal for a library to be LGPL while binaries are GPL as a GPL
library would only ever be usable by other GPL-only projects, which isn't the
case for very many of the liblxc downstreams.
The issue here is really carelessness. None of those GPL headers were put there
intentionally, instead being wrongly copy/pasted from other parts of the
codebase which is indeed intended to be GPLv2+. This is also made clear in our
CONTRIBUTING file in this repository:
Licensing for new files:
------------------------
LXC is made of files shipped under a few different licenses.
Anything that ends up being part of the LXC library needs to be released
under LGPLv2.1+ or a license compatible with it (though the latter will
only be accepted for cases where the code originated elsewhere and was
imported into LXC).
Language bindings for the libraries need to be released under LGPLv2.1+.
Anything else (non-libraries) needs to be Free Software and needs to be
allowed to link with LGPLv2.1+ code (if needed). LXC upstream prefers
LGPLv2.1+ or GPLv2 for those.
When introducing a new file into the project, please make sure it has a
copyright header making clear under which license it's being released
and if it doesn't match the criteria described above, please explain
your decision on the lxc-devel mailing-list when submitting your patch.
This is intended to switch over files to LGPLv2.1+ to which end we have
collected ACKs from relevant people.
/* Affected People */
Christian Brauner <christian.brauner@ubuntu.com>
Donghwa Jeong <dh48.jeong@samsung.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Donghwa Jeong <dh48.jeong@samsung.com>
liblxc has always been meant to be LGPLv2.1+ as reflected by the many
downstreams projects and bindings which are themselves under LGPLv2.1+ or other
licenses which would be incompatible with linking against a GPLv2+ library.
It's pretty normal for a library to be LGPL while binaries are GPL as a GPL
library would only ever be usable by other GPL-only projects, which isn't the
case for very many of the liblxc downstreams.
The issue here is really carelessness. None of those GPL headers were put there
intentionally, instead being wrongly copy/pasted from other parts of the
codebase which is indeed intended to be GPLv2+. This is also made clear in our
CONTRIBUTING file in this repository:
Licensing for new files:
------------------------
LXC is made of files shipped under a few different licenses.
Anything that ends up being part of the LXC library needs to be released
under LGPLv2.1+ or a license compatible with it (though the latter will
only be accepted for cases where the code originated elsewhere and was
imported into LXC).
Language bindings for the libraries need to be released under LGPLv2.1+.
Anything else (non-libraries) needs to be Free Software and needs to be
allowed to link with LGPLv2.1+ code (if needed). LXC upstream prefers
LGPLv2.1+ or GPLv2 for those.
When introducing a new file into the project, please make sure it has a
copyright header making clear under which license it's being released
and if it doesn't match the criteria described above, please explain
your decision on the lxc-devel mailing-list when submitting your patch.
This is intended to switch over files to LGPLv2.1+ to which end we have
collected ACKs from relevant people.
/* Affected People */
Christian Brauner <christian.brauner@ubuntu.com>
Donghwa Jeong <dh48.jeong@samsung.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Donghwa Jeong <dh48.jeong@samsung.com>
liblxc has always been meant to be LGPLv2.1+ as reflected by the many
downstreams projects and bindings which are themselves under LGPLv2.1+ or other
licenses which would be incompatible with linking against a GPLv2+ library.
It's pretty normal for a library to be LGPL while binaries are GPL as a GPL
library would only ever be usable by other GPL-only projects, which isn't the
case for very many of the liblxc downstreams.
The issue here is really carelessness. None of those GPL headers were put there
intentionally, instead being wrongly copy/pasted from other parts of the
codebase which is indeed intended to be GPLv2+. This is also made clear in our
CONTRIBUTING file in this repository:
Licensing for new files:
------------------------
LXC is made of files shipped under a few different licenses.
Anything that ends up being part of the LXC library needs to be released
under LGPLv2.1+ or a license compatible with it (though the latter will
only be accepted for cases where the code originated elsewhere and was
imported into LXC).
Language bindings for the libraries need to be released under LGPLv2.1+.
Anything else (non-libraries) needs to be Free Software and needs to be
allowed to link with LGPLv2.1+ code (if needed). LXC upstream prefers
LGPLv2.1+ or GPLv2 for those.
When introducing a new file into the project, please make sure it has a
copyright header making clear under which license it's being released
and if it doesn't match the criteria described above, please explain
your decision on the lxc-devel mailing-list when submitting your patch.
This is intended to switch over files to LGPLv2.1+ to which end we have
collected ACKs from relevant people.
/* Affected People */
Christian Brauner <christian.brauner@ubuntu.com>
Donghwa Jeong <dh48.jeong@samsung.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Acked-by: Donghwa Jeong <dh48.jeong@samsung.com>
Previously this set `ctx->ns_fd[*]` to `-EBADF` until commit fd2a88b190eb ("attach: cleanup macros lxc_proc_close_ns_fd",
but there are some code paths where we call this before
later calling `lxc_proc_put_context_info` which would call
this function again with the file descriptors still
unchanged.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
projects / thirdparty / lxc.git / log
