From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: richard.genoud@gmail.com
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Maxime Ripard <maxime.ripard@bootlin.com>,
Vinod Koul <vinod.koul@intel.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
dmaengine@vger.kernel.org,
Linux Kernel <linux-kernel@vger.kernel.org>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
Mario Forner <m.forner@be4energy.com>
Subject: Re: DMA: atmel_serial: Opening and closing the serial device repeatedly causes kmalloc-32 slab leak
Date: Tue, 27 Nov 2018 10:58:43 +0100 [thread overview]
Message-ID: <20181127095843.GF19871@piout.net> (raw)
In-Reply-To: <83753d21-f3c8-c8dd-75d7-741cb597d1a3@sorico.fr>
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 <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <unistd.h>
>
>
> 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.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
WARNING: multiple messages have this Message-ID (diff)
From: alexandre.belloni@bootlin.com (Alexandre Belloni)
To: linux-arm-kernel@lists.infradead.org
Subject: DMA: atmel_serial: Opening and closing the serial device repeatedly causes kmalloc-32 slab leak
Date: Tue, 27 Nov 2018 10:58:43 +0100 [thread overview]
Message-ID: <20181127095843.GF19871@piout.net> (raw)
In-Reply-To: <83753d21-f3c8-c8dd-75d7-741cb597d1a3@sorico.fr>
Hello Richard,
On 27/11/2018 10:51:13+0100, richard.genoud at 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 <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <unistd.h>
>
>
> 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.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-11-27 9:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <22061488.b0eNpyQjWt@linux-7rm0>
2018-11-27 9:51 ` DMA: atmel_serial: Opening and closing the serial device repeatedly causes kmalloc-32 slab leak Richard Genoud
2018-11-27 9:51 ` richard.genoud
2018-11-27 9:51 ` richard.genoud
2018-11-27 9:58 ` Alexandre Belloni [this message]
2018-11-27 9:58 ` Alexandre Belloni
2018-11-27 9:55 Richard Genoud
2018-11-27 9:55 ` richard.genoud
2018-11-27 9:55 ` richard.genoud
-- strict thread matches above, loose matches on Subject: below --
2018-11-27 10:46 Richard Genoud
2018-11-27 10:46 ` Richard Genoud
2018-11-27 10:46 ` Richard Genoud
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181127095843.GF19871@piout.net \
--to=alexandre.belloni@bootlin.com \
--cc=dmaengine@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=ludovic.desroches@microchip.com \
--cc=m.forner@be4energy.com \
--cc=maxime.ripard@bootlin.com \
--cc=nicolas.ferre@microchip.com \
--cc=richard.genoud@gmail.com \
--cc=vinod.koul@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.