Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1971989

Summary: mkswap some-file gets stuck
Product: Red Hat Enterprise Linux 9 Reporter: Brian Lane <bcl>
Component: util-linuxAssignee: Karel Zak <kzak>
Status: CLOSED CURRENTRELEASE QA Contact: Frantisek Sumsal <fsumsal>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 9.0CC: extras-qa, fsumsal, jonathan, kzak
Target Milestone: betaFlags: pm-rhel: mirror+
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: util-linux-2.37.1-1.el9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1971877 Environment:
Last Closed: 2021-12-07 21:50:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1971877    
Bug Blocks:    

Description Brian Lane 2021-06-14 23:01:51 UTC
+++ This bug was initially created as a clone of Bug #1971877 +++

Description of problem:
While scratch building a new version of parted we discovered that the test suite gets stuck running mkswap on a file and never exits.

https://koji.fedoraproject.org/koji/taskinfo?taskID=70093944

The setup for the mock used by the builder is here:

https://kojipkgs.fedoraproject.org//work/tasks/4003/70094003/mock_output.log

It is using util-linux-core-2.37-2.fc35.x86_64


The test that is getting stuck is basically doing this:

dd if=/dev/null of=loop-file bs=1 seek=1M
mkswap loop-file
parted -s loop-file mklabel msdos

An strace of the stuck process on the builder shows it stuck in a loop doing this repeatedly:

26902 ioctl(3, FS_IOC_FIEMAP, {fm_start=4820512, fm_length=18446744073709551615, fm_flags=FIEMAP_FLAG_SYNC, fm_extent_count=145} => {fm_flags=FIEMAP_FLAG_SYNC, fm_mapped_extents=0, ...}) = 0

The builder is Fedora 34 with kernel 5.12.8-300.fc34 and this is running in a rawhide mock environment.

I have been unable to reproduce this locally, sorry about that. It does seem to hit all the koji builder arches except for i686.

--- Additional comment from Brian Lane on 2021-06-14 14:51:42 PDT ---

If I switch it to using 'dd if=/dev/zero of=loop-file bs=1M count=1' instead of /dev/null it doesn't get stuck so it appears to be related to having a file that's just one big hole. 

A later use of mkswap on a file created with dd.../dev/null also doesn't fail because (I think) the file is written to before the mkswap is run on it (parted test t9050).

--- Additional comment from Robert-André Mauchin 🐧 on 2021-06-14 14:52:26 PDT ---

Result of the bisection:

95025c29e2ae7b1b203fb18d57509f675e924cd is the first bad commit
commit 195025c29e2ae7b1b203fb18d57509f675e924cd
Author: Karel Zak <kzak>
Date:   Wed Sep 9 11:00:40 2020 +0200

    mkswap: check for holes and unwanted extentd in file
    
    Let's make mkswap(8) more user-friend and report possible swapon
    issues already when user initialize a swap file. The extents check
    produces warnings, no exit with error.
    
      # dd if=/dev/zero of=img count=100 bs=1MiB
      # chmod 0600 img
    
      # fallocate --dig-hole --offset 64520192 --length 1MiB img
      # fallocate --dig-hole --offset 84520960 --length 1MiB img
    
      # ./mkswap img
      mkswap: extents check failed:
        - hole detected at offset 64520192 (size 1048576 bytes)
        - hole detected at offset 84520960 (size 1048576 bytes)
      file img can be rejected by kernel on swap activation.
    
      Setting up swapspace version 1, size = 100 MiB (104853504 bytes)
      no label, UUID=92091112-26b5-47aa-a02a-592e52528319
    
    It checks for holes in the file, and for unknown, inline, shared and
    deallocated extents.
    
    Addresses: https://github.com/karelzak/util-linux/issues/1120
    Signed-off-by: Karel Zak <kzak>

 configure.ac        |  1 +
 disk-utils/mkswap.c | 96 +++++++++++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 95 insertions(+), 2 deletions(-)

Comment 2 Karel Zak 2021-06-15 10:10:50 UTC
Fixed by upstream commit 8a3a74160b96498d672e3652827aa7e6d7f3a120. The change will be available in v2.37.1 (planned for RHEL-9).