Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754686AbaDNSmF (ORCPT ); Mon, 14 Apr 2014 14:42:05 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:48575 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754505AbaDNSmD (ORCPT ); Mon, 14 Apr 2014 14:42:03 -0400 Date: Mon, 14 Apr 2014 08:04:45 -0700 From: Greg Kroah-Hartman To: David Fries Cc: Belisko Marek , Evgeniy Polyakov , LKML , "Dr. H. Nikolaus Schaller" Subject: Re: w1: 3.14-rc7 - possible recursive locking detected Message-ID: <20140414150445.GC12482@kroah.com> References: <20140323215041.GB5096@spacedout.fries.net> <698551395662480@web15j.yandex.ru> <20140413222401.GE5096@spacedout.fries.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140413222401.GE5096@spacedout.fries.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 13, 2014 at 05:24:01PM -0500, David Fries wrote: > Belisko Marek, > Here is a possible solution, could you give it a try and report back? > > Greg Kroah-Hartman, > Evgeniy asked me to look into this report. I don't have the > reporter's hardware configuration, but I wouldn't think that would be > needed, just some w1 bus master (even W1_MASTER_GPIO might work), then > loading the slave device and manually adding a slave device with that > family id. Even then I didn't reproduce the reported recursive > locking error. I saw unrelated locking reports, but not this one. I > wrote up the included patch, but that undoes the notify changes that > you added earlier in commit 47eba33a0997fc7, and I wanted to ask about > that commit. Specifically these two lines, > > err = device_register(&sl->dev); > ... > + dev_set_uevent_suppress(&sl->dev, false); > + kobject_uevent(&sl->dev.kobj, KOBJ_ADD); > > Wouldn't the default be to not suppress? Nothing in the W1 system > enables suppressing so is that even needed? (I'm fine with saying > it's a good idea). > device_register at some point must call device_add and device_add > calls kobject_uevent(&dev->kobj, KOBJ_ADD); > so doesn't the KOBJ_ADD send the add a second time? As in it > shouldn't be needed? > Can the suppress be called before device_register to avoid the > automatic notify, then after it returns setup the slave device as this > patch does to avoid this problem report, and then call the KOBJ_ADD to > make everything happy? I really have no idea, if your fix resolves an issue, that's great, I'll be glad to take it. I have no w1 devices to test any of this, and don't even remember writing that kernel patch :) thanks, greg k-h -- 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/