From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de, Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Vladimir Davydov <vdavydov@virtuozzo.com>,
linux-mm@kvack.org, brouer@redhat.com,
Rao Shoaib <rao.shoaib@oracle.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH RT] mm/slub: close possible memory-leak in kmem_cache_alloc_bulk()
Date: Wed, 13 Dec 2017 15:46:54 +0100 [thread overview]
Message-ID: <20171213154654.2971ef2a@redhat.com> (raw)
In-Reply-To: <20171213140555.s4hzg3igtjfgaueh@linutronix.de>
On Wed, 13 Dec 2017 15:05:55 +0100
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> Under certain circumstances we could leak elements which were moved to
> the local "to_free" list. The damage is limited since I can't find any
> users here.
>
> Cc: stable-rt@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> Jesper: There are no users of kmem_cache_alloc_bulk() and kfree_bulk().
> Only kmem_cache_free_bulk() is used since it was introduced. Do you
> think that it would make sense to remove those?
I would like to keep them.
Rao Shoaib (Cc'ed) is/was working on a patchset for RCU-bulk-free that
used the kfree_bulk() API.
I plan to use kmem_cache_alloc_bulk() in the bpf-map "cpumap", for bulk
allocating SKBs during dequeue of XDP frames. (My original bulk alloc
SKBs use-case during NAPI/softirq was never merged).
> mm/slub.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index ffd2fa0f415e..9053e929ce9d 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3240,6 +3240,7 @@ int kmem_cache_alloc_bulk(struct kmem_cache *s, gfp_t flags, size_t size,
> return i;
> error:
> local_irq_enable();
> + free_delayed(&to_free);
> slab_post_alloc_hook(s, flags, i, p);
> __kmem_cache_free_bulk(s, i, p);
> return 0;
I've not seen free_delayed() before... and my cscope cannot find it...
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org,
tglx@linutronix.de, Peter Zijlstra <peterz@infradead.org>,
Steven Rostedt <rostedt@goodmis.org>,
Vladimir Davydov <vdavydov@virtuozzo.com>,
linux-mm@kvack.org, brouer@redhat.com,
Rao Shoaib <rao.shoaib@oracle.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH RT] mm/slub: close possible memory-leak in kmem_cache_alloc_bulk()
Date: Wed, 13 Dec 2017 15:46:54 +0100 [thread overview]
Message-ID: <20171213154654.2971ef2a@redhat.com> (raw)
In-Reply-To: <20171213140555.s4hzg3igtjfgaueh@linutronix.de>
On Wed, 13 Dec 2017 15:05:55 +0100
Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> Under certain circumstances we could leak elements which were moved to
> the local "to_free" list. The damage is limited since I can't find any
> users here.
>
> Cc: stable-rt@vger.kernel.org
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
> Jesper: There are no users of kmem_cache_alloc_bulk() and kfree_bulk().
> Only kmem_cache_free_bulk() is used since it was introduced. Do you
> think that it would make sense to remove those?
I would like to keep them.
Rao Shoaib (Cc'ed) is/was working on a patchset for RCU-bulk-free that
used the kfree_bulk() API.
I plan to use kmem_cache_alloc_bulk() in the bpf-map "cpumap", for bulk
allocating SKBs during dequeue of XDP frames. (My original bulk alloc
SKBs use-case during NAPI/softirq was never merged).
> mm/slub.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index ffd2fa0f415e..9053e929ce9d 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3240,6 +3240,7 @@ int kmem_cache_alloc_bulk(struct kmem_cache *s, gfp_t flags, size_t size,
> return i;
> error:
> local_irq_enable();
> + free_delayed(&to_free);
> slab_post_alloc_hook(s, flags, i, p);
> __kmem_cache_free_bulk(s, i, p);
> return 0;
I've not seen free_delayed() before... and my cscope cannot find it...
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
next prev parent reply other threads:[~2017-12-13 14:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-13 14:05 [PATCH RT] mm/slub: close possible memory-leak in kmem_cache_alloc_bulk() Sebastian Andrzej Siewior
2017-12-13 14:05 ` Sebastian Andrzej Siewior
2017-12-13 14:46 ` Jesper Dangaard Brouer [this message]
2017-12-13 14:46 ` Jesper Dangaard Brouer
2017-12-13 14:50 ` Sebastian Andrzej Siewior
2017-12-13 14:50 ` Sebastian Andrzej Siewior
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=20171213154654.2971ef2a@redhat.com \
--to=brouer@redhat.com \
--cc=bigeasy@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=rao.shoaib@oracle.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=vdavydov@virtuozzo.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.