Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp484350imm; Wed, 22 Aug 2018 07:34:34 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaseaargX2W3CIN7uocZ9/Ys/XfcVqqEfZdq7EHRKVYBJEQD6xWvgyBBDbxYikiuhylyMWt X-Received: by 2002:a62:4784:: with SMTP id p4-v6mr2256503pfi.170.1534948474500; Wed, 22 Aug 2018 07:34:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1534948474; cv=none; d=google.com; s=arc-20160816; b=02EWsF/1bRDRMKCwOMfGYijjFPIO+RTdsOhM4dnkFEtzqxT9m0Mhpi9AdBsUqmOs6m LcTkNKSPr8iHQsTPGl+00l7k5ipJWCNyTfphf3Kes1ZzLFyRpFCulUNxp3HaE902OuAu CCqPA2F3bTK46RWyhZNjUZsxSWOKkZDoEu83smYFuXfafx/WQu48o8BE6NhSl6MLijLQ 7+qBWpJljDiBOtcXN+Hf1dP/dnVNtU7rxzRlHXlsHPifuOEF8wW91QpZWqSm20U5am2v yIOTCz3wyJXznR6P54tcw+D5I03Q08Sw8LpaIUU2oGCVwHVHF3NRc528gX2LCyDYiw8I 2WRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=r+/uy4/GSEU3ms8it4N4w5h8LKfcGyk79CJhOskoNtU=; b=aXEIZq9jS+cUsHRjYvys3wFkJAEdXrJD20IV+FzPH90e8/z2ojqCmVxL68tfPa4ZR5 1GA2oK3WDpMRBDfeli3hjLIcJ+02dNqi0EjtsJheNgvwh50uZjVFCA0uenoozQ/5IaEl S26nV1t5UQdN9oGpSSdnCvm0NVLO72ZyXjxr92wHcnd2HgWvBTbe9TlBneowZg66nE2K Ybwcl1/rnU1E9W30SXkCDDZIUyXN+NzbO8ML0pNK+zOIyHVwSJFc5FwuYb2V8OU3XB6R junUlbYWtBl8zjEA21/YXIa70+MxXizulK8FX+nFZQFfNAArSq3DqMfesOV8oZG2ylq5 zmBg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=I3uHYz87; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a27-v6si1111209pfh.164.2018.08.22.07.34.18; Wed, 22 Aug 2018 07:34:34 -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; dkim=pass header.i=@kernel.org header.s=default header.b=I3uHYz87; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729090AbeHVR5d (ORCPT + 99 others); Wed, 22 Aug 2018 13:57:33 -0400 Received: from mail.kernel.org ([198.145.29.99]:42586 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728718AbeHVR5d (ORCPT ); Wed, 22 Aug 2018 13:57:33 -0400 Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E9E3221528 for ; Wed, 22 Aug 2018 14:32:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1534948344; bh=r+/uy4/GSEU3ms8it4N4w5h8LKfcGyk79CJhOskoNtU=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=I3uHYz87dwXCCvaEmA9LV4A3NbSr34+v1ot8CKv17uJ9P79BfmO41PrtqMnk+G0c2 K9OleDl4WYBrMgmGYu4O6cFsmaAVIyBtQSx0+vzlu4Wd/moPJU9Ju4h9c5Am4C5Uu7 rZUJMjT152WpkDZI3CGPYMUXwyQjBcHRd4nn+OfI= Received: by mail-wm0-f50.google.com with SMTP id c14-v6so2224975wmb.4 for ; Wed, 22 Aug 2018 07:32:23 -0700 (PDT) X-Gm-Message-State: APzg51APwwVyu4YOIAsoNd1BsxT/z9anaN3J5cFkKqpwpt/EM6wqeLMP nARmu+z25YdLKL0jxWkXTq35cTuaf75Tbp4o4nAmJw== X-Received: by 2002:a1c:5c93:: with SMTP id q141-v6mr2515245wmb.133.1534948342406; Wed, 22 Aug 2018 07:32:22 -0700 (PDT) MIME-Version: 1.0 References: <20180822105547.9634-1-johan@kernel.org> In-Reply-To: <20180822105547.9634-1-johan@kernel.org> From: Rob Herring Date: Wed, 22 Aug 2018 09:32:11 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/9] of: fix compatible-child-node lookups To: Johan Cc: Greg Kroah-Hartman , Frank Rowand , devicetree@vger.kernel.org, Linux Kernel Mailing List , ck.hu@mediatek.com, p.zabel@pengutronix.de, Rob Clark , airlied@linux.ie, Ulf Hansson , rainyfeeling@outlook.com, boris.brezillon@bootlin.com, opendmb@gmail.com, Florian Fainelli , davem@davemloft.net, peppe.cavallaro@st.com, alexandre.torgue@st.com, joabreu@synopsys.com, sameo@linux.intel.com, sre@kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 22, 2018 at 5:57 AM Johan Hovold wrote: > > Several drivers currently use of_find_compatible_node() to lookup child > nodes while failing to notice that the of_find_ functions search the > entire tree depth-first and therefore can match unrelated (non-child) > nodes. That is not quite right. It searches all nodes following 'from', so not the entire tree unless 'from' is NULL. The purpose of 'from' is to iterate to find all compatible nodes. But you are correct that anyone calling of_find_compatible_node directly with from != NULL is wrong. I'd really like to make of_find_compatible_node() function as searching all of the sub-tree as that should be what all the callers want (unless they've open coded for_each_compatible_node). Though maybe 2 functions to search the whole tree and just immediate children is best. Also, it would be good to remove the type parameter as device_type is deprecated (mostly). It looks like most if not all callers setting type could drop it and just match on compatible. It seems to just serve as additional validation of the DT. > The fact that these functions also drop a reference to the node they > start searching from (e.g. the parent node) is typically also > overlooked, something which can lead to use-after-free bugs (e.g. after > probe deferrals). > > This series adds a new helper, similar to of_get_child_by_name(), > that can be used to lookup compatible child nodes, and uses the new > helper to fix child-node lookups throughout the tree. > > This is related to the fixes I posted about a year ago, which addressed > a similar anti-pattern when looking up child nodes by name. Since it > took me more than a year to get all those fixes into Linus' tree (one > fix is still pending), and as these fixes depend on the new helper, I'm > suggesting that these all go in through Rob's or Greg's trees. I'm happy to take them or apply the dependency now and then anything not picked up by sub-maintainers for 4.20. Rob