* [REGRESSION] fuse: xdg-document-portal gets stuck and causes suspend to fail in mainline
@ 2026-01-11 11:37 Thorsten Leemhuis
2026-01-11 15:32 ` Bernd Schubert
0 siblings, 1 reply; 5+ messages in thread
From: Thorsten Leemhuis @ 2026-01-11 11:37 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: Linux kernel regressions list, LKML, Linux-fsdevel
Lo! I can reliably get xdg-document-portal stuck on latest -mainline
(and -next, too; 6.18.4. works fine) trough the Signal flatpak, which
then causes suspend to fail:
"""
> [ 194.439381] PM: suspend entry (s2idle)
> [ 194.454708] Filesystems sync: 0.015 seconds
> [ 194.696767] Freezing user space processes
> [ 214.700978] Freezing user space processes failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):
> [ 214.701143] task:xdg-document-po state:D stack:0 pid:2651 tgid:2651 ppid:1939 task_flags:0x400000 flags:0x00080002
> [ 214.701151] Call Trace:
> [ 214.701154] <TASK>
> [ 214.701167] __schedule+0x2b8/0x5e0
> [ 214.701181] schedule+0x27/0x80
> [ 214.701188] request_wait_answer+0xce/0x260 [fuse]
> [ 214.701202] ? __pfx_autoremove_wake_function+0x10/0x10
> [ 214.701212] __fuse_simple_request+0x120/0x340 [fuse]
> [ 214.701219] fuse_lookup_name+0xc3/0x210 [fuse]
> [ 214.701235] fuse_lookup+0x99/0x1c0 [fuse]
> [ 214.701242] ? srso_alias_return_thunk+0x5/0xfbef5
> [ 214.701247] ? fuse_dentry_init+0x23/0x50 [fuse]
> [ 214.701257] lookup_one_qstr_excl+0xa8/0xf0
> [ 214.701264] start_removing_noperm+0x59/0x80
> [ 214.701268] ? d_find_alias+0x82/0xd0
> [ 214.701273] fuse_reverse_inval_entry+0x7d/0x1f0 [fuse]
> [ 214.701280] ? fuse_copy_do+0x5f/0xa0 [fuse]
> [ 214.701287] fuse_notify+0x4a1/0x750 [fuse]
> [ 214.701295] ? iov_iter_get_pages2+0x1d/0x40
> [ 214.701301] ? srso_alias_return_thunk+0x5/0xfbef5
> [ 214.701305] fuse_dev_do_write+0x2e4/0x440 [fuse]
> [ 214.701313] fuse_dev_write+0x6b/0xa0 [fuse]
> [ 214.701320] do_iter_readv_writev+0x161/0x260
> [ 214.701327] vfs_writev+0x168/0x3c0
> [ 214.701334] ? ksys_write+0xcd/0xf0
> [ 214.701338] ? do_writev+0x7f/0x110
> [ 214.701341] do_writev+0x7f/0x110
> [ 214.701344] do_syscall_64+0x7e/0x6b0
> [ 214.701350] ? srso_alias_return_thunk+0x5/0xfbef5
> [ 214.701352] ? __handle_mm_fault+0x445/0x690
> [ 214.701359] ? srso_alias_return_thunk+0x5/0xfbef5
> [ 214.701363] ? srso_alias_return_thunk+0x5/0xfbef5
> [ 214.701365] ? count_memcg_events+0xd6/0x210
> [ 214.701371] ? srso_alias_return_thunk+0x5/0xfbef5
> [ 214.701373] ? handle_mm_fault+0x212/0x340
> [ 214.701377] ? srso_alias_return_thunk+0x5/0xfbef5
> [ 214.701379] ? do_user_addr_fault+0x2b4/0x7b0
> [ 214.701387] ? srso_alias_return_thunk+0x5/0xfbef5
> [ 214.701389] ? irqentry_exit+0x6d/0x540
> [ 214.701393] ? srso_alias_return_thunk+0x5/0xfbef5
> [ 214.701395] ? exc_page_fault+0x7e/0x1a0
> [ 214.701398] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [ 214.701402] RIP: 0033:0x7f3c144f9982
> [ 214.701467] RSP: 002b:00007fff80e2f388 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
> [ 214.701470] RAX: ffffffffffffffda RBX: 00007f3bec000cf0 RCX: 00007f3c144f9982
> [ 214.701472] RDX: 0000000000000003 RSI: 00007fff80e2f460 RDI: 0000000000000007
> [ 214.701474] RBP: 00007fff80e2f3b0 R08: 0000000000000000 R09: 0000000000000000
> [ 214.701475] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> [ 214.701477] R13: 00007f3bec000cf0 R14: 00007f3c14bb8280 R15: 00007f3be8001200
> [ 214.701481] </TASK>
"""
Killing the mentioned process using "kill -9" doesn't help. I can
reliably trigger this in -mainline and -next using the Signal flatpak on
Fedora 43 by trying to send a picture (which gets xdg-document-portal
involved). It works the first time, but trying again won't and will
cause Signal to get stuck for a few seconds. Works fine in 6.18.4.
Is this maybe known already or does anybody have an idea what's wrong?
If not I guess I'll have to bisect this.
Ciao, Thorsten
#regzbot introduced: v6.18..
#regzbot title: fuse: xdg-document-portal gets stuck and causes suspend
to fail
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [REGRESSION] fuse: xdg-document-portal gets stuck and causes suspend to fail in mainline
2026-01-11 11:37 [REGRESSION] fuse: xdg-document-portal gets stuck and causes suspend to fail in mainline Thorsten Leemhuis
@ 2026-01-11 15:32 ` Bernd Schubert
2026-01-12 3:58 ` NeilBrown
0 siblings, 1 reply; 5+ messages in thread
From: Bernd Schubert @ 2026-01-11 15:32 UTC (permalink / raw)
To: Thorsten Leemhuis, Miklos Szeredi
Cc: Linux kernel regressions list, LKML, Linux-fsdevel, NeilBrown,
Christian Brauner
On 1/11/26 12:37, Thorsten Leemhuis wrote:
> Lo! I can reliably get xdg-document-portal stuck on latest -mainline
> (and -next, too; 6.18.4. works fine) trough the Signal flatpak, which
> then causes suspend to fail:
>
> """
>> [ 194.439381] PM: suspend entry (s2idle)
>> [ 194.454708] Filesystems sync: 0.015 seconds
>> [ 194.696767] Freezing user space processes
>> [ 214.700978] Freezing user space processes failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):
>> [ 214.701143] task:xdg-document-po state:D stack:0 pid:2651 tgid:2651 ppid:1939 task_flags:0x400000 flags:0x00080002
>> [ 214.701151] Call Trace:
>> [ 214.701154] <TASK>
>> [ 214.701167] __schedule+0x2b8/0x5e0
>> [ 214.701181] schedule+0x27/0x80
>> [ 214.701188] request_wait_answer+0xce/0x260 [fuse]
>> [ 214.701202] ? __pfx_autoremove_wake_function+0x10/0x10
>> [ 214.701212] __fuse_simple_request+0x120/0x340 [fuse]
>> [ 214.701219] fuse_lookup_name+0xc3/0x210 [fuse]
>> [ 214.701235] fuse_lookup+0x99/0x1c0 [fuse]
>> [ 214.701242] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 214.701247] ? fuse_dentry_init+0x23/0x50 [fuse]
>> [ 214.701257] lookup_one_qstr_excl+0xa8/0xf0
Introduced by c9ba789dad15 ("VFS: introduce start_creating_noperm() and
start_removing_noperm()")?
Why is the new code doing a lookup on an entry that is about to be
invalidated?
In order to handle this at least one fuse server process needs to be
available, but for this specific case the lookup still doesn't make sense.
We could do something like this
diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
index 4b6b3d2758ff..7edbace7eddc 100644
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@ -1599,6 +1599,15 @@ int fuse_reverse_inval_entry(struct fuse_conn
*fc, u64 parent_nodeid,
if (!dir)
goto put_parent;
+ /* Check dcache first - if not cached, nothing to invalidate */
+ name->hash = full_name_hash(dir, name->name, name->len);
+ entry = d_lookup(dir, name);
+ if (!entry) {
+ err = 0;
+ dput(dir);
+ goto put_parent;
+ }
+
entry = start_removing_noperm(dir, name);
dput(dir);
if (IS_ERR(entry))
But let's assume the dentry exists - start_removing_noperm() will now
trigger a revalidate and get the same issue. From my point of view the
above commit should be reverted for fuse.
>> [ 214.701264] start_removing_noperm+0x59/0x80
>> [ 214.701268] ? d_find_alias+0x82/0xd0
>> [ 214.701273] fuse_reverse_inval_entry+0x7d/0x1f0 [fuse]
>> [ 214.701280] ? fuse_copy_do+0x5f/0xa0 [fuse]
>> [ 214.701287] fuse_notify+0x4a1/0x750 [fuse]
>> [ 214.701295] ? iov_iter_get_pages2+0x1d/0x40
>> [ 214.701301] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 214.701305] fuse_dev_do_write+0x2e4/0x440 [fuse]
>> [ 214.701313] fuse_dev_write+0x6b/0xa0 [fuse]
>> [ 214.701320] do_iter_readv_writev+0x161/0x260
>> [ 214.701327] vfs_writev+0x168/0x3c0
>> [ 214.701334] ? ksys_write+0xcd/0xf0
>> [ 214.701338] ? do_writev+0x7f/0x110
>> [ 214.701341] do_writev+0x7f/0x110
>> [ 214.701344] do_syscall_64+0x7e/0x6b0
>> [ 214.701350] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 214.701352] ? __handle_mm_fault+0x445/0x690
>> [ 214.701359] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 214.701363] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 214.701365] ? count_memcg_events+0xd6/0x210
>> [ 214.701371] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 214.701373] ? handle_mm_fault+0x212/0x340
>> [ 214.701377] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 214.701379] ? do_user_addr_fault+0x2b4/0x7b0
>> [ 214.701387] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 214.701389] ? irqentry_exit+0x6d/0x540
>> [ 214.701393] ? srso_alias_return_thunk+0x5/0xfbef5
>> [ 214.701395] ? exc_page_fault+0x7e/0x1a0
>> [ 214.701398] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>> [ 214.701402] RIP: 0033:0x7f3c144f9982
>> [ 214.701467] RSP: 002b:00007fff80e2f388 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
>> [ 214.701470] RAX: ffffffffffffffda RBX: 00007f3bec000cf0 RCX: 00007f3c144f9982
>> [ 214.701472] RDX: 0000000000000003 RSI: 00007fff80e2f460 RDI: 0000000000000007
>> [ 214.701474] RBP: 00007fff80e2f3b0 R08: 0000000000000000 R09: 0000000000000000
>> [ 214.701475] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
>> [ 214.701477] R13: 00007f3bec000cf0 R14: 00007f3c14bb8280 R15: 00007f3be8001200
>> [ 214.701481] </TASK>
> """
>
> Killing the mentioned process using "kill -9" doesn't help. I can
> reliably trigger this in -mainline and -next using the Signal flatpak on
> Fedora 43 by trying to send a picture (which gets xdg-document-portal
> involved). It works the first time, but trying again won't and will
> cause Signal to get stuck for a few seconds. Works fine in 6.18.4.
>
> Is this maybe known already or does anybody have an idea what's wrong?
> If not I guess I'll have to bisect this.
>
> Ciao, Thorsten
>
> #regzbot introduced: v6.18..
> #regzbot title: fuse: xdg-document-portal gets stuck and causes suspend
> to fail
>
>
Thanks,
Bernd
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [REGRESSION] fuse: xdg-document-portal gets stuck and causes suspend to fail in mainline
2026-01-11 15:32 ` Bernd Schubert
@ 2026-01-12 3:58 ` NeilBrown
2026-01-12 9:45 ` Christian Brauner
2026-01-12 10:40 ` Bernd Schubert
0 siblings, 2 replies; 5+ messages in thread
From: NeilBrown @ 2026-01-12 3:58 UTC (permalink / raw)
To: Bernd Schubert
Cc: Thorsten Leemhuis, Miklos Szeredi, Linux kernel regressions list,
LKML, Linux-fsdevel, Christian Brauner
On Mon, 12 Jan 2026, Bernd Schubert wrote:
>
> On 1/11/26 12:37, Thorsten Leemhuis wrote:
> > Lo! I can reliably get xdg-document-portal stuck on latest -mainline
> > (and -next, too; 6.18.4. works fine) trough the Signal flatpak, which
> > then causes suspend to fail:
> >
> > """
> >> [ 194.439381] PM: suspend entry (s2idle)
> >> [ 194.454708] Filesystems sync: 0.015 seconds
> >> [ 194.696767] Freezing user space processes
> >> [ 214.700978] Freezing user space processes failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):
> >> [ 214.701143] task:xdg-document-po state:D stack:0 pid:2651 tgid:2651 ppid:1939 task_flags:0x400000 flags:0x00080002
> >> [ 214.701151] Call Trace:
> >> [ 214.701154] <TASK>
> >> [ 214.701167] __schedule+0x2b8/0x5e0
> >> [ 214.701181] schedule+0x27/0x80
> >> [ 214.701188] request_wait_answer+0xce/0x260 [fuse]
> >> [ 214.701202] ? __pfx_autoremove_wake_function+0x10/0x10
> >> [ 214.701212] __fuse_simple_request+0x120/0x340 [fuse]
> >> [ 214.701219] fuse_lookup_name+0xc3/0x210 [fuse]
> >> [ 214.701235] fuse_lookup+0x99/0x1c0 [fuse]
> >> [ 214.701242] ? srso_alias_return_thunk+0x5/0xfbef5
> >> [ 214.701247] ? fuse_dentry_init+0x23/0x50 [fuse]
> >> [ 214.701257] lookup_one_qstr_excl+0xa8/0xf0
>
> Introduced by c9ba789dad15 ("VFS: introduce start_creating_noperm() and
> start_removing_noperm()")?
>
> Why is the new code doing a lookup on an entry that is about to be
> invalidated?
>
>
> In order to handle this at least one fuse server process needs to be
> available, but for this specific case the lookup still doesn't make sense.
>
> We could do something like this
>
> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> index 4b6b3d2758ff..7edbace7eddc 100644
> --- a/fs/fuse/dir.c
> +++ b/fs/fuse/dir.c
> @@ -1599,6 +1599,15 @@ int fuse_reverse_inval_entry(struct fuse_conn
> *fc, u64 parent_nodeid,
> if (!dir)
> goto put_parent;
>
> + /* Check dcache first - if not cached, nothing to invalidate */
> + name->hash = full_name_hash(dir, name->name, name->len);
> + entry = d_lookup(dir, name);
> + if (!entry) {
> + err = 0;
> + dput(dir);
> + goto put_parent;
> + }
> +
> entry = start_removing_noperm(dir, name);
> dput(dir);
> if (IS_ERR(entry))
>
>
> But let's assume the dentry exists - start_removing_noperm() will now
> trigger a revalidate and get the same issue. From my point of view the
> above commit should be reverted for fuse.
>
>
> >> [ 214.701264] start_removing_noperm+0x59/0x80
> >> [ 214.701268] ? d_find_alias+0x82/0xd0
> >> [ 214.701273] fuse_reverse_inval_entry+0x7d/0x1f0 [fuse]
> >> [ 214.701280] ? fuse_copy_do+0x5f/0xa0 [fuse]
> >> [ 214.701287] fuse_notify+0x4a1/0x750 [fuse]
> >> [ 214.701295] ? iov_iter_get_pages2+0x1d/0x40
> >> [ 214.701301] ? srso_alias_return_thunk+0x5/0xfbef5
> >> [ 214.701305] fuse_dev_do_write+0x2e4/0x440 [fuse]
> >> [ 214.701313] fuse_dev_write+0x6b/0xa0 [fuse]
> >> [ 214.701320] do_iter_readv_writev+0x161/0x260
> >> [ 214.701327] vfs_writev+0x168/0x3c0
> >> [ 214.701334] ? ksys_write+0xcd/0xf0
> >> [ 214.701338] ? do_writev+0x7f/0x110
> >> [ 214.701341] do_writev+0x7f/0x110
> >> [ 214.701344] do_syscall_64+0x7e/0x6b0
> >> [ 214.701350] ? srso_alias_return_thunk+0x5/0xfbef5
> >> [ 214.701352] ? __handle_mm_fault+0x445/0x690
> >> [ 214.701359] ? srso_alias_return_thunk+0x5/0xfbef5
> >> [ 214.701363] ? srso_alias_return_thunk+0x5/0xfbef5
> >> [ 214.701365] ? count_memcg_events+0xd6/0x210
> >> [ 214.701371] ? srso_alias_return_thunk+0x5/0xfbef5
> >> [ 214.701373] ? handle_mm_fault+0x212/0x340
> >> [ 214.701377] ? srso_alias_return_thunk+0x5/0xfbef5
> >> [ 214.701379] ? do_user_addr_fault+0x2b4/0x7b0
> >> [ 214.701387] ? srso_alias_return_thunk+0x5/0xfbef5
> >> [ 214.701389] ? irqentry_exit+0x6d/0x540
> >> [ 214.701393] ? srso_alias_return_thunk+0x5/0xfbef5
> >> [ 214.701395] ? exc_page_fault+0x7e/0x1a0
> >> [ 214.701398] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> >> [ 214.701402] RIP: 0033:0x7f3c144f9982
> >> [ 214.701467] RSP: 002b:00007fff80e2f388 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
> >> [ 214.701470] RAX: ffffffffffffffda RBX: 00007f3bec000cf0 RCX: 00007f3c144f9982
> >> [ 214.701472] RDX: 0000000000000003 RSI: 00007fff80e2f460 RDI: 0000000000000007
> >> [ 214.701474] RBP: 00007fff80e2f3b0 R08: 0000000000000000 R09: 0000000000000000
> >> [ 214.701475] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> >> [ 214.701477] R13: 00007f3bec000cf0 R14: 00007f3c14bb8280 R15: 00007f3be8001200
> >> [ 214.701481] </TASK>
> > """
> >
> > Killing the mentioned process using "kill -9" doesn't help. I can
> > reliably trigger this in -mainline and -next using the Signal flatpak on
> > Fedora 43 by trying to send a picture (which gets xdg-document-portal
> > involved). It works the first time, but trying again won't and will
> > cause Signal to get stuck for a few seconds. Works fine in 6.18.4.
> >
> > Is this maybe known already or does anybody have an idea what's wrong?
> > If not I guess I'll have to bisect this.
> >
> > Ciao, Thorsten
> >
> > #regzbot introduced: v6.18..
> > #regzbot title: fuse: xdg-document-portal gets stuck and causes suspend
> > to fail
> >
> >
>
> Thanks,
> Bernd
>
I post a fix
https://lore.kernel.org/all/176454037897.634289.3566631742434963788@noble.neil.brown.name/
a while ago. There was some talk in that thread of reverting the
breaking change instead. I seems nothing happened.
Christian: should I resend my patch?
Thanks,
NeilBrown
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [REGRESSION] fuse: xdg-document-portal gets stuck and causes suspend to fail in mainline
2026-01-12 3:58 ` NeilBrown
@ 2026-01-12 9:45 ` Christian Brauner
2026-01-12 10:40 ` Bernd Schubert
1 sibling, 0 replies; 5+ messages in thread
From: Christian Brauner @ 2026-01-12 9:45 UTC (permalink / raw)
To: NeilBrown
Cc: Bernd Schubert, Thorsten Leemhuis, Miklos Szeredi,
Linux kernel regressions list, LKML, Linux-fsdevel
On Mon, Jan 12, 2026 at 02:58:20PM +1100, NeilBrown wrote:
> On Mon, 12 Jan 2026, Bernd Schubert wrote:
> >
> > On 1/11/26 12:37, Thorsten Leemhuis wrote:
> > > Lo! I can reliably get xdg-document-portal stuck on latest -mainline
> > > (and -next, too; 6.18.4. works fine) trough the Signal flatpak, which
> > > then causes suspend to fail:
> > >
> > > """
> > >> [ 194.439381] PM: suspend entry (s2idle)
> > >> [ 194.454708] Filesystems sync: 0.015 seconds
> > >> [ 194.696767] Freezing user space processes
> > >> [ 214.700978] Freezing user space processes failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):
> > >> [ 214.701143] task:xdg-document-po state:D stack:0 pid:2651 tgid:2651 ppid:1939 task_flags:0x400000 flags:0x00080002
> > >> [ 214.701151] Call Trace:
> > >> [ 214.701154] <TASK>
> > >> [ 214.701167] __schedule+0x2b8/0x5e0
> > >> [ 214.701181] schedule+0x27/0x80
> > >> [ 214.701188] request_wait_answer+0xce/0x260 [fuse]
> > >> [ 214.701202] ? __pfx_autoremove_wake_function+0x10/0x10
> > >> [ 214.701212] __fuse_simple_request+0x120/0x340 [fuse]
> > >> [ 214.701219] fuse_lookup_name+0xc3/0x210 [fuse]
> > >> [ 214.701235] fuse_lookup+0x99/0x1c0 [fuse]
> > >> [ 214.701242] ? srso_alias_return_thunk+0x5/0xfbef5
> > >> [ 214.701247] ? fuse_dentry_init+0x23/0x50 [fuse]
> > >> [ 214.701257] lookup_one_qstr_excl+0xa8/0xf0
> >
> > Introduced by c9ba789dad15 ("VFS: introduce start_creating_noperm() and
> > start_removing_noperm()")?
> >
> > Why is the new code doing a lookup on an entry that is about to be
> > invalidated?
> >
> >
> > In order to handle this at least one fuse server process needs to be
> > available, but for this specific case the lookup still doesn't make sense.
> >
> > We could do something like this
> >
> > diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
> > index 4b6b3d2758ff..7edbace7eddc 100644
> > --- a/fs/fuse/dir.c
> > +++ b/fs/fuse/dir.c
> > @@ -1599,6 +1599,15 @@ int fuse_reverse_inval_entry(struct fuse_conn
> > *fc, u64 parent_nodeid,
> > if (!dir)
> > goto put_parent;
> >
> > + /* Check dcache first - if not cached, nothing to invalidate */
> > + name->hash = full_name_hash(dir, name->name, name->len);
> > + entry = d_lookup(dir, name);
> > + if (!entry) {
> > + err = 0;
> > + dput(dir);
> > + goto put_parent;
> > + }
> > +
> > entry = start_removing_noperm(dir, name);
> > dput(dir);
> > if (IS_ERR(entry))
> >
> >
> > But let's assume the dentry exists - start_removing_noperm() will now
> > trigger a revalidate and get the same issue. From my point of view the
> > above commit should be reverted for fuse.
> >
> >
> > >> [ 214.701264] start_removing_noperm+0x59/0x80
> > >> [ 214.701268] ? d_find_alias+0x82/0xd0
> > >> [ 214.701273] fuse_reverse_inval_entry+0x7d/0x1f0 [fuse]
> > >> [ 214.701280] ? fuse_copy_do+0x5f/0xa0 [fuse]
> > >> [ 214.701287] fuse_notify+0x4a1/0x750 [fuse]
> > >> [ 214.701295] ? iov_iter_get_pages2+0x1d/0x40
> > >> [ 214.701301] ? srso_alias_return_thunk+0x5/0xfbef5
> > >> [ 214.701305] fuse_dev_do_write+0x2e4/0x440 [fuse]
> > >> [ 214.701313] fuse_dev_write+0x6b/0xa0 [fuse]
> > >> [ 214.701320] do_iter_readv_writev+0x161/0x260
> > >> [ 214.701327] vfs_writev+0x168/0x3c0
> > >> [ 214.701334] ? ksys_write+0xcd/0xf0
> > >> [ 214.701338] ? do_writev+0x7f/0x110
> > >> [ 214.701341] do_writev+0x7f/0x110
> > >> [ 214.701344] do_syscall_64+0x7e/0x6b0
> > >> [ 214.701350] ? srso_alias_return_thunk+0x5/0xfbef5
> > >> [ 214.701352] ? __handle_mm_fault+0x445/0x690
> > >> [ 214.701359] ? srso_alias_return_thunk+0x5/0xfbef5
> > >> [ 214.701363] ? srso_alias_return_thunk+0x5/0xfbef5
> > >> [ 214.701365] ? count_memcg_events+0xd6/0x210
> > >> [ 214.701371] ? srso_alias_return_thunk+0x5/0xfbef5
> > >> [ 214.701373] ? handle_mm_fault+0x212/0x340
> > >> [ 214.701377] ? srso_alias_return_thunk+0x5/0xfbef5
> > >> [ 214.701379] ? do_user_addr_fault+0x2b4/0x7b0
> > >> [ 214.701387] ? srso_alias_return_thunk+0x5/0xfbef5
> > >> [ 214.701389] ? irqentry_exit+0x6d/0x540
> > >> [ 214.701393] ? srso_alias_return_thunk+0x5/0xfbef5
> > >> [ 214.701395] ? exc_page_fault+0x7e/0x1a0
> > >> [ 214.701398] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > >> [ 214.701402] RIP: 0033:0x7f3c144f9982
> > >> [ 214.701467] RSP: 002b:00007fff80e2f388 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
> > >> [ 214.701470] RAX: ffffffffffffffda RBX: 00007f3bec000cf0 RCX: 00007f3c144f9982
> > >> [ 214.701472] RDX: 0000000000000003 RSI: 00007fff80e2f460 RDI: 0000000000000007
> > >> [ 214.701474] RBP: 00007fff80e2f3b0 R08: 0000000000000000 R09: 0000000000000000
> > >> [ 214.701475] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> > >> [ 214.701477] R13: 00007f3bec000cf0 R14: 00007f3c14bb8280 R15: 00007f3be8001200
> > >> [ 214.701481] </TASK>
> > > """
> > >
> > > Killing the mentioned process using "kill -9" doesn't help. I can
> > > reliably trigger this in -mainline and -next using the Signal flatpak on
> > > Fedora 43 by trying to send a picture (which gets xdg-document-portal
> > > involved). It works the first time, but trying again won't and will
> > > cause Signal to get stuck for a few seconds. Works fine in 6.18.4.
> > >
> > > Is this maybe known already or does anybody have an idea what's wrong?
> > > If not I guess I'll have to bisect this.
> > >
> > > Ciao, Thorsten
> > >
> > > #regzbot introduced: v6.18..
> > > #regzbot title: fuse: xdg-document-portal gets stuck and causes suspend
> > > to fail
> > >
> > >
> >
> > Thanks,
> > Bernd
> >
>
> I post a fix
>
> https://lore.kernel.org/all/176454037897.634289.3566631742434963788@noble.neil.brown.name/
>
> a while ago. There was some talk in that thread of reverting the
> breaking change instead. I seems nothing happened.
I pinged a bunch of times but nobody ever responded.
So then let's just apply your patch. I picked it up.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [REGRESSION] fuse: xdg-document-portal gets stuck and causes suspend to fail in mainline
2026-01-12 3:58 ` NeilBrown
2026-01-12 9:45 ` Christian Brauner
@ 2026-01-12 10:40 ` Bernd Schubert
1 sibling, 0 replies; 5+ messages in thread
From: Bernd Schubert @ 2026-01-12 10:40 UTC (permalink / raw)
To: NeilBrown
Cc: Thorsten Leemhuis, Miklos Szeredi, Linux kernel regressions list,
LKML, Linux-fsdevel, Christian Brauner
On 1/12/26 04:58, NeilBrown wrote:
> On Mon, 12 Jan 2026, Bernd Schubert wrote:
>>
>> On 1/11/26 12:37, Thorsten Leemhuis wrote:
>>> Lo! I can reliably get xdg-document-portal stuck on latest -mainline
>>> (and -next, too; 6.18.4. works fine) trough the Signal flatpak, which
>>> then causes suspend to fail:
>>>
>>> """
>>>> [ 194.439381] PM: suspend entry (s2idle)
>>>> [ 194.454708] Filesystems sync: 0.015 seconds
>>>> [ 194.696767] Freezing user space processes
>>>> [ 214.700978] Freezing user space processes failed after 20.004 seconds (1 tasks refusing to freeze, wq_busy=0):
>>>> [ 214.701143] task:xdg-document-po state:D stack:0 pid:2651 tgid:2651 ppid:1939 task_flags:0x400000 flags:0x00080002
>>>> [ 214.701151] Call Trace:
>>>> [ 214.701154] <TASK>
>>>> [ 214.701167] __schedule+0x2b8/0x5e0
>>>> [ 214.701181] schedule+0x27/0x80
>>>> [ 214.701188] request_wait_answer+0xce/0x260 [fuse]
>>>> [ 214.701202] ? __pfx_autoremove_wake_function+0x10/0x10
>>>> [ 214.701212] __fuse_simple_request+0x120/0x340 [fuse]
>>>> [ 214.701219] fuse_lookup_name+0xc3/0x210 [fuse]
>>>> [ 214.701235] fuse_lookup+0x99/0x1c0 [fuse]
>>>> [ 214.701242] ? srso_alias_return_thunk+0x5/0xfbef5
>>>> [ 214.701247] ? fuse_dentry_init+0x23/0x50 [fuse]
>>>> [ 214.701257] lookup_one_qstr_excl+0xa8/0xf0
>>
>> Introduced by c9ba789dad15 ("VFS: introduce start_creating_noperm() and
>> start_removing_noperm()")?
>>
>> Why is the new code doing a lookup on an entry that is about to be
>> invalidated?
>>
>>
>> In order to handle this at least one fuse server process needs to be
>> available, but for this specific case the lookup still doesn't make sense.
>>
>> We could do something like this
>>
>> diff --git a/fs/fuse/dir.c b/fs/fuse/dir.c
>> index 4b6b3d2758ff..7edbace7eddc 100644
>> --- a/fs/fuse/dir.c
>> +++ b/fs/fuse/dir.c
>> @@ -1599,6 +1599,15 @@ int fuse_reverse_inval_entry(struct fuse_conn
>> *fc, u64 parent_nodeid,
>> if (!dir)
>> goto put_parent;
>>
>> + /* Check dcache first - if not cached, nothing to invalidate */
>> + name->hash = full_name_hash(dir, name->name, name->len);
>> + entry = d_lookup(dir, name);
>> + if (!entry) {
>> + err = 0;
>> + dput(dir);
>> + goto put_parent;
>> + }
>> +
>> entry = start_removing_noperm(dir, name);
>> dput(dir);
>> if (IS_ERR(entry))
>>
>>
>> But let's assume the dentry exists - start_removing_noperm() will now
>> trigger a revalidate and get the same issue. From my point of view the
>> above commit should be reverted for fuse.
>>
>>
>>>> [ 214.701264] start_removing_noperm+0x59/0x80
>>>> [ 214.701268] ? d_find_alias+0x82/0xd0
>>>> [ 214.701273] fuse_reverse_inval_entry+0x7d/0x1f0 [fuse]
>>>> [ 214.701280] ? fuse_copy_do+0x5f/0xa0 [fuse]
>>>> [ 214.701287] fuse_notify+0x4a1/0x750 [fuse]
>>>> [ 214.701295] ? iov_iter_get_pages2+0x1d/0x40
>>>> [ 214.701301] ? srso_alias_return_thunk+0x5/0xfbef5
>>>> [ 214.701305] fuse_dev_do_write+0x2e4/0x440 [fuse]
>>>> [ 214.701313] fuse_dev_write+0x6b/0xa0 [fuse]
>>>> [ 214.701320] do_iter_readv_writev+0x161/0x260
>>>> [ 214.701327] vfs_writev+0x168/0x3c0
>>>> [ 214.701334] ? ksys_write+0xcd/0xf0
>>>> [ 214.701338] ? do_writev+0x7f/0x110
>>>> [ 214.701341] do_writev+0x7f/0x110
>>>> [ 214.701344] do_syscall_64+0x7e/0x6b0
>>>> [ 214.701350] ? srso_alias_return_thunk+0x5/0xfbef5
>>>> [ 214.701352] ? __handle_mm_fault+0x445/0x690
>>>> [ 214.701359] ? srso_alias_return_thunk+0x5/0xfbef5
>>>> [ 214.701363] ? srso_alias_return_thunk+0x5/0xfbef5
>>>> [ 214.701365] ? count_memcg_events+0xd6/0x210
>>>> [ 214.701371] ? srso_alias_return_thunk+0x5/0xfbef5
>>>> [ 214.701373] ? handle_mm_fault+0x212/0x340
>>>> [ 214.701377] ? srso_alias_return_thunk+0x5/0xfbef5
>>>> [ 214.701379] ? do_user_addr_fault+0x2b4/0x7b0
>>>> [ 214.701387] ? srso_alias_return_thunk+0x5/0xfbef5
>>>> [ 214.701389] ? irqentry_exit+0x6d/0x540
>>>> [ 214.701393] ? srso_alias_return_thunk+0x5/0xfbef5
>>>> [ 214.701395] ? exc_page_fault+0x7e/0x1a0
>>>> [ 214.701398] entry_SYSCALL_64_after_hwframe+0x76/0x7e
>>>> [ 214.701402] RIP: 0033:0x7f3c144f9982
>>>> [ 214.701467] RSP: 002b:00007fff80e2f388 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
>>>> [ 214.701470] RAX: ffffffffffffffda RBX: 00007f3bec000cf0 RCX: 00007f3c144f9982
>>>> [ 214.701472] RDX: 0000000000000003 RSI: 00007fff80e2f460 RDI: 0000000000000007
>>>> [ 214.701474] RBP: 00007fff80e2f3b0 R08: 0000000000000000 R09: 0000000000000000
>>>> [ 214.701475] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
>>>> [ 214.701477] R13: 00007f3bec000cf0 R14: 00007f3c14bb8280 R15: 00007f3be8001200
>>>> [ 214.701481] </TASK>
>>> """
>>>
>>> Killing the mentioned process using "kill -9" doesn't help. I can
>>> reliably trigger this in -mainline and -next using the Signal flatpak on
>>> Fedora 43 by trying to send a picture (which gets xdg-document-portal
>>> involved). It works the first time, but trying again won't and will
>>> cause Signal to get stuck for a few seconds. Works fine in 6.18.4.
>>>
>>> Is this maybe known already or does anybody have an idea what's wrong?
>>> If not I guess I'll have to bisect this.
>>>
>>> Ciao, Thorsten
>>>
>>> #regzbot introduced: v6.18..
>>> #regzbot title: fuse: xdg-document-portal gets stuck and causes suspend
>>> to fail
>>>
>>>
>>
>> Thanks,
>> Bernd
>>
>
> I post a fix
>
> https://lore.kernel.org/all/176454037897.634289.3566631742434963788@noble.neil.brown.name/
>
> a while ago. There was some talk in that thread of reverting the
> breaking change instead. I seems nothing happened.
>
> Christian: should I resend my patch?
This didn't go to linux-fsdevel and I'm not subscribed to the other
lists. Might be the same for others. The patch looks good to me
Reviewed-by: Bernd Schubert <bschubert@ddn.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-01-12 10:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-01-11 11:37 [REGRESSION] fuse: xdg-document-portal gets stuck and causes suspend to fail in mainline Thorsten Leemhuis
2026-01-11 15:32 ` Bernd Schubert
2026-01-12 3:58 ` NeilBrown
2026-01-12 9:45 ` Christian Brauner
2026-01-12 10:40 ` Bernd Schubert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®