Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   bugzilla-daemon@kernel.org
To:     linux-ext4@vger.kernel.org
Subject: [Bug 216322] Freezing of tasks failed after 60.004 seconds (1 tasks
 refusing to freeze... task:fstrim  ext4_trim_fs - Dell XPS 13 9310
Date:   Thu, 04 Aug 2022 00:44:45 +0000
Message-ID: <bug-216322-13602-8CEcnRTAPy@https.bugzilla.kernel.org/>
In-Reply-To: <bug-216322-13602@https.bugzilla.kernel.org/>
References: <bug-216322-13602@https.bugzilla.kernel.org/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Auto-Submitted: auto-generated
MIME-Version: 1.0
Precedence: bulk

https://bugzilla.kernel.org/show_bug.cgi?id=3D216322

Theodore Tso (tytso@mit.edu) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tytso@mit.edu

--- Comment #2 from Theodore Tso (tytso@mit.edu) ---
So the problem is that the FITRIM ioctl does not check if a signal is pendi=
ng,
and so if the fstrim program requests that the entire SSD (len=3DULLONG_MAX=
),
like the broomstick set off by Mickey Mouse in Fantasia's "Sorcerer's
Apprentive", it will mindlessly send discard requests for any blocks not in=
 use
by the file system until it is done.   Or to put it another way, "Neither r=
ain,
nor snow, or a request to freeze the OS, shall stop the FITRIM ioctl from i=
ts
appointed task."  :-)

The question is how to fix things.   The problem is that the FITRIM ioctl
interface is pretty horrible.   The fstrim_range.len variable is an IN/OUT
field where on the input it is the number of bytes that should be trimmed (=
from
start to start+len) and when the ioctl returns fstrm_range.len is the numbe=
r of
bytes that were actually trimmed.   So this is not really amenable for
-ERESTARTSYS.

Worse, the fstrim program in util-linux doesn't handle an EAGAIN error retu=
rn
code, so if it gets the EAGAIN after try_to_freeze_tasks send the fake sign=
al
to the process, fstrim will print to stderr "fstrim: FITRIM ioctl failed" a=
nd
the rest of the file system trim operation will be aborted.

It might be that the only way we can fix this is to have FITRIM return EAGA=
IN,
which will stop the fstrim in its tracks.  This is... not great, but typica=
lly
fstrim is run out of crontab or a systemd timer once a month, so if the user
tries to suspend right as the fstrim is running, hopefully we'll get lucky =
next
month.    We can then try teach fstrim to do the right thing, and so this
lossage mode would only happen in the combination of a new kernel and an ol=
der
version of util-linux.

I'm not happy with that solution, but the alternative of creating a new FIT=
RIM2
ioctl that has a sane interface means that you need an new kernel and a new
util-linux package, and if you don't, the user will have to deal with a hot
laptop bag and a drained battery.   And not changing FITRIM's behaviour will
have the same potential end result, if the user gets unlucky and tries to
suspend the laptop when there is more than 60 seconds left before FITRIM to
complete.   :-/

The other thing I'll note is that every file system has its own FITRIM
implementation, and I suspect they all have this issue, because the FITRIM
interface is fundamentally flawed.

--=20
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.=