Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1174336imm; Wed, 13 Jun 2018 14:48:39 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJpW0vCTC+ljumlR5+a75CqXY3jznrOB5S9yCDEDwucSA4OEJGud62GbZiNdqRQj/1FFPA+ X-Received: by 2002:a63:6485:: with SMTP id y127-v6mr5485544pgb.126.1528926519070; Wed, 13 Jun 2018 14:48:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528926519; cv=none; d=google.com; s=arc-20160816; b=orFO7qyjkr79dVPZUfk60MCdZK9/GGFYU9cYrqUVrGqPDxa0ZnsreXHA1qG0bd9a8Y YOGSDq5iG3Lq8JAptWy6Do9YcbI6PxjJ5T36A/ned2kknDyZDifYinRy6Mw4edGpEb8v e59bFBHJCyZdajka5TecwdxuQZTdgqrZy1VUofyA3GeZjf2j8/MC8uHCLgNFdf837039 5vIVLujTaLh0GVIvXYDErRRS9pFFcG2KeT+MHvBOwXLNQU3Mvh5DapdWJgy9Ho3wRBff 6POftKkF1nVq7ygdv6X3t1rPHFL2j9C8XoequRXSsp/2hHMH8KroAIj+yIO9+6SH7Jrj 4PBw== 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=3mnLc0Qd51YQgbM3T5FxLl8Op3Un1auyOIMcBhY5fZk=; b=HKHknv4OXI+kTh8+dT82GZy8kzjNa4NMM38azJ5fei+PUf357dsrn4DiIJ7o0GqGNl dJ8TxroQenhnWdZBR0LToD7JGQhkmWSSeZEArIQ2Wc1Sn+PUVWf+ofzn7zdsad04+7tm AAFT/U/p3ybwfC9OYYeU9UM0o/0RHThcxKWd/sXhfOMg+T1sUZ5b1nTOJ72S6klYas3F V0Jt6PjU2XrX1K2/E2dLacGXHK0AU7MAwlyvWogwPWEU8E4gjrZR/WCSHmHv7Bks2kHr T5CLJuEAZjQRBjGZw9NWeqYVFQVqTldwc6Yc4GbJAyhD39zMYTwgXLnfLLNmtxyQkjnp YDgQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Ksz4CBc1; 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 f13-v6si3055984pgo.265.2018.06.13.14.48.24; Wed, 13 Jun 2018 14:48:39 -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=Ksz4CBc1; 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 S1754567AbeFMVrk (ORCPT + 99 others); Wed, 13 Jun 2018 17:47:40 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:33618 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754517AbeFMVri (ORCPT ); Wed, 13 Jun 2018 17:47:38 -0400 Received: by mail-pg0-f65.google.com with SMTP id e11-v6so1902756pgq.0; Wed, 13 Jun 2018 14:47:38 -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=3mnLc0Qd51YQgbM3T5FxLl8Op3Un1auyOIMcBhY5fZk=; b=Ksz4CBc1kl0PEj6kVHSn3mCtPJhwo0kV5Q/T+umni/vd1cE+Lqr9DQUBuG8f4qkjhh zGDGRktsMDi4vVbRaj4X+n3b2Ixj3Yl7vBGb3mYHveVhUI3672lcjSFs77HWMP2YH+DC sLotrFrueYdDaW4irfjT63E20oOH3aPoIco8CtxvWjUOGwb8KaLDNBs7yjGDRCFjFeWD 1k7FzLXQ4jkwXdrYgEP4i1QOtn6ELXbM01lPMpSCUcof3wQ4IjwcCvIpHWln0X/o1Mu8 AmLsbmSuQRU1VdvweNKceGb26Lk4svwm6Pivy6ybDKq3KGIE3XGR4ynEIi9zzWFiIb9c h+Yw== 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=3mnLc0Qd51YQgbM3T5FxLl8Op3Un1auyOIMcBhY5fZk=; b=RVZ9MFFe5IC+8vDb0JoYPoHcbOtzXyihE/r11EPsg0Tw3QZAyvIV3M0BM45wiNaHfl xSpcdkZu0ta4MuQUyI3WY6bsIKpTVLgsR0emBBFHpfhJQEW2EBDTzYAGDeSHkrqI5aT5 JnbTQDmG3AaLx2swLOXEfo773EMLeCEHgJmHprxVOpFrmHjZRqdrdnxytRnxRiHIo9kn Xqz1//P7LeG3F1roFoGJWRrIr18qrfjfvjXmlVQsV3Ty5n8hoijiS5MMm+Ttgc7EjWIA JWBcqz1lekiUi0mUEvy+AL7CTdjJ8gfXTHTrY6eae6TUssR552nAEp4t6qNX31EZMuMT lxAQ== X-Gm-Message-State: APt69E2MNN418slmdwenEXsJpbx72DX4D8V1wFrjse8wXHZwjpH46s7p 9GffFG9YaM4Ujq6CcTM0kqc= X-Received: by 2002:a65:6290:: with SMTP id f16-v6mr5554118pgv.155.1528926457753; Wed, 13 Jun 2018 14:47:37 -0700 (PDT) Received: from [192.168.43.210] (mobile-166-137-177-220.mycingular.net. [166.137.177.220]) by smtp.gmail.com with ESMTPSA id s27-v6sm7337409pfk.184.2018.06.13.14.47.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Jun 2018 14:47:37 -0700 (PDT) Subject: Re: [PATCH v5 1/3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle() To: Alan Tull Cc: Rob Herring , cpandya@codeaurora.org, "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , linux-kernel , linux-fpga@vger.kernel.org, Moritz Fischer References: <1520208889-3908-1-git-send-email-frowand.list@gmail.com> <1520208889-3908-2-git-send-email-frowand.list@gmail.com> From: Frank Rowand Message-ID: Date: Wed, 13 Jun 2018 14:47:27 -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: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/13/18 07:42, Alan Tull wrote: > On Tue, Jun 12, 2018 at 1:16 PM, Alan Tull wrote: >> On Sun, Mar 4, 2018 at 6:14 PM, wrote: >> >> Hi Frank, >> >> I'm investigating a refcount use-after-free warning that happens after >> overlays are applied, removed, reapplied a few (typically three) times >> (see below). This is new in v4.17, didn't happen in v4.16. As I was >> investigating I found that rebuilding the phandle_cache after overlays >> are applied or removed seems to help. > > I was probably wrong about this. The more I look at the phandle_cache code, > the more it looks looks good and straightforward. Probably disabling > phandle_cache is 'fixing' things through some weird side effect. I'll > keep investigating. Sorry for the noise. I suspect that you have found an issue, even if it is not the cause of the refcount issue. I noted in a reply to v4 of the patch: >> +static void of_populate_phandle_cache(void) >> +{ >> +Â Â Â unsigned long flags; >> +Â Â Â u32 cache_entries; >> +Â Â Â struct device_node *np; >> +Â Â Â u32 phandles = 0; >> + >> +Â Â Â raw_spin_lock_irqsave(&devtree_lock, flags); >> + >> +Â Â Â kfree(phandle_cache); > > I couldn't understood this. Everything else looks good to me. I will be adding a call to of_populate_phandle_cache() from the devicetree overlay code. I put the kfree here so that the previous cache memory is freed when a new cache is created. Adding the call from the overlay code is not done in this series because I have a patch series modifying overlays and I do not want to create a conflict or ordering between that series and that patch. The lack of the call from overlay code means that overlay code will gain some of the overhead reduction from this patch, but possibly not the entire reduction. Sorry I'm not giving a link to the archive of this message - I have a class I have to go to so I don't have enough time to find it. The email was Subject: Re: [PATCH v3] of: cache phandle nodes to reduce cost of of_find_node_by_phandle() Date: Fri, 16 Feb 2018 14:20:22 -0800 Message-ID: <46d5fc76-33e3-d54a-26b8-e9bb8332924d@gmail.com> Quickly looking at the current code, I don't see the overlay patch that I mentioned. I have to dig into what happened to that. Leaving a phandle from an overlay in the phandle cache after the overlay is removed would clearly be a bug. -Frank