On Thu, 12 Jun 2025 17:40:29 +0800, Chen Linxuan wrote:
> This patch add a simple functional test for the "abort" file
> in fusectlfs (/sys/fs/fuse/connections/ID/about).
>
> A simple fuse daemon is added for testing.
>
> Related discussion can be found in the link below.
>
> [...]
Applied to t
ion is aborted
> > - Apply changes suggested by Shuah Khan
> >- Update commit message
> > - Link to v2:
> > https://lore.kernel.org/all/20250517012350.10317-2-chenlinx...@uniontech.com/
> > Changes in v2:
> > - Apply changes suggested by Amir Goldstein
> &g
On 25/06/16 11:02PM, Naresh Kamboju wrote:
> The following test regressions noticed while running selftests/mm gup_longterm
> test cases on Dragonboard-845c, Dragonboard-410c, rock-pi-4, qemu-arm64 and
> qemu-x86_64 this build have required selftest/mm/configs included and
> toolchain
> is clang n
On Fri, 23 May 2025 14:37:49 +1000, Alistair Popple wrote:
> Commit 6be3e21d25ca ("fs/dax: don't skip locked entries when scanning
> entries") introduced a new function, wait_entry_unlocked_exclusive(),
> which waits for the current entry to become unlocked without advancing
> the XArray iterator s
On Wed, May 14, 2025 at 10:02:02AM +0800, Chen Linxuan wrote:
> I failed to build this test on Ubuntu 24.04. Compiler complains that
> function sys_open_tree has already been defined in
> "../filesystems/overlayfs/wrappers.h".
>
> Signed-off-by: Chen Linxuan
> ---
This is already fixed in the ne
to be used in this way. That
->vm_file pointer usage should get a fat comment above it explaining how
what you're doing is safe.
> you'd want for that is basically a raw __get_file_rcu(), but that is
> static and I think Christian wouldn't want to expose more of these
&
On Thu, May 01, 2025 at 02:46:46PM +0200, Peter Zijlstra wrote:
> On Thu, May 01, 2025 at 01:42:35PM +0200, Peter Zijlstra wrote:
> > On Wed, Oct 16, 2024 at 07:14:34PM -0700, John Hubbard wrote:
> > > On 10/16/24 3:06 PM, Lorenzo Stoakes wrote:
> > > > On Wed, Oct 16, 2024 at 02:00:27PM -0600, Shu
On Fri, 11 Apr 2025 17:09:40 +0200, Nam Cao wrote:
> While trying the coredump test on qemu-system-riscv64, I observed test
> failures for various reasons.
>
> This series makes the test works on qemu-system-riscv64.
>
> Best regards,
> Nam
>
> [...]
Applied to the vfs-6.16.coredump branch of t
> didn't lift off and DAX ended up being kind of niche, I think the effort
> to maintain DAX in ext2 is not justified and we should just drop it (and
> direct existing users to use ext4 driver instead for the cases where they
> need it). I'll have a look into it.
+1
Am 11.04.25 um 14:42 schrieb Heiko Carstens:
On Fri, Apr 11, 2025 at 01:11:55PM +0200, Christian Borntraeger wrote:
Am 10.04.25 um 20:44 schrieb David Hildenbrand:
[...]
---
So, given that
(a) people are actively running into this
(b) we'll have to backport this quite a lot
(c) the
Am 10.04.25 um 20:44 schrieb David Hildenbrand:
[...]
---
So, given that
(a) people are actively running into this
(b) we'll have to backport this quite a lot
(c) the spec issue is not a s390x-only issue
(d) it's still unclear how to best deal with the spec issue
I suggest getting this fix he
On Mon, Apr 07, 2025 at 07:50:49PM +0800, Xiangsheng Hou wrote:
> In certain scenarios, for example, during fuzz testing, the source
> name may be NULL, which could lead to a kernel panic. Therefore, an
> extra check for the source name should be added.
Oha, that's not great and easily reproducibl
On Mon, Apr 07, 2025 at 04:46:48PM +0200, David Hildenbrand wrote:
> On 07.04.25 16:24, Liam R. Howlett wrote:
> > * Nikita Kalyazin [250407 10:05]:
> > >
> >
> > ...
> >
> > > >
> > > > All of this is extremely confusing because the onus of figuring out what
> > > > the final code will look l
On Mon, 07 Apr 2025 19:50:49 +0800, Xiangsheng Hou wrote:
> In certain scenarios, for example, during fuzz testing, the source
> name may be NULL, which could lead to a kernel panic. Therefore, an
> extra check for the source name should be added.
>
>
Applied to the vfs.fixes branch of the vfs/v
xander Gordeev
Cc: Christian Borntraeger
Cc: Sven Schnelle
Cc: "Michael S. Tsirkin"
Cc: Wei Wang
Signed-off-by: David Hildenbrand
Acked-by: Christian Borntraeger
I will apply this to our internal s390 tree and let it sit for a
day to get CI coverage.
Alexander, Vasily, Heiko,
NtCsaYBeKL739Xz_6kernel4sync3rcuNtB2_5Guard3new 16 -
>-16
> Total: Before=23385830, After=23385730, chg -0.00%
>
> Link: https://github.com/Rust-for-Linux/linux/issues/1145
> Signed-off-by: I Hsin Cheng
> ---Reviewed-by: Christian Schrefl
Cheers
Christian
On Tue, 26 Nov 2024 at 12:36, Christian Göttsche
wrote:
>
> 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: warni
t
> >
> > (if still applicable)
>
> MY GOD. Hahaha. How embarrassing. God knows how 'Gideon' ended up
> there. Apologies to all, I appear to have had a senior moment there...
>
> Feel free to correct Christian, unless we want to leave this as an Easter
> Egg? :P
Everybody knows it's the "quotidian knot" that's the most challenging.
On Tue, Feb 04, 2025 at 09:43:31AM -0800, Suren Baghdasaryan wrote:
> On Tue, Feb 4, 2025 at 2:01 AM Lorenzo Stoakes
> wrote:
> >
> > On Tue, Feb 04, 2025 at 10:46:35AM +0100, Christian Brauner wrote:
> > > On Thu, 30 Jan 2025 20:40:25 +, Lorenzo Stoakes wrote:
>
On Thu, 30 Jan 2025 20:40:25 +, Lorenzo Stoakes wrote:
> If you wish to utilise a pidfd interface to refer to the current process or
> thread it is rather cumbersome, requiring something like:
>
> int pidfd = pidfd_open(getpid(), 0 or PIDFD_THREAD);
>
> ...
>
> [...]
Updated mer
> Intent is for Christian to take this in his tree (if he so wishes) to be
> clear!
If you send me an updated blurb I can fold it.
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
1 - 100 of 3165 matches
Mail list logo
