On Thu, 02 Jan 2025 09:22:55 +0100, Nam Cao wrote:
> In /proc/PID/stat, there is the kstkesp field which is the stack pointer of
> a thread. While the thread is active, this field reads zero. But during a
> coredump, it should have a valid value.
>
> However, at the moment, kstkesp is zero even du
On Tue, Dec 10, 2024 at 07:14:07PM +0100, Florian Weimer wrote:
> * Aleksa Sarai:
>
> > sched_getattr(2) doesn't care about trailing non-zero bytes in the
> > (ksize > usize) case, so just use copy_struct_to_user() without checking
> > ignored_trailing.
>
> I think this is what causes glibc's mis
On Wed, Oct 30, 2024 at 04:37:37PM +, Lorenzo Stoakes wrote:
> On Mon, Oct 28, 2024 at 04:06:07PM +, Lorenzo Stoakes wrote:
> > I guess I'll try to adapt that and respin a v7 when I get a chance.
>
> Hm looking at this draft patch, it seems like a total rework of pidfd's
> across the board
On Thu, Nov 21, 2024 at 01:57:32PM +0100, Alexander Mikhalitsyn wrote:
> >Currently SCM_PIDFD cmsg cannot be sent via unix socket
> >(returns -EINVAL) and SO_PASSPIDFD doesn't support flags.
> >The created pidfd always has flags set to 0.
> >
> >This patch implements SCM_PIDFD cmsg in AF_UNIX socke
On Sat, 16 Nov 2024 00:41:14 +1100, Michael Ellerman wrote:
> Currently the mount_setattr_test fails on machines with a 64K PAGE_SIZE,
> with errors such as:
>
> # RUN mount_setattr_idmapped.invalid_fd_negative ...
> mkfs.ext4: No space left on device while writing out and closing f
C: Aleksa Sarai
> Link: https://github.com/uapi-group/kernel-features#set-comm-field-before-exec
> ---
We finally went full circle back to what was originally proposed :)
Reviewed-by: Christian Brauner
pid = pidfd_pid(file);
> + /* If we allow opening a pidfd via /proc/, do so. */
> + if (IS_ERR(pid) && allow_proc)
> + pid = tgid_pidfd_to_pid(file);
>
> - if (IS_ERR(pid)) {
> + if (IS_ERR(pid)) {
> +
_setattr_idmapped.idmap_mount_tree_invalid
> # PASSED: 1 / 1 tests passed.
>
> Signed-off-by: zhouyuhang
> ---
Reviewed-by: Christian Brauner
On Thu, 10 Oct 2024 07:40:33 +1100, Aleksa Sarai wrote:
> This is something that I've been thinking about for a while. We had a
> discussion at LPC 2020 about this[1] but the proposals suggested there
> never materialised.
>
> In short, it is quite difficult for userspace to detect the feature
> c
On Fri, Oct 11, 2024 at 12:05:55PM +0100, Lorenzo Stoakes wrote:
> The means by which a pid is determined from a pidfd is duplicated, with
> some callers holding a reference to the (pid)fd, and others explicitly
> pinning the pid.
>
> Introduce __pidfd_get_pid() which abstracts both approaches and
On Thu, 10 Oct 2024 07:40:36 +1100, Aleksa Sarai wrote:
> While we do currently return -EFAULT in this case, it seems prudent to
> follow the behaviour of other syscalls like clone3. It seems quite
> unlikely that anyone depends on this error code being EFAULT, but we can
> always revert this if it
gument, and use GFP_ATOMIC on
> the fast path.
>
> Link:
> https://lore.kernel.org/all/hfcr2aget2zojmqpr4uhlzvnep4vgskblx5b6xf2ddosbsrke7@nt34bxgp7j2x
> Fixes: efcd71af38be ("vsock/virtio: avoid queuing packets when intermediate
> queue is empty")
> Reported-by: Chr
On Mon, Sep 30, 2024 at 03:32:25PM GMT, Lorenzo Stoakes wrote:
> On Mon, Sep 30, 2024 at 04:21:23PM GMT, Aleksa Sarai wrote:
> > On 2024-09-30, Lorenzo Stoakes wrote:
> > > On Mon, Sep 30, 2024 at 02:34:33PM GMT, Christian Brauner wrote:
> > > > On Mon, Sep 30, 2
On Fri, Sep 27, 2024 at 03:21:59PM GMT, Edgecombe, Rick P wrote:
> On Fri, 2024-09-27 at 10:50 +0200, Christian Brauner wrote:
> > The legacy clone system call had required userspace to know in which
> > direction the stack was growing and then pass down the stack pointer
> &g
On Mon, Sep 30, 2024 at 11:39:49AM GMT, Lorenzo Stoakes wrote:
> On Mon, Sep 30, 2024 at 12:33:18PM GMT, Florian Weimer wrote:
> > * Lorenzo Stoakes:
> >
> > > If you wish to utilise a pidfd interface to refer to the current process
> > > (from the point of view of userland - from the kernel point
On Wed, Aug 21, 2024 at 06:23:18PM GMT, Mark Brown wrote:
> On Wed, Aug 21, 2024 at 03:54:49PM +, Edgecombe, Rick P wrote:
> > On Wed, 2024-08-21 at 13:45 +0100, Mark Brown wrote:
>
> > > It's entirely possible it just leaked. My own attempts to dig through
> > > the archives haven't turned u
On Tue, Sep 03, 2024 at 11:36:28AM GMT, Ba Jing wrote:
> The macro MAX_PID_NS_LEVEL is never referenced in the code, so remove it.
>
> Signed-off-by: Ba Jing
> ---
Reviewed-by: Christian Brauner
On Sat, Jun 22, 2024 at 03:41:19PM GMT, Linus Torvalds wrote:
> On Sat, 22 Jun 2024 at 14:25, Mateusz Guzik wrote:
> >
> > +cc Linus
>
> Thanks.
>
> > To sum up the problem: stat and statx met with "" + AT_EMPTY_PATH have
> > more work to do than fstat and its hypotethical statx counterpart:
> >
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 fd
into a pull
request 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
> 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 in
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 throu
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_ of t
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 use-case f
/events")
readdir(fd, ...)
then they are licensed to list an entry in that directory. So all that
needs to be done is to actually list those files in that directory. And
since they already exist (they were created during mkdir) we just need
to splice in inodes and dentries for them. But for tha
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 .p
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.
>
>
Appli
> Lifetime rules for fs-private parts of superblock are really private to
Fine, I'll drop that. It's still correct that a filesystem needs to take
care when it frees sb->s_fs_info. See the RCU fun you just encountered.
for both the old and new logic fwiw. I hope to
upstream these docs soon so we all have something to point to.
>From 200666901f53db74edf309d48e3c74fd275a822a Mon Sep 17 00:00:00 2001
From: Christian Brauner
Date: Fri, 15 Sep 2023 16:01:02 +0200
Subject: [PATCH 1/2] porting: document new bl
On Thu, Sep 14, 2023 at 05:58:05PM +0100, Al Viro wrote:
> On Thu, Sep 14, 2023 at 04:02:25PM +0200, Christian Brauner wrote:
>
> > Yes, you're right that making the superblock and not the filesytem type
> > the bd_holder changes the logic and we are aware of that of cour
On Thu, Sep 14, 2023 at 08:23:31PM +0100, Al Viro wrote:
> On Thu, Sep 14, 2023 at 05:58:05PM +0100, Al Viro wrote:
>
> > Incidentally, I'm going to add a (belated by 10 years) chunk in porting.rst
> > re making sure that anything in superblock that might be needed by methods
> > called in RCU mod
> Christoph, could you explain what the hell do we need that for? It does
> create the race in question and AFAICS 2c18a63b760a (and followups trying
> to plug holes in it) had been nothing but headache.
>
> Old logics: if mount attempt with a different fs type happens, -EBUSY
> is precisely corr
> BTW, this part of commit message in 2c18a63b760a is rather confused:
> Recent rework moved block device closing out of sb->put_super() and into
> sb->kill_sb() to avoid deadlocks as s_umount is held in put_super() and
> blkdev_put() can end up taking s_umount again.
>
> That was *NOT
super(struct super_block *s)
I wouldn't mind s/s/sb/ here as well. So we stop using @s in some and
@sb in other places.
Otherwise looks good to me,
Reviewed-by: Christian Brauner
n 3b0c2d3eaa83 ("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: C
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.
> > >
95ebabde382c ("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
mapping
> * change 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 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 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
, when we start
> seeing x86_64 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 arch
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
-linus-2021-04-08 tag.
Thanks!
Christian
for-linus-2021-04-08
--------
Christian Brauner (1):
file: fix close_range() for unshare+cloexec
fs/file.c | 21 +
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 this,
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 ...
>
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
> > consu
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 increases
tly determined
> 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 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
. (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
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 Mon, Apr 05, 2021 at 06:28:54PM +, Al Viro wrote:
> On Mon, Apr 05, 2021 at 06:23:49PM +, Al Viro wrote:
> > On Mon, Apr 05, 2021 at 07:08:01PM +0200, Christian Brauner wrote:
> >
> > > Ah dentry count of -127 looks... odd.
> >
> > dead + 1...
&g
On Mon, Apr 05, 2021 at 04:18:58PM +, Al Viro wrote:
> On Mon, Apr 05, 2021 at 01:44:37PM +0200, Christian Brauner wrote:
> > On Sun, Apr 04, 2021 at 08:17:21PM +, Al Viro wrote:
> > > On Sun, Apr 04, 2021 at 06:50:10PM +, Al Viro wrote:
> > >
> > &g
On Sun, Apr 04, 2021 at 08:17:21PM +, Al Viro wrote:
> On Sun, Apr 04, 2021 at 06:50:10PM +, Al Viro wrote:
>
> > > Yeah, I have at least namei.o
> > >
> > > https://drive.google.com/file/d/1AvO1St0YltIrA86DXjp1Xg3ojtS9owGh/view?usp=sharing
> >
> > *grumble*
> >
> > Is it reproducible w
On Sun, Apr 04, 2021 at 04:44:06PM +, Al Viro wrote:
> On Sun, Apr 04, 2021 at 06:40:40PM +0200, Christian Brauner wrote:
>
> > > Very interesting. What happens if you call loop() twice? And now I
> > > wonder
> > > whether it's root or cwd, actually.
On Sun, Apr 04, 2021 at 06:52:08PM +0200, Christian Brauner wrote:
> On Sun, Apr 04, 2021 at 06:40:40PM +0200, Christian Brauner wrote:
> > On Sun, Apr 04, 2021 at 03:56:02PM +, Al Viro wrote:
> > > On Sun, Apr 04, 2021 at 01:34:45PM +0200, Christian Brauner wrote:
> >
On Sun, Apr 04, 2021 at 06:40:40PM +0200, Christian Brauner wrote:
> On Sun, Apr 04, 2021 at 03:56:02PM +, Al Viro wrote:
> > On Sun, Apr 04, 2021 at 01:34:45PM +0200, Christian Brauner wrote:
> >
> > > Sorry for not replying to your earlier mail but I've been
On Sun, Apr 04, 2021 at 03:56:02PM +, Al Viro wrote:
> On Sun, Apr 04, 2021 at 01:34:45PM +0200, Christian Brauner wrote:
>
> > Sorry for not replying to your earlier mail but I've been debugging this
> > too. My current theory is that it's related
On Sun, Apr 04, 2021 at 02:34:08AM +, Al Viro wrote:
> On Thu, Apr 01, 2021 at 07:11:12PM +, Al Viro wrote:
>
> > > I _think_ I see what the issue is. It seems that an assumption made in
> > > this commit might be wrong and we're missing a mnt_add_count() bump that
> > > we would otherwise
On Thu, Apr 01, 2021 at 05:16:03AM -0700, syzbot wrote:
> syzbot has bisected this issue to:
>
> commit 73d90386b559d6f4c3c5db5e6bb1b68aae8fd3e7
> Author: Damien Le Moal
> Date: Thu Jan 28 04:47:27 2021 +
>
> nvme: cleanup zone information initialization
>
> bisection log: https://sy
On Thu, Apr 01, 2021 at 02:09:20AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:d19cc4bf Merge tag 'trace-v5.12-rc5' of git://git.kernel.o..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1018f281d0
> kernel
On Thu, Apr 01, 2021 at 07:46:13PM +0200, Christian Brauner wrote:
> On Thu, Apr 01, 2021 at 10:09:18AM -0600, Jens Axboe wrote:
> > On 4/1/21 9:45 AM, Christian Brauner wrote:
> > > On Thu, Apr 01, 2021 at 02:09:20AM -0700, syzbot wrote:
> > >> Hello,
> >
On Thu, Apr 01, 2021 at 10:09:18AM -0600, Jens Axboe wrote:
> On 4/1/21 9:45 AM, Christian Brauner wrote:
> > On Thu, Apr 01, 2021 at 02:09:20AM -0700, syzbot wrote:
> >> Hello,
> >>
> >> syzbot found the following issue on:
> >>
> >> H
On Mon, Mar 29, 2021 at 11:21:34AM +0200, Christian Brauner wrote:
> On Sat, Mar 27, 2021 at 11:33:37PM +, Al Viro wrote:
> > On Fri, Mar 26, 2021 at 02:50:11PM +0100, Christian Brauner wrote:
> > > @@ -632,6 +632,7 @@ EXPORT_SYMBOL(close_fd); /* for ksys_close() */
> &g
On Sat, Mar 27, 2021 at 11:33:37PM +, Al Viro wrote:
> On Fri, Mar 26, 2021 at 02:50:11PM +0100, Christian Brauner wrote:
> > @@ -632,6 +632,7 @@ EXPORT_SYMBOL(close_fd); /* for ksys_close() */
> > static inline void __range_cloexec(struct files_
On Fri, Mar 26, 2021 at 10:34:28AM +0100, Christian Brauner wrote:
> On Fri, Mar 26, 2021, 10:21 Dmitry Vyukov wrote:
>
> > On Fri, Mar 26, 2021 at 10:12 AM Christian Brauner
> > wrote:
> > >
> > > On Fri, Mar 26, 2021 at 09:02:08AM +0100, Dmitry Vyukov wrot
On Fri, Mar 26, 2021 at 09:02:08AM +0100, Dmitry Vyukov wrote:
> On Fri, Mar 26, 2021 at 8:55 AM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:5ee96fa9 Merge tag 'irq-urgent-2021-03-21' of git://git.ke..
> > git tree: upstream
> > console
On Thu, Mar 25, 2021 at 01:13:41PM +0100, Christian Brauner wrote:
> On Thu, Mar 25, 2021 at 10:53:43AM +, Roberto Sassu wrote:
> > > From: Roberto Sassu
> > > Sent: Friday, March 5, 2021 4:19 PM
> > > With the patch to allow xattr/attr operations if a portabl
On Thu, Mar 25, 2021 at 10:53:43AM +, Roberto Sassu wrote:
> > From: Roberto Sassu
> > Sent: Friday, March 5, 2021 4:19 PM
> > With the patch to allow xattr/attr operations if a portable signature
> > verification fails, cp and tar can copy all xattrs/attrs so that at the
> > end of the process
From: Christian Brauner
I don't see an obvious reason why the upper 32 bit check needs to be
open-coded this way. Switch to upper_32_bits() which is more idiomatic and
should conceptually be the same check.
Cc: Amir Goldstein
Cc: Jan Kara
Signed-off-by: Christian Brauner
---
fs/n
On Thu, Mar 25, 2021 at 09:22:08AM +0100, Christoph Hellwig wrote:
> The receive_fd_replace case shares almost no logic with the more general
> __receive_fd case, so split it into a separate function.
>
> BTW, I'm not sure if receive_fd_replace is such a useful primitive to
> start with, why not j
On Mon, Mar 22, 2021 at 03:48:59PM +0100, Miklos Szeredi wrote:
> There's a substantial amount of boilerplate in filesystems handling
> FS_IOC_[GS]ETFLAGS/ FS_IOC_FS[GS]ETXATTR ioctls.
>
> Also due to userspace buffers being involved in the ioctl API this is
> difficult to stack, as shown by overl
On Mon, Mar 22, 2021 at 03:33:38PM -0700, Darrick J. Wong wrote:
> On Mon, Mar 22, 2021 at 03:48:59PM +0100, Miklos Szeredi wrote:
> > There's a substantial amount of boilerplate in filesystems handling
> > FS_IOC_[GS]ETFLAGS/ FS_IOC_FS[GS]ETXATTR ioctls.
> >
> > Also due to userspace buffers bein
On Mon, Mar 22, 2021 at 01:01:11PM -0400, Vivek Goyal wrote:
> On Sat, Mar 20, 2021 at 11:03:22AM +0100, Christian Brauner wrote:
> > On Fri, Mar 19, 2021 at 11:42:48PM +0100, Andreas Grünbacher wrote:
> > > Hi,
> > >
> > > Am Fr., 19. März 2
/* panic? */;
> | ^
>
> panic() is probably not the correct choice here, but a WARN_ON
> seems appropriate and avoids the compile-time warning.
>
> Signed-off-by: Arnd Bergmann
> ---
Thanks!
Reviewed-by: Christian Brauner
On Tue, Mar 23, 2021 at 06:49:09AM +0530, Bhaskar Chowdhury wrote:
>
> s/concurent/concurrent/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
Looks good,
Reviewed-by: Christian Brauner
On Tue, Mar 23, 2021 at 01:03:56AM -0700, zhouchuangao wrote:
> Maybe it's easier for us to understand the function of
> check_kill_permission.
>
> Signed-off-by: zhouchuangao
> ---
> kernel/signal.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/signal.c
nction fails.
>
> Add a separate NULL check to tell gcc about it as well.
>
> Signed-off-by: Arnd Bergmann
> ---
Seems reasonable,
Acked-by: Christian Brauner
there's a typo
in the patch subject :)
s/arcc/arc/
otherwise
Reviewed-by: Christian Brauner
efine cmpxchg() as a statement expression these days, it is no longer
> necessary to evaluate its return code, and the if() can just be droped.
>
> Signed-off-by: Arnd Bergmann
> ---
Thanks you!
Reviewed-by: Christian Brauner
On Mon, Mar 22, 2021 at 02:02:54PM +0100, Arnd Bergmann wrote:
> On Mon, Mar 22, 2021 at 1:15 PM Christian Brauner
> wrote:
> > On Mon, Mar 22, 2021 at 12:38:24PM +0100, Arnd Bergmann wrote:
> > > From: Arnd Bergmann
> > >
> > > The fallthrough commen
st architectures, we could just drop the if() entirely, but
> in some cases this causes a different warning.
And you don't see the warning for the second unconditional
cmpxchg(p, sentinel, ACL_NOT_CACHED);
below?
>
> Signed-off-by: Arnd Bergmann
> ---
In any case that should be fine,
Reviewed-by: Christian Brauner
On Fri, Mar 19, 2021 at 11:42:48PM +0100, Andreas Grünbacher wrote:
> Hi,
>
> Am Fr., 19. März 2021 um 20:58 Uhr schrieb Vivek Goyal :
> > posix_acl_update_mode() determines what's the equivalent mode and if SGID
> > needs to be cleared or not. I need to make use of this code in fuse
> > as well.
On Thu, Mar 18, 2021 at 08:39:13PM +, Sargun Dhillon wrote:
> On Thu, Mar 18, 2021 at 03:54:54PM +0100, Christian Brauner wrote:
> > Sorry, I just found that mail.
> >
> > On Mon, Mar 01, 2021 at 03:44:06PM -0800, Kees Cook wrote:
> > > On Mon, Mar 01, 2021
On Thu, Mar 18, 2021 at 04:35:34PM +, Al Viro wrote:
> On Thu, Mar 18, 2021 at 03:00:20PM +, Matthew Wilcox wrote:
> > On Thu, Mar 18, 2021 at 10:31:53PM +0800, Xiaofeng Cao wrote:
> > > change 'sould' to 'should'
> > > change 'colocated' to 'collocated'
> >
> > uh. collocated is incorrec
On Thu, Mar 18, 2021 at 11:31:45PM +0800, Xiaofeng Cao wrote:
> change 'backwords' to 'backwards'
> change 'and argument' to 'an argument'
> change 'visibile' to 'visible'
> change 'wont't' to 'won't'
> reorganize sentence
>
> Signed-off-by: Xiaofeng Cao
> ---
Reviewed-by: Christian Brauner
Sorry, I just found that mail.
On Mon, Mar 01, 2021 at 03:44:06PM -0800, Kees Cook wrote:
> On Mon, Mar 01, 2021 at 02:21:56PM +0100, Christian Brauner wrote:
> > On Mon, Mar 01, 2021 at 12:09:09PM +0100, Christian Brauner wrote:
> > > On Sat, Feb 20, 2021 at 01:31:57AM -08
root with next.
>
> Addresses-Coverity: ("Copy-paste error")
> Fixes: d919b33dafb3 ("proc: faster open/read/close with "permanent" files")
> Signed-off-by: Colin Ian King
> ---
Thanks! Seems very much like it.
Acked-by: Christian Brauner
On Thu, Mar 18, 2021 at 11:48:45AM +0100, Christian Brauner wrote:
> [+Cc Aleksa, the author of openat2()]
>
> and a comment below. :)
>
> On Wed, Mar 17, 2021 at 09:47:17PM -0400, Richard Guy Briggs wrote:
> > The openat2(2) syscall was added in kernel v5.6 with commit fd
1 - 100 of 1018 matches
Mail list logo
