Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp886138pxb; Tue, 14 Sep 2021 10:47:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxsPBbWAn1YckiIPlanJyAXd++8WCkkwTMl28z3ceLM7CIrVWgtIEbxU3RQU0AqChTJESvP X-Received: by 2002:a6b:f114:: with SMTP id e20mr14707338iog.41.1631641666030; Tue, 14 Sep 2021 10:47:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1631641666; cv=none; d=google.com; s=arc-20160816; b=fL37QbC4kfihVTzoODBgwzjDJ/cBypp7M0qubOb71JDZmViKrc4U/1UeCrRFQgPKK1 PHFdQAIQMxPLKq1OUi6sqMSg+XRsdcRb0kZIfr8bIMOlET7xSZVbNaRtd62mzHbB96Yj mu5r1mK3UQdRdqFIWMQN70OzOHkkNZKk03XmEp6SysNYGo2hCY5dgTGXgB8qY1Jupsoz Uco1BwKkYYt5pkT/PbSaWHt8SVoLiu3d/vsaWeoifrSsRGbr2PAphTQFDB32kaLxN+sC 7KWpghggJatmPsDZarUypIJlFHGyg1k/zRm7X7hJOWiRZ5LzK3FmiuHqjF27B4padayu gnpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=30/B84g0scVe64w1jrJPAZx8Vu/dGGlZHuOB6QGy0Rs=; b=oCyf3l2GA53dJcWZS0rfOlOK2XBM9Jke+wpufD1Jsd8PjZqmbkLoYrlUJNI676jal0 7DZ0lK9dkvaLfKTWwYzicnj4nVgQHRBcmM0itVdP7oTuQPlM/jm7d6xnbEuGjHFHSqhD BoSc73W3NkUa8Lb1FbLDtveVYI7dibFei6Hb2YuPdL+457Qnn46d409XsrD+owSYbh29 avnuy/3Rjvf+lDRKp3Ys6ZbcDsKCIHt0bFk+TrE8QOzIfSlg73+a9crwDtFJQ6tuJk3P vBpZljDwOsv/sYAxa5oA77xc6LVE4ZcJqAVd9A9+BPxFKwNWbx6qfYY6uCxyWNVBkzOc WNDg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=RX+Ricnc; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o20si12694689iov.71.2021.09.14.10.47.33; Tue, 14 Sep 2021 10:47:46 -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; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=RX+Ricnc; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231725AbhINRrt (ORCPT + 99 others); Tue, 14 Sep 2021 13:47:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230495AbhINRrt (ORCPT ); Tue, 14 Sep 2021 13:47:49 -0400 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A2614C061762 for ; Tue, 14 Sep 2021 10:46:31 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id w19so8656701pfn.12 for ; Tue, 14 Sep 2021 10:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=30/B84g0scVe64w1jrJPAZx8Vu/dGGlZHuOB6QGy0Rs=; b=RX+Ricnc4mmAv/2u3XbIfohQD7aUkR5aJ5OTlSvGLp5M85x/LTP2P05AipcYelIDJ3 wLfcoD+QlsV7Uq+8fE3q1QnE+7ZcIf+kjtWCEHmbbp+eJ0e7f7R1Gky7wN33PU3WWQl1 QcFTHx+ryxw+dJM2lQRfrPwczd0yif6mVX59ueVVZV3O+HnXX+qgT7J09v7koiTcmxTA jElVUo7qtfnXc58sreR7P5KN7wURFXbIEyT1agjHoU4YgRXZA9KDRljEfwd6ppOEKA5c qxgaA3g4hne6kR9VbCp6GoaQs1pFsNtR2XsIcoDTgnd4onlGk6P1LhtneyRs6sJWs1zJ yj6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=30/B84g0scVe64w1jrJPAZx8Vu/dGGlZHuOB6QGy0Rs=; b=BwhuovqBTGNZO3tf3J8XUSj70GTUnXhVaXQKFxjxeztUrFbnq7nKjUvVarwxbN10GV O5aAFsUriNdOC73KN6k0rnZL++xF4+4LxGjoTm88mDDw6IHg7Uwaw2M2JyUagEwQEs5B xLq68CWwSacSMidigfIprj8aVKQpqsX39JLcUV3P+cn0YakF/we4bFhVKJAj4MLJc+51 dAPZUFDwMPoR0Th/u1JSBk9Le9somEjkKz5I6U8ffQqIF60f0TH7HHGy6a+TNXFmeTca Izs9XxoB7Rq+nWu06xUtwWA1kbI+VjMwAhJnziakr8MBx9owTisyl+34AE0vIXf1Kl+u +NeA== X-Gm-Message-State: AOAM5325sWYH662slLs6KxYg7dl9eITR0Wq0s6xJb1DfX3uxRwbbvf/4 597w4QWjurTLogN/BR1miNKdfRt1oqW50jKGBySR45Cs7d0KHg== X-Received: by 2002:a63:3545:: with SMTP id c66mr16405202pga.377.1631641591034; Tue, 14 Sep 2021 10:46:31 -0700 (PDT) MIME-Version: 1.0 References: <20210913223339.435347-1-sashal@kernel.org> <20210913223339.435347-4-sashal@kernel.org> In-Reply-To: From: Dan Williams Date: Tue, 14 Sep 2021 10:46:20 -0700 Message-ID: Subject: Re: [PATCH AUTOSEL 5.14 04/25] cxl/pci: Introduce cdevm_file_operations To: Sasha Levin Cc: Linux Kernel Mailing List , stable , Ben Widawsky , Jonathan Cameron , linux-cxl@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 14, 2021 at 10:01 AM Sasha Levin wrote: > > On Tue, Sep 14, 2021 at 08:42:04AM -0700, Dan Williams wrote: > >On Mon, Sep 13, 2021 at 3:33 PM Sasha Levin wrote: > >> > >> From: Dan Williams > >> > >> [ Upstream commit 9cc238c7a526dba9ee8c210fa2828886fc65db66 ] > >> > >> In preparation for moving cxl_memdev allocation to the core, introduce > >> cdevm_file_operations to coordinate file operations shutdown relative to > >> driver data release. > >> > >> The motivation for moving cxl_memdev allocation to the core (beyond > >> better file organization of sysfs attributes in core/ and drivers in > >> cxl/), is that device lifetime is longer than module lifetime. The cxl_pci > >> module should be free to come and go without needing to coordinate with > >> devices that need the text associated with cxl_memdev_release() to stay > >> resident. The move will fix a use after free bug when looping driver > >> load / unload with CONFIG_DEBUG_KOBJECT_RELEASE=y. > >> > >> Another motivation for passing in file_operations to the core cxl_memdev > >> creation flow is to allow for alternate drivers, like unit test code, to > >> define their own ioctl backends. > > > >Hi Sasha, > > > >Please drop this. It's not a fix, it's just a reorganization for > >easing the addition of new features and capabilities. > > I'll drop it, but just to satisfy my curiousity: the description says it > fixes a use-after-free bug in the existing code, is it not the case? It does fix a problem if the final put_device() happens after the module text has been unloaded. However, I am only aware of the artificial trigger for that (CONFIG_DEBUG_KOBJECT_RELEASE=y). I.e. if CONFIG_DEBUG_KOBJECT_RELEASE=n I am not aware of any agent that will hold a device reference besides the driver itself. That was the rationale for not tagging this for -stable.