Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp2956450imb; Mon, 4 Mar 2019 19:38:04 -0800 (PST) X-Google-Smtp-Source: APXvYqwX/cPJWNtuOiPBc4JEL0TxyLidqxezp6c0ny1LYehj+UAI31az778h7e3/QuaxqaVAPQyc X-Received: by 2002:a17:902:e409:: with SMTP id ci9mr23430031plb.221.1551757084132; Mon, 04 Mar 2019 19:38:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551757084; cv=none; d=google.com; s=arc-20160816; b=lQr3aqxtaXHuwFKqo9CDSiG9yl05/plSj68HKZktV0QkHROFo3FM6nRjxAYtHABHyJ mnbjchkS6iCD6MfuGySYuZWJgJF8jyj8h3hduax0fnlti64LT4ffzeXV20nSh2yBgsx9 uEGjXNojChV3jH4XD3Rv/51oIYGQXpgNghURe2SCQGl9I9jywoHOT/WM+PGvdCV4YzaD 8M+jlUiM+MmeeK8sCasB73ZR2d29pi3p7bErNCFXaTX3t6K3XjSbu7LSIIvB3/Ayt8De TmfXqIr0H7jPjDUyXBFP3oZxvRQ53+zBG+TSoCk2dtX+7tgsHd8NiaAgQEhi+F7F/loB O49w== 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; bh=GIcRQWlRuzePKke3kmlr7/WYI2F6GVoViemY5trqCNI=; b=z98bH4G6m+8nHOUD7pF1qfqwiaBeGwrqU89t3bbNdGNcH+4al9Apj7qq0+dev+2CiH L2dmvpwPd8C9P33dYRhuFJFJSVzmkUITa9GK97I/bNTTuG3c/ZenL5EsvsajdQCcqpAK ejW0ou3/X2zq0PD8JN7Kdqr5cSqeZQ9WqrLrGuqle9f6G/+nY7MZPKTwjb//U52Leo4M z+YhQuGy3L+pBC7LbatcA89twPAJjk+FZKgCpRhgyoL0du/KYOykGCXPv/cuTREzhYf2 1xglYhBUtVjF5s2escwO+FVLhEuLK7XAl8MTjqNVz/hieAnwa9LwdB1nSY9+TH1vILjN oqYA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=mCXp5fP+; 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 j70si6705812pgd.65.2019.03.04.19.37.48; Mon, 04 Mar 2019 19:38:04 -0800 (PST) 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=mCXp5fP+; 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 S1727026AbfCEDgP (ORCPT + 99 others); Mon, 4 Mar 2019 22:36:15 -0500 Received: from mail-ua1-f68.google.com ([209.85.222.68]:33690 "EHLO mail-ua1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726590AbfCEDgO (ORCPT ); Mon, 4 Mar 2019 22:36:14 -0500 Received: by mail-ua1-f68.google.com with SMTP id q17so6499052uam.0; Mon, 04 Mar 2019 19:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GIcRQWlRuzePKke3kmlr7/WYI2F6GVoViemY5trqCNI=; b=mCXp5fP+qhJAdj4eAMnHdUH8WNH3sPg4fF2HNK9R7tY0m7QEajNhF9DPOwYP9rTGuL Ofk/BHGLnZryHesn0ttG3qBlOpCD/y2iMC6tz4ll0z+Z7xnhr00hxGj3xTCb9LSLP1cT jm0U0DY59rhGH4ilexukNzye6XEGNzoIJgROkGXiLiyEMig9Lj/XpzzlrtCuI0KqcqzM WjwBFZv1s00KGAZ3b7Ncv4fJX6BwLTGPuZva7gbTo42t6/9zDsBgWxb7dh5IFjDQY3zH kEz8E1RF/WbT9odLRQewnhfctH/8+eeYCPLstTFXNiXL9KZaG5mmaUrb8fiU9hedW9d6 hxqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GIcRQWlRuzePKke3kmlr7/WYI2F6GVoViemY5trqCNI=; b=IKTQ/zt/DssTrQbEqc8QRIoWeWNBKztapvq4T5S74zHYS1YX7e/bOmBZBBe4VAWIJa liRwkowUpkBI1//ih5CZvzOYHXhsLXzLljuewO9w2kr8XI1N110etktAxyNBBBSjwZXl a5FOEVmpdyPlm4ZYKrtXX1/1fLQdG4LmqbMZvQx3p4SyvKkfS5zQjs74czAC/uID8RtH lMzdmz5Wec5F7tr7wlX8D/ehsEfqGT7HQOdj4xaGoIctOJ7lOFXuzkd5KwCjkG18M38A Ouq4Awc4MvBbvOJKWqVrh1onmZ3zkDMwyFefIHoewCcM7y5jUZNfgKyqh0TE3NZTH371 JwqQ== X-Gm-Message-State: APjAAAUpuC5GipeS7S7DK5daQvLbkGYBb4SQ7VfI/5OiM/Ebc1sS50sP F0KEZ6zpm0nNWiAHwzX26Gkh5O1afHd1zqT61ew= X-Received: by 2002:a67:78ce:: with SMTP id t197mr64347vsc.152.1551756973215; Mon, 04 Mar 2019 19:36:13 -0800 (PST) MIME-Version: 1.0 References: <20190219074500.16454-1-vichy.kuo@gmail.com> In-Reply-To: From: pierre kuo Date: Tue, 5 Mar 2019 11:36:01 +0800 Message-ID: Subject: Re: [PATCH 1/1] of: reserved_mem: fix reserve memory leak To: Rob Herring Cc: Marek Szyprowski , Frank Rowand , devicetree@vger.kernel.org, "linux-kernel@vger.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 > You should Cc the author(s) of this code. I've added Marek. Thanks ^^ The cc lists I got were from get_maintainer.pl, no matter running with of_reserved_mem.c or patch file. (with file) $ perl scripts/get_maintainer.pl --separator , --norolestats drivers/of/of_reserved_mem.c Rob Herring ,Frank Rowand ,devicetree@vger.kernel.org,linux-kernel@vger.kernel.org (with patch) $ perl scripts/get_maintainer.pl --separator , --norolestats 0001-of-reserved_mem-fix-reserve-memory-leak.patch Rob Herring ,Frank Rowand ,devicetree@vger.kernel.org,linux-kernel@vger.kernel.org > > The __reserved_mem_init_node will call region specific reserved memory > > init codes, but once all compatibled init codes failed, the memory region > > will left in memory.reserved and cause leakage. > > > > Take cma reserve memory DTS for example, if user declare 1MB size, > > which is not align to (PAGE_SIZE << max(MAX_ORDER - 1, > > pageblock_order)), rmem_cma_setup will return -EINVAL. > > Meanwhile, rmem_dma_setup will also return -EINVAL since "reusable" > > property is not set. If finally there is no reserved memory init pick up > > this memory, kernel will left the 1MB leak in memory.reserved. > > > > This patch will remove this kind of memory from memory.reserved, only > > when __reserved_mem_init_node return neither 0 nor -ENOENT. > > I'm not sure that un-reserving memory on error is the correct > behavior. It may be fine for something like CMA, but if it is some > shared memory used by another processor in the system not reserving it > would probably never be correct. In this patch, we un-reserving memory ONLY if explicit compatible matching fail. That mean driver found something wrong while matching and let OS know. (But reserved-memory without compatible property will not be affected.) So per ur explaination, there would be cases that driver reported matching memory fail, but the memory is still needed by another processor? Appreciate ur kind help,