Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752148Ab3CJUf0 (ORCPT ); Sun, 10 Mar 2013 16:35:26 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:36966 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751167Ab3CJUfY (ORCPT ); Sun, 10 Mar 2013 16:35:24 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Greg KH Cc: Ming Lei , Tommi Rantala , Jens Axboe , Andrew Morton , Guo Chao , Tejun Heo , LKML , Dave Jones References: <20130308204113.GA15334@kroah.com>

<20130310164102.GD4392@kroah.com> Date: Sun, 10 Mar 2013 13:35:12 -0700 In-Reply-To: <20130310164102.GD4392@kroah.com> (Greg KH's message of "Sun, 10 Mar 2013 09:41:02 -0700") Message-ID: <87r4jnouwv.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1/2mfOfo0upxJqITD0haVENkNynuwDrkxI= X-SA-Exim-Connect-IP: 98.207.153.68 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 TR_Symld_Words too many words that have symbols inside * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -3.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 0.1 XMSolicitRefs_0 Weightloss drug X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Greg KH X-Spam-Relay-Country: Subject: Re: kernel BUG at fs/sysfs/group.c:65! X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1674 Lines: 38 Greg KH writes: > On Sun, Mar 10, 2013 at 04:53:11PM +0800, Ming Lei wrote: >> On Sun, Mar 10, 2013 at 12:36 AM, Tommi Rantala wrote: >> > [ 40.089036] [] sysfs_get_dirent+0x39/0x80 >> > [ 40.089036] [] sysfs_remove_group+0x29/0x100 >> > [ 40.089036] [] blk_trace_remove_sysfs+0x14/0x20 >> > [ 40.089036] [] blk_unregister_queue+0x5e/0x90 >> > [ 40.089036] [] del_gendisk+0x107/0x250 >> > [ 40.089036] [] loop_remove+0x18/0x40 >> >> Then the crash is triggered in device release path, which should have >> been avoided in device add path. >> >> If we want to fix the problem completely, add_disk() must handle failure >> path correctly and return error code on failures, which may involve big >> work, since add_disk() are called by 50+ drivers. > > Ok, but the root problem here is add_disk() is being called to create a > disk that was already created, right? Surely the caller should have > detected this before it called to the block core? > > Who is calling add_disk() here? Is this a fuse device? If so, then any > user can trigger this, right? > > That should be the "easier" fix at the moment to resolve this issue. At first glance this looks like rances in the loop driver. Still user triggerable but not quite as bad as fuse. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/