Long running ioctl and pm, which should have higher priority?

Long running ioctl and pm, which should have higher priority?

[Qu Wenruo]

Hi,

Recently I'm dealing with a bug that long running btrfs ioctls (e.g. 
scrub, dev-replace, relocation etc) can block pm suspension/hibernation.

The reason is not that hard to understand, pm requires all user 
processes to be frozen, which requires them to return to the user space, 
thus long running ioctl will break that requirement and leads to timeout.

I have submitted a fix to btrfs so that when it detects the fs or the 
process is being frozen, cancel the ioctl so pm can continue.
(https://lore.kernel.org/linux-btrfs/cover.1760588662.git.wqu@suse.com/T/#t)

But there is a question concerning me, which should have the higher 
priority? The long running ioctl or pm?


A) Long running ioctl has the priority

If the ioctl should have higher priority, the current code is fine, but 
the problem is pm will freeze all other processes (e.g. hang the GUI) 
while waiting for the long running ioctl until time out.

This can be a very frustrating behavior, thus I'm wondering if we go 
this path, is there any interface to show something like, DO NOT 
SUSPEND/HIBERNATE, and immediately let the pm to abort any 
suspension/hibernation attempt without extra timeout?


B) PM has the priority

That's what my patchset did, but the problem is a lot of jobs can not be 
ensured to finish.
If a long running ioctl is interrupted, user may need manual 
intervention to restart the process.

In some cases, the interrupted ioctl is fine to resume, like balance, 
and previously relocated blocks are already written to disk, and re-run 
the operation will start from what's left.

But some operations are not, like scrub which doesn't have any on-disk 
record on the process. It's completely on the ioctl caller to do the 
extra resume.

Furthermore the interruption may be indistinguishable between pm and 
real user signals (SIGINT etc).
If we resume immediately after pm thaw, it may mean intentionally 
interrupted operation will also be resumed.


Any feedback will be appreciated, especially from PM side.

Thanks,
Qu

Re: Long running ioctl and pm, which should have higher priority?

[Askar Safin]

Qu Wenruo <quwenruo.btrfs@gmx.com>:
> But there is a question concerning me, which should have the higher 
> priority? The long running ioctl or pm?

Of course, pm.

I have a huge btrfs fs on a laptop.

I don't want scrub to prevent suspend, even if that suspend is happening
automatically.

> Furthermore the interruption may be indistinguishable between pm and 
> real user signals (SIGINT etc).

If we interrupted because of signal, ioctl should return EINTR. This is
what all other syscalls do.

If we were cancelled, we should return ECANCELED.

If we interrupted because of process freeze or fs freeze, then... I
don't know what we should do in this case, but definitely not ECANCELED
(because we are not cancelled). EINTR will go, or maybe something else
(EAGAIN?).

Then, userspace program "btrfs scrub" can resume process if it
got EINTR. (But this is totally unimportant for me.)

Also, please CC me when sending any emails about this scrub/trim bug.

-- 
Askar Safin

Re: Long running ioctl and pm, which should have higher priority?

[Qu Wenruo]

在 2025/10/17 21:09, Askar Safin 写道:
> Qu Wenruo <quwenruo.btrfs@gmx.com>:
>> But there is a question concerning me, which should have the higher
>> priority? The long running ioctl or pm?
> 
> Of course, pm.
> 
> I have a huge btrfs fs on a laptop.
> 
> I don't want scrub to prevent suspend, even if that suspend is happening
> automatically.
> 
>> Furthermore the interruption may be indistinguishable between pm and
>> real user signals (SIGINT etc).
> 
> If we interrupted because of signal, ioctl should return EINTR. This is
> what all other syscalls do.
> 
> If we were cancelled, we should return ECANCELED.
> 
> If we interrupted because of process freeze or fs freeze, then... I
> don't know what we should do in this case, but definitely not ECANCELED
> (because we are not cancelled). EINTR will go, or maybe something else
> (EAGAIN?).
> 
> Then, userspace program "btrfs scrub" can resume process if it
> got EINTR. (But this is totally unimportant for me.)

The problem is, dev-replace can not be resumed, but start again from the 
very beginning.
As the interrupted dev-replace will remove the to-be-added device.

Scrub it self is more or less fine, just need some extra parameters to 
tell scrub to start from certain bytenr.

Thanks,
Qu

> 
> Also, please CC me when sending any emails about this scrub/trim bug.
> 

Re: Long running ioctl and pm, which should have higher priority?

[Andrei Borzenkov]

On Fri, Oct 17, 2025 at 1:43 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>
>
>
> 在 2025/10/17 21:09, Askar Safin 写道:
> > Qu Wenruo <quwenruo.btrfs@gmx.com>:
> >> But there is a question concerning me, which should have the higher
> >> priority? The long running ioctl or pm?
> >
> > Of course, pm.
> >
> > I have a huge btrfs fs on a laptop.
> >
> > I don't want scrub to prevent suspend, even if that suspend is happening
> > automatically.
> >
> >> Furthermore the interruption may be indistinguishable between pm and
> >> real user signals (SIGINT etc).
> >
> > If we interrupted because of signal, ioctl should return EINTR. This is
> > what all other syscalls do.
> >
> > If we were cancelled, we should return ECANCELED.
> >
> > If we interrupted because of process freeze or fs freeze, then... I
> > don't know what we should do in this case, but definitely not ECANCELED
> > (because we are not cancelled). EINTR will go, or maybe something else
> > (EAGAIN?).
> >
> > Then, userspace program "btrfs scrub" can resume process if it
> > got EINTR. (But this is totally unimportant for me.)
>
> The problem is, dev-replace can not be resumed, but start again from the
> very beginning.

What happens if there is a power failure? We are left with two devices
that are part of btrfs. How does btrfs decide which one is good and
which one is not?

> As the interrupted dev-replace will remove the to-be-added device.
>

In case of power failure it has no chance to remove anything.

> Scrub it self is more or less fine, just need some extra parameters to
> tell scrub to start from certain bytenr.
>
> Thanks,
> Qu
>
> >
> > Also, please CC me when sending any emails about this scrub/trim bug.
> >
>
>

Re: Long running ioctl and pm, which should have higher priority?

[Qu Wenruo]

在 2025/10/17 21:16, Andrei Borzenkov 写道:
> On Fri, Oct 17, 2025 at 1:43 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> 在 2025/10/17 21:09, Askar Safin 写道:
>>> Qu Wenruo <quwenruo.btrfs@gmx.com>:
>>>> But there is a question concerning me, which should have the higher
>>>> priority? The long running ioctl or pm?
>>>
>>> Of course, pm.
>>>
>>> I have a huge btrfs fs on a laptop.
>>>
>>> I don't want scrub to prevent suspend, even if that suspend is happening
>>> automatically.
>>>
>>>> Furthermore the interruption may be indistinguishable between pm and
>>>> real user signals (SIGINT etc).
>>>
>>> If we interrupted because of signal, ioctl should return EINTR. This is
>>> what all other syscalls do.
>>>
>>> If we were cancelled, we should return ECANCELED.
>>>
>>> If we interrupted because of process freeze or fs freeze, then... I
>>> don't know what we should do in this case, but definitely not ECANCELED
>>> (because we are not cancelled). EINTR will go, or maybe something else
>>> (EAGAIN?).
>>>
>>> Then, userspace program "btrfs scrub" can resume process if it
>>> got EINTR. (But this is totally unimportant for me.)
>>
>> The problem is, dev-replace can not be resumed, but start again from the
>> very beginning.
> 
> What happens if there is a power failure? We are left with two devices
> that are part of btrfs. How does btrfs decide which one is good and
> which one is not?

That's restartable. There is an item in the root tree indicating the 
process.

But canceled one will remove that. And we can not keep it without a 
running replace.
That will open a window where writes are not properly duplicated and 
cause problems.

> 
>> As the interrupted dev-replace will remove the to-be-added device.
>>
> 
> In case of power failure it has no chance to remove anything.
> 
>> Scrub it self is more or less fine, just need some extra parameters to
>> tell scrub to start from certain bytenr.
>>
>> Thanks,
>> Qu
>>
>>>
>>> Also, please CC me when sending any emails about this scrub/trim bug.
>>>
>>
>>
>