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
On 12.04.21 12:53, Muchun Song wrote:
On Mon, Apr 12, 2021 at 6:42 PM Christian Borntraeger
wrote:
FWIW, I was away the last week, and I checked yesterdays next (e99d8a849517)
regression runs.
I still do see errors in our CI system:
[ 2263.021681] [ cut here
FWIW, I was away the last week, and I checked yesterdays next (e99d8a849517)
regression runs.
I still do see errors in our CI system:
[ 2263.021681] [ cut here ]
[ 2263.021697] percpu ref (obj_cgroup_release) <= 0 (0) after switching to
atomic
[ 2263.021748] WARNING: CPU
Christian Hesse on Mo, 2021/03/15 14:10:
> Hello everybody,
>
> Christian Hesse on Tue, 2021/03/02 09:34:
> > I see this on a git server with lots of ssh logins. It happens every few
> > hours to days. No idea how to reproduce, guess it's a race condition?
> &g
contrast to flash devices which have standard commands for this). I suppose
that there is no much value getting vendor specific information from a chip. If
the drivers knows the vendor, it should also know the chip (e.g. from the dt).
regards
Christian
On Friday, 9 April 2021, 17:47:17 CEST, Jiri
ore some freeing functions is not needed.
>
> Signed-off-by: Qiheng Lin
Reviewed-by: Christian Gmeiner
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info/privacypolicy
Am 01.04.21 um 03:59 schrieb Bernard:
From: "Christian König"
Date: 2021-03-31 21:15:22
To: Bernard Zhao ,Huang Rui ,David Airlie
,Daniel Vetter
,dri-de...@lists.freedesktop.org,linux-kernel@vger.kernel.org
Cc: opensource.ker...@vivo.com
Subject: Re: [PATCH] drm/ttm: cleanup codi
Am 09.04.21 um 13:00 schrieb Vlastimil Babka:
On 4/9/21 9:17 AM, Christian König wrote:
To be able to switch to a spinlock and reduce lock contention in the TTM
shrinker we don't want to hold a mutex while unmapping and freeing pages
from the pool.
Does using spinlock instead of mutex r
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
Switch back to using a spinlock again by moving the IOMMU unmap outside
of the locked region.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_pool.c | 40 +++---
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
-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 +
anged. Instead, the timestamp returned by SYNC_IOC_FILE_INFO
became the first time anything used the static stub fence, which has no
meaning to userspace.
Signed-off-by: David Stevens
Reviewed-by: Christian König
Should I push this to drm-misc-next or how do you want to upstream it?
T
when the fence is signaled
to avoid races between signaling and adding a callback.
And for this the global spinlock should be perfectly sufficient. Apart
from that looks good to me.
Regards,
Christian.
/*
* fence context counter: each execution context should have its own
* fence co
Am 08.04.21 um 11:30 schrieb David Stevens:
On Thu, Apr 8, 2021 at 4:03 PM Christian König wrote:
Am 08.04.21 um 06:59 schrieb David Stevens:
From: David Stevens
This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6.
Using the singleton stub fence in drm_syncobj_assign_null_handle
t) {
Not just are there helpers for taking ns_lock
static inline void lock_ns_list(struct mnt_namespace *ns)
static inline void unlock_ns_list(struct mnt_namespace *ns)
they are private to fs/namespace.c because it's the only place that
should ever walk this list.
This seems buggy: why is it ok here to only take ns_lock and not also
namespace_sem like mnt_already_visible() and __is_local_mountpoint() or
the relevant proc iterators? I might be missing something.
> + sb = mnt->mnt.mnt_sb;
> +
> + /* The same mount may be mounted in multiple places */
> + if (radix_tree_lookup(&info->superblocks, (unsigned long)sb))
> + continue;
> +
> + err = radix_tree_insert(&info->superblocks,
> + (unsigned long)sb, (void *)1);
> + if (err)
> + goto out;
> + }
> +
> + radix_tree_for_each_slot(slot, &info->superblocks, &iter, 0) {
> + sb = (struct super_block *)iter.index;
> + atomic_inc(&sb->s_active);
It also isn't nice that you mess with sb->s_active directly.
Imho, this is poking around in a lot of fs/ specific stuff that other
parts of the kernel should not care about or have access to.
Christian
re "stacked containers"? Do you mean nested
containers, i.e. containers running within containers?
Christian
tion which returns a newly initialized stub fence
in the dma_fence.c code.
Regards,
Christian.
Signed-off-by: David Stevens
---
drivers/gpu/drm/drm_syncobj.c | 58 ++-
1 file changed, 44 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c
ncluding caller locks) and
> it might be ok, but that's messy.
>
> Another approach may be to identify filesystem types that do not
> need memcg awareness and feed that into alloc_super() to set/clear
> the SHRINKER_MEMCG_AWARE flag. This could be based on fstype - most
> virtual filesystems that expose system information do not really
I think that might already help quite a bit as those tend to make up
most of the mounts and even unprivileged containers can create new
instances of such mounts and will do so when they e.g. run systemd and
thus also systemd services.
Christian
ing Stéphane Graber who has experience/insight about stuff like this.
Christian
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
:3013:8-16:
WARNING: use scnprintf or sprintf
Signed-off-by: Xuezhi Zhang
Acked-by: Christian König
---
drivers/gpu/drm/amd/pm/amdgpu_pm.c | 58 +++---
1 file changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/amd/pm/amdgpu_pm.c
b/drivers/gpu
What hardware are you using and how do you exactly trigger this?
Thanks,
Christian.
Am 07.04.21 um 11:30 schrieb Mikhail Gavrilov:
Hi!
During the 5.12 testing cycle I observed the repeatable bug when
launching heavy graphic applications.
The kernel log is flooded with the message "Unexp
Am 07.04.21 um 09:47 schrieb Daniel Gomez:
On Tue, 6 Apr 2021 at 22:56, Alex Deucher wrote:
On Mon, Mar 22, 2021 at 6:34 AM Christian König
wrote:
Hi Daniel,
Am 22.03.21 um 10:38 schrieb Daniel Gomez:
On Fri, 19 Mar 2021 at 21:29, Felix Kuehling wrote:
This caused a regression in kfdtest
page corruption.
Can you please describe why you need that?
Regards,
Christian.
Am 07.04.21 um 10:25 schrieb Huang Rui:
On Wed, Apr 07, 2021 at 09:27:46AM +0800, songqiang wrote:
Please add the description in the commit message and subject.
Thanks,
Ray
Signed-off-by: songqiang
---
drivers/gpu/dr
1 - 100 of 3120 matches
Mail list logo
