Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1604091imm; Wed, 20 Jun 2018 22:53:57 -0700 (PDT) X-Google-Smtp-Source: ADUXVKL2+MA7WONKwWVwX4tcq2lNAQ34LJ3t+i3eR3xDMuSpSNPE88/xLR2LAGSfRfJ4oo9oWyRr X-Received: by 2002:a62:8995:: with SMTP id n21-v6mr25626423pfk.83.1529560437805; Wed, 20 Jun 2018 22:53:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529560437; cv=none; d=google.com; s=arc-20160816; b=qh4vUDsHrkm5qjlQ6MP7MwQekjkHb6Y04Tsgk7VPW5eeRaIquAES1p1aPjQAuOHygC U/oK53f7butrolfGEkOGIfG1i+2qh40PyqEdyBrIkx1fQ0E+y+cqpOf2RA+em3pv1t1h qQ+Sd7YQf9ygskp87Hn8BvwYQxfH6Sca00ClcOo+eZgeyLPDvs8Ziszd4nZZihntsuRv JFX9jl0fEvnFdVc/j4C8DGhA/dfb5MLFjZLia6LMxyIo3Ih/v4caB6FsMOkywIyD1AUF 0aG6MD2gwryYO/MWP1yTRjj6m/Gg2PYv2wuxoowjTPcwsgqkmocm1D1/mD3zKCGmZiEs 5VXQ== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=xbpELsugNZF8rjInA45zjC7oTJelH8Om7FekrP4jTnI=; b=KgJuKEDZrHcOtkwcviEKc+A26hlyswejRknffnVidPSr9ycmAju+syZAj4lYexailg tbtvzQSAcueDTaPomJve12A0wxaC8MKx8nx8a9wuZzItpnjVguGT2yifBWhf+k8klOq8 3kVr7q7+3DSbZcfIPyVlSfSwE/mVRDpf6XSOBxfBKvNg2JMFtISw+9ZPSB0Exm2qCvu/ 7klMHzr5Ov0GP7OBOzkQAT1//tF/PBjHv9JcsHjDsDXQ/p3qKM8fUJ3aj5fuv8MFViz5 3VwbeZYLlZFteqpXWO4AKMGxMkgIdKxtJQfKTEqY5bT9HYx8swTEDIdVas8sa92/JmGN FHdA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dSKaoXjC; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d4-v6si3782011pfa.263.2018.06.20.22.53.42; Wed, 20 Jun 2018 22:53:57 -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=@gmail.com header.s=20161025 header.b=dSKaoXjC; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932564AbeFUFwm (ORCPT + 99 others); Thu, 21 Jun 2018 01:52:42 -0400 Received: from mail-pf0-f193.google.com ([209.85.192.193]:33681 "EHLO mail-pf0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750789AbeFUFwj (ORCPT ); Thu, 21 Jun 2018 01:52:39 -0400 Received: by mail-pf0-f193.google.com with SMTP id b17-v6so967136pfi.0; Wed, 20 Jun 2018 22:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xbpELsugNZF8rjInA45zjC7oTJelH8Om7FekrP4jTnI=; b=dSKaoXjCEMQIsD7+DthIJTftT3dncnwEzMduyFuM3Cx2dd23XvTGYt7/bw7A4avxum KL1RANsJkosRm32BqzQgqzZ+uyRwcwlt44npBkKdU9pT7x1w4oU2/GI/1j6deq9JCE2Q YsrFbSNNNeACWW31qQqAIFgr2KhXfjEKDw+z1HLVFGewhjT8y1N5UjYty+VTvR1OMcDm 0ehqV7qFDx5MXUmJuZMoDC4DfK8YsJO9zgl7V3k4jAm1qVQs4ebc0oMkUs81cR7jg0Rn uz36prI1arZ3llosG9H4dGg2n8+9KOryO08SJ5zjF1uMPD3egQ/071ac9WK7piwg25uX 1RYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xbpELsugNZF8rjInA45zjC7oTJelH8Om7FekrP4jTnI=; b=Bm5W8q6n3QK2NUx+VklEsZ/z3pYGf0MHPhRoW6N1KPiJSAJdd5cTKOQyVzCw2Lxa+9 QNsJ8684Kvf7YEmj5yfXVrpmzWHaO4kzrk8fnbUZoo7uEd9A13nOFgJ3OewE+8gxySjh CVA3gJ0Lxa6y2QBIR8USLWW/XkXUMPTJk2QKasmKYIfVKKywsEo9ZZLfQt+aG5Ikcojn m8LPau3XCL6+SYqNXHZW/FUgngKW++CsFIofk8ZcSgzpOYWgAQj4oLjNqeHCsYhsWcBB xO8UVvBlka9/wEVx61II3jAblS9eQc0XvgLygLotcq5UOD6RfdHsY+Y3HcCVWYhPduc4 su3A== X-Gm-Message-State: APt69E0oqRhsGFYMfQyMXy/abQ4otDsxQUNe8kST7HqvXzMBCc8rw7/F A+r52PFF/hjhRK0kwM42ygSIe/sKuy0= X-Received: by 2002:a62:d9c5:: with SMTP id b66-v6mr25886978pfl.41.1529560359469; Wed, 20 Jun 2018 22:52:39 -0700 (PDT) Received: from [10.10.3.96] (s169.156.222.122.fls.vectant.ne.jp. [122.222.156.169]) by smtp.gmail.com with ESMTPSA id z26-v6sm8322802pfd.60.2018.06.20.22.52.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Jun 2018 22:52:38 -0700 (PDT) Subject: Re: [RFC PATCH] of: overlay: update phandle cache on overlay apply and remove To: Rob Herring Cc: Alan Tull , Pantelis Antoniou , Pantelis Antoniou , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" , Geert Uytterhoeven References: <1529251416-14814-1-git-send-email-frowand.list@gmail.com> From: Frank Rowand Message-ID: <1bb4ef5c-5813-fbea-9536-48b339c1e010@gmail.com> Date: Wed, 20 Jun 2018 22:52:34 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/20/18 11:23, Rob Herring wrote: > On Sun, Jun 17, 2018 at 10:03 AM, wrote: >> From: Frank Rowand >> >> A comment in the review of the patch adding the phandle cache said that >> the cache would have to be updated when modules are applied and removed. >> This patch implements the cache updates. >> >> Fixes: 0b3ce78e90fc ("of: cache phandle nodes to reduce cost of of_find_node_by_phandle()") >> Reported-by: Alan Tull >> Suggested-by: Alan Tull >> Signed-off-by: Frank Rowand >> --- >> >> Compiles for one configuration. >> NOT boot tested. >> Not run through my normal process to check for new warnings, etc. > > I'm assuming you will resend a non-RFC version for me to apply. Yes, I will. > > I think it would be a bit better if callers didn't have to do free and > populate themselves, but just made an invalidate call (like a normal > cache) and re-populating the cache could happen on demand. Or if it > was done as a single call, you could just copy the old entries to the > new larger array. But maybe there would be a race condition in doing > that? In any case, all that could be a subsequent patch. Yes, the unspoken, underlying issue is a race condition. I'll update the commit comment to explain the race issues a little bit. And maybe add a code comment if I can be concise enough. -Frank > > Rob >