On Mon, 13 May 2024 17:50:30 +, Justin Stitt wrote:
> Running syzkaller with the newly enabled signed integer overflow
> sanitizer produces this report:
>
> [ 195.401651] [ cut here ]
> [ 195.404808] UBSAN: signed-integer-overflow in ../fs/open.c:321:15
> [
> For the uapi issue you describe below my take would be that we should just
> try, and hope that everyone's been dutifully using O_CLOEXEC. But maybe
> I'm biased from the gpu world, where we've been hammering it in that
> "O_CLOEXEC or bust" mantra since well over a decade. Really the only valid
On Thu, May 09, 2024 at 08:48:20AM -0700, Linus Torvalds wrote:
> On Thu, 9 May 2024 at 04:39, Christian Brauner wrote:
> >
> > Not worth it without someone explaining in detail why imho. First pass
> > should be to try and replace kcmp() in scenarios where it's obv
On Wed, May 08, 2024 at 10:14:44AM -0700, Linus Torvalds wrote:
> On Wed, 8 May 2024 at 09:19, Linus Torvalds
> wrote:
> >
> > So since we already have two versions of F_DUPFD (the other being
> > F_DUPFD_CLOEXEC) I decided that the best thing to do is to just extend
> > on that existing naming
On Wed, May 08, 2024 at 10:32:08AM +0200, Daniel Vetter wrote:
> On Wed, May 08, 2024 at 07:55:08AM +0200, Christian König wrote:
> > Am 07.05.24 um 21:07 schrieb Linus Torvalds:
> > > On Tue, 7 May 2024 at 11:04, Daniel Vetter wrote:
> > > > On Tue, May 07, 2024 at 09:46:31AM -0700, Linus
On Mon, May 06, 2024 at 04:29:44PM +0200, Christian König wrote:
> Am 04.05.24 um 20:20 schrieb Linus Torvalds:
> > On Sat, 4 May 2024 at 08:32, Linus Torvalds
> > wrote:
> > > Lookie here, the fundamental issue is that epoll can call '->poll()'
> > > on a file descriptor that is being closed
On Tue, May 07, 2024 at 07:45:02PM +0200, Christian König wrote:
> Am 07.05.24 um 18:46 schrieb Linus Torvalds:
> > On Tue, 7 May 2024 at 04:03, Daniel Vetter wrote:
> > > It's really annoying that on some distros/builds we don't have that, and
> > > for gpu driver stack reasons we _really_ need
On Tue, May 07, 2024 at 12:07:10PM -0700, Linus Torvalds wrote:
> On Tue, 7 May 2024 at 11:04, Daniel Vetter wrote:
> >
> > On Tue, May 07, 2024 at 09:46:31AM -0700, Linus Torvalds wrote:
> >
> > > I'd be perfectly ok with adding a generic "FISAME" VFS level ioctl
> > > too, if this is possibly a
On Mon, May 06, 2024 at 02:47:23PM +0200, Daniel Vetter wrote:
> On Sun, May 05, 2024 at 01:53:48PM -0700, Linus Torvalds wrote:
> > On Sun, 5 May 2024 at 13:30, Al Viro wrote:
> > >
> > > 0. special-cased ->f_count rule for ->poll() is a wart and it's
> > > better to get rid of it.
> > >
>
On Mon, May 06, 2024 at 11:27:04AM +0200, Christian Brauner wrote:
> On Mon, May 06, 2024 at 10:45:35AM +0200, Christian Brauner wrote:
> > > The fact is, it's not dma-buf that is violating any rules. It's epoll.
> >
> > I agree that epoll() not taking a reference
On Mon, May 06, 2024 at 10:45:35AM +0200, Christian Brauner wrote:
> > The fact is, it's not dma-buf that is violating any rules. It's epoll.
>
> I agree that epoll() not taking a reference on the file is at least
> unexpected and contradicts the usual code patterns for the sake o
> The fact is, it's not dma-buf that is violating any rules. It's epoll.
I agree that epoll() not taking a reference on the file is at least
unexpected and contradicts the usual code patterns for the sake of
performance and that it very likely is the case that most callers of
f_op->poll() don't
On Sat, May 04, 2024 at 08:40:25AM -0700, Linus Torvalds wrote:
> On Sat, 4 May 2024 at 08:32, Linus Torvalds
> wrote:
> >
> > Now, during this TOTALLY INNOCENT sock_poll(), in another thread, the
> > file closing completes, eventpoll_release() finishes [..]
>
> Actually, Al is right that
On Sat, May 04, 2024 at 12:39:00AM +0100, Al Viro wrote:
> On Fri, May 03, 2024 at 04:16:15PM -0700, Linus Torvalds wrote:
> > On Fri, 3 May 2024 at 15:07, Al Viro wrote:
> > >
> > > Suppose your program calls select() on a pipe and dmabuf, sees data to be
> > > read
> > > from pipe, reads it,
On Fri, May 03, 2024 at 12:59:52PM -0700, Kees Cook wrote:
> On Fri, May 03, 2024 at 01:35:09PM -0600, Jens Axboe wrote:
> > On 5/3/24 1:22 PM, Kees Cook wrote:
> > > On Fri, May 03, 2024 at 12:49:11PM -0600, Jens Axboe wrote:
> > >> On 5/3/24 12:26 PM, Kees Cook wrote:
> > >>> Thanks for doing
On Fri, May 03, 2024 at 11:26:32AM -0700, Kees Cook wrote:
> On Fri, May 03, 2024 at 06:54:22PM +0700, Bui Quang Minh wrote:
> > [...]
> > Root cause:
> > AFAIK, eventpoll (epoll) does not increase the registered file's reference.
> > To ensure the safety, when the registered file is deallocated
On Fri, 03 May 2024 13:16:25 -0700, Kees Cook wrote:
> It should never happen that get_file() is called on a file with
> f_count equal to zero. If this happens, a use-after-free condition
> has happened[1], and we need to attempt a best-effort reporting of
> the situation to help find the root
On Fri, May 03, 2024 at 02:33:37PM -0700, Linus Torvalds wrote:
> On Fri, 3 May 2024 at 14:24, Al Viro wrote:
> >
> > Can we get to ep_item_poll(epi, ...) after eventpoll_release_file()
> > got past __ep_remove()? Because if we can, we have a worse problem -
> > epi freed under us.
>
> Look at
On Fri, May 03, 2024 at 04:41:19PM -0700, Linus Torvalds wrote:
> On Fri, 3 May 2024 at 16:23, Kees Cook wrote:
> >
> > static bool __must_check get_dma_buf_unless_doomed(struct dma_buf *dmabuf)
> > {
> > return atomic_long_inc_not_zero(>file->f_count) != 0L;
> > }
> >
> > If we end up
On Fri, May 03, 2024 at 12:36:14PM +0200, Peter Zijlstra wrote:
> On Fri, May 03, 2024 at 11:37:25AM +0200, Christian Brauner wrote:
> > On Thu, May 02, 2024 at 05:41:23PM -0700, Kees Cook wrote:
> > > On Fri, May 03, 2024 at 01:14:45AM +0100, Al Viro wrote:
> > > >
On Fri, May 03, 2024 at 12:36:14PM +0200, Peter Zijlstra wrote:
> On Fri, May 03, 2024 at 11:37:25AM +0200, Christian Brauner wrote:
> > On Thu, May 02, 2024 at 05:41:23PM -0700, Kees Cook wrote:
> > > On Fri, May 03, 2024 at 01:14:45AM +0100, Al Viro wrote:
> > > >
On Thu, May 02, 2024 at 05:41:23PM -0700, Kees Cook wrote:
> On Fri, May 03, 2024 at 01:14:45AM +0100, Al Viro wrote:
> > On Thu, May 02, 2024 at 05:10:18PM -0700, Kees Cook wrote:
> >
> > > But anyway, there needs to be a general "oops I hit 0"-aware form of
> > > get_file(), and it seems like
On Thu, May 02, 2024 at 05:41:23PM -0700, Kees Cook wrote:
> On Fri, May 03, 2024 at 01:14:45AM +0100, Al Viro wrote:
> > On Thu, May 02, 2024 at 05:10:18PM -0700, Kees Cook wrote:
> >
> > > But anyway, there needs to be a general "oops I hit 0"-aware form of
> > > get_file(), and it seems like
> Fix this by simply deleting the "binderfs_test:" Makefile target and
> letting lib.mk handle it instead.
>
> [1]
> https://lore.kernel.org/all/20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c...@valentinobst.de/
>
> Fixes: 6e29225af902 ("binderfs: port tests to test harness infrastructure")
> Cc: Christian Brauner
> Signed-off-by: John Hubbard
> ---
Reviewed-by: Christian Brauner
On Thu, May 02, 2024 at 05:25:33PM -0500, John Groves wrote:
> On 24/05/02 07:17PM, Al Viro wrote:
> > On Mon, Apr 29, 2024 at 12:04:23PM -0500, John Groves wrote:
> > > Famfs needs a slightly different kill_super variant than already existed.
> > > Putting it local to famfs would require
On Thu, May 02, 2024 at 04:03:24PM -0700, Kees Cook wrote:
> On Fri, May 03, 2024 at 12:53:56AM +0200, Jann Horn wrote:
> > On Fri, May 3, 2024 at 12:34 AM Kees Cook wrote:
> > > If f_count reaches 0, calling get_file() should be a failure. Adjust to
> > > use atomic_long_inc_not_zero() and
On Thu, May 02, 2024 at 04:03:24PM -0700, Kees Cook wrote:
> On Fri, May 03, 2024 at 12:53:56AM +0200, Jann Horn wrote:
> > On Fri, May 3, 2024 at 12:34 AM Kees Cook wrote:
> > > If f_count reaches 0, calling get_file() should be a failure. Adjust to
> > > use atomic_long_inc_not_zero() and
On Mon, Apr 29, 2024 at 09:19:09PM +0200, Mickaël Salaün wrote:
> Replace a wrong EXPECT_GT(self->child_pid_exited, 0) with EXPECT_GE(),
> which will be actually tested on the parent and child sides with a
> following commit.
>
> Cc: Christian Brauner
> Cc: Shuah Khan
>
On Mon, Apr 29, 2024 at 09:19:03PM +0200, Mickaël Salaün wrote:
> Required by switch_timens() to open /proc/self/ns/time_for_children.
>
> CONFIG_GENERIC_VDSO_TIME_NS is not available on UML, so pidfd_setns_test
> cannot be run successfully on this architecture.
>
> Cc: Chris
On Mon, Apr 29, 2024 at 12:04:24PM -0500, John Groves wrote:
> Start building up from the famfs module operations. This commit
> includes the following:
>
> * Register as a file system
> * Parse mount parameters
> * Allocate or find (and initialize) a superblock via famfs_get_tree()
> * Lookup
On Tue, Apr 23, 2024 at 05:30:52PM +0300, Amir Goldstein wrote:
> On Tue, Apr 23, 2024 at 4:21 PM Roberto Sassu
> wrote:
> >
> > On Tue, 2024-04-23 at 09:02 +0300, Amir Goldstein wrote:
> > > On Mon, Apr 22, 2024 at 6:07 PM Stefan Berger
> > > wrote:
> > > >
> > > > This series fixes the
On Fri, Apr 19, 2024 at 11:14:59AM +0800, Baokun Li wrote:
> Instead of allocating the erofs_sb_info in get_tree() allocate it during
> init_fs_context() and after this erofs_fs_context is no longer needed,
> so replace ctx with sbi, no functional changes.
>
> Suggested-by: Jingbo Xu
>
On Wed, Apr 17, 2024 at 08:22:22AM -0700, Nathan Chancellor wrote:
> Hi Christian,
>
> I am looking at tools/testing/selftests/clone3/clone3_set_tid.c as part
> of a patch to clean up the uses of 'return ksft_exit_...();' throughout
> the selftests (as they call exit() so they do not return) and
>From e4f586a41748b6edc05aca36d49b7b39e55def81 Mon Sep 17 00:00:00 2001
From: Christian Brauner
Date: Mon, 15 Apr 2024 20:17:46 +0800
Subject: [PATCH] erofs: reliably distinguish block based and fscache mode
When erofs_kill_sb() is called in block dev based mode, s_bdev may not have
been initia
On Mon, Apr 15, 2024 at 10:35:53PM +0800, Ming Lei wrote:
> On Mon, Apr 15, 2024 at 02:35:17PM +0200, Christian Brauner wrote:
> > On Mon, Apr 15, 2024 at 05:26:19PM +0800, Ming Lei wrote:
> > > Hello,
> > >
> > > On Tue, Jan 23, 2024 at 02:26:21PM +0100, Chr
On Mon, Apr 15, 2024 at 08:17:46PM +0800, Baokun Li wrote:
> When erofs_kill_sb() is called in block dev based mode, s_bdev may not have
> been initialised yet, and if CONFIG_EROFS_FS_ONDEMAND is enabled, it will
> be mistaken for fscache mode, and then attempt to free an anon_dev that has
> never
On Mon, Apr 15, 2024 at 05:26:19PM +0800, Ming Lei wrote:
> Hello,
>
> On Tue, Jan 23, 2024 at 02:26:21PM +0100, Christian Brauner wrote:
> > Signed-off-by: Christian Brauner
> > ---
> > drivers/md/dm.c | 23 +--
> > d
On Wed, Apr 10, 2024 at 06:40:22PM +0100, Al Viro wrote:
> On Wed, Apr 10, 2024 at 01:26:47PM -0400, Matthew Sakai wrote:
>
> > > 'dm_dev->bdev_file', it's ok to get inode from the file.
>
> It can be done much easier, though -
>
> [PATCH] dm-vdo: use bdev_nr_bytes(bdev) instead of
On Thu, Apr 04, 2024 at 11:19:00AM +0200, Jan Kara wrote:
> On Wed 03-04-24 14:54:03, Kees Cook wrote:
> > With adding __counted_by(handle_bytes) to struct file_handle, we need
> > to explicitly set it in the one place it wasn't yet happening prior to
> > accessing the flex array "f_handle".
> >
On Wed, Apr 03, 2024 at 01:58:15PM +0100, David Howells wrote:
> Christoph Hellwig wrote:
>
> > > So why are we bothering with EXPORT_SYMBOL at all? Why don't you just
> > > send a patch replace all of them with EXPORT_SYMBOL_GPL()?
> >
> > No my business.
>
> Clearly it is as you're
On Thu, 28 Mar 2024 16:33:52 +, David Howells wrote:
> The primary purpose of these patches is to rework the netfslib writeback
> implementation such that pages read from the cache are written to the cache
> through ->writepages(), thereby allowing the fscache page flag to be
> retired.
>
>
On Fri, 22 Mar 2024 21:41:18 +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> There is some care taken to ensure these destination buffers are
>
On Thu, Mar 28, 2024 at 01:24:25PM +0200, Roberto Sassu wrote:
> On 3/28/2024 12:08 PM, Christian Brauner wrote:
> > On Thu, Mar 28, 2024 at 12:53:40PM +0200, Roberto Sassu wrote:
> > > On 3/26/2024 12:40 PM, Christian Brauner wrote:
> > > >
On Thu, Mar 28, 2024 at 12:53:40PM +0200, Roberto Sassu wrote:
> On 3/26/2024 12:40 PM, Christian Brauner wrote:
> > > we can change the parameter of security_path_post_mknod() from
> > > dentry to inode?
> >
> > If all current callers only operate on the inode t
> we can change the parameter of security_path_post_mknod() from
> dentry to inode?
If all current callers only operate on the inode then it seems the best
to only pass the inode. If there's some reason someone later needs a
dentry the hook can always be changed.
For bigger changes it's also
On Mon, 25 Mar 2024 19:34:01 -0600, Gustavo A. R. Silva wrote:
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for
> array
On Sun, Mar 24, 2024 at 04:50:24PM +, Roberto Sassu wrote:
> > From: Al Viro [mailto:v...@ftp.linux.org.uk] On Behalf Of Al Viro
> > Sent: Sunday, March 24, 2024 6:47 AM
> > On Sun, Mar 24, 2024 at 12:00:15AM -0500, Steve French wrote:
> > > Anyone else seeing this kernel crash in do_mknodat
On Mon, Mar 11, 2024 at 11:43:00PM +0100, David Sterba wrote:
> On Mon, Mar 11, 2024 at 02:43:11PM +0100, Christian Brauner wrote:
> > On Mon, Mar 11, 2024 at 08:12:33AM +, Johannes Thumshirn wrote:
> > > On 08.03.24 03:29, Kent Overstreet wrote:
> > > > Add a n
On Mon, Mar 11, 2024 at 04:15:04PM -0400, Kent Overstreet wrote:
> On Mon, Mar 11, 2024 at 02:43:11PM +0100, Christian Brauner wrote:
> > On Mon, Mar 11, 2024 at 08:12:33AM +, Johannes Thumshirn wrote:
> > > On 08.03.24 03:29, Kent Overstreet wrote:
> > > >
On Mon, Mar 11, 2024 at 08:12:33AM +, Johannes Thumshirn wrote:
> On 08.03.24 03:29, Kent Overstreet wrote:
> > Add a new statx field for (sub)volume identifiers, as implemented by
> > btrfs and bcachefs.
> >
> > This includes bcachefs support; we'll definitely want btrfs support as
> > well.
> > > >
> > > > > > Link:
> > > > > > https://lore.kernel.org/linux-fsdevel/2uvhm6gweyl7iyyp2xpfryvcu2g3padagaeqcbiavjyiis6prl@yjm725bizncq/
> > > > > > Signed-off-by: Kent Overstreet
> > > > > > Cc: Josef Ba
On Thu, Mar 07, 2024 at 12:39:58PM -0500, Kent Overstreet wrote:
> On Mon, Mar 04, 2024 at 10:18:22AM +0100, Christian Brauner wrote:
> > On Sat, Mar 02, 2024 at 05:02:03PM -0500, Kent Overstreet wrote:
> > > Add a new statx field for (sub)volume identifiers.
> > >
&
On Thu, Mar 07, 2024 at 12:18:52PM +0800, Gao Xiang wrote:
> Hi,
>
> (try to +Cc Christian and Al here...)
>
> On 2024/3/7 11:41, Jingbo Xu wrote:
> > Hi Baokun,
> >
> > Thanks for catching this!
> >
> >
> > On 3/7/24 10:52 AM, Gao Xiang wrote:
> > > Hi Baokun,
> > >
> > > On 2024/3/7 10:44,
On Tue, Mar 05, 2024 at 01:46:56PM +0100, Roberto Sassu wrote:
> On Tue, 2024-03-05 at 10:12 +0100, Christian Brauner wrote:
> > On Mon, Mar 04, 2024 at 10:56:17AM -0600, Seth Forshee (DigitalOcean) wrote:
> > > On Mon, Mar 04, 2024 at 05:17:57PM +0100, Roberto Sassu wrote:
>
On Tue, 05 Mar 2024 13:27:06 +0100, Christian Brauner wrote:
> The vfs_getxattr_alloc() interface is a special-purpose in-kernel api
> that does a racy query-size+allocate-buffer+retrieve-data. It is used by
> EVM, IMA, and fscaps to retrieve xattrs. Recently, we've seen issues
> where
that are larger than that.
Link: https://lore.kernel.org/r/ZeXcQmHWcYvfCR93@do-x1extreme [1]
Signed-off-by: Christian Brauner
---
fs/xattr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/xattr.c b/fs/xattr.c
index 09d927603433..a53c930e3018 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -395,6
On Mon, Mar 04, 2024 at 10:56:17AM -0600, Seth Forshee (DigitalOcean) wrote:
> On Mon, Mar 04, 2024 at 05:17:57PM +0100, Roberto Sassu wrote:
> > On Mon, 2024-03-04 at 09:31 -0600, Seth Forshee (DigitalOcean) wrote:
> > > On Mon, Mar 04, 2024 at 11:19:54AM +0100, Roberto Sassu wrote:
> > > > On
nel.org/linux-fsdevel/2uvhm6gweyl7iyyp2xpfryvcu2g3padagaeqcbiavjyiis6prl@yjm725bizncq/
> Signed-off-by: Kent Overstreet
> Cc: Josef Bacik
> Cc: Miklos Szeredi
> Cc: Christian Brauner
> Cc: David Howells
> ---
As I've said many times before I'm supportive of this and would pick up
a patch like this. There's definitely
> I have seen this policy of adding tests in other subsystems (eBPF),
It makes sense if the drive of the patchset would be IMA/EVM features
not refactoring of existing code.
> Happy to try adding the tests, would appreciate your help to review if
Cool, happy to help review them.
On Fri, Mar 01, 2024 at 10:19:13AM +0100, Roberto Sassu wrote:
> On Wed, 2024-02-21 at 15:24 -0600, Seth Forshee (DigitalOcean) wrote:
> > Support the new fscaps security hooks by converting the vfs_caps to raw
> > xattr data and then handling them the same as other xattrs.
>
> Hi Seth
>
> I
On Wed, Feb 28, 2024 at 11:27:05PM -0800, Linus Torvalds wrote:
> On Wed, 28 Feb 2024 at 23:20, Linus Torvalds
> wrote:
> >
> >
> > - take the lock exclusively if O_APPEND or if it *looks* like you
> > might extend the file size.
> >
> > - otherwise, take the shared lock, and THEN RE-CHECK. The
On Wed, Feb 21, 2024 at 03:24:51PM -0600, Seth Forshee (DigitalOcean) wrote:
> Add handlers which read fs caps from the lower or upper filesystem and
> write/remove fs caps to the upper filesystem, performing copy-up as
> necessary.
>
> While fscaps only really make sense on regular files, the
On Wed, Feb 21, 2024 at 03:24:50PM -0600, Seth Forshee (DigitalOcean) wrote:
> Provide a type-safe interface for removing filesystem capabilities and a
> generic implementation suitable for most filesystems. Also add an
> internal interface, vfs_remove_fscaps_nosec(), which is called with the
>
On Wed, Feb 21, 2024 at 03:24:49PM -0600, Seth Forshee (DigitalOcean) wrote:
> Provide a type-safe interface for setting filesystem capabilities and a
> generic implementation suitable for most filesystems.
>
> Signed-off-by: Seth Forshee (DigitalOcean)
> ---
> fs/xattr.c | 79
>
dst_pos,
> loff_t len, unsigned int remap_flags);
> +extern int vfs_get_fscaps_nosec(struct mnt_idmap *idmap, struct dentry
> *dentry,
> + struct vfs_caps *caps);
> +extern int vfs_get_fscaps(struct mnt_idmap *idmap, struct dentry *dentry,
> + struct vfs_caps *caps);
Please drop the externs. Other than my usual complaing about this
falling back to the legacy vfs_*xattr() interfaces,
Reviewed-by: Christian Brauner
ed-off-by: Seth Forshee (DigitalOcean)
> ---
Looks good,
Reviewed-by: Christian Brauner
will need to
> convert to raw xattr data for verification and updates of its hashes.
>
> Signed-off-by: Seth Forshee (DigitalOcean)
> ---
Looks good,
Reviewed-by: Christian Brauner
On Wed, Feb 21, 2024 at 03:24:41PM -0600, Seth Forshee (DigitalOcean) wrote:
> Signed-off-by: Seth Forshee (DigitalOcean)
> ---
Looks good,
Reviewed-by: Christian Brauner
On Wed, Feb 21, 2024 at 03:24:40PM -0600, Seth Forshee (DigitalOcean) wrote:
> Signed-off-by: Seth Forshee (DigitalOcean)
> ---
Looks good,
Reviewed-by: Christian Brauner
oks good,
Reviewed-by: Christian Brauner
On Thu, Feb 22, 2024 at 09:38:04AM -0600, Seth Forshee (DigitalOcean) wrote:
> On Thu, Feb 22, 2024 at 04:20:08PM +0100, Christian Brauner wrote:
> > > + if ((magic_etc & VFS_CAP_REVISION_MASK) != VFS_CAP_REVISION_1) {
> > > + vfs_caps->permitted.val +=
> &g
On Wed, Feb 21, 2024 at 03:24:31PM -0600, Seth Forshee (DigitalOcean) wrote:
> This series converts filesystem capabilities from passing around raw
> xattr data to using a kernel-internal representation with type safe
> uids, similar to the conversion done previously for posix ACLs.
> Currently
licies.
>
> Signed-off-by: Seth Forshee (DigitalOcean)
> ---
Looks good,
Reviewed-by: Christian Brauner
On Wed, Feb 21, 2024 at 03:24:37PM -0600, Seth Forshee (DigitalOcean) wrote:
> To pass around vfs_caps instead of raw xattr data we will need to
> convert between the two representations near userspace and disk
> boundaries. We already convert xattrs from disks to vfs_caps, so move
> that code
gt;
> Acked-by: Paul Moore
> Signed-off-by: Seth Forshee (DigitalOcean)
> ---
Looks good,
Reviewed-by: Christian Brauner
On Wed, Feb 21, 2024 at 03:24:34PM -0600, Seth Forshee (DigitalOcean) wrote:
> Capability code depends on vfs_ns_cap_data being an extension of
> vfs_cap_data, so verify this at compile time.
>
> Suggested-by: Christian Brauner
> Signed-off-by: Seth Forshee (DigitalOcean)
&g
On Wed, Feb 21, 2024 at 03:24:33PM -0600, Seth Forshee (DigitalOcean) wrote:
> mnt_idmapping.h uses declarations from cred.h, so it should include that
> file directly.
>
> Signed-off-by: Seth Forshee (DigitalOcean)
> ---
Looks good,
Reviewed-by: Christian Brauner
.h though as it is
> defined in mnt_idmapping.h, which uses definitions from cred.h.
>
> Split out the core vfsid type definitions into a separate file which can
> be included from cred.h.
>
> Signed-off-by: Seth Forshee (DigitalOcean)
> ---
Looks good,
Reviewed-by: Christian Brauner
On Mon, Feb 19, 2024 at 09:38:33AM +0100, Linux regression tracking (Thorsten
Leemhuis) wrote:
> On 29.01.24 10:49, David Howells wrote:
> > Fix netfs_unbuffered_write_iter() to return immediately if
> > generic_write_checks() returns 0, indicating there's nothing to write.
> > Note that
On Sat, 17 Feb 2024 16:14:31 +0800, Baokun Li wrote:
> The following memory leak was reported after unbinding /dev/cachefiles:
>
> ==
> unreferenced object 0x9b674176e3c0 (size 192):
> comm "cachefilesd2", pid 680, jiffies
On Wed, Feb 14, 2024 at 08:18:01PM +0100, Oleg Nesterov wrote:
> On 02/14, Tycho Andersen wrote:
> >
> > On Wed, Feb 14, 2024 at 06:55:55PM +0100, Oleg Nesterov wrote:
> > >
> > > We want to check the "flags" argument at the start, we do not want to
> > > delay the "case 0:" check until we have
On Fri, Feb 02, 2024 at 11:50:07AM -0300, Gabriel Krisman Bertazi wrote:
> Eric Biggers writes:
>
> > On Wed, Jan 31, 2024 at 03:35:40PM -0300, Gabriel Krisman Bertazi wrote:
> >> Eric Biggers writes:
> >>
> >> > On Mon, Jan 29, 2024 at 05:43:22PM -0300, Gabriel Krisman Bertazi wrote:
> >> >>
On Fri, Feb 09, 2024 at 11:46:16AM +0100, Roberto Sassu wrote:
> On Fri, 2024-02-09 at 11:12 +0100, Christian Brauner wrote:
> > On Mon, Jan 15, 2024 at 07:17:56PM +0100, Roberto Sassu wrote:
> > > From: Roberto Sassu
> > >
> > > In preparation to move I
ation to be
> reverted.
>
> Signed-off-by: Roberto Sassu
> Reviewed-by: Stefan Berger
> Reviewed-by: Mimi Zohar
> Acked-by: Casey Schaufler
> ---
> fs/attr.c | 1 +
Acked-by: Christian Brauner
; reverted.
>
> Signed-off-by: Roberto Sassu
> Reviewed-by: Stefan Berger
> Reviewed-by: Mimi Zohar
> Reviewed-by: Casey Schaufler
> ---
> fs/xattr.c | 9 +
Acked-by: Christian Brauner
ease(file);
> ima_file_free(file);
This has always been an extremely dicy hook in here and that's caused us
issues before for stacking filesystems so I'm not enthusiastic about
exposing this to all LSMs. So reluctantly,
Acked-by: Christian Brauner
On Mon, Jan 15, 2024 at 07:17:56PM +0100, Roberto Sassu wrote:
> From: Roberto Sassu
>
> In preparation to move IMA and EVM to the LSM infrastructure, introduce the
> file_post_open hook. Also, export security_file_post_open() for NFS.
>
> Based on policy, IMA calculates the digest of the file
On Fri, Feb 09, 2024 at 10:56:33AM +0100, Christian Brauner wrote:
> On Mon, Jan 15, 2024 at 07:17:56PM +0100, Roberto Sassu wrote:
> > From: Roberto Sassu
> >
> > In preparation to move IMA and EVM to the LSM infrastructure, introduce the
> > file_p
>
> The new hook returns a value and can cause the open to be aborted.
>
> Signed-off-by: Roberto Sassu
> Reviewed-by: Stefan Berger
> Acked-by: Casey Schaufler
> Reviewed-by: Mimi Zohar
> ---
> fs/namei.c| 2 ++
Acked-by: Christian Brauner
;
> Signed-off-by: Roberto Sassu
> Acked-by: Casey Schaufler
> Reviewed-by: Mimi Zohar
> ---
> fs/namei.c | 5 +
Acked-by: Christian Brauner
y: Roberto Sassu
> Acked-by: Casey Schaufler
> Reviewed-by: Mimi Zohar
> ---
> fs/namei.c| 1 +
Acked-by: Christian Brauner
ation to be
> reverted.
>
> Signed-off-by: Roberto Sassu
> Reviewed-by: Stefan Berger
> Acked-by: Casey Schaufler
> Reviewed-by: Mimi Zohar
> ---
> fs/posix_acl.c| 1 +
Acked-by: Christian Brauner
everted.
>
> Signed-off-by: Roberto Sassu
> Reviewed-by: Stefan Berger
> Acked-by: Casey Schaufler
> Reviewed-by: Mimi Zohar
> ---
> fs/posix_acl.c| 1 +
Acked-by: Christian Brauner
in lsm_list_modules_test.c.
>
> Signed-off-by: Roberto Sassu
> Acked-by: Chuck Lever
> ---
> fs/file_table.c | 2 -
> fs/namei.c| 6 -
> fs/nfsd/vfs.c | 7 --
> fs/open.c | 1 -
Acked-by: Christian Brauner
-
> fs/posix_acl.c| 3 -
> fs/xattr.c| 2 -
Acked-by: Christian Brauner
(dentry, ia_valid);
> security_inode_post_setattr(idmap, dentry, ia_valid);
> - ima_inode_post_setattr(idmap, dentry, ia_valid);
> evm_inode_post_setattr(idmap, dentry, ia_valid);
> }
Acked-by: Christian Brauner
On Wed, Feb 07, 2024 at 03:34:59PM +0100, Paolo Bonzini wrote:
> On Wed, Nov 22, 2023 at 1:49 PM Christian Brauner wrote:
> >
> > Ever since the evenfd type was introduced back in 2007 in commit
> > e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_
On Wed, Feb 07, 2024 at 03:34:59PM +0100, Paolo Bonzini wrote:
> On Wed, Nov 22, 2023 at 1:49 PM Christian Brauner wrote:
> >
> > Ever since the evenfd type was introduced back in 2007 in commit
> > e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_
On Wed, Feb 07, 2024 at 03:34:59PM +0100, Paolo Bonzini wrote:
> On Wed, Nov 22, 2023 at 1:49 PM Christian Brauner wrote:
> >
> > Ever since the evenfd type was introduced back in 2007 in commit
> > e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_
On Fri, 02 Feb 2024 13:01:30 +0200, Amir Goldstein wrote:
> Miklos,
>
> When posting the patches for file_user_path(), I wrote [1]:
>
> "This change already makes file_dentry() moot, but for now we did not
> change this helper just added a WARN_ON() in ovl_d_real() to catch if we
> have made
1 - 100 of 5014 matches
Mail list logo
