This is coming from:
commit 6286ae97d10ea2b5cd90532163797ab217bfdbdf
Author: Christoph Lameter [off-list ref]
Date: Fri May 3 15:43:18 2013 +0000
slab: Return NULL for oversized allocations
The inline path seems to have changed the SLAB behavior for very large
kmalloc allocations with commit e3366016 ("slab: Use common
kmalloc_index/kmalloc_size functions"). This patch restores the old
behavior but also adds diagnostics so that we can figure where in the
code these large allocations occur.
Reported-and-tested-by: Tetsuo Handa [off-list ref]
Signed-off-by: Christoph Lameter [off-list ref]
Link: http://lkml.kernel.org/r/201305040348.CIF81716.OStQOHFJMFLOVF@I-love.SAKURA.ne.jp
[ penberg@kernel.org: use WARN_ON_ONCE ]
Signed-off-by: Pekka Enberg [off-list ref]
You'll have to convince Cristoph that WARN_ON_ONCE() there is evil and
has to be eradicated so that KASAN can run (but then we'd not know
easily that some allocation failed because it was too big and never
had a chance of succeeding vs. ordinary memory failure).
Can I recommend that maybe you introduce infrastructure for
panic_on_warn to ignore certain "well known" warnings?
Thanks.
--
Dmitry
This is coming from:
commit 6286ae97d10ea2b5cd90532163797ab217bfdbdf
Author: Christoph Lameter [off-list ref]
Date: Fri May 3 15:43:18 2013 +0000
slab: Return NULL for oversized allocations
The inline path seems to have changed the SLAB behavior for very large
kmalloc allocations with commit e3366016 ("slab: Use common
kmalloc_index/kmalloc_size functions"). This patch restores the old
behavior but also adds diagnostics so that we can figure where in the
code these large allocations occur.
Reported-and-tested-by: Tetsuo Handa [off-list ref]
Signed-off-by: Christoph Lameter [off-list ref]
Link: http://lkml.kernel.org/r/201305040348.CIF81716.OStQOHFJMFLOVF@I-love.SAKURA.ne.jp
[ penberg@kernel.org: use WARN_ON_ONCE ]
Signed-off-by: Pekka Enberg [off-list ref]
You'll have to convince Cristoph that WARN_ON_ONCE() there is evil and
has to be eradicated so that KASAN can run (but then we'd not know
easily that some allocation failed because it was too big and never
had a chance of succeeding vs. ordinary memory failure).
Can I recommend that maybe you introduce infrastructure for
panic_on_warn to ignore certain "well known" warnings?
Hi Christoph,
What was the motivation behind that WARNING about large allocations in
kmalloc? Why do we want to know about them? Is the general policy that
kmalloc calls with potentially large size requests need to use NOWARN?
If this WARNING still considered useful? Or we should change it to
pr_err?
From: Christopher Lameter <hidden> Date: 2018-09-24 15:08:19
On Sun, 23 Sep 2018, Dmitry Vyukov wrote:
What was the motivation behind that WARNING about large allocations in
kmalloc? Why do we want to know about them? Is the general policy that
kmalloc calls with potentially large size requests need to use NOWARN?
If this WARNING still considered useful? Or we should change it to
pr_err?
In general large allocs should be satisfied by the page allocator. The
slab allocators are used for allocating and managing small objects. The
page allocator has mechanisms to deal with large objects (compound pages,
multiple page sized allocs etc).
On Mon, Sep 24, 2018 at 5:08 PM, Christopher Lameter [off-list ref] wrote:
On Sun, 23 Sep 2018, Dmitry Vyukov wrote:
quoted
What was the motivation behind that WARNING about large allocations in
kmalloc? Why do we want to know about them? Is the general policy that
kmalloc calls with potentially large size requests need to use NOWARN?
If this WARNING still considered useful? Or we should change it to
pr_err?
In general large allocs should be satisfied by the page allocator. The
slab allocators are used for allocating and managing small objects. The
page allocator has mechanisms to deal with large objects (compound pages,
multiple page sized allocs etc).
I am asking more about the status of this warning. If it fires in
input_mt_init_slots(), does it mean that input_mt_init_slots() needs
to be fixed? If not, then we need to change this warning to something
else.
From: Christopher Lameter <hidden> Date: 2018-09-24 15:55:07
On Mon, 24 Sep 2018, Dmitry Vyukov wrote:
On Mon, Sep 24, 2018 at 5:08 PM, Christopher Lameter [off-list ref] wrote:
quoted
On Sun, 23 Sep 2018, Dmitry Vyukov wrote:
quoted
What was the motivation behind that WARNING about large allocations in
kmalloc? Why do we want to know about them? Is the general policy that
kmalloc calls with potentially large size requests need to use NOWARN?
If this WARNING still considered useful? Or we should change it to
pr_err?
In general large allocs should be satisfied by the page allocator. The
slab allocators are used for allocating and managing small objects. The
page allocator has mechanisms to deal with large objects (compound pages,
multiple page sized allocs etc).
I am asking more about the status of this warning. If it fires in
input_mt_init_slots(), does it mean that input_mt_init_slots() needs
to be fixed? If not, then we need to change this warning to something
else.
Hmmm.. kmalloc falls back to the page allocator already?
See
static __always_inline void *kmalloc(size_t size, gfp_t flags)
{
if (__builtin_constant_p(size)) {
if (size > KMALLOC_MAX_CACHE_SIZE)
return kmalloc_large(size, flags);
Note that this uses KMALLOC_MAX_CACHE_SIZE which should be smaller than
KMALLOC_MAX_SIZE.
How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
are larger than the maximum allowed by the page allocator. Thus the warning
and the NULL return.
On Mon, Sep 24, 2018 at 03:55:04PM +0000, Christopher Lameter wrote:
On Mon, 24 Sep 2018, Dmitry Vyukov wrote:
quoted
On Mon, Sep 24, 2018 at 5:08 PM, Christopher Lameter [off-list ref] wrote:
quoted
On Sun, 23 Sep 2018, Dmitry Vyukov wrote:
quoted
What was the motivation behind that WARNING about large allocations in
kmalloc? Why do we want to know about them? Is the general policy that
kmalloc calls with potentially large size requests need to use NOWARN?
If this WARNING still considered useful? Or we should change it to
pr_err?
In general large allocs should be satisfied by the page allocator. The
slab allocators are used for allocating and managing small objects. The
page allocator has mechanisms to deal with large objects (compound pages,
multiple page sized allocs etc).
I am asking more about the status of this warning. If it fires in
input_mt_init_slots(), does it mean that input_mt_init_slots() needs
to be fixed? If not, then we need to change this warning to something
else.
Hmmm.. kmalloc falls back to the page allocator already?
See
static __always_inline void *kmalloc(size_t size, gfp_t flags)
{
if (__builtin_constant_p(size)) {
It would not be a constant here though.
if (size > KMALLOC_MAX_CACHE_SIZE)
return kmalloc_large(size, flags);
Note that this uses KMALLOC_MAX_CACHE_SIZE which should be smaller than
KMALLOC_MAX_SIZE.
How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
are larger than the maximum allowed by the page allocator. Thus the warning
and the NULL return.
The size in this particular case is being derived from a value passed
from userspace. Input core does not care about any limits on size of
memory kmalloc() can support and is perfectly happy with getting NULL
and telling userspace to go away with their silly requests by returning
-ENOMEM.
For the record: I definitely do not want to pre-sanitize size neither in
uinput nor in input core.
Thanks.
--
Dmitry
On Mon, Sep 24, 2018 at 8:41 PM, Dmitry Torokhov
[off-list ref] wrote:
On Mon, Sep 24, 2018 at 03:55:04PM +0000, Christopher Lameter wrote:
quoted
On Mon, 24 Sep 2018, Dmitry Vyukov wrote:
quoted
On Mon, Sep 24, 2018 at 5:08 PM, Christopher Lameter [off-list ref] wrote:
quoted
On Sun, 23 Sep 2018, Dmitry Vyukov wrote:
quoted
What was the motivation behind that WARNING about large allocations in
kmalloc? Why do we want to know about them? Is the general policy that
kmalloc calls with potentially large size requests need to use NOWARN?
If this WARNING still considered useful? Or we should change it to
pr_err?
In general large allocs should be satisfied by the page allocator. The
slab allocators are used for allocating and managing small objects. The
page allocator has mechanisms to deal with large objects (compound pages,
multiple page sized allocs etc).
I am asking more about the status of this warning. If it fires in
input_mt_init_slots(), does it mean that input_mt_init_slots() needs
to be fixed? If not, then we need to change this warning to something
else.
Hmmm.. kmalloc falls back to the page allocator already?
See
static __always_inline void *kmalloc(size_t size, gfp_t flags)
{
if (__builtin_constant_p(size)) {
It would not be a constant here though.
quoted
if (size > KMALLOC_MAX_CACHE_SIZE)
return kmalloc_large(size, flags);
Note that this uses KMALLOC_MAX_CACHE_SIZE which should be smaller than
KMALLOC_MAX_SIZE.
How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
are larger than the maximum allowed by the page allocator. Thus the warning
and the NULL return.
The size in this particular case is being derived from a value passed
from userspace. Input core does not care about any limits on size of
memory kmalloc() can support and is perfectly happy with getting NULL
and telling userspace to go away with their silly requests by returning
-ENOMEM.
For the record: I definitely do not want to pre-sanitize size neither in
uinput nor in input core.
Christopher,
Assuming that the size is large enough to fail in all allocators, is
this warning still useful? How? Should we remove it?
From: Matthew Wilcox <willy@infradead.org> Date: 2018-09-27 14:35:46
On Mon, Sep 24, 2018 at 11:41:58AM -0700, Dmitry Torokhov wrote:
quoted
How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
are larger than the maximum allowed by the page allocator. Thus the warning
and the NULL return.
The size in this particular case is being derived from a value passed
from userspace. Input core does not care about any limits on size of
memory kmalloc() can support and is perfectly happy with getting NULL
and telling userspace to go away with their silly requests by returning
-ENOMEM.
For the record: I definitely do not want to pre-sanitize size neither in
uinput nor in input core.
On Thu, Sep 27, 2018 at 07:35:37AM -0700, Matthew Wilcox wrote:
On Mon, Sep 24, 2018 at 11:41:58AM -0700, Dmitry Torokhov wrote:
quoted
quoted
How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
are larger than the maximum allowed by the page allocator. Thus the warning
and the NULL return.
The size in this particular case is being derived from a value passed
from userspace. Input core does not care about any limits on size of
memory kmalloc() can support and is perfectly happy with getting NULL
and telling userspace to go away with their silly requests by returning
-ENOMEM.
For the record: I definitely do not want to pre-sanitize size neither in
uinput nor in input core.
Probably should be using kvzalloc then.
No. No sane input device can track so many contacts so we need to use
kvzalloc(). Failing to allocate memory is proper response here.
Thanks.
--
Dmitry
From: Christopher Lameter <hidden> Date: 2018-10-17 15:35:19
On Tue, 16 Oct 2018, Dmitry Torokhov wrote:
On Thu, Sep 27, 2018 at 07:35:37AM -0700, Matthew Wilcox wrote:
quoted
On Mon, Sep 24, 2018 at 11:41:58AM -0700, Dmitry Torokhov wrote:
quoted
quoted
How large is the allocation? AFACIT nRequests larger than KMALLOC_MAX_SIZE
are larger than the maximum allowed by the page allocator. Thus the warning
and the NULL return.
The size in this particular case is being derived from a value passed
from userspace. Input core does not care about any limits on size of
memory kmalloc() can support and is perfectly happy with getting NULL
and telling userspace to go away with their silly requests by returning
-ENOMEM.
For the record: I definitely do not want to pre-sanitize size neither in
uinput nor in input core.
Probably should be using kvzalloc then.
No. No sane input device can track so many contacts so we need to use
kvzalloc(). Failing to allocate memory is proper response here.
What is a "contact" here? Are we talking about SG segments?
On October 17, 2018 8:35:15 AM PDT, Christopher Lameter [off-list ref] wrote:
On Tue, 16 Oct 2018, Dmitry Torokhov wrote:
quoted
On Thu, Sep 27, 2018 at 07:35:37AM -0700, Matthew Wilcox wrote:
quoted
On Mon, Sep 24, 2018 at 11:41:58AM -0700, Dmitry Torokhov wrote:
quoted
quoted
How large is the allocation? AFACIT nRequests larger than
KMALLOC_MAX_SIZE
quoted
quoted
quoted
quoted
are larger than the maximum allowed by the page allocator. Thus
the warning
quoted
quoted
quoted
quoted
and the NULL return.
The size in this particular case is being derived from a value
passed
quoted
quoted
quoted
from userspace. Input core does not care about any limits on size
of
quoted
quoted
quoted
memory kmalloc() can support and is perfectly happy with getting
NULL
quoted
quoted
quoted
and telling userspace to go away with their silly requests by
returning
quoted
quoted
quoted
-ENOMEM.
For the record: I definitely do not want to pre-sanitize size
neither in
quoted
quoted
quoted
uinput nor in input core.
Probably should be using kvzalloc then.
No. No sane input device can track so many contacts so we need to use
kvzalloc(). Failing to allocate memory is proper response here.
What is a "contact" here? Are we talking about SG segments?
No, we are talking about maximum number of fingers a person can have. Devices don't usually track more than 10 distinct contacts on the touch surface at a time.
Thanks.
--
Dmitry
From: Christopher Lameter <hidden> Date: 2018-10-17 15:54:01
On Wed, 17 Oct 2018, Dmitry Torokhov wrote:
quoted
What is a "contact" here? Are we talking about SG segments?
No, we are talking about maximum number of fingers a person can have. Devices don't usually track more than 10 distinct contacts on the touch surface at a time.
Ohh... Way off my usual contexts of development. Sorry.
Ok you have my blessing.