On Tue, Apr 19, 2022 at 07:47:09PM +0800, Yang Xu wrote:
> Since xfs_generic_create only calls xfs_set_acl when enable this kconfig, we
> don't need to call posix_acl_create for the !CONFIG_XFS_POSIX_ACL case.
>
> The previous patch has added missing umask strip for tmpfile, so all creation
>
On Mon, Mar 14, 2022 at 05:43:40PM -0700, Todd Kjos wrote:
> On Wed, Mar 9, 2022 at 8:53 AM T.J. Mercier wrote:
> >
> > This test verifies that the cgroup GPU memory charge is transferred
> > correctly when a dmabuf is passed between processes in two different
> > cgroups and the sender specifies
Are the tests run with security.nesting=true set?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1959013
Title:
systemd test_exec_umask_namespace fails in privileged
Are the tests run with security.nesting=true set?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1959013
Title:
systemd test_exec_umask_namespace fails in privileged container
To manage
On Mon, Jan 24, 2022 at 05:25:57PM +0100, Christian Brauner wrote:
> On Fri, Jan 21, 2022 at 03:59:52PM +, gm...@pm.me wrote:
> > Dear all,
> >
> > Has anyone tried to run a rootless container, or simply pull an image, from
> > a systemd-homed session?
> &g
On Fri, Jan 21, 2022 at 03:59:52PM +, gm...@pm.me wrote:
> Dear all,
>
> Has anyone tried to run a rootless container, or simply pull an image, from a
> systemd-homed session?
>
> For some reason I am told there are potentially insufficient UIDs or GIDs
> available:
>
> $ buildah from
On Wed, Jan 19, 2022 at 09:18:05AM +, David Howells wrote:
> Christoph Hellwig wrote:
>
> > On Tue, Jan 18, 2022 at 05:40:14PM +, David Howells wrote:
> > > Christoph Hellwig wrote:
> > >
> > > > On Tue, Jan 18, 2022 at 01:54:54PM +, David Howells wrote:
> > > > > Add an
On Mon, Jan 03, 2022 at 02:44:10PM -, Christian Ehrhardt wrote:
> @stgraber - since this is lx[cd] and you still usually do the uploads.
> Do you have insight or opinion about this?
LXCFS upstream contains a commit that will simply make
/var/lib/lxcfs/cgroup an empty directory without
oid: binder: Move buffer out of area shared with
> user space")
> Signed-off-by: Todd Kjos
> ---
Looks good.
Acked-by: Christian Brauner
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
ignment checks. Previously the alignment checks would
> have been done in a different place, but this lets us print more
> useful error messages.
>
> Reviewed-by: Martijn Coenen
> Signed-off-by: Todd Kjos
> ---
Looks good.
Acked-by: Christian Brauner
Suggested-by: Dan Carpenter
> Signed-off-by: Todd Kjos
> ---
Looks good.
Acked-by: Christian Brauner
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
are visible to the
> target prior to the fixups.
>
> Instead of copying all of the data first, copy data only
> after any needed fixups have been applied.
>
> Fixes: 457b9a6f09f0 ("Staging: android: add binder driver")
> Reviewed-by: Martijn Coenen
> Signed-off-by: Tod
tigation. It is a partial
> reversion because subsequent patches rely on proc->cred.
>
> Cc: sta...@vger.kernel.org # 4.4+
> Fixes: 29bc22ac5e5b ("binder: use euid from cred instead of using task")
> Signed-off-by: Todd Kjos
> Change-Id: I9b1769a3510fed250bb
s_failure' can be used to accurately detect this case.
>
> Fixes: 44d8047f1d87 ("binder: use standard functions to allocate fds")
> Signed-off-by: Todd Kjos
> ---
Looks good to me.
Acked-by: Christian Brauner
__
ame of xattr
> too if caller asked for it (xattr_name != NULL).
>
> Signed-off-by: Vivek Goyal
> Reviewed-by: Jeff Layton
> ---
Looks good to me.
Reviewed-by: Christian Brauner
___
Virtio-fs mailing list
Virtio-fs@redhat.com
https://listman.redhat.com/mailman/listinfo/virtio-fs
On Mon, Sep 13, 2021 at 05:32:32PM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 13, 2021 at 12:04:04PM -0500, Mike Christie wrote:
> > I just realized I forgot to cc the virt list so adding now.
> >
> > Christian see the very bottom for a different fork patch.
> >
> > On 7/12/21 7:05 AM,
On Mon, Sep 13, 2021 at 05:32:32PM -0400, Michael S. Tsirkin wrote:
> On Mon, Sep 13, 2021 at 12:04:04PM -0500, Mike Christie wrote:
> > I just realized I forgot to cc the virt list so adding now.
> >
> > Christian see the very bottom for a different fork patch.
> >
> > On 7/12/21 7:05 AM,
This was caused by a recent change to how we handle selinux and apparmor config
options when LXC is compiled without support. I've sent
https://github.com/lxc/lxc/pull/3969
specific to stable-4.0.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
This was caused by a recent change to how we handle selinux and apparmor config
options when LXC is compiled without support. I've sent
https://github.com/lxc/lxc/pull/3969
specific to stable-4.0.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
** Changed in: lxc (Ubuntu)
Status: New => Confirmed
** Changed in: lxc (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
** Changed in: lxc (Ubuntu)
Status: New => Confirmed
** Changed in: lxc (Ubuntu)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1943441
Title:
lxc:
or the file object may never be
> dereferenced -- which can lead to hung processes.
>
> Force the binder thread back to userspace if an fd is closed during
> BC_FREE_BUFFER handling.
>
> Signed-off-by: Todd Kjos
> ---
Looks good. Th
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1940392
Title:
fs: removing mandatory locks
Status in linux package
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1940392
Title:
fs: removing mandatory locks
To manage notifications about this
Public bug reported:
Hello,
Upstream is dicussing the removal of mandatory locks. To actually do
this at some point distros will need to start disabling
CONFIG_MANDATORY_FILE_LOCKING. It seems our kernel still defaults to
CONFIG_MANDATORY_FILE_LOCKING=y. If feasible I'd like to propose
disabling
Public bug reported:
Hello,
Upstream is dicussing the removal of mandatory locks. To actually do
this at some point distros will need to start disabling
CONFIG_MANDATORY_FILE_LOCKING. It seems our kernel still defaults to
CONFIG_MANDATORY_FILE_LOCKING=y. If feasible I'd like to propose
disabling
** Changed in: linux-meta-hwe-5.11 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-meta-hwe-5.11 in Ubuntu.
https://bugs.launchpad.net/bugs/1939301
Title:
REGRESSION: shiftfs lets sendfile
** Changed in: linux-meta-hwe-5.11 (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1939301
Title:
REGRESSION: shiftfs lets sendfile fail with EINVAL
To
** Changed in: lxc (Ubuntu Impish)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1938771
Title:
lxc-test-rootfs test regression
** Changed in: lxc (Ubuntu Impish)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1938771
Title:
lxc-test-rootfs test regression with 4.0.10-0ubuntu3
To
Also added tests around rootfs mount options.
** Changed in: lxc (Ubuntu Impish)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1938771
Also added tests around rootfs mount options.
** Changed in: lxc (Ubuntu Impish)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1938771
Title:
Thanks for reporting this. I've fixed this in:
https://github.com/lxc/lxc/pull/3921
** Changed in: lxc (Ubuntu Impish)
Status: New => Confirmed
** Changed in: lxc (Ubuntu Impish)
Assignee: (unassigned) => Christian Brauner (cbrauner)
--
You received this bug notification b
Thanks for reporting this. I've fixed this in:
https://github.com/lxc/lxc/pull/3921
** Changed in: lxc (Ubuntu Impish)
Status: New => Confirmed
** Changed in: lxc (Ubuntu Impish)
Assignee: (unassigned) => Christian Brauner (cbrauner)
--
You received this bug notification b
nstead of
> relying on an extra null at the end).
>
> Christoph was finding it hard to find time so I took his patches,
> added my changes in patch3 and reposting the patch series.
>
> I have tested it with 9p, virtiofs and ext4 filesystems as rootfs
>
Hm, what is the LXC version used here? Is it the one in Bionic?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1776381
Title:
lxc-test-api-reboot will hang with autopkgtest
Hm, what is the LXC version used here? Is it the one in Bionic?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1776381
Title:
lxc-test-api-reboot will hang with autopkgtest
To manage notifications
and special files), and currently that fails. This
> patch should help.
>
> Link:
> https://lore.kernel.org/linux-fsdevel/20210625191229.1752531-1-vgo...@redhat.com/
> Signed-off-by: Vivek Goyal
> ---
Seems reasonable and useful.
Acked-by: Christian Brauner
One question,
On Fri, Jun 25, 2021 at 03:12:29PM -0400, Vivek Goyal wrote:
> As of now user.* xattrs are allowed only on regular files and directories.
> And in case of directories if sticky bit is set, then it is allowed
> only if caller is owner or has CAP_FOWNER.
>
> "man xattr" suggests that primary reason
I'm currently treating this as an upstream kernel regression reported
here
https://lore.kernel.org/regressions/20210607142245.eikvyeacqwwu6dn3@wittgenstein
We should wait whether a simple revert will be acceptable or whether
anything else is needed from LXC specifically.
--
You received this
I'm currently treating this as an upstream kernel regression reported
here
https://lore.kernel.org/regressions/20210607142245.eikvyeacqwwu6dn3@wittgenstein
We should wait whether a simple revert will be acceptable or whether
anything else is needed from LXC specifically.
--
You received this
On Mon, Jun 07, 2021 at 05:14:50AM -, Andrea Righi wrote:
> Public bug reported:
>
> The lxc autotest is failing with the following error(s) on the latest
> kernel linux-unstable 5.13:
>
> FAIL: lxc-tests: lxc-test-apparmor (1s)
> ---
> failed - opened /sys/kernel/uevent_helper
> ---
> PASS:
On Mon, Jun 07, 2021 at 05:14:50AM -, Andrea Righi wrote:
> Public bug reported:
>
> The lxc autotest is failing with the following error(s) on the latest
> kernel linux-unstable 5.13:
>
> FAIL: lxc-tests: lxc-test-apparmor (1s)
> ---
> failed - opened /sys/kernel/uevent_helper
> ---
> PASS:
--
That's helpful, thanks
Acked-by: Christian Brauner
--
Linux-cachefs mailing list
Linux-cachefs@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-cachefs
@@
> #include
> #include
> #include
> -#include
> +#include // struct open_how
>
> #include "audit.h"
>
> @@ -1319,6 +1319,12 @@ static void show_special(struct audit_context
> *context, int *call_panic)
> audit_log_format(ab,
; @@ -76,6 +76,7 @@
> #include
> #include
> #include
> +#include
>
> #include "audit.h"
>
> @@ -196,6 +197,8 @@ static int audit_match_perm(struct audit_context *ctx,
> int mask)
> return ((mask & AUDIT_PERM_WRITE) && ctx-
d 32 bit in any compat code, causing
> redefinition warnings.
>
> Signed-off-by: Richard Guy Briggs
> Link:
> https://lore.kernel.org/r/2300b1083a32aade7ae7efb95826e8f3f260b1df.1621363275.git@redhat.com
Looks good.
Acked-by: Christian Brauner
Fwiw, I would exp
; @@ -76,6 +76,7 @@
> #include
> #include
> #include
> +#include
>
> #include "audit.h"
>
> @@ -196,6 +197,8 @@ static int audit_match_perm(struct audit_context *ctx,
> int mask)
> return ((mask & AUDIT_PERM_WRITE) && ctx->argv[0] == SYS_BIND);
> case AUDITSC_EXECVE:
> return mask & AUDIT_PERM_EXEC;
> + case AUDITSC_OPENAT2:
> + return mask & ACC_MODE((u32)((struct open_how
> *)ctx->argv[2])->flags);
That's a lot of dereferncing, casting and masking all at once. Maybe a
small static inline helper would be good for the sake of legibility? Sm
like:
static inline u32 audit_openat2_acc(struct open_how *how, int mask)
{
u32 flags = how->flags;
return mask & ACC_MODE(flags);
}
but not sure. Just seems more legible to me.
Otherwise.
Acked-by: Christian Brauner
d 32 bit in any compat code, causing
> redefinition warnings.
>
> Signed-off-by: Richard Guy Briggs
> Link:
> https://lore.kernel.org/r/2300b1083a32aade7ae7efb95826e8f3f260b1df.1621363275.git@redhat.com
Looks good.
Acked-by: Christian Brauner
Fwiw, I would exp
Looking forward to seeing you all (virtually) there! :)
Stéphane Graber (Canonical)
Mike Rapoport (IBM)
Christian Brauner (Canonical)
Adrian Reber (Red Hat)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org
On Thu, Apr 22, 2021 at 10:34:08PM -0400, Richard Guy Briggs wrote:
> On 2021-03-18 08:08, Richard Guy Briggs wrote:
> > On 2021-03-18 11:48, Christian Brauner wrote:
> > > [+Cc Aleksa, the author of openat2()]
> >
> > Ah! Thanks for pulling in Aleksa
c2d3eaa83 ("Revert
> 95ebabde382c ("capabilities: Don't allow writing ambiguous v3 file
> capabilities")").
>
> [1]: https://github.com/containers/buildah/issues/3071
>
> Signed-off-by: Serge Hallyn
> Reviewed-by: Andrew G. Morgan
> Tested-by: Christian B
On Mon, Apr 19, 2021 at 10:42:08PM -0500, Serge Hallyn wrote:
> On Mon, Apr 19, 2021 at 06:09:11PM +0200, Christian Brauner wrote:
> > On Mon, Apr 19, 2021 at 07:25:14AM -0500, Serge Hallyn wrote:
> > > cap_setfcap is required to create file capabilities.
> > >
abde382c ("capabilities: Don't allow writing ambiguous v3 file
capabilities")
> Signed-off-by: Serge Hallyn
> Reviewed-by: Andrew G. Morgan
> Tested-by: Christian Brauner
> Reviewed-by: Christian Brauner
> Cc: "Eric W. Biederman"
On Mon, Apr 19, 2021 at 05:52:39PM +0200, Giuseppe Scrivano wrote:
> ebied...@xmission.com (Eric W. Biederman) writes:
>
> > Guiseppe can you take a look at this?
> >
> > This is a second attempt at tightening up the semantics of writing to
> > file capabilities from a user namespace.
> >
> > The
On Mon, Apr 19, 2021 at 07:33:04PM +0800, Wan Jiabing wrote:
> struct path is declared at 85th line.
> The declaration here is unnecessary. Remove it.
>
> Signed-off-by: Wan Jiabing
> ---
Looks good,
Reviewed-by: Christian Brauner
verify_root_mapping to Christian's suggested flow
> ---
Thank you. This looks good. I tested this with:
- fstests
- LXD testsuite
- Podman testsuite
- libcap testsuite
Tested-by: Christian Brauner
Reviewed-by: Christian Brauner
On Fri, Apr 16, 2021 at 05:58:25PM +0200, Christian Brauner wrote:
> On Fri, Apr 16, 2021 at 03:35:59PM +, Al Viro wrote:
> > On Fri, Apr 16, 2021 at 05:13:10PM +0200, Christian Brauner wrote:
> >
> > > My point here was more that the _file_ has already been opened
On Fri, Apr 16, 2021 at 03:35:59PM +, Al Viro wrote:
> On Fri, Apr 16, 2021 at 05:13:10PM +0200, Christian Brauner wrote:
>
> > My point here was more that the _file_ has already been opened _before_
> > that call to io_uring_add_task_file(). But any potential non-trivia
On Fri, Apr 16, 2021 at 02:09:35PM +, Al Viro wrote:
> On Fri, Apr 16, 2021 at 03:42:52PM +0200, Christian Brauner wrote:
> > > > are drivers/dma-buf/sw_sync.c and drivers/dma-buf/sync_file.c, etc.
> > >
> > > FWIW, pretty much all ioctls that return
On Thu, Apr 15, 2021 at 11:58:51PM -0500, Serge Hallyn wrote:
> (Eric - this patch (v3) is a cleaned up version of the previous approach.
> v4 is at
> https://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux.git/log/?h=2021-04-15/setfcap-nsfscaps-v4
> and is the approach you suggested. I can
On Fri, Apr 16, 2021 at 04:15:43AM +, Al Viro wrote:
> On Fri, Apr 02, 2021 at 12:01:05PM -0700, Kees Cook wrote:
> > On Thu, Mar 25, 2021 at 09:22:09AM +0100, Christoph Hellwig wrote:
> > > receive_fd_replace shares almost no code with the general case, so split
> > > it out. Also remove the
On Fri, Apr 16, 2021 at 05:55:16AM +, Al Viro wrote:
> On Fri, Apr 16, 2021 at 05:19:50AM +, Al Viro wrote:
> > On Thu, Apr 01, 2021 at 12:40:34PM +0200, Christian Brauner wrote:
>
> > > and see whether all of them can be switched to simply using
> > > re
On Wed, Apr 14, 2021 at 12:46:01PM +0300, Mike Rapoport wrote:
> On Wed, Apr 14, 2021 at 10:46:05AM +0200, Christian Brauner wrote:
> > On Wed, Apr 14, 2021 at 08:14:22AM +0200, Mauro Carvalho Chehab wrote:
> > > Em Tue, 13 Apr 2021 21:40:20 -0700
> > > Yury Norov es
From: Christian Brauner
So far ecryptfs only verified that the superblock wasn't read-only but
didn't check whether the mount was. This made sense when we did not use
a private mount because the read-only state could change at any point.
Now that we have a private mount and mount properties
From: Christian Brauner
Since [1] we support creating private mounts from a given path's
vfsmount. This makes them very suitable for any filesystem or
filesystem functionality that piggybacks on paths of another filesystem.
Overlayfs, cachefiles, and ecryptfs are three prime examples.
Since
From: Christian Brauner
So far cachefiles only verified that the superblock wasn't read-only but
didn't check whether the mount was. This made sense when we did not use
a private mount because the read-only state could change at any point.
Now that we have a private mount and mount properties
From: Christian Brauner
Document mnt_clone_internal().
Cc: Amir Goldstein
Cc: Christoph Hellwig
Cc: Miklos Szeredi
Cc: Al Viro
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: Christian Brauner
---
fs/namespace.c | 16
1 file changed, 16 insertions(+)
diff --git a/fs
From: Christian Brauner
We're about to switch all filesystems that stack on top or otherwise use
a struct path of another filesystem to use clone_private_mount() in the
following commits. Most of these filesystems like ecryptfs and
cachefiles don't need the MS_UNBDINDABLE check that overlayfs
From: Christian Brauner
Since [1] we support creating private mounts from a given path's
vfsmount. This makes them very suitable for any filesystem or
filesystem functionality that piggybacks on paths of another filesystem.
Overlayfs and ecryptfs (which I'll port next) are just two such
examples
From: Christian Brauner
Extend the kernel documentation for clone_private_mount(). Add some more
detailed info about its usage and convert it into proper kernel doc.
Cc: Amir Goldstein
Cc: Christoph Hellwig
Cc: Miklos Szeredi
Cc: Al Viro
Cc: linux-fsde...@vger.kernel.org
Signed-off
From: Christian Brauner
Hey,
Since [1] we support creating private mounts from a given path's
vfsmount. This makes them very suitable for any filesystem or
filesystem functionality that piggybacks on paths of another filesystem.
Overlayfs, cachefiles, and ecryptfs are three prime examples
Kernels with 32-bits userspace and when cameras started
> being supported on arm32.
>
> We did have some real bugs with "enum", as, on that time, some
> compilers (gcc, I guess) were optimizing them to have less than
> 32 bits on certain architectures, when it fits.
Fwiw, Ale
+0x270b2)
```
Signed-off-by: Evgeny Vereshchagin
Commit: c4142ec2a0ccffcfa6e78c01e8b60cf3848e1244
https://github.com/lxc/lxc/commit/c4142ec2a0ccffcfa6e78c01e8b60cf3848e1244
Author: Christian Brauner
Date: 2021-04-13 (Tue, 13 Apr 2021)
Changed paths:
M src/tests/cgpath.c
Log
present since 5.9, when addfd was added.
>
> Fixes: 7cf97b1254550
> Cc: sta...@vger.kernel.org # 5.9+
> Signed-off-by: Rodrigo Campos
> ---
So the agent will see the return value from
wait_for_completion_interruptible() and know that the addfd wasn't
successful and the target will notice that no addfd request has actually
been added and essentially try again. Seems like a decent fix and can be
backported cleanly. I assume seccomp testsuite passes.
Acked-by: Christian Brauner
Branch: refs/heads/stable-4.0
Home: https://github.com/lxc/lxc
Commit: 8e2ef39ba53871acc526207285320a14f820d62d
https://github.com/lxc/lxc/commit/8e2ef39ba53871acc526207285320a14f820d62d
Author: Christian Brauner
Date: 2021-04-13 (Tue, 13 Apr 2021)
Changed paths:
M src
Vereshchagin
Commit: ca52b7ff13c8e37bb8c33feb38c1efe74fa73382
https://github.com/lxc/lxc/commit/ca52b7ff13c8e37bb8c33feb38c1efe74fa73382
Author: Christian Brauner
Date: 2021-04-13 (Tue, 13 Apr 2021)
Changed paths:
M src/tests/lxcpath.c
Log Message:
---
Merge
)
```
Signed-off-by: Evgeny Vereshchagin
Commit: 274615f9e3f2bbb0e2b7a9c007b6dcd54169404f
https://github.com/lxc/lxc/commit/274615f9e3f2bbb0e2b7a9c007b6dcd54169404f
Author: Christian Brauner
Date: 2021-04-13 (Tue, 13 Apr 2021)
Changed paths:
M src/tests/cgpath.c
Log Message
://github.com/lxc/lxc/commit/933acfaa431ed4d28bb3301dec0eae9cc375b422
Author: Christian Brauner
Date: 2021-04-12 (Mon, 12 Apr 2021)
Changed paths:
M src/lxc/commands.c
M src/lxc/confile.c
M src/lxc/lxccontainer.c
Log Message:
---
confile: make lxc_get_config
!
Christian
for-linus-2021-04-08
Christian Brauner (1):
file: fix close_range() for unshare+cloexec
fs/file.c | 21 +
1 file changed, 17 insertions
On Wed, Apr 07, 2021 at 02:46:11PM -0700, Daniel Xu wrote:
> This commit introduces the bpf page cache iterator. This iterator allows
> users to run a bpf prog against each page in the "page cache".
> Internally, the "page cache" is extremely tied to VFS superblock + inode
> combo. Because of
On Wed, Apr 07, 2021 at 02:46:10PM -0700, Daniel Xu wrote:
> There currently does not exist a way to answer the question: "What is in
> the page cache?". There are various heuristics and counters but nothing
> that can tell you anything like:
>
> * 3M from /home/dxu/foo.txt
> * 5K from ...
>
://github.com/lxc/lxc/commit/33c0a5466e0d7789a2971ae212a5885b7b31ed46
Author: Christian Brauner
Date: 2021-04-07 (Wed, 07 Apr 2021)
Changed paths:
M .github/workflows/build.yml
M .github/workflows/cifuzz.yml
M .github/workflows/coverity.yml
M .github/workflows/static
Log Message:
---
cifuzz: fuzz longer
Signed-off-by: Evgeny Vereshchagin
Commit: b425aad13f4a2a5e10a50e37dad83b771312a108
https://github.com/lxc/lxc/commit/b425aad13f4a2a5e10a50e37dad83b771312a108
Author: Christian Brauner
Date: 2021-04-07 (Wed, 07 Apr 2021)
Changed pa
On Wed, Apr 07, 2021 at 08:28:07AM +1000, Dave Chinner wrote:
> On Mon, Apr 05, 2021 at 11:18:48AM +0530, Bharata B Rao wrote:
> > Hi,
> >
> > When running 1 (more-or-less-empty-)containers on a bare-metal Power9
> > server(160 CPUs, 2 NUMA nodes, 256G memory), it is seen that memory
> >
On Wed, Apr 07, 2021 at 01:54:48PM +0200, Michal Hocko wrote:
> On Mon 05-04-21 11:18:48, Bharata B Rao wrote:
> > Hi,
> >
> > When running 1 (more-or-less-empty-)containers on a bare-metal Power9
> > server(160 CPUs, 2 NUMA nodes, 256G memory), it is seen that memory
> > consumption
etermined
> by posix_acl_update_mode().
>
> Cc: Christian Brauner
> Cc: Andreas Gruenbacher
> Signed-off-by: Roberto Sassu
> ---
Looks good,
Reviewed-by: Christian Brauner
signatures are immutable, all subsequent operations
> fail (e.g. fchown()), even if the operation is legitimate (does not alter
> the current value).
>
> This patch avoids this problem by reporting successful operation to user
> space when that operation does not alter the current valu
On Wed, Apr 07, 2021 at 01:30:19PM +0300, Amir Goldstein wrote:
> On Wed, Apr 7, 2021 at 12:02 PM Christian Brauner wrote:
> >
> > From: Christian Brauner
> >
> > So far cachefiles only verified that the superblock wasn't read-only but
> > didn't check whether th
Log Message:
---
cifuzz: fuzz longer
Signed-off-by: Evgeny Vereshchagin
Commit: 9d984c3fb5b4ae386ef956704977dc687488c74e
https://github.com/lxc/lxc/commit/9d984c3fb5b4ae386ef956704977dc687488c74e
Author: Christian Brauner
Date: 2021-04-07 (Wed, 07 Apr 2021)
Changed paths:
From: Christian Brauner
So far cachefiles only verified that the superblock wasn't read-only but
didn't check whether the mount was. This made sense when we did not use
a private mount because the read-only state could change at any point.
Now that we have a private mount and mount properties
From: Christian Brauner
Since [1] we support creating private mounts from a given path's
vfsmount. This makes them very suitable for any filesystem or
filesystem functionality that piggybacks on paths of another filesystem.
Overlayfs and ecryptfs (which I'll port next) are just two such
examples
ase. (Be good to see kbuild do an allmodconfig build
of this though.)
Acked-by: Christian Brauner
> arch/powerpc/kernel/setup-common.c | 1 +
> arch/x86/include/asm/desc.h | 1 +
> arch/x86/kernel/cpu/mshyperv.c | 1 +
> arch/x86/kernel/setup.c | 1 +
&g
ase. (Be good to see kbuild do an allmodconfig build
of this though.)
Acked-by: Christian Brauner
> arch/powerpc/kernel/setup-common.c | 1 +
> arch/x86/include/asm/desc.h | 1 +
> arch/x86/kernel/cpu/mshyperv.c | 1 +
> arch/x86/kernel/setup.c | 1 +
&g
On Tue, Apr 06, 2021 at 02:15:01PM +, Al Viro wrote:
> On Tue, Apr 06, 2021 at 03:22:05PM +0200, Christian Brauner wrote:
>
> > Why is a another function in charge of checking the return value of an
> > initialization function. If something like path_init() fails why is t
ase. (Be good to see kbuild do an allmodconfig build
of this though.)
Acked-by: Christian Brauner
> arch/powerpc/kernel/setup-common.c | 1 +
> arch/x86/include/asm/desc.h | 1 +
> arch/x86/kernel/cpu/mshyperv.c | 1 +
> arch/x86/kernel/setup.c | 1 +
&g
ase. (Be good to see kbuild do an allmodconfig build
of this though.)
Acked-by: Christian Brauner
> arch/powerpc/kernel/setup-common.c | 1 +
> arch/x86/include/asm/desc.h | 1 +
> arch/x86/kernel/cpu/mshyperv.c | 1 +
> arch/x86/kernel/setup.c | 1 +
&g
On Tue, Apr 06, 2021 at 01:13:13PM +, Al Viro wrote:
> On Tue, Apr 06, 2021 at 02:35:05PM +0200, Christian Brauner wrote:
>
> > And while we're at it might I bring up the possibility of an additional
> > cleanup of how we currently call path_init().
> > Right now we pa
On Tue, Apr 06, 2021 at 01:38:39AM +, Al Viro wrote:
> On Mon, Apr 05, 2021 at 10:07:37PM +0200, Christian Brauner wrote:
>
> > > diff --git a/fs/namei.c b/fs/namei.c
> > > index 216f16e74351..82344f1139ff 100644
> > > --- a/fs/namei.c
> > > +++ b/fs/
On Tue, Apr 06, 2021 at 10:12:25AM +0100, David Howells wrote:
> Christian Brauner wrote:
>
> > Besides that - and probably irrelevant from the perspective of a
> > cachefiles developer - it also makes things simpler for a variety of
> > other vfs features. One conc
601 - 700 of 5019 matches
Mail list logo
