(Please d̲o̲ Cc me on replies, I don’t subscribe to this list. Thanks!)

Hi,

this is a bit curious problem:

I have a setup with swap devices on dmcrypt:

$ cat /etc/crypttab
# <target name> <source device> <key file> <options>
crtpv LABEL=fooclvm none discard,luks,initramfs cswp1 /dev/vg-foo/lv-swp1 /dev/random discard,cipher=aes-xts-plain64,size=256,plain,swap
cswp2 /dev/vg-foo/lv-swp2 /dev/random discard,cipher=aes-xts-plain64,size=256,plain,swap

In a cronjob, I basically do swapoff && cryptdisks_stop && \
cryptdisks_start && swapon for both swaps individually to
throw away the old encryption key regularily (but not too
frequently).

I immediately ran into the problem, when trying this for the
first time, that a “swapoff /dev/mapper/cswp1” returns before
the device is released, so the subsequent cryptdisks_stop fails.

I found that inserting a “cat /proc/swaps”, funnily enough,
makes those failures less frequent but still present; adding
a “sleep 3” as well made it work for months.

Until tonight when it didn’t.

Just adding a “sleep” is no proper fix anyway, so the question
is, how to wait in a shell script until the swap device is
*really* swapoff’d when the syscall returns too early, and
(someone from the Linux kernel maintainers reading this?) should
I report the latter as a bug against the kernel?

This is on bullseye/amd64, on VMs and bare metal both. Using
direct partitions like /dev/sda3 (or via LABEL= to avoid trouble)
makes no difference from using LVs.

Thanks in advance,
//mirabilos
--
16:47⎜«mika:#grml» .oO(mira ist einfach gut....) 23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :) 23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Aug 20, 2024 at 11:34:32PM +0000, Thorsten Glaser wrote:

Just adding a “sleep” is no proper fix anyway, so the question
is, how to wait in a shell script until the swap device is
*really* swapoff’d when the syscall returns too early, and
(someone from the Linux kernel maintainers reading this?) should
I report the latter as a bug against the kernel?

I forget where and when (a long time ago?) but I recall having learned
that prior to swapoff it is necessary to call sync and in my history I
have it like this:

sync && sync && sync && swapoff

I couldn't tell why I have sync 3 times, but I know that it's how I've
called swapoff since as far back as I can remember.

Regards,

-Roberto

--
Roberto C. Sánchez

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Aug 20, 2024 at 20:04:11 -0400, Roberto C. S�nchez wrote:

sync && sync && sync && swapoff

I couldn't tell why I have sync 3 times, but I know that it's how I've
called swapoff since as far back as I can remember.

Cargo cult. It was never useful to the best of my knowledge.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Aug 21, 2024 at 02:18:44AM CEST, Greg Wooledge <greg@wooledge.org> said:

On Tue, Aug 20, 2024 at 20:04:11 -0400, Roberto C. Sánchez wrote:

sync && sync && sync && swapoff

I couldn't tell why I have sync 3 times, but I know that it's how I've called swapoff since as far back as I can remember.

Cargo cult. It was never useful to the best of my knowledge.

Once upon a time, the sync command would return before the actual
syscall where completed. Doing 3 times sync gave you a very high
probability that the first one indeed completed all its writes.

But it was already false in SunOS 4 (~1990)

--
Erwan David

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Aug 21, 2024 at 08:39:37 +0200, Erwan David wrote:

On Wed, Aug 21, 2024 at 02:18:44AM CEST, Greg Wooledge <greg@wooledge.org> said:

On Tue, Aug 20, 2024 at 20:04:11 -0400, Roberto C. S�nchez wrote:

sync && sync && sync && swapoff

I couldn't tell why I have sync 3 times, but I know that it's how I've called swapoff since as far back as I can remember.

Cargo cult. It was never useful to the best of my knowledge.

Once upon a time, the sync command would return before the actual
syscall where completed. Doing 3 times sync gave you a very high
probability that the first one indeed completed all its writes.

But it was already false in SunOS 4 (~1990)

Even if that's true, running them all in the same command as Roberto
shows would not give you any benefit.

