Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2336512ybz; Thu, 23 Apr 2020 16:15:58 -0700 (PDT) X-Google-Smtp-Source: APiQypI5ztgGe+RxJHPMsL4SVQrse1GFKsKu6DNd2Kdfo52+bTpmYxsAxrSxXjrzGfpk3qf9lsQQ X-Received: by 2002:a17:906:5e50:: with SMTP id b16mr4956060eju.331.1587683758028; Thu, 23 Apr 2020 16:15:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683758; cv=none; d=google.com; s=arc-20160816; b=pS/PBUyDaC/75nNWjgCUEiY26n7A1XS34tVLY14Vu0VXv11qMnSGZyeiQ6M/M6MV09 CQzZR4ZdIaGrFiP7Ml+rYr0bzm531NxxGW3u80C2o/xDHTDb280vnZtQtJ4ccznPX0hX sdXiwHYZuOLIil2iEmRRbDwqMlsTb/gIDhawFMBB8VFN9kZCyGYE4KdRdDMrYs+lppUt TMNHddl9iny7FFCrcm1Bb5W1wMcWBQr0lgU/VecDeIFavRYL/M57ODO1WXBpl70/P6WZ hXUcQEbXcVBUjF/KwWXyuUJT63NwAj8Y9i94US6OrW5EJE5eWCLUQDykNdt+iF7heKeD qwXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=gD27ql1ym6v87aHq9m6eAym19MrH/FK23+8Ag//WJec=; b=DomY1R3dF5Fdc3X2mg/uaEA4VRP72X+WeRUJnUZS3vtqQaAErvyK1dTZhp4E2+4ET5 t9BZDffcYUqhJLivWHqyQP/SMtPbqtENxARR1VeDENXn4BqqJB+Ntb73qhkIMAX+Ee52 2Pj4ZNQdYWCs2MnQZlo/9KH9jHkQZkA3SHaPc/6W1ERMjdoupK9Z91jgEqjfzKZXkDSo mVdGmRbci5aQTfvGNQW4kLXDsYAGg+tW/AloksXpOY8Lt3za0lRXsPTmHLk2D7cKXTdg yKChxc3AghBz2eyvXg373l5UGcESXmiGtFeKb+pzI1HL6NjkAzxLb+u9O6HEKjH02JT8 6ugw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i2si2027741edn.210.2020.04.23.16.15.34; Thu, 23 Apr 2020 16:15:58 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729420AbgDWXNL (ORCPT + 99 others); Thu, 23 Apr 2020 19:13:11 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:50072 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728506AbgDWXGv (ORCPT ); Thu, 23 Apr 2020 19:06:51 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvY-0004mp-RF; Fri, 24 Apr 2020 00:06:40 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvU-00E6v2-Cr; Fri, 24 Apr 2020 00:06:36 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Luo Jiaxing" , "Martin K. Petersen" , "James Bottomley" , "John Garry" Date: Fri, 24 Apr 2020 00:06:35 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 168/245] scsi: enclosure: Fix stale device oops with hot replug In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: James Bottomley commit 529244bd1afc102ab164429d338d310d5d65e60d upstream. Doing an add/remove/add on a SCSI device in an enclosure leads to an oops caused by poisoned values in the enclosure device list pointers. The reason is because we are keeping the enclosure device across the enclosed device add/remove/add but the current code is doing a device_add/device_del/device_add on it. This is the wrong thing to do in sysfs, so fix it by not doing a device_del on the enclosure device simply because of a hot remove of the drive in the slot. [mkp: added missing email addresses] Fixes: 43d8eb9cfd0a ("[SCSI] ses: add support for enclosure component hot removal") Link: https://lore.kernel.org/r/1578532892.3852.10.camel@HansenPartnership.com Signed-off-by: James Bottomley Reported-by: Luo Jiaxing Tested-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Ben Hutchings --- drivers/misc/enclosure.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/misc/enclosure.c +++ b/drivers/misc/enclosure.c @@ -364,10 +364,9 @@ int enclosure_remove_device(struct enclo cdev = &edev->component[i]; if (cdev->dev == dev) { enclosure_remove_links(cdev); - device_del(&cdev->cdev); put_device(dev); cdev->dev = NULL; - return device_add(&cdev->cdev); + return 0; } } return -ENODEV;