linux-kernel - Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Mon, 6 Feb 2017 21:42:13 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     Jens Axboe <axboe@...com>
Cc:     James Bottomley <James.Bottomley@...senpartnership.com>,
        Christoph Hellwig <hch@....de>,
        kernel test robot <xiaolong.ye@...el.com>,
        Bart Van Assche <bart.vanassche@...disk.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        Jan Kara <jack@...e.cz>, Omar Sandoval <osandov@...ndov.com>,
        Omar Sandoval <osandov@...com>,
        LKML <linux-kernel@...r.kernel.org>,
        Jens Axboe <axboe@...nel.dk>, LKP <lkp@...org>,
        linux-scsi <linux-scsi@...r.kernel.org>,
        linux-block@...r.kernel.org
Subject: Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup

On Mon, Feb 6, 2017 at 8:09 PM, Jens Axboe <axboe@...com> wrote:
> On 02/06/2017 05:14 PM, James Bottomley wrote:
>> On Sun, 2017-02-05 at 21:13 -0800, Dan Williams wrote:
>>> On Sun, Feb 5, 2017 at 1:13 AM, Christoph Hellwig <hch@....de> wrote:
>>>> Dan,
>>>>
>>>> can you please quote your emails?  I can't find any content
>>>> inbetween all these quotes.
>>>
>>> Sorry, I'm using gmail, but I'll switch to attaching the logs.
>>>
>>> So with help from Xiaolong I was able to reproduce this, and it does
>>> not appear to be a regression. We simply change the failure output of
>>> an existing bug. Attached is a log of the same test on v4.10-rc7
>>> (i.e. without the recent block/scsi fixes), and it shows sda being
>>> registered twice.
>>>
>>> "[    6.647077] kobject (d5078ca4): tried to init an initialized
>>> object, something is seriously wrong."
>>>
>>> The change that "scsi, block: fix duplicate bdi name registration
>>> crashes" makes is to properly try to register sdb since the sda devt
>>> is still alive. However that's not a fix because we've managed to
>>> call blk_register_queue() twice on the same queue.
>>
>> OK, time to involve others: linux-scsi and linux-block cc'd and I've
>> inserted the log below.
>>
>> James
>>
>> ---
>>
>> [    5.969672] scsi host0: scsi_debug: version 1.86 [20160430]
>> [    5.969672]   dev_size_mb=8, opts=0x0, submit_queues=1, statistics=0
>> [    5.971895] scsi 0:0:0:0: Direct-Access     Linux    scsi_debug       0186 PQ: 0 ANSI: 7
>> [    6.006983] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
>> [    6.026965] sd 0:0:0:0: [sda] Write Protect is off
>> [    6.027870] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
>> [    6.066962] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
>> [    6.486962] sd 0:0:0:0: [sda] Attached SCSI disk
>> [    6.488377] sd 0:0:0:0: [sda] Synchronizing SCSI cache
>> [    6.489455] sd 0:0:0:0: Attached scsi generic sg0 type 0
>> [    6.526982] sd 0:0:0:0: [sda] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
>> [    6.546964] sd 0:0:0:0: [sda] Write Protect is off
>> [    6.547873] sd 0:0:0:0: [sda] Mode Sense: 73 00 10 08
>> [    6.586963] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA
>> [    6.647077] kobject (d5078ca4): tried to init an initialized object, something is seriously wrong.
>
> So sda is probed twice, and hilarity ensues when we try to register it
> twice.  I can't reproduce this, using scsi_debug and with scsi_async
> enabled.
>
> This is running linux-next? What's your .config?
>

The original failure report is here:

http://marc.info/?l=linux-kernel&m=148619222300774&w=2

...but it reproduces on current mainline with the same config. I
haven't spotted what makes scsi_debug behave like this.