You'd need to physically *type* the command and press Enter three times
to get any "protection". And even then, it's really just the extra
time that it takes to type those commands out. You'd get the same
"protection" by simply waiting 10 seconds (or whatever's appropriate)
after running sync once.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Aug 20, 2024 at 08:18:44PM -0400, Greg Wooledge wrote:

On Tue, Aug 20, 2024 at 20:04:11 -0400, Roberto C. S�nchez wrote:

sync && sync && sync && swapoff

I couldn't tell why I have sync 3 times, but I know that it's how I've called swapoff since as far back as I can remember.

Cargo cult. It was never useful to the best of my knowledge.

Yeah, that is not at all unspurising to me.

It seemed somewhat odd and since I couldn't, even after wracking my
brain, come up with a source or even a vaguely plausible reason for that particular incantation, I figured it either wasn't doing what I thought
I what was doing or (more likley) it was doing something but essentially
as a side-effect.

Regards,

-Roberto

--
Roberto C. S�nchez

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Aug 21, 2024 at 08:39:37AM +0200, Erwan David wrote:

On Wed, Aug 21, 2024 at 02:18:44AM CEST, Greg Wooledge <greg@wooledge.org> said:

On Tue, Aug 20, 2024 at 20:04:11 -0400, Roberto C. Sánchez wrote:

sync && sync && sync && swapoff

I couldn't tell why I have sync 3 times, but I know that it's how I've called swapoff since as far back as I can remember.

Cargo cult. It was never useful to the best of my knowledge.

Once upon a time, the sync command would return before the actual
syscall where completed. Doing 3 times sync gave you a very high
probability that the first one indeed completed all its writes.

I do remember one smart alec typing the following, he did not realise that typing on separate lines was to slow him down:

sync;sync;sync
^P
H

^P on a PDP-11 console made it enter console state and 'H' then halted the processor.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Aug 21, 2024 at 07:38:29AM -0400, Greg Wooledge wrote:

Even if that's true, running them all in the same command as Roberto
shows would not give you any benefit.

In early Unix sync *did* return immediately after scheduling a buffer flush.

You'd need to physically *type* the command and press Enter three times
to get any "protection". And even then, it's really just the extra
time that it takes to type those commands out.

This is exactly what I was taught to do in the 1980s and the reason was to cause delay before typing ^p.

You'd get the same "protection" by simply waiting 10 seconds (or whatever's appropriate) after running sync once.

Remembering to wait is much harder than remembering to type sync on 3 lines - especially late at night.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Just adding a “sleep” is no proper fix anyway, so the question
is, how to wait in a shell script until the swap device is
*really* swapoff’d when the syscall returns too early, and
(someone from the Linux kernel maintainers reading this?) should
I report the latter as a bug against the kernel?

I'd file a bug report against the `mount` package (the one that
provides `swapoff`).


Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

(Please Cc me on replies.)

Franco Martelli dixit:

interrupt it when a condition is satisfied, e.g.:

while true
do
/usr/bin/grep lv-swp1 /proc/swaps >/dev/null 2>&1

Not the right condition though… it’s absent there but still in use.
I am looking for the right thing to check…

bye,
//mirabilos
--
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Not the right condition though… it’s absent there but still in use.
I am looking for the right thing to check…

How 'bout checking the success of `cryptdisks_stop`?


Stefan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Mike Castle dixit:

Does cryptdisks have the ability to display what is in use at the
moment? Maybe polling that before executing the stop?

That’s what I would like to ask and why I sent this eMail.

I suspect that the race is that, when the the swapoff() syscall
returns, the kernel has indeed moved all of the content off, so that
part is fine... but it has not yet released whatever kind of resources
is has on the backing store (akin to an open file handle).

My guess as well.

You could then control the timeout by looping no more than N times,
then failing a bit more gracefully than it is now.

That’d be a method of last resort, same category as the sleep,
except even worse. I’d like to find a way to prevent that.

Thanks,
//mirabilos
--
<cnuke> den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt…
oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder
LAN party │ <nvb> damals, als der pizzateig noch auf dem monior "gegangen" ist

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Aug 22, 2024 at 01:45:06PM -0500, David Wright wrote:

On Thu 22 Aug 2024 at 17:21:04 (+0000), Thorsten Glaser wrote:

Mike Castle dixit:

[...]

