Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp2374069pxb; Mon, 11 Jan 2021 08:05:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJz0B5ZT1+zrpzE0krEc3uwr7NkbYpYbWL+msKUU/vcB1rU8AmQUQ9g1OP/8tkzAvO2lTHRZ X-Received: by 2002:a05:6402:1684:: with SMTP id a4mr69493edv.348.1610381152272; Mon, 11 Jan 2021 08:05:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610381152; cv=none; d=google.com; s=arc-20160816; b=BK7jHE9sxWI1uOL6BhVBLNmSMFRAIhGJ8ZFeGrFvwp8Nb1eywKrlr8ENrAOZfgY4Cs vxB8IVoHMKIExIHtquG3CJD9azgXEnAlasuMUxN5KYrmV7MpmMXgJXasGp/PTvkS6RKv XfYNC49u/OK4J0IgXtbdbv5bt0WgBQLgZjg8v3QOG0H54UepIBO2qdU6SlVfNgKG1pB+ BCJ+PVliYe2lvvHkOK1T+6cWZg3E/bzNltlCE3BCug01E2Y0dNNoAvrjWh9IO4TCwlwI ebp5Rvwadto+k/04/Z3vFxd3PWHCrj/dK5LlH6Fi0v7AJ4OL775LpiNy4gS95buuAMUo salg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=TIU1pJD0jiZnHBum1cVDOg5WUqRGfkfJjh/dF50w1k0=; b=BhgExfNzLT4oNQBR8XJpnkf8aQMV5tuubdJ4e2MRyv1c92xUVGdL5sRyBwPIlsMme7 jbpEhvaSjmyUa9h68RQlKLfDYQ0ytyVuVy4HKSaItFDiMxA1+m1dt7pzeMtkZFNY08ac SEmH1BCOsbbqAE1JS9RYe7/NIHqcGRzQHUwr/bj/a1+qdTp+l4uIjk9x2goNxydMjo9z QI2BXkRE51Cn7b027b/tjFXvJGyQvd+r/yf1kk0gXVuq1YAcr9vmTyXy3yvQ8sbwgZQk 5ytNnsKWm30835Di6MiriC7UcRvP24Wa1lSToQYRuwOYxkmhXNYgFKDZDKHALSY/IfVj 8nqQ== 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 j24si6677355ejs.60.2021.01.11.08.05.23; Mon, 11 Jan 2021 08:05:52 -0800 (PST) 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 S1732431AbhAKQBC (ORCPT + 99 others); Mon, 11 Jan 2021 11:01:02 -0500 Received: from mx2.suse.de ([195.135.220.15]:39468 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729275AbhAKQBB (ORCPT ); Mon, 11 Jan 2021 11:01:01 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 1C57EB18B; Mon, 11 Jan 2021 16:00:20 +0000 (UTC) Subject: Re: [PATCH] nvme: hwmon: fix crash on device teardown To: Daniel Wagner , Enzo Matsumiya Cc: Sagi Grimberg , linux-kernel@vger.kernel.org, linux-nvme@lists.infradead.org, Jens Axboe , Keith Busch , Christoph Hellwig References: <20201209213228.5044-1-ematsumiya@suse.de> <4ebb1b8c-4bb0-6ebf-3417-d4aee1bdd3a8@suse.de> <20201230143805.2v4izgkzbnisssvr@beryllium.lan> <20201230151653.ozlqlwef7f2tarwz@beryllium.lan> <20201230153138.4f2jd2yd2vkqndby@beryllium.lan> <20210104210610.hliiupywksawgei3@hyori> <20210105094545.3tq7c6ev5yn3bhyi@beryllium.lan> From: Hannes Reinecke Message-ID: <412d45ef-40af-24c3-4aa2-042ecbba05cd@suse.de> Date: Mon, 11 Jan 2021 17:00:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20210105094545.3tq7c6ev5yn3bhyi@beryllium.lan> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/5/21 10:45 AM, Daniel Wagner wrote: > On Mon, Jan 04, 2021 at 06:06:10PM -0300, Enzo Matsumiya wrote: >> @Daniel maybe try tweaking your tests to use a smaller controller >> loss timeout (-l option)? I do this on my tests because the default >> value kicks in about 30min after hot-removal -- i.e. you >> have to actually wait for the timeout to expire to trigger the bug. > > As far I can tell, the blktests test I am using will trigger the same > bug. The problem is that the lifetime of hwmon sysfs entry should be > aligned to the lifetime of the nvme sysfs entry. Currently, hwmon's > lifetime is bound to the lifetime of the ctl sysfs entry. When the nvme > entry goes away (and obviously also the underlying device), the hwmon > sysfs entry still references it. > Yeah, using the controller node for devm allocations is quite dodgy. Does this one help? diff --git a/drivers/nvme/host/hwmon.c b/drivers/nvme/host/hwmon.c index 6fdd07fb3001..7260af028cf7 100644 --- a/drivers/nvme/host/hwmon.c +++ b/drivers/nvme/host/hwmon.c @@ -226,7 +226,7 @@ static const struct hwmon_chip_info int nvme_hwmon_init(struct nvme_ctrl *ctrl) { - struct device *dev = ctrl->dev; + struct device *dev = ctrl->device; struct nvme_hwmon_data *data; struct device *hwmon; int err; @@ -240,8 +240,7 @@ int nvme_hwmon_init(struct nvme_ctrl *ctrl) err = nvme_hwmon_get_smart_log(data); if (err) { - dev_warn(ctrl->device, - "Failed to read smart log (error %d)\n", err); + dev_warn(dev, "Failed to read smart log (error %d)\n", err); devm_kfree(dev, data); return err; } Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect hare@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer