Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1434953ybi; Wed, 3 Jul 2019 15:59:32 -0700 (PDT) X-Google-Smtp-Source: APXvYqwkjS5RYevaHJYKHHGhqcnU8EQYeJcQ9TxDlhb0HPJZcBvRTxJOe0+T0zZ/KdA7UbH3rUce X-Received: by 2002:a17:902:294a:: with SMTP id g68mr46253364plb.169.1562194772174; Wed, 03 Jul 2019 15:59:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562194772; cv=none; d=google.com; s=arc-20160816; b=IppVY2m4JZ0bVAwWdesTYZ0tlHkJU7YNNkVKtYtm/aISkyzQ5MkfeiAWY6MgtFEDB5 Ho295GIEWyiue48vpm50ceIxCdQGE5j8BqvI8HdPjFPljwf2CUbuuqLF18GvBIBtgEI9 a5v+sUFNiyq54d/a5VLxu+e6BLDbKeX2xtAKUw+nK7/n+4nNM4y0PLCrNcKIpnUuDzyT oeYiNvhry6TOvIgZyv7NQ0RiGzAQ22FJXXrB9tWPRpDJf8pvmM+PPWKAaAQnziakV0qN 0i+YAk19KTF0iBaWeX1cT3+CkIi9wv6YDEl0YpE26h8BcWhwFmyMRtj4VYK6cPdvF/pM jCpw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=CwXYIwhg3FFIcGcBNJ7dfewzCx9vH4OcZJhzi9iVgZc=; b=kF157sphIw4A75i5fQBpsuvGy4450vSNeO+ymrtvlct5RL/orpoZBZScO+zcBz0ufh IjdGTufjAJlWrlkaoHy55jVHhIbbwtS2026AmhO7yDzYR9F++Riv0X6e+AIBXaE+K65x 01zjHkGfmr3QFVoE2QqtwmfZE/sGMB4w79tFD6xkqAnENbtSyun6sZcSvw9sEkm85iMY N+IU+0fO9muPMmU5dBYCQkY/oYnb5pPI87kAqSpcTMvUXv1YF46pxGumqmmUv62OmI8H PsPviYZjS7NgdnXBNI+b5Kcm7SGs6tmkxUQM2A+2wKNC72bW6daVfQAlak37W16jS+mg WY1A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j14si3501999pgj.519.2019.07.03.15.59.16; Wed, 03 Jul 2019 15:59:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727421AbfGCW5W (ORCPT + 99 others); Wed, 3 Jul 2019 18:57:22 -0400 Received: from gate.crashing.org ([63.228.1.57]:40589 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726902AbfGCW5W (ORCPT ); Wed, 3 Jul 2019 18:57:22 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id x63MvDeS012356; Wed, 3 Jul 2019 17:57:14 -0500 Message-ID: <319ae04497cf1982076bf801cfdf565046096fd4.camel@kernel.crashing.org> Subject: Re: [PATCH v4 OPT2] driver core: Fix use-after-free and double free on glue directory From: Benjamin Herrenschmidt To: Greg KH , Muchun Song Cc: rafael@kernel.org, prsood@codeaurora.org, mojha@codeaurora.org, gkohli@codeaurora.org, linux-kernel@vger.kernel.org Date: Thu, 04 Jul 2019 08:57:13 +1000 In-Reply-To: <20190703193606.GA8452@kroah.com> References: <20190626144021.7249-1-smuchun@gmail.com> <20190703193606.GA8452@kroah.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2019-07-03 at 21:36 +0200, Greg KH wrote: > > > -static struct kobject *get_device_parent(struct device *dev, > > - struct device *parent) > > +/** > > + * __get_device_parent() - Get the parent device kobject. > > + * @dev: Pointer to the device structure. > > + * @parent: Pointer to the parent device structure. > > + * @lock: When we live in a glue directory, should we hold the > > + * gdp_mutex lock when this function returns? If @lock > > + * is true, this function returns with the gdp_mutex > > + * holed. Otherwise it will not. > > Ugh, if you are trying to get me to hate one version of these patches, > this is how you do it :) > > A function should not "sometimes takes a lock, sometimes does not, > depending on a parameter passed into it" That way lies madness... Yes, I prefer this approach to the fix but I dont like the patch either for the same reason... ... > Anyway, this is a mess. > > Ugh I hate glue dirs... Amen... Ben.