diff mbox series

[17/16] generic/459: prevent collisions between test VMs backed by a shared disk pool

Message ID 20241126202729.GP9438@frogsfrogsfrogs (mailing list archive)
State New
Headers show
Series [01/16] generic/757: fix various bugs in this test | expand

Commit Message

Darrick J. Wong Nov. 26, 2024, 8:27 p.m. UTC 
From: Darrick J. Wong <djwong@kernel.org>

If you happen to be running fstests on a bunch of VMs and the VMs all
have access to a shared disk pool, then it's possible that two VMs could
be running generic/459 at exactly the same time.  In that case, it's a
VERY bad thing to have two nodes trying to create an LVM volume group
named "vg_459" because one node will succeed, after which the other node
will see the vg_459 volume group that it didn't create:

  A volume group called vg_459 already exists.
  Logical volume pool_459 already exists in Volume group vg_459.
  Logical Volume "lv_459" already exists in volume group "vg_459"

But then, because this is bash, we don't abort the test script and
continue executing.  If we're lucky this fails when /dev/vg_459/lv_459
disappears before mkfs can run:

  Error accessing specified device /dev/mapper/vg_459-lv_459: No such file or directory
  Usage: mkfs.xfs

But in the bad case both nodes write filesystems to the same device and
then they trample all over each other.  Fix this by adding the hostname
and pid to all the LVM names so that they won't collide.

Fixes: 461dad511f6b91 ("generic: Test filesystem lockup on full overprovisioned dm-thin")
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
 tests/generic/459 |   15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

Comments

Christoph Hellwig Nov. 27, 2024, 5:43 a.m. UTC | #1 
On Tue, Nov 26, 2024 at 12:27:29PM -0800, Darrick J. Wong wrote:
> From: Darrick J. Wong <djwong@kernel.org>
> 
> If you happen to be running fstests on a bunch of VMs and the VMs all
> have access to a shared disk pool, then it's possible that two VMs could
> be running generic/459 at exactly the same time.  In that case, it's a
> VERY bad thing to have two nodes trying to create an LVM volume group
> named "vg_459" because one node will succeed, after which the other node
> will see the vg_459 volume group that it didn't create:
> 
>   A volume group called vg_459 already exists.
>   Logical volume pool_459 already exists in Volume group vg_459.
>   Logical Volume "lv_459" already exists in volume group "vg_459"
> 
> But then, because this is bash, we don't abort the test script and
> continue executing.  If we're lucky this fails when /dev/vg_459/lv_459
> disappears before mkfs can run:

How the F.. do the VG names leak out of the VM scope?

That being said, the unique names looks fine to me, so:

Reviewed-by: Christoph Hellwig <hch@lst.de>
Darrick J. Wong Nov. 27, 2024, 4:35 p.m. UTC | #2 
On Tue, Nov 26, 2024 at 09:43:42PM -0800, Christoph Hellwig wrote:
> On Tue, Nov 26, 2024 at 12:27:29PM -0800, Darrick J. Wong wrote:
> > From: Darrick J. Wong <djwong@kernel.org>
> > 
> > If you happen to be running fstests on a bunch of VMs and the VMs all
> > have access to a shared disk pool, then it's possible that two VMs could
> > be running generic/459 at exactly the same time.  In that case, it's a
> > VERY bad thing to have two nodes trying to create an LVM volume group
> > named "vg_459" because one node will succeed, after which the other node
> > will see the vg_459 volume group that it didn't create:
> > 
> >   A volume group called vg_459 already exists.
> >   Logical volume pool_459 already exists in Volume group vg_459.
> >   Logical Volume "lv_459" already exists in volume group "vg_459"
> > 
> > But then, because this is bash, we don't abort the test script and
> > continue executing.  If we're lucky this fails when /dev/vg_459/lv_459
> > disappears before mkfs can run:
> 
> How the F.. do the VG names leak out of the VM scope?

I ran fstests-xfs on my fstests-ocfs2 cluster, wherein all nodes have
write access to all disks because we're all one big happy fleet.  Each
node gets a list of which disks it can use for fstests so in theory
there's no overlap ... until two machines tried to create LVM VGs with
the same name at exactly the same time and tripped.  A sane prod system
would adjust the access controls per fstests run but I'm too lazy to do
that every night.

(Yeah, I just confessed to occasionally fstesting ocfs2.)

> That being said, the unique names looks fine to me, so:
> 
> Reviewed-by: Christoph Hellwig <hch@lst.de>

Thanks!

--D
diff mbox series

Patch

diff --git a/tests/generic/459 b/tests/generic/459
index 98177f6b5ef8fb..32ee899f929819 100755
--- a/tests/generic/459
+++ b/tests/generic/459
@@ -47,10 +47,17 @@  _require_command "$THIN_CHECK_PROG" thin_check
 _require_freeze
 _require_odirect
 
-vgname=vg_$seq
-lvname=lv_$seq
-poolname=pool_$seq
-snapname=snap_$seq
+# Create all the LVM names with the hostname and pid so that we don't have any
+# collisions between VMs running from a shared pool of disks.  Hyphens become
+# underscores because LVM turns those into double hyphens, which messes with
+# accessing /dev/mapper/$vg-$lv (which you're not supposed to do but this test
+# does anyway).
+lvmsuffix="${seq}_$(hostname -s | tr '-' '_')_$$"
+
+vgname=vg_$lvmsuffix
+lvname=lv_$lvmsuffix
+poolname=pool_$lvmsuffix
+snapname=snap_$lvmsuffix
 origpsize=200
 virtsize=300
 newpsize=300