linux-kernel - Re: [PATCH] block: rename 'q->debugfs_dir' in blk_unregister

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]

Message-ID: <18bf436a-9c6a-dba8-46a4-ef57132f467a@huawei.com>
Date:   Wed, 12 Feb 2020 12:20:50 +0800
From:   "yukuai (C)" <yukuai3@...wei.com>
To:     Bart Van Assche <bvanassche@....org>, <axboe@...nel.dk>,
        <ming.lei@...hat.com>
CC:     <yi.zhang@...wei.com>, <zhangxiaoxu5@...wei.com>,
        <luoshijie1@...wei.com>, <linux-block@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] block: rename 'q->debugfs_dir' in blk_unregister_queue()

On 2020/2/12 11:27, Bart Van Assche wrote:
> What is the behavior of this loop if multiple block devices are being
> removed concurrently? Does it perhaps change remove block device removal
> from an O(1) into an O(n) operation?
Yes, there may be performance overhead.(I thought it's minimal) However,
I can change the name of dir form "read_to_remove_%d" to
"read_to_remove_%s(dev_name)_%d" to fix that.
> 
> Since this scenario may only matter to syzbot tests: has it been
> considered to delay block device creation if the debugfs directory from
> a previous incarnation of the block device still exists?
> 
I think it's a bug device creation succeed when the debugfs directory
exist. Of course delay block device creation can fix the problem, but I
haven't come up with a good solution. And by renaming the dir, there is
no need to delay cration.

Thanks!
Yu Kuai