All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Simon Kirby <sim@hostway.ca>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [3.1-rc6] kmalloc(64) leak from IDE
Date: Thu, 22 Sep 2011 10:48:11 +0200	[thread overview]
Message-ID: <20110922084811.GC17640@liondog.tnic> (raw)
In-Reply-To: <20110922072643.GA27232@hostway.ca>

On Thu, Sep 22, 2011 at 12:26:44AM -0700, Simon Kirby wrote:
> All sorts of fun with 3.1-rc!
> 
> On an older x86 box still using the IDE code, I'm seeing a kmalloc(64)
> leak (according to slabtop) that basically OOM'd the box in a few days
> (640 MB of RAM). This has popped up since 2.6.36, which ran for a long
> time on this box with no problems. Issues seen on -rc5, so I rebuilt with
> CONFIG_DEBUG_KMEMLEAK on 9d037a777695993ec7437e5f451647dea7919d4c and
> /sys/kernel/debug/kmemleak filled up with size 64 traces involving IDE
> requests. Every trace seems to contain idedisk_prep_fn():
> 
> unreferenced object 0xe30c00c0 (size 64):
>   comm "md6_raid1", pid 255, jiffies 4294903935 (age 23889.704s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 ea 00 00 00 00 00 00 00 00  ................
>     7e 00 00 00 20 00 00 00 01 00 00 00 00 00 00 00  ~... ...........
>   backtrace:
>     [<c1495c37>] kmemleak_alloc+0x27/0x50
>     [<c10b2f4a>] kmem_cache_alloc_trace+0x8a/0x120
>     [<c131fe47>] idedisk_prep_fn+0x37/0xf0
>     [<c12758b3>] blk_peek_request+0xa3/0x1e0
>     [<c1311f15>] __ide_requeue_and_plug+0x25/0x30
>     [<c131257d>] do_ide_request+0x3d/0x4e0
>     [<c1270ff4>] __blk_run_queue+0x14/0x20
>     [<c127699c>] __make_request+0x21c/0x290
>     [<c1274f26>] generic_make_request+0x1a6/0x490
>     [<c127526c>] submit_bio+0x5c/0xd0
>     [<c13a651b>] md_super_write+0x6b/0x80
>     [<c13a67ec>] md_update_sb+0x2bc/0x540
>     [<c13a7d51>] md_check_recovery+0x2c1/0x5f0
>     [<c138abce>] raid1d+0x2e/0xd90
>     [<c13a58d5>] md_thread+0xe5/0x110
>     [<c1047df4>] kthread+0x74/0x80
> 
> unreferenced object 0xc1c3d900 (size 64):
>   comm "hardirq", pid 0, jiffies 5819438 (age 829.636s)
>   hex dump (first 32 bytes):
>     00 00 00 00 00 00 00 ea 00 00 00 00 00 00 00 00  ................
>     7e 00 00 00 20 00 00 00 01 00 00 00 00 00 00 00  ~... ...........
>   backtrace:
>     [<c1495c37>] kmemleak_alloc+0x27/0x50
>     [<c10b2f4a>] kmem_cache_alloc_trace+0x8a/0x120
>     [<c131fe47>] idedisk_prep_fn+0x37/0xf0
>     [<c12758b3>] blk_peek_request+0xa3/0x1e0
>     [<c1311f15>] __ide_requeue_and_plug+0x25/0x30
>     [<c1311f2f>] ide_requeue_and_plug+0xf/0x20
>     [<c1311fb8>] ide_intr+0x78/0x1e0
>     [<c1065c14>] handle_irq_event_percpu+0x54/0x1d0
>     [<c1065dac>] handle_irq_event+0x1c/0x30
>     [<c1067b8c>] handle_level_irq+0x4c/0xa0
>     [<ffffffff>] 0xffffffff
> 
> idedisk_prep_fn() seems to allocate a command and return it as
> rq->special, but I'm not following what happens after that.

AFAIR, that's blk_peek_request - it calls q->prep_rq_fn which is
idedisk_prep_fn() and it unconditionally allocates those ide_cmd's
without freeing them and I can imagine the upper layer requeue one
request a couple of times back-to-back, leading to the leaks.

So maybe the following could work, it is a stab in the dark for all I
know:

--
diff --git a/drivers/ide/ide-disk.c b/drivers/ide/ide-disk.c
index 274798068a54..16f69be820c7 100644
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -435,7 +435,12 @@ static int idedisk_prep_fn(struct request_queue *q, struct request *rq)
 	if (!(rq->cmd_flags & REQ_FLUSH))
 		return BLKPREP_OK;
 
-	cmd = kzalloc(sizeof(*cmd), GFP_ATOMIC);
+	if (rq->special) {
+		cmd = rq->special;
+		memset(cmd, 0, sizeof(*cmd));
+	} else {
+		cmd = kzalloc(sizeof(*cmd), GFP_ATOMIC);
+	}
 
 	/* FIXME: map struct ide_taskfile on rq->cmd[] */
 	BUG_ON(cmd == NULL);
--

Can you rerun it with kmemleak enabled and check whether it still
triggers?

Also, I'm sure you know IDE is deprecated, so what are the chances of
moving this box to libata? Also, can you send me your .config pls?

Thanks.

-- 
Regards/Gruss,
    Boris.

  reply	other threads:[~2011-09-22  8:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-22  7:26 Simon Kirby
2011-09-22  8:48 ` Borislav Petkov [this message]
2011-09-22 20:23   ` Simon Kirby
2011-09-23  7:21     ` Borislav Petkov
2011-09-23 15:58       ` Bernd Schubert
2011-09-23 16:08         ` Bjorn Helgaas
2011-09-23 16:08           ` Bjorn Helgaas
2011-09-23 16:34           ` Bernd Schubert
2011-09-23 16:40             ` Bjorn Helgaas
2011-09-23 16:40               ` Bjorn Helgaas
2011-09-23 17:49               ` Bernd Schubert
2011-09-23 17:38       ` Simon Kirby
2011-09-25  8:58         ` Borislav Petkov
2011-09-26  8:05           ` Simon Kirby
2011-09-27 17:07             ` Borislav Petkov
2011-09-29  9:27               ` Borislav Petkov
2011-09-29 22:45                 ` Simon Kirby
2011-09-30  6:40                   ` Borislav Petkov

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=20110922084811.GC17640@liondog.tnic \
    --to=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sim@hostway.ca \
    --subject='Re: [3.1-rc6] kmalloc(64) leak from IDE' \
    /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

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.