Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <2bd80da6-944c-4c9d-febf-f83b4302492a@nbd.name>
Date:   Thu, 3 Mar 2022 07:58:54 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0)
 Gecko/20100101 Thunderbird/91.6.1
Subject: Re: [PATCH 03/11] net: ethernet: mtk_eth_soc: add support for
 Wireless Ethernet Dispatch (WED)
Content-Language: en-US
To:     Jakub Kicinski <kuba@kernel.org>
Cc:     netdev@vger.kernel.org, John Crispin <john@phrozen.org>,
        Sean Wang <sean.wang@mediatek.com>,
        Mark Lee <Mark-MC.Lee@mediatek.com>,
        "David S. Miller" <davem@davemloft.net>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-mediatek@lists.infradead.org
References: <20220225101811.72103-1-nbd@nbd.name>
 <20220225101811.72103-4-nbd@nbd.name>
 <20220225221848.7c7be7f6@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
From:   Felix Fietkau <nbd@nbd.name>
In-Reply-To: <20220225221848.7c7be7f6@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 26.02.22 07:18, Jakub Kicinski wrote:
> On Fri, 25 Feb 2022 11:18:02 +0100 Felix Fietkau wrote:
>> +	page_list = kcalloc(n_pages, sizeof(*page_list), GFP_KERNEL);
>> +	if (!page_list)
>> +		return -ENOMEM;
>> +
>> +	dev->buf_ring.size = ring_size;
>> +	dev->buf_ring.pages = page_list;
>> +
>> +	desc = dma_alloc_coherent(dev->hw->dev, ring_size * sizeof(*desc),
>> +				  &desc_phys, GFP_KERNEL);
>> +	if (!desc)
>> +		return -ENOMEM;
>> +
>> +	dev->buf_ring.desc = desc;
>> +	dev->buf_ring.desc_phys = desc_phys;
>> +
>> +	for (i = 0, page_idx = 0; i < ring_size; i += MTK_WED_BUF_PER_PAGE) {
>> +		dma_addr_t page_phys, buf_phys;
>> +		struct page *page;
>> +		void *buf;
>> +		int s;
>> +
>> +		page = __dev_alloc_pages(GFP_KERNEL, 0);
>> +		if (!page)
>> +			return -ENOMEM;
> 
> I haven't looked at the code, yet, but this sure looks leaky.
It's not leaky. If the alloc fails, mtk_wed_detach is still called, 
which cleans up even incomplete ring allocations.

- Felix