From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754112AbbJOHHa (ORCPT ); Thu, 15 Oct 2015 03:07:30 -0400 Received: from mx2.suse.de ([195.135.220.15]:36578 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753432AbbJOHH3 (ORCPT ); Thu, 15 Oct 2015 03:07:29 -0400 Message-ID: <1444892846.19542.22.camel@suse.de> Subject: Re: [PATCH 0/3] SCSI: Fix hard lockup in scsi_remove_target() From: Johannes Thumshirn To: emilne@redhat.com, James Bottomley Cc: Christoph Hellwig , Hannes Reinecke , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Date: Thu, 15 Oct 2015 09:07:26 +0200 In-Reply-To: <1444854130.26884.33.camel@localhost.localdomain> References: <1444833036.2220.38.camel@HansenPartnership.com> <1444854130.26884.33.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2015-10-14 at 16:22 -0400, Ewan Milne wrote: > On Wed, 2015-10-14 at 07:30 -0700, James Bottomley wrote: > > On Wed, 2015-10-14 at 15:50 +0200, Johannes Thumshirn wrote: > > > Removing a SCSI target via scsi_remove_target() suspected to be > > > racy. When a > > > sibling get's removed from the list it can occassionly happen > > > that one CPU is > > > stuck endlessly looping around this code block > > > > > > list_for_each_entry(starget, &shost->__targets, siblings) { > > > if (starget->state == STARGET_DEL) > > > continue; > > > > How long is the __targets list? It seems a bit unlikely that this > > is > > the exact cause, because for a short list all in STARGET_DEL that > > loop > > should exit very quickly. Where in the code does > > scsi_remove_target > > +0x68/0x240 actually point to? > > > > Is it not a bit more likely that we're following a removed list > > element? > > Since that points back to itself, the list_for_each_entry() would > > then > > circulate forever. If that's the case the simple fix would be to > > use > > the safe version of the list traversal macro. > > > > James > > For what it's worth, I've seen a dump where this was exactly the > case. > starget was in STARGET_DEL state, starget->siblings pointed to > itself, > kref was 0, reap_ref was 0 (this was a while back). > That's exactly what I have here as well. I'll give Christoph's patch a shot today and report back. > The problem was not able to be reproduced at the time. > > -Ewan > >