From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933172AbdKGAMQ (ORCPT ); Mon, 6 Nov 2017 19:12:16 -0500 Received: from mail-qt0-f195.google.com ([209.85.216.195]:47982 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755369AbdKGAML (ORCPT ); Mon, 6 Nov 2017 19:12:11 -0500 X-Google-Smtp-Source: ABhQp+QOnfq17xjDszW3g7cn+9wcQ+ie5S4shrAQsZE/CaY3sCnKt92R4PndiW7sc7EATFjDAff14Q== Date: Mon, 6 Nov 2017 16:12:07 -0800 From: Tejun Heo To: Linus Torvalds Cc: Fengguang Wu , IDE-ML , Christoph Hellwig , Hannes Reinecke , Linux Kernel Mailing List , Johannes Thumshirn , "Martin K. Petersen" , linux-scsi , James Bottomley Subject: Re: [ata_scsi_offline_dev] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238 Message-ID: <20171107001207.GH3252168@devbig577.frc2.facebook.com> References: <20171029225155.qcum5i75awrt5tzm@wfg-t540p.sh.intel.com> <20171029231835.3725fnd5yehlmqob@wfg-t540p.sh.intel.com> <20171030110511.scfrdtlnf5lbdhu5@pd.tnic> <526e7cf2-0672-e44b-c32f-26128a2dfd37@codeaurora.org> <20171106224635.qopgsszwxzuitkpf@wfg-t540p.sh.intel.com> <20171106225354.6ucl4f4ipsjlntzl@wfg-t540p.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Mon, Nov 06, 2017 at 03:12:31PM -0800, Linus Torvalds wrote: > But it does seem to be a new regression in 4.14, caused by commit > 8a97712e5314 ("scsi: make 'state' device attribute pollable"), because > that's what added the sysfs_notify() call to scsi_device_set_state(), > which made that spinlock be a problem. Yeah, pinged Hannes about it a couple of weeks ago. > That commit came in through the SCSI merge this merge window, and it > seems to still revert cleanly. > > So I do suspect that by now we should just revert that commit. It's > not clear why that state attribute should be pollable, and the new > code is clearly very much buggy. I think reverting is the right thing to do right now. If necessary, we can make kernfs_notify() safe to be called from atomic contexts. Thanks. -- tejun