linux-kernel - Re: [PATCH] sysfs: replace WARN() with pr_debug in sysfs_remove

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] [day] [month] [year] [list]

Message-ID: <a5701c95-304a-e727-48eb-55ffeec04013@oracle.com>
Date:   Wed, 2 Aug 2017 07:49:37 +0800
From:   Ethan Zhao <ethan.zhao@...cle.com>
To:     Greg KH <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
        ethan.kernel@...il.com
Subject: Re: [PATCH] sysfs: replace WARN() with pr_debug in
 sysfs_remove_group()

Grep,


On 2017/8/2 2:06, Greg KH wrote:
> On Tue, Aug 01, 2017 at 05:02:25PM +0900, Ethan Zhao wrote:
>> There is no enough error handling in block device adding/registration
>> path, for example,
>>
>> device_add_disk()
>>    blk_register_queue()
>>
>> When kernel returns from device_add_disk(), no return value to tell
>> us it was successful or not --- that suggests it would always succeed,
>> and according to this assumption, then during block device removal/
>> unregistration steps,
>>
>> sd_remove()
>>    del_gendisk()
>>      blk_unregister_queue()
>>
>> dpm_sysfs_remove(), blk_trace_remove_sysfs() will be called blindly,
>> though there is likely no 'trace' 'power' sysfs groups there because
>> actually blk_register_queue()/device_add() failed somewhere. thus
>> causes WARN flood emitted from sysfs_remove_group() as following triggered
>> by unloading fnic driver:
> Then fix the real issue here, don't paper over the issue by changing the
> sysfs core please.  No other subsystem seems to be having this issue.
   Yep, I agree it is kind of cover up block layer issue.

  Thanks,
  Ethan
> thanks,
>
> greg k-h
>