(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
On Mon, Feb 05, 2024 at 07:06:00AM -0500, Jeff Layton wrote:
> On Mon, 2024-02-05 at 12:57 +0100, Christian Brauner wrote:
> > On Mon, Feb 05, 2024 at 06:55:44AM -0500, Jeff Layton wrote:
> > > On Mon, 2024-02-05 at 12:36 +0100, Christian Brauner wrote:
> > > >
On Mon, Feb 05, 2024 at 06:55:44AM -0500, Jeff Layton wrote:
> On Mon, 2024-02-05 at 12:36 +0100, Christian Brauner wrote:
> > > diff --git a/include/linux/filelock.h b/include/linux/filelock.h
> > > index 085ff6ba0653..a814664b1053 100644
> > > --- a/include/linux/
> diff --git a/include/linux/filelock.h b/include/linux/filelock.h
> index 085ff6ba0653..a814664b1053 100644
> --- a/include/linux/filelock.h
> +++ b/include/linux/filelock.h
> @@ -147,6 +147,29 @@ int fcntl_setlk64(unsigned int, struct file *, unsigned
> int,
> int fcntl_setlease(unsigned int
On Fri, Feb 02, 2024 at 02:41:16PM +0200, Amir Goldstein wrote:
> On Fri, Feb 2, 2024 at 2:19 PM Miklos Szeredi wrote:
> >
> > On Fri, 2 Feb 2024 at 12:01, Amir Goldstein wrote:
> >
> > > diff --git a/Documentation/filesystems/locking.rst
> > > b/Documentation/filesystems/locking.rst
> > >
On Thu, Feb 01, 2024 at 04:18:32PM +0200, Amir Goldstein wrote:
> On Thu, Feb 1, 2024 at 3:35 PM Christian Brauner wrote:
> >
> > On Wed, Jan 31, 2024 at 09:56:25AM -0500, Stefan Berger wrote:
> > >
> > >
> > > On 1/31/24 09:25, Christian Brauner wrote:
uest based on the patches. And this has a merge commit of the
following form:
commit 363af2435e403ac323ab2543da91f5984047bdb8
Merge: 6613476e225e 6c6109548454
Author: Christian Brauner
AuthorDate: Fri Feb 2 12:09:26 2024 +0100
Commit: Christian Brauner
CommitDate: Fri Feb 2 12:09:26 2024
On Wed, Jan 31, 2024 at 09:56:25AM -0500, Stefan Berger wrote:
>
>
> On 1/31/24 09:25, Christian Brauner wrote:
> > On Wed, Jan 31, 2024 at 03:25:29PM +0200, Amir Goldstein wrote:
> > > On Tue, Jan 30, 2024 at 11:46 PM Stefan Berger
> > > wrote:
> > &
On Wed, Jan 31, 2024 at 03:25:29PM +0200, Amir Goldstein wrote:
> On Tue, Jan 30, 2024 at 11:46 PM Stefan Berger wrote:
> >
> > Copying up xattrs is solely based on the security xattr name. For finer
> > granularity add a dentry parameter to the security_inode_copy_up_xattr
> > hook definition,
On Mon, 29 Jan 2024 10:40:15 -0800, Kees Cook wrote:
> The mix of int, unsigned int, and unsigned long used by struct
> poll_list::len, todo, len, and j meant that the signed overflow
> sanitizer got worried it needed to instrument several places where
> arithmetic happens between these variables.
On Mon, 29 Jan 2024 10:37:29 -0800, Kees Cook wrote:
> The loop counter "i" in copy_compat_iovec_from_user() is an int, but
> because the nr_segs argument is unsigned long, the signed overflow
> sanitizer got worried "i" could wrap around. Instead of making "i" an
> unsigned long (which may
On Mon, 29 Jan 2024 09:49:17 +, David Howells wrote:
> Here are a couple of fixes for netfslib:
>
> (1) Fix an i_dio_count leak on a DIO read starting beyond EOF.
>
> (2) Fix a missing zero-length check in an unbuffered write causing 9p to
> indicate EIO.
>
> [...]
Applied to the
://github.com/KSPP/linux/issues/344 [4]
> Cc: Benjamin LaHaise
> Cc: Alexander Viro
> Cc: Christian Brauner
> Cc: Jan Kara
> Cc: linux-...@kvack.org
> Cc: linux-fsde...@vger.kernel.org
> Signed-off-by: Kees Cook
> ---
What's the plan?
Merge the generic infrastructure and we can pick the individual patches?
On Mon, Jan 22, 2024 at 04:18:08PM +0100, Christian Brauner wrote:
> On Mon, Jan 22, 2024 at 12:38:33PM +, David Howells wrote:
> > Hi Christian,
> >
> > Here are some miscellaneous fixes for netfslib and a number of filesystems:
> >
> > (1) Replace folio_i
On Fri, Jan 19, 2024 at 11:33:37AM -0500, Paul Moore wrote:
> Hello all,
>
> I just noticed the recent addition of IORING_OP_FIXED_FD_INSTALL and I
> see that it is currently written to skip the io_uring auditing.
> Assuming I'm understanding the patch correctly, and I'll admit that
> I've only
On Mon, Jan 22, 2024 at 12:38:33PM +, David Howells wrote:
> Hi Christian,
>
> Here are some miscellaneous fixes for netfslib and a number of filesystems:
>
> (1) Replace folio_index() with folio->index in netfs, afs and cifs.
>
> (2) Fix an oops in fscache_put_cache().
>
> (3) Fix
On Mon, 22 Jan 2024 11:49:59 +, David Howells wrote:
> Update the MAINTAINERS records for netfs and cachefiles to reflect a change of
> mailing list for both as Red Hat no longer archives the mailing list in a
> publicly accessible place.
>
> Also add Jeff Layton as a reviewer.
Yay!
>
>
> May I take the liberty to ask why I don't see patch applied to above branch?
Just wasn't pushed yet. It is now.
On Thu, 11 Jan 2024 19:32:29 +0800, Hu Yadi wrote:
> Replace SYS_ with __NR_. Using the __NR_
> notation, provided by UAPI, is useful to build tests on systems without
> the SYS_ definitions.
>
> Replace SYS_move_mount with __NR_move_mount
>
> Similar changes: commit 87129ef13603
On Fri, 12 Jan 2024 15:40:59 +0800, Hu Yadi wrote:
> One build issue comes up due to both mount.h included dev_in_maps.c
>
> In file included from dev_in_maps.c:10:
> /usr/include/sys/mount.h:35:3: error: expected identifier before numeric
> constant
>35 | MS_RDONLY = 1, /* Mount
> I'd like to have this considered for inclusion in v6.9. Christian, would
> you be amenable to shepherding this into mainline (assuming there are no
> major objections, of course)?
Yes, of course I will be happy to.
On Thu, Jan 11, 2024 at 04:53:19PM -0500, Steven Rostedt wrote:
> On Thu, 11 Jan 2024 22:01:32 +0100
> Christian Brauner wrote:
>
> > What I'm pointing out in the current logic is that the caller is
> > taxed twice:
> >
> > (1) Once when the VFS has done inode_p
On Wed, Jan 10, 2024 at 08:07:46AM -0500, Steven Rostedt wrote:
> On Wed, 10 Jan 2024 12:45:36 +0100
> Christian Brauner wrote:
>
> > So say you do:
> >
> > mkdir /sys/kernel/tracing/instances/foo
> >
> > After this has returned we know everything we
On Mon, Jan 08, 2024 at 10:23:31AM -0500, Steven Rostedt wrote:
> On Mon, 8 Jan 2024 12:04:54 +0100
> Christian Brauner wrote:
>
> > > > IOW, the inode_permission() in lookup_one_len() that eventfs does is
> > > > redundant and just wrong.
> > >
&
On Sun, Jan 07, 2024 at 01:32:28PM -0500, Steven Rostedt wrote:
> On Sun, 7 Jan 2024 13:29:12 -0500
> Steven Rostedt wrote:
>
> > >
> > > IOW, the inode_permission() in lookup_one_len() that eventfs does is
> > > redundant and just wrong.
> >
> > I don't think so.
>
> Just to make it clear.
> > * Tracefs supports the creation of instances from userspace via mkdir.
> > For example,
> >
> > mkdir /sys/kernel/tracing/instances/foo
> >
> > And here the idmapping is relevant so we need to make the helpers
> > aware of the idmapping.
> >
> > I just went and plumbed this
On Sun, Jan 07, 2024 at 06:42:33PM +0100, Christian Brauner wrote:
> On Sun, Jan 07, 2024 at 01:42:39PM +0100, Christian Brauner wrote:
> > > > So tracefs supports remounting with different uid/gid mount options and
> > > > then actually wades through _all
On Sun, Jan 07, 2024 at 01:42:39PM +0100, Christian Brauner wrote:
> > > So tracefs supports remounting with different uid/gid mount options and
> > > then actually wades through _all_ of the inodes and changes their
> > > ownership internally? What's the us
e they already exist (they were created during mkdir) we just need
to splice in inodes and dentries for them. But for that we shouldn't
check permissions on the directory again. Because we've done that
already correctly when the VFS called may_lookup().
IOW, the inode_permission() in lookup_one_len(
On Wed, Jan 03, 2024 at 08:32:46PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (Google)"
>
> Instead of walking the dentries on mount/remount to update the gid values of
> all the dentries if a gid option is specified on mount, just update the root
> inode. Add .getattr, .setattr, and
On Wed, Jan 03, 2024 at 02:59:24PM +, David Howells wrote:
> Hi Christian, Jeff, Gao, Dominique,
>
> Here are some additional patches for my netfs-lib tree:
>
> (1) Fix __cachefiles_prepare_write() to correctly validate against the DIO
> alignment.
>
> (2) 9p: Fix initialisation of
On Sun, Dec 24, 2023 at 08:40:05AM -0800, syzbot wrote:
> syzbot suspects this issue was fixed by commit:
>
> commit fd1464105cb37a3b50a72c1d2902e97a71950af8
> Author: Jan Kara
> Date: Wed Oct 18 15:29:24 2023 +
>
> fs: Avoid grabbing sb->s_umount under bdev->bd_holder_lock
>
>
fied filesystems that don't support EVM based on a new SB_I flag.
We're wasting a flag for a single filesystem but we do have enough of
them left so I think this is ok,
Reviewed-by: Christian Brauner
On Wed, Dec 13, 2023 at 10:48:01AM +0100, Christian Brauner wrote:
> On Wed, Dec 13, 2023 at 08:46:54AM +1100, NeilBrown wrote:
> > On Wed, 13 Dec 2023, Miklos Szeredi wrote:
> > > On Tue, 12 Dec 2023 at 16:35, Kent Overstreet
> > > wrote:
> > >
> &g
On Wed, Dec 13, 2023 at 08:46:54AM +1100, NeilBrown wrote:
> On Wed, 13 Dec 2023, Miklos Szeredi wrote:
> > On Tue, 12 Dec 2023 at 16:35, Kent Overstreet
> > wrote:
> >
> > > Other poeple have been finding ways to contribute to the technical
> > > discussion; just calling things "ugly and
> But when you show up to a discussion that's been going on for a page,
On the bcachefs mailing list without fsdevel or anyone else Cced.
> where everything's been constructively gathering input, and you start
> namecalling - and crucially, _without giving any technical justification
I didn't
On Tue, Dec 12, 2023 at 10:16:31AM -0500, Kent Overstreet wrote:
> On Tue, Dec 12, 2023 at 09:56:45AM +0100, Christian Brauner wrote:
> > On Tue, Dec 12, 2023 at 08:32:55AM +0200, Amir Goldstein wrote:
> > > > > STATX_ATTR_INUM_NOT_UNIQUE - it is poss
On Tue, Dec 12, 2023 at 03:06:07PM +0100, Miklos Szeredi wrote:
> On Tue, 12 Dec 2023 at 14:48, Christian Brauner wrote:
>
> > Exposing the subvolume id in statx() is still fine imho. It's a concept
> > shared between btrfs and bcachefs and it's pretty useful for intere
On Tue, Dec 12, 2023 at 10:42:58AM +0100, Miklos Szeredi wrote:
> On Tue, 12 Dec 2023 at 10:35, Christian Brauner wrote:
>
> > So taking a step back here, please. The original motivation for this
> > discussion was restricted to handle btrfs - and now bcachefs as well.
>
On Tue, Dec 12, 2023 at 10:28:12AM +0100, Miklos Szeredi wrote:
> On Tue, 12 Dec 2023 at 10:23, Christian Brauner wrote:
> >
> > On Tue, Dec 12, 2023 at 09:10:47AM +, David Howells wrote:
> > > Christian Brauner wrote:
>
On Tue, Dec 12, 2023 at 09:10:47AM +, David Howells wrote:
> Christian Brauner wrote:
>
> > > > > I suggest:
> > > > >
> > > > > STATX_ATTR_INUM_NOT_UNIQUE - it is possible that two files have the
> > > > >
On Tue, Dec 12, 2023 at 01:13:07PM +1100, NeilBrown wrote:
> On Tue, 12 Dec 2023, Kent Overstreet wrote:
> > On Tue, Dec 12, 2023 at 11:59:51AM +1100, NeilBrown wrote:
> > > On Tue, 12 Dec 2023, Kent Overstreet wrote:
> > > > NFSv4 specs that for the maximum size? That is pretty hefty...
> > >
>
On Tue, Dec 12, 2023 at 08:32:55AM +0200, Amir Goldstein wrote:
> On Tue, Dec 12, 2023 at 7:53 AM Dave Chinner wrote:
> >
> > On Tue, Dec 12, 2023 at 11:59:51AM +1100, NeilBrown wrote:
> > > On Tue, 12 Dec 2023, Kent Overstreet wrote:
> > > > On Tue, Dec 12, 2023 at 10:53:07AM +1100, NeilBrown
> The second problem is that one security.evm is not enough. We need two,
> to store the two different HMACs. And we need both at the same time,
> since when overlayfs is mounted the lower/upper directories can be
> still accessible.
"Changes to the underlying filesystems while part of a mounted
On Fri, Dec 08, 2023 at 11:55:19PM +0200, Amir Goldstein wrote:
> On Fri, Dec 8, 2023 at 7:25 PM Roberto Sassu
> wrote:
> >
> > From: Roberto Sassu
> >
> > EVM updates the HMAC in security.evm whenever there is a setxattr or
> > removexattr operation on one of its protected xattrs (e.g.
On Fri, Dec 01, 2023 at 11:38:33AM -0600, Seth Forshee (DigitalOcean) wrote:
> On Fri, Dec 01, 2023 at 06:02:55PM +0100, Christian Brauner wrote:
> > On Wed, Nov 29, 2023 at 03:50:25PM -0600, Seth Forshee (DigitalOcean) wrote:
> > > Add inode operations for getting, setting and r
On Sat, Dec 02, 2023 at 01:34:32PM -0800, Kees Cook wrote:
> On Sat, Dec 02, 2023 at 09:28:46PM +, Al Viro wrote:
> > On Sat, Dec 02, 2023 at 01:22:13PM -0800, Kees Cook wrote:
> > > Allow __free(iput) markings for easier cleanup on inode allocations.
> >
> > NAK. That's a bloody awful idea
On Wed, Nov 29, 2023 at 03:50:27PM -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 | 87
>
On Wed, Nov 29, 2023 at 03:50:26PM -0600, Seth Forshee (DigitalOcean) wrote:
> Provide a type-safe interface for retrieving filesystem capabilities and
> a generic implementation suitable for most filesystems. Also add an
> internal interface, __vfs_get_fscaps(), which skips security checks for
>
struct vfs_caps *);
> + int (*set_fscaps)(struct mnt_idmap *, struct dentry *,
> + const struct vfs_caps *, int flags);
If it's really a flags argument, then unsigned int, please,
Reviewed-by: Christian Brauner
> + int (*remove_fscaps)(struct mnt_idmap *, str
On Wed, Nov 29, 2023 at 03:50:24PM -0600, Seth Forshee (DigitalOcean) wrote:
> cap_inode_getsecurity() implements a handful of policies for capability
> xattrs read by userspace:
>
> - It returns EINVAL if the on-disk capability is in v1 format.
>
> - It masks off all bits in magic_etc except
On Wed, Nov 29, 2023 at 03:50:23PM -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
to me,
Reviewed-by: Christian Brauner
> 2) lookup fails. It's already possible; e.g. if server has
I think that's the sanest option. The other options seem even less
intuitive.
> not fatal. The trouble is, that won't be a transient failure -
> not until somebody tries to look the old location up.
Eh, nfs semantics are quite
On Mon, Nov 27, 2023 at 09:10:54AM -0800, Linus Torvalds wrote:
> On Mon, 27 Nov 2023 at 02:27, Christian Brauner wrote:
> >
> > So I've picked up your patch (vfs.misc). It's clever alright so thanks
> > for the comments in there otherwise I would've stared at this for far
&g
On Mon, Nov 27, 2023 at 09:10:54AM -0800, Linus Torvalds wrote:
> On Mon, 27 Nov 2023 at 02:27, Christian Brauner wrote:
> >
> > So I've picked up your patch (vfs.misc). It's clever alright so thanks
> > for the comments in there otherwise I would've stared at this for far
&g
On Mon, Nov 27, 2023 at 06:38:42AM +, Al Viro wrote:
> On Sun, Nov 26, 2023 at 06:41:41PM +, Al Viro wrote:
>
> > d_invalidate() situation is more subtle - we need to sort out its interplay
> > with d_splice_alias().
> >
> > More concise variant of the scenario in question:
> > * we have
> So that nobody else would waste any time on this, attached is a new
> attempt. This time actually tested *after* the changes.
So I've picked up your patch (vfs.misc). It's clever alright so thanks
for the comments in there otherwise I would've stared at this for far
too long.
It's a little
> So that nobody else would waste any time on this, attached is a new
> attempt. This time actually tested *after* the changes.
So I've picked up your patch (vfs.misc). It's clever alright so thanks
for the comments in there otherwise I would've stared at this for far
too long.
It's a little
> I took a look at the code generation, and honestly, I think we're
> better off just making __fget_files_rcu() have special logic for this
> all, and not use __get_file_rcu().
My initial massaging of the patch did that btw. Then I sat there
wondering whether it would matter if we just made it
> I took a look at the code generation, and honestly, I think we're
> better off just making __fget_files_rcu() have special logic for this
> all, and not use __get_file_rcu().
My initial massaging of the patch did that btw. Then I sat there
wondering whether it would matter if we just made it
On Mon, 20 Nov 2023 12:14:17 +0800, Jia Zhu wrote:
> Changes since v5:
> In cachefiles_daemon_poll(), replace xa_for_each_marked with
> xas_for_each_marked.
>
> [Background]
>
> In the on-demand read mode, if user daemon unexpectedly closes an on-demand fd
> (for example, due to
On Wed, 22 Nov 2023 13:48:21 +0100, Christian Brauner wrote:
> Hey everyone,
>
> This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> significantly. They can be made void and not take any unnecessary
> arguments.
>
> I've added a few more simplifica
> root, a condition likely to be stable for a given test system.
>
> Signed-off-by: Mark Brown
> ---
May I already acked this. Not sure,
Acked-by: Christian Brauner
On Wed, 22 Nov 2023 13:48:21 +0100, Christian Brauner wrote:
> Hey everyone,
>
> This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> significantly. They can be made void and not take any unnecessary
> arguments.
>
> I've added a few more simplifica
On Wed, 22 Nov 2023 13:48:21 +0100, Christian Brauner wrote:
> Hey everyone,
>
> This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> significantly. They can be made void and not take any unnecessary
> arguments.
>
> I've added a few more simplifica
> > * eventfd_signal - Adds @n to the eventfd counter.
>
> This still refers to @n here, and in patch 4.
Fixed and folded. Thanks!
> > + if (!vgpu->msi_trigger)
> > + return;
> > + eventfd_signal(vgpu->msi_trigger, 1);
> > }
>
> I think it's a little simpler to write as
> if (vgpu->msi_trigger)
> eventfd_signal(vgpu->msi_trigger, 1);
Good point. I folded that suggestion into the patch.
On Thu, Nov 23, 2023 at 12:17:19PM +, Mark Brown wrote:
> On Thu, Nov 23, 2023 at 11:28:47AM +0100, Christian Brauner wrote:
> > On Mon, Nov 20, 2023 at 11:54:30PM +, Mark Brown wrote:
>
> > Any reasonably maximum that should be assumed here? IOW, what happens if
&g
On Thu, Nov 23, 2023 at 11:37:54AM +, Mark Brown wrote:
> On Thu, Nov 23, 2023 at 11:10:24AM +0100, Christian Brauner wrote:
> > On Tue, Nov 21, 2023 at 04:09:40PM +, Mark Brown wrote:
> > > On Tue, Nov 21, 2023 at 12:21:37PM +, Szabolcs Nagy wrote:
> >
> > * eventfd_signal - Adds @n to the eventfd counter.
>
> This still refers to @n here, and in patch 4.
Fixed and folded. Thanks!
> > * eventfd_signal - Adds @n to the eventfd counter.
>
> This still refers to @n here, and in patch 4.
Fixed and folded. Thanks!
> > + if (!vgpu->msi_trigger)
> > + return;
> > + eventfd_signal(vgpu->msi_trigger, 1);
> > }
>
> I think it's a little simpler to write as
> if (vgpu->msi_trigger)
> eventfd_signal(vgpu->msi_trigger, 1);
Good point. I folded that suggestion into the patch.
> > + if (!vgpu->msi_trigger)
> > + return;
> > + eventfd_signal(vgpu->msi_trigger, 1);
> > }
>
> I think it's a little simpler to write as
> if (vgpu->msi_trigger)
> eventfd_signal(vgpu->msi_trigger, 1);
Good point. I folded that suggestion into the patch.
On Mon, Nov 20, 2023 at 11:54:30PM +, Mark Brown wrote:
> Unlike with the normal stack there is no API for configuring the the shadow
> stack for a new thread, instead the kernel will dynamically allocate a new
> shadow stack with the same size as the normal stack. This appears to be due
> to
On Tue, Nov 21, 2023 at 04:09:40PM +, Mark Brown wrote:
> On Tue, Nov 21, 2023 at 12:21:37PM +, Szabolcs Nagy wrote:
> > The 11/21/2023 11:17, Christian Brauner wrote:
>
> > > I have a few questions that are probably me just not knowing much about
> > >
No caller care about the return value.
Signed-off-by: Christian Brauner
---
fs/eventfd.c| 40 +++-
include/linux/eventfd.h | 16 +++-
2 files changed, 22 insertions(+), 34 deletions(-)
diff --git a/fs/eventfd.c b/fs/eventfd.c
index
The eventfd_signal_mask() helper was introduced for io_uring and similar
to eventfd_signal() it always passed 1 for @n. So don't bother with that
argument at all.
Signed-off-by: Christian Brauner
---
fs/eventfd.c| 7 ---
include/linux/eventfd.h | 5 ++---
io_uring/io_uring.c
Ever since the evenfd type was introduced back in 2007 in commit
e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
function only ever passed 1 as a value for @n. There's no point in
keeping that additional argument.
Signed-off-by: Christian Brauner
---
arch/x86/kv
The single caller of inject_virtual_interrupt() ignores the return value
anyway. This allows us to simplify eventfd_signal() in follow-up
patches.
Signed-off-by: Christian Brauner
---
drivers/gpu/drm/i915/gvt/interrupt.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff
Hey everyone,
This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
significantly. They can be made void and not take any unnecessary
arguments.
I've added a few more simplifications based on Sean's suggestion.
Signed-off-by: Christian Brauner
Changes in v2:
- further
No caller care about the return value.
Signed-off-by: Christian Brauner
---
fs/eventfd.c| 40 +++-
include/linux/eventfd.h | 16 +++-
2 files changed, 22 insertions(+), 34 deletions(-)
diff --git a/fs/eventfd.c b/fs/eventfd.c
index
No caller care about the return value.
Signed-off-by: Christian Brauner
---
fs/eventfd.c| 40 +++-
include/linux/eventfd.h | 16 +++-
2 files changed, 22 insertions(+), 34 deletions(-)
diff --git a/fs/eventfd.c b/fs/eventfd.c
index
The eventfd_signal_mask() helper was introduced for io_uring and similar
to eventfd_signal() it always passed 1 for @n. So don't bother with that
argument at all.
Signed-off-by: Christian Brauner
---
fs/eventfd.c| 7 ---
include/linux/eventfd.h | 5 ++---
io_uring/io_uring.c
The eventfd_signal_mask() helper was introduced for io_uring and similar
to eventfd_signal() it always passed 1 for @n. So don't bother with that
argument at all.
Signed-off-by: Christian Brauner
---
fs/eventfd.c| 7 ---
include/linux/eventfd.h | 5 ++---
io_uring/io_uring.c
Ever since the evenfd type was introduced back in 2007 in commit
e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
function only ever passed 1 as a value for @n. There's no point in
keeping that additional argument.
Signed-off-by: Christian Brauner
---
arch/x86/kv
Ever since the evenfd type was introduced back in 2007 in commit
e1ad7468c77d ("signal/timer/event: eventfd core") the eventfd_signal()
function only ever passed 1 as a value for @n. There's no point in
keeping that additional argument.
Signed-off-by: Christian Brauner
---
arch/x86/kv
The single caller of inject_virtual_interrupt() ignores the return value
anyway. This allows us to simplify eventfd_signal() in follow-up
patches.
Signed-off-by: Christian Brauner
---
drivers/gpu/drm/i915/gvt/interrupt.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff
The single caller of inject_virtual_interrupt() ignores the return value
anyway. This allows us to simplify eventfd_signal() in follow-up
patches.
Signed-off-by: Christian Brauner
---
drivers/gpu/drm/i915/gvt/interrupt.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff
Hey everyone,
This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
significantly. They can be made void and not take any unnecessary
arguments.
I've added a few more simplifications based on Sean's suggestion.
Signed-off-by: Christian Brauner
Changes in v2:
- further
Hey everyone,
This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
significantly. They can be made void and not take any unnecessary
arguments.
I've added a few more simplifications based on Sean's suggestion.
Signed-off-by: Christian Brauner
Changes in v2:
- further
On Mon, Nov 20, 2023 at 11:54:28PM +, Mark Brown wrote:
> The kernel has recently added support for shadow stacks, currently
> x86 only using their CET feature but both arm64 and RISC-V have
> equivalent features (GCS and Zicfiss respectively), I am actively
> working on GCS[1]. With shadow
On Sun, Nov 19, 2023 at 06:11:39PM -0500, Gabriel Krisman Bertazi wrote:
> Christian Brauner writes:
>
> > On Wed, 16 Aug 2023 01:07:54 -0400, Gabriel Krisman Bertazi wrote:
> >> This is v6 of the negative dentry on case-insensitive directories.
> >> Thanks E
On Wed, 08 Nov 2023 10:15:50 +0530, Abhinav Singh wrote:
> Sparse static analysis tools generate a warning with this message
> "Using plain integer as NULL pointer". In this case this warning is
> being shown because we are trying to initialize pointer to NULL using
> integer value 0.
>
>
> Did something happen to this patch? I do not see it in your branch nor the
> linux-next one nor Linus's tree.
Sorry, my bad. I'll send that out as a fixes pr soon.
On Wed, 1 Nov 2023 18:43:06 +0100, Jan Kara wrote:
> Convert bcachefs to use bdev_open_by_path() and pass the handle around.
>
>
Applied to the vfs.super branch of the vfs/vfs.git tree.
Patches in the vfs.super branch should appear in linux-next soon.
Please report any outstanding bugs that
101 - 200 of 5019 matches
Mail list logo
