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 Mon, Dec 02, 2024 at 11:24:29PM +0200, Vladimir Oltean wrote:
> On Mon, Dec 02, 2024 at 09:39:15PM +0100, Christian Marangi wrote:
> > Mhh the problem seems to be -c
> >
> > Let me post some outputs...
> >
> > root@OpenWrt:~# ping -V
> > ping from i
On Mon, Dec 02, 2024 at 10:28:16PM +0100, Christian Marangi wrote:
> On Mon, Dec 02, 2024 at 11:24:29PM +0200, Vladimir Oltean wrote:
> > On Mon, Dec 02, 2024 at 09:39:15PM +0100, Christian Marangi wrote:
> > > Mhh the problem seems to be -c
> > >
>
On Sat, Nov 30, 2024 at 05:48:40PM +0200, Vladimir Oltean wrote:
> On Sat, Nov 30, 2024 at 04:46:14PM +0100, Christian Marangi wrote:
> > On Sat, Nov 30, 2024 at 05:43:07PM +0200, Vladimir Oltean wrote:
> > > On Sat, Nov 30, 2024 at 12:33:09PM +0100, Christian Marangi wro
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 Sat, Nov 30, 2024 at 05:43:07PM +0200, Vladimir Oltean wrote:
> On Sat, Nov 30, 2024 at 12:33:09PM +0100, Christian Marangi wrote:
> > If the coreutils variant of ping is used instead of the busybox one, the
> > ping_do() command is broken. This comes by the fact that for cor
ls on real
hardware. With the introduced sleep of one second after mc_route_prepare,
the test corretly pass as the packet can correctly be delivered.
Cc: sta...@vger.kernel.org
Fixes: 90b9566aa5cd ("selftests: forwarding: add a test for
local_termination.sh")
Signed-off-by: Christian Marangi
ot;)
Signed-off-by: Christian Marangi
---
tools/testing/selftests/net/forwarding/lib.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/net/forwarding/lib.sh
b/tools/testing/selftests/net/forwarding/lib.sh
index c992e385159c..2060f95d5c62 100
From: Christian Göttsche
The function kunit_status_to_ok_not_ok() returns string literals, thus
declare the return value as such.
Reported by clang:
./include/kunit/test.h:143:10: warning: returning 'const char[3]' from a
function with result type 'char *'
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
;ll post what I've got (with the current ABI) today, incorporating
> your x86 fixes and the tighter validation and we can see what people
> think. Perhaps Christian remembers what's going on there?
The legacy clone system call had required userspace to know in which
direction th
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
Am 16.11.23 um 11:13 schrieb Ilya Leoshkevich:
It's also possible to get a free s390 machine at [1].
[1] https://linuxone.cloud.marist.edu/oss
I think the URL for registration is this one
https://linuxone.cloud.marist.edu/#/register?flag=VM
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
Christopherson
Cc: Michael Tokarev
Cc: Christian Borntraeger
Signed-off-by: Wanpeng Li
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
Reviewed-by: Christian Borntraeger
---
include/linux/context_tracking.h | 9 -
1 file changed, 8 insertions(+), 1
accounting.
Suggested-by: Thomas Gleixner
Cc: Thomas Gleixner
Cc: Michael Tokarev
Cc: Christian Borntraeger
Signed-off-by: Wanpeng Li
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
Reviewed-by: Christian Borntraeger
---
include/linux/context_tracking.h | 24
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.
> > >
Am 20.04.21 um 09:46 schrieb Michal Hocko:
On Tue 20-04-21 09:32:14, Christian König wrote:
Am 20.04.21 um 09:04 schrieb Michal Hocko:
On Mon 19-04-21 18:37:13, Christian König wrote:
Am 19.04.21 um 18:11 schrieb Michal Hocko:
[...]
What I am trying to bring up with NUMA side is that the
Am 20.04.21 um 09:04 schrieb Michal Hocko:
On Mon 19-04-21 18:37:13, Christian König wrote:
Am 19.04.21 um 18:11 schrieb Michal Hocko:
[...]
The question is not whether it is NUMA aware but whether it is useful to
know per-numa data for the purpose the counter is supposed to serve.
No, not
Am 19.04.21 um 18:11 schrieb Michal Hocko:
On Mon 19-04-21 17:44:13, Christian König wrote:
Am 19.04.21 um 17:19 schrieb peter.enderb...@sony.com:
On 4/19/21 5:00 PM, Michal Hocko wrote:
On Mon 19-04-21 12:41:58, peter.enderb...@sony.com wrote:
On 4/19/21 2:16 PM, Michal Hocko wrote:
On
it 95ebabde382c371572297915b104e55403674e73
Author: Eric W. Biederman
Date: Thu Dec 17 09:42:00 2020 -0600
capabilities: Don't allow writing ambiguous v3 file capabilities
commit 3b0c2d3eaa83da259d7726192cf55a137769012f
Author: Eric W. Biederman
Date: Fri Mar 12 15:07:09 2021 -0600
Revert
struct uid_gid_extent *extent0 = NULL;
> >> +
> >> + for (idx = 0; idx < new_map->nr_extents; idx++) {
> >> + u32 lower_first;
>
> nit: lower_first seems unused?
>
> >> +
> >> + if (new_map->nr_extents <= UID_GID_MAP_MAX_BASE_EXTENTS)
> >> + extent0 = &new_map->extent[idx];
> >> + else
> >> + extent0 = &new_map->forward[idx];
> >> + if (extent0->lower_first == 0)
> >> + break;
> >> +
> >> + extent0 = NULL;
> >> + }
>
> Tested-by: Giuseppe Scrivano
Thanks for running the tests and confirming my results!
Christian
your new counter? Or the NUMA locality is of no importance?
Sounds good to me, if Christian Koenig think it is good, I will use that.
It is only virtio in drivers that use the global_node_page_state if
that matters.
DMA-buf are not NUMA aware at all. On which node the pages are allocated
(and i
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
Hillf Danton on Mo, 2021/04/12 16:05:
> Looks like double free or use after free based on 0xdead.
> If possible, would you try the mainline with KASAN enabled, given the fear
> that few guys can find time for 5.10 this week?
Currently running 5.11.13 with KASAN enabled for about a week. Either th
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
that
EXPORT_SYMBOL_GPL is unnecessary. If one day someone
want to call it from the module, maybe it’s not too late to export
it at that time.
Yeah, that is a rather good point. Only symbols which should be used by
modules/drivers should be exported.
Christian.
Thanks.
+
#ifdef C
Am 17.04.21 um 13:20 schrieb peter.enderb...@sony.com:
On 4/17/21 12:59 PM, Christian König wrote:
Am 17.04.21 um 12:40 schrieb Peter Enderborg:
This adds a total used dma-buf memory. Details
can be found in debugfs, however it is not for everyone
and not always available. dma-buf are indirect
have problems.
Signed-off-by: Peter Enderborg
Reviewed-by: Christian König
How do you want to upstream this?
---
drivers/dma-buf/dma-buf.c | 13 +
fs/proc/meminfo.c | 5 -
include/linux/dma-buf.h | 1 +
3 files changed, 18 insertions(+), 1 deletion(-)
diff
: expecting prototype for
amdgpu_cs_wait_all_fence(). Prototype was for amdgpu_cs_wait_all_fences()
instead
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1656: warning: expecting prototype for
amdgpu_cs_find_bo_va(). Prototype was for amdgpu_cs_find_mapping() instead
Cc: Alex Deucher
Cc: "Chri
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c:169: warning: Function parameter or
member 'sched_score' not described in 'amdgpu_ring_init'
Cc: Alex Deucher
Cc: "Christian Kön
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c:311: warning: expecting prototype for
amdgpu_copy_ttm_mem_to_mem(). Prototype was for amdgpu_ttm_copy_mem_to_mem()
instead
Cc: Alex Deucher
Cc: "Christian
:96: warning: expecting prototype for
amdgpu_dummy_page_fini(). Prototype was for amdgpu_gart_dummy_page_fini()
instead
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Nirmoy Das
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Sig
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:444: warning: Function parameter or
member 'sched_score' not described in 'amdgpu_fence_driver_init_ring'
Cc: Alex Deucher
Cc: "Ch
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_device.c:1101: warning: This comment starts
with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
Cc: Alex Deucher
Cc: &
parameter or member
'num_dma32_pages' not described in 'ttm_tt_mgr_init'
Cc: Christian Koenig
Cc: Huang Rui
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Lee Jones
For that one I would rather prefer to just document the two parameters.
or member
'gfp_flags' not described in 'ttm_global_swapout'
drivers/gpu/drm/ttm/ttm_device.c:112: warning: expecting prototype for A
buffer object shrink method that tries to swap out the first(). Prototype was
for ttm_global_swapout() instead
Cc: Christian Koenig
Cc
Am 16.04.21 um 16:37 schrieb Lee Jones:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/ttm/ttm_bo.c:293: warning: expecting prototype for function
ttm_bo_cleanup_refs(). Prototype was for ttm_bo_cleanup_refs() instead
Cc: Christian Koenig
Cc: Huang Rui
Cc: David Airlie
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 16.04.21 16:58, Stephen Rothwell wrote:
Hi all,
On Fri, 16 Apr 2021 16:02:01 +0200 Paolo Bonzini wrote:
On 16/04/21 14:38, Christian Borntraeger wrote:
On 16.04.21 14:27, Stephen Rothwell wrote:
Hi all,
In commit
c3171e94cc1c ("KVM: s390: VSIE: fix MVPG handling for pref
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
.include.
Link:
https://lore.kernel.org/lkml/86dadf33-70f7-a5ac-cb8c-64966d2f4...@linux.ibm.com/
Fixes: d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
scripts/Makefile.compiler")
Reported-by: Janosch Frank
Reported-by: Christian Borntraeger
Signed-off-by: Masahiro Yamada
looks better.
Tested-by: Christian Borntraeger
global_allocated.
Christian.
static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen)
{
@@ -79,6 +80,7 @@ static void dma_buf_release(struct dentry *dentry)
if (dmabuf->resv == (struct dma_resv *)&dmabuf[1])
dma_resv_fini(dmabuf->resv);
+ atomi
On 16.04.21 14:27, Stephen Rothwell wrote:
Hi all,
In commit
c3171e94cc1c ("KVM: s390: VSIE: fix MVPG handling for prefixing and MSO")
Fixes tag
Fixes: bdf7509bbefa ("s390/kvm: VSIE: correctly handle MVPG when in VSIE")
has these problem(s):
- Subject does not match target commit s
describe which cases that are.
Christian.
Signed-off-by: Peter Enderborg
---
drivers/dma-buf/dma-buf.c | 12
fs/proc/meminfo.c | 2 ++
include/linux/dma-buf.h | 1 +
3 files changed, 15 insertions(+)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma
Am 15.04.21 um 22:33 schrieb Andrew Morton:
On Thu, 15 Apr 2021 13:56:24 +0200 "Christian König"
wrote:
@@ -530,6 +525,11 @@ void ttm_pool_fini(struct ttm_pool *pool)
for (j = 0; j < MAX_ORDER; ++j)
ttm_pool_type_fini(&am
On 15.04.21 10:06, Christian Borntraeger wrote:
On 15.04.21 09:27, Masahiro Yamada wrote:
Since commit d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
scripts/Makefile.compiler"), some kselftests fail to build.
The tools/ directory opted out Kbuild, and went in a different
Switch back to using a spinlock again by moving the IOMMU unmap outside
of the locked region.
v2: Add a comment explaining why we need sync_shrinkers().
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 44 +-
1 file changed, 22 insertions
e the device which those pages
belong to.
Taking and releasing the shrinker semaphore on the write side after
unmapping and freeing all pages should make sure that no shrinker is running in
paralell any more.
Signed-off-by: Christian König
---
include/linux/shrinker.h | 1 +
mm/vmscan.c
Link:
https://lore.kernel.org/lkml/86dadf33-70f7-a5ac-cb8c-64966d2f4...@linux.ibm.com/
Fixes: d9f4ff50d2aa ("kbuild: spilt cc-option and friends to
scripts/Makefile.compiler")
Reported-by: Janosch Frank
Reported-by: Christian Borntraeger
Signed-off-by: Masahiro Yamada
When applyin
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
Am 13.04.21 um 23:19 schrieb Mikhail Gavrilov:
On Tue, 13 Apr 2021 at 12:29, Christian König wrote:
Hi Mikhail,
the crash is a known issue and should be fixed by:
commit f63da9ae7584280582cbc834b20cc18bfb203b14
Author: Philip Yang
Date: Thu Apr 1 00:22:23 2021 -0400
drm/amdgpu
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
On 4/13/2021 3:57 PM, Andrew Lunn wrote:
Ok, we can agree that there will not be a perfect naming. Would it be a
possibility to rename the existing TJA11xx driver to TJA1100-1-2 or is that
unwanted?
It is generally a bad idea. It makes back porting fixing harder if the
file changes name.
If n
On 4/13/2021 3:30 PM, Andrew Lunn wrote:
On Tue, Apr 13, 2021 at 08:56:30AM +0200, Christian Herber wrote:
Hi Andrew,
On 4/12/2021 6:52 PM, Andrew Lunn wrote:
So what you are say is, you don't care if the IP is completely
different, it all goes in one driver. So lets put this driver
On 13.04.21 14:51, Janosch Frank wrote:
On 2/28/21 7:10 AM, Masahiro Yamada wrote:
scripts/Kbuild.include is included everywhere, but macros such as
cc-option are needed by build targets only.
For example, when 'make clean' traverses the tree, it does not need
to evaluate $(call cc-option,).
On 13.04.21 09:16, Wanpeng Li wrote:
The bugzilla https://bugzilla.kernel.org/show_bug.cgi?id=209831
reported that the guest time remains 0 when running a while true
loop in the guest.
The commit 87fa7f3e98a131 ("x86/kvm: Move context tracking where it
belongs") moves guest_exit_irqoff() clos
On 13.04.21 09:52, Wanpeng Li wrote:
Or did I miss anything.
I mean the if (!context_tracking_enabled_this_cpu()) part in the
function context_guest_enter_irqoff() ifdef
CONFIG_VIRT_CPU_ACCOUNTING_GEN. :)
Ah I missed that. Thanks.
On 13.04.21 09:38, Wanpeng Li wrote:
On Tue, 13 Apr 2021 at 15:35, Christian Borntraeger
wrote:
On 13.04.21 09:16, Wanpeng Li wrote:
[...]
@@ -145,6 +155,13 @@ static __always_inline void guest_exit_irqoff(void)
}
#else
THis is the else part
+static __always_inline void
On 13.04.21 09:16, Wanpeng Li wrote:
[...]
@@ -145,6 +155,13 @@ static __always_inline void guest_exit_irqoff(void)
}
#else
+static __always_inline void context_guest_enter_irqoff(void)
+{
+ instrumentation_begin();
+ rcu_virt_note_context_switch(smp_processor_id());
+
perfectly
possible. See here for example https://en.wikipedia.org/wiki/Halting_problem
What we do with misbehaving applications is to log the incident and
prevent the queue which does nasty things from doing even more submissions.
Regards,
Christian.
Am 13.04.21 um 00:05 schrieb Mikhail Gavrilov
1xx is creating more issues, as it assumes that
the devices which are managed by the driver are always TJA... devices
which may not be true.
Christian
When mmaping an extra device region verify that the region index
derived from the mmap offset is valid.
Fixes: a15b1883fee1 ("vfio_pci: Allow mapping extra regions")
Cc: sta...@vger.kernel.org
Signed-off-by: Christian A. Ehrhardt
---
drivers/vfio/pci/vfio_pci.c | 4 +++-
1 file
.
Thanks,
Christian.
Am 07.04.21 um 20:06 schrieb Mikhail Gavrilov:
On Wed, 7 Apr 2021 at 15:46, Christian König
wrote:
What hardware are you using
$ inxi -bM
System:Host: fedora Kernel: 5.12.0-0.rc6.184.fc35.x86_64+debug
x86_64 bits: 64 Desktop: GNOME 40.0
Distro: Fedora release 3
1 - 100 of 3144 matches
Mail list logo