I suspect that the race is that, when the the swapoff() syscall
returns, the kernel has indeed moved all of the content off, so that
part is fine... but it has not yet released whatever kind of resources
is has on the backing store (akin to an open file handle).

My guess as well.

I'm not convinced. Finding out what needs copying back and locating
somewhere to put it is AIUI a slow process.

Actually, thinking about it: if the system hasn't enough discardable
RAM, the process might take arbitrarily long, no?

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZseS1QAKCRAFyCz1etHa RlUNAJ9iZJQGm/aFDo4zfC67Z6Wsi5Iv0wCfTlmGQESrkjvstM2rDEmFUekjmGE=
=zMsE
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hey,

Thorsten Glaser <tg@debian.org> wrote on 21/08/2024 at 01:34:32+0200:

(Please d̲o̲ Cc me on replies, I don’t subscribe to this list. Thanks!)

Hi,

this is a bit curious problem:

I have a setup with swap devices on dmcrypt:

$ cat /etc/crypttab
# <target name> <source device> <key file> <options>
crtpv LABEL=fooclvm none discard,luks,initramfs
cswp1 /dev/vg-foo/lv-swp1 /dev/random discard,cipher=aes-xts-plain64,size=256,plain,swap
cswp2 /dev/vg-foo/lv-swp2 /dev/random discard,cipher=aes-xts-plain64,size=256,plain,swap

In a cronjob, I basically do swapoff && cryptdisks_stop && \
cryptdisks_start && swapon for both swaps individually to throw away
the old encryption key regularily (but not too frequently).

Ooc, what do you expect to actually gain from this setup?

Apart from that, I had read that discard does a bad job and prople
should use a fstrim timer and drop discard options from mount points.

Bests,

--
PEB

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJDBAEBCgAtFiEE5CQeth7uIW7ehIz87iFbn7jEWwsFAmbIbawPHHBlYkBkZWJp YW4ub3JnAAoJEO4hW5+4xFsLkHoP+wWbUUZ3yZAKMt7AWiiQNR+h+xBfvv4KPFr8 wB982ovttYVST3bOINxIA/OE2z8NsYujHWa8oHhAGzFfhCHkTzVogMJbsGGX+woy 0QGg3uscc2eNeuJxPY+kdxTdHQqn1ZZDcdEjvSqXsvolC0F/bmRA+JMnYJDG9CBZ tztbdmhdc1QLQ7x06ESbs7SuAYRclbz/uhzDgxsZH+IrOKWBu6Xc1Nov/SB5DwAy I2Wopnva5H1YQr1xkuFUgkvhvd2+LfKR27QLX0VlWoqb4R8QTTCg2+Uju3FJWUBd 1F+4scMr83uDU9BofyG/oJFIhyOuOINNZSWHhg9uyd3aNNBY53UPDm3X56JJAiq1 wYe46hq2DUaebwZV6NYWdA84NKeou6Umx2I3y3freCJybJR9BlHNrRPQOqYlb1tW 3T9nNVY4WJRGQF7zNq3AVPlpOuMXwkQZHko7oX//pPsuYl7z+QFxWI80zxy75Id1 8b6sxvCaZ4Bx7tGRpY7ZkyjkDxiRzb3N89AAo9az2rC7M9wxPAIPoPTqX5UeF/HP YWzI8o0pmry00rHu46OQc3kpXI5WUiAd3G3MsNUkV243c3IpFPj02bDm1gI+m8// 5Wy/4jbsxNUPK83ZUtkrnhLlTp7ybE4x9aOO6WZZhZtiCFbW1pLsj2ADIK/ux52D
1ZiZhdlX
=WucU
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Pierre-Elliott Bécue dixit:

In a cronjob, I basically do swapoff && cryptdisks_stop && \
cryptdisks_start && swapon for both swaps individually to throw away
the old encryption key regularily (but not too frequently).

Ooc, what do you expect to actually gain from this setup?

Encryption key rotation. Pages encrypted with the old key
are no longer readable afterwards. This is for long-running
VMs, on hoster infra, mostly (so the hoster could snapshot
the storage any time (ok, they could also snapshot the RAM,
but…)).

This is to get a bit closer to swapencrypt on BSD, which
uses separate keys for each page or set of pages, AIUI.

bye,
//mirabilos
--
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)