Thank you for the explanation!
> systemd isn't aware of it and it would clean the hierarchy according to its
> configuration
Yup, that is what I would expect from systemd after reading docs — to be a
full, robust and confident owner of the cgroups hierarchies on a host.
However, if you don’t
On 19.11.2020 18.32, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote:
Hi udev people-
The upcoming Linux SGX driver has a device node /dev/sgx. User code
opens it, does various setup things, mmaps it, and needs to be able to
create PROT_EXEC
On Thu, Nov 19, 2020 at 08:17:08AM -0800, Andy Lutomirski wrote:
> Hi udev people-
>
> The upcoming Linux SGX driver has a device node /dev/sgx. User code
> opens it, does various setup things, mmaps it, and needs to be able to
> create PROT_EXEC mappings. This gets quite awkward if /dev is
Hi udev people-
The upcoming Linux SGX driver has a device node /dev/sgx. User code
opens it, does various setup things, mmaps it, and needs to be able to
create PROT_EXEC mappings. This gets quite awkward if /dev is mounted
noexec.
Can udev arrange to make a device node executable on distros
Hi.
On Wed, Nov 18, 2020 at 09:46:03PM +0300, Andrei Enshin wrote:
> Just out of curiosity, how systemd in particular may be disrupted with
> such record in root of it’s cgroups hierarchy as /kubpods/bla/bla
> during service (de)activation?
> Or how it may disrupt the kubelet or workload running