From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751600AbdHAXtM (ORCPT ); Tue, 1 Aug 2017 19:49:12 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:46315 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750947AbdHAXtK (ORCPT ); Tue, 1 Aug 2017 19:49:10 -0400 Subject: Re: [PATCH] sysfs: replace WARN() with pr_debug in sysfs_remove_group() To: Greg KH References: <1501574545-15691-1-git-send-email-ethan.zhao@oracle.com> <20170801180635.GA31628@kroah.com> Cc: linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, ethan.kernel@gmail.com From: Ethan Zhao Organization: Oracle Corporation Message-ID: Date: Wed, 2 Aug 2017 07:49:37 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170801180635.GA31628@kroah.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >