linux-kernel - problem with block: Move bdi_unregister() to del_gendisk() commit 165a5e22fafb127ecb5914e12e8c32a1f0d3f820

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <6fdebabe-d399-0fe0-0d5e-fd84cc189101@internode.on.net>
Date:   Wed, 8 Mar 2017 20:37:54 +1030
From:   Arthur Marsh <arthur.marsh@...ernode.on.net>
To:     Jan Kara <jack@...e.cz>
Cc:     Lekshmi Pillai <lekshmicpillai@...ibm.com>,
        Tejun Heo <tj@...nel.org>, Omar Sandoval <osandov@...com>,
        Jens Axboe <axboe@...com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-scsi@...r.kernel.org
Subject: problem with block: Move bdi_unregister() to del_gendisk() commit
 165a5e22fafb127ecb5914e12e8c32a1f0d3f820


On one of my pc's I have 2 PATA disks (one, WDC below is used for 
booting, the other SAMSUNG is not mounted), plus an IBM SCSI disk using 
a DPT 2044W controller with eata driver and sometimes a Verbatim 
Storengo USB stick.

On recent 4.10.0+ kernel builds (i386), the resulting kernel would pause 
during the start-up when the USB stick was inserted but boot normally 
otherwise.

A git-bisect lead to:

commit 165a5e22fafb127ecb5914e12e8c32a1f0d3f820
Author: Jan Kara <jack@...e.cz>
Date:   Wed Feb 8 08:05:56 2017 +0100

     block: Move bdi_unregister() to del_gendisk()

     Commit 6cd18e711dd8 "block: destroy bdi before blockdev is
     unregistered." moved bdi unregistration (at that time through
     bdi_destroy()) from blk_release_queue() to blk_cleanup_queue() because
     it needs to happen before blk_unregister_region() call in del_gendisk()
     for MD. SCSI though will free up the device number from sd_remove()
     called through a maze of callbacks from device_del() in
     __scsi_remove_device() before blk_cleanup_queue() and thus similar 
races
     as described in 6cd18e711dd8 can happen for SCSI as well as reported by
     Omar [1].

     Moving bdi_unregister() to del_gendisk() works for MD and fixes the
     problem for SCSI since del_gendisk() gets called from sd_remove() 
before
     freeing the device number.

     This also makes device_add_disk() (calling bdi_register_owner()) more
     symmetric with del_gendisk().

     [1] http://marc.info/?l=linux-block&m=148554717109098&w=2

When booting the bad kernel, I would eventually get a prompt to press 
the enter key to boot and it eventually started, but the SCSI disk 
partitions were not found by blkid nor could they be mounted.

lsscsi reports:

[0:0:6:0]    disk    IBM      DCAS-34330W      S65A  /dev/sda
[1:0:0:0]    disk    ATA      WDC WD3200AAJB-0 2C01  /dev/sdc
[2:0:0:0]    cd/dvd  HL-DT-ST DVDRAM GSA-4163B A103  /dev/sr0
[2:0:1:0]    disk    ATA      SAMSUNG SP4002H  0-57  /dev/sdd
[3:0:0:0]    disk    Verbatim STORE N GO       5.00  /dev/sdb

blkid reports:

/dev/sdb1: LABEL="STORENGO" UUID="B08B-79DA" TYPE="vfat" 
PARTUUID="961d9655-01"
/dev/sdc1: UUID="bfdeb6d6-0b77-4beb-a63d-bdc3e455b8ea" TYPE="ext3" 
PTTYPE="dos" PARTUUID="000750bf-01"
/dev/sdc5: UUID="26b7280a-f40c-49dd-a086-dbbb9b7e3def" TYPE="swap" 
PARTUUID="000750bf-05"
/dev/sdc6: UUID="7417-5AFF" TYPE="vfat" PARTUUID="000750bf-06"
/dev/sdc7: UUID="96c96a61-8615-4715-86d0-09cb8c62638c" TYPE="ext3" 
PARTUUID="000750bf-07"
/dev/sdd1: LABEL="W-98 SE" UUID="3571-16DE" TYPE="vfat" 
PARTUUID="43598af3-01"
/dev/sdd3: UUID="fd6a052e-c062-4c47-801d-087595635c5d" SEC_TYPE="ext2" 
TYPE="ext3" PARTUUID="43598af3-03"
/dev/sdd5: UUID="026a3f5c-0064-4ae7-869e-519d2cee05e7" SEC_TYPE="ext2" 
TYPE="ext3" PTTYPE="dos" PARTUUID="43598af3-05"
/dev/sdd6: UUID="9a0970fa-74ba-4426-98ac-1e8b81933e0e" TYPE="swap" 
PARTUUID="43598af3-06"
/dev/sdd7: UUID="4912-06CA" TYPE="vfat" PARTUUID="43598af3-07"

The boot screen is at:

http://www.users.on.net/~arthur.marsh/20170308_185555.jpg

and the dmesg output from booting the bad kernel is attached.

I'm happy to supply any other configuration details needed and run 
further tests.

Regards,

Arthur.




View attachment "20170308-dmesg.txt" of type "text/plain" (55568 bytes)