Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp720873imu; Tue, 27 Nov 2018 05:26:37 -0800 (PST) X-Google-Smtp-Source: AFSGD/Xuz3QbrAXkGXZgpMLdK/kxgWxUEhm4XuDAmOYexCwm5OuNvpKfQmBsy4NIwAiZ5SfgubGL X-Received: by 2002:a17:902:227:: with SMTP id 36mr32581697plc.140.1543325197654; Tue, 27 Nov 2018 05:26:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543325197; cv=none; d=google.com; s=arc-20160816; b=P+Ds1Y7ayScXesmG3h/bEaDlu+bJRpyJqu6wDNY1NncvN9fGAxmJ5KtGYmLhHpy92z Z61xVnmeMwcMI7R4iHA8NwMGkC/ZNq3Y2pI/Ciw8PUktAohXME3E5gP2ZJ81Yz8tcUjf kvfuD9JJWvF4dWo8g7LZZ4gca5GKQT4rCyK971wV09KatXxPuhtVGdSS1ABq4dNdtkq6 syx1TPT0DzRf3EEgJom0ulBO1HvaJtHyyd8eqDNmoTLUib8dwP4P8lVacq9PEbPQe53P D0QOIzc7Hk0qC/KG3D/RYAMw7naI3KXfOOY4oF40utbBL9N1V01TbaLSzZk7y3iPGit0 Torw== 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; bh=NiDjIF3XoyLsmxzGBkgjpGIUvNuz2y95mA9watVoRtY=; b=yndsLetDH6/rtxtdLqNV4A2H8cNbEGjJbgfeGXtfvYDgZRIC6CsuqkPcXjmc7vuE3n FhXb4oSqjA8XEwSKCoXAS9aP3vKKHXrNDGUCGWI44uvxhNftTE2eat1FTf3wRa2FRJw4 C726i70HMU0HDtlZJ49MPz/Ab6C3Gj6p05IAMWqPaBV5Sqcxksvuc9yf5lFq7XMRwrUR 2vjBGHi6fEv3jpb89nBSfx8fXaXYuFBW97U9z2Khje9PasBXUgRChTANG1AAq3+LQ0KL HE5gXMChiwtS+iBCeP0apWElXPnnRzAPtrxuMxrOD+O+T6QMbAgz4bi1abVTLpu8L43W RSag== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e39si3975413plg.388.2018.11.27.05.26.10; Tue, 27 Nov 2018 05:26:37 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729573AbeK0Vob (ORCPT + 99 others); Tue, 27 Nov 2018 16:44:31 -0500 Received: from mout01.posteo.de ([185.67.36.141]:59166 "EHLO mout01.posteo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729540AbeK0Voa (ORCPT ); Tue, 27 Nov 2018 16:44:30 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id D7523160064 for ; Tue, 27 Nov 2018 11:46:58 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4340pT1znXz6tm7; Tue, 27 Nov 2018 11:46:57 +0100 (CET) Subject: Re: DMA: atmel_serial: Opening and closing the serial device repeatedly causes kmalloc-32 slab leak To: Alexandre Belloni , richard.genoud@gmail.com Cc: Ludovic Desroches , Nicolas Ferre , Maxime Ripard , "linux-arm-kernel@lists.infradead.org" , dmaengine@vger.kernel.org, Linux Kernel , "linux-serial@vger.kernel.org" , Mario Forner , Vinod Koul References: <22061488.b0eNpyQjWt@linux-7rm0> <83753d21-f3c8-c8dd-75d7-741cb597d1a3@sorico.fr> <20181127095843.GF19871@piout.net> From: Richard Genoud Message-ID: Date: Tue, 27 Nov 2018 11:46:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <20181127095843.GF19871@piout.net> Content-Type: text/plain; charset=utf-8 Content-Language: fr Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 27/11/2018 à 10:58, Alexandre Belloni a écrit : > Hello Richard, > > On 27/11/2018 10:51:13+0100, richard.genoud@gmail.com wrote: >> Hi all, >> >> I reproduced the memory leak on my board (at91sam9g35-cm) with a 4.20-rc3. >> >> It triggered an OOM after a couple of hours running a code like this: >> #include >> #include >> #include >> #include >> >> >> int main(int argc, char **argv) >> { >> int fd; >> do { >> fd = open("/dev/ttyS1", O_RDONLY); >> close(fd); >> } while (true); >> return 0; >> } >> >> As Mario pointed out, this only happens when atmel,use-dma-{r,t}x are >> used in the device-tree. >> >> Adding: >> CONFIG_DEBUG_SLAB=y >> CONFIG_DEBUG_SLAB_LEAK=y >> Doesn't show anything suspect in /proc/slab_allocators >> >> From what I found until now, it's something done in : >> dma_request_slave_channel(); >> that leaks kmalloc-32 >> Mabe I missed something, but it seems that everything DMA related is >> deallocated in atmel_release_{tx,rx}_dma(). >> >> Is this ringing a bell ? >> > > Yes, this is known issue and it has yet to be worked on. > After a talk on freenode, Alex found the problem. A patch is on its way. Thanks !