On Wed, Jun 12, 2013 at 1:34 AM, Andrew Morton
wrote:
> __GFP_NOWARN is frequently used by kernel code to probe for "how big an
> allocation can I get". That's a bit lame, but it's used on slow paths
> and is pretty simple.
Applied to slab/urgent, thanks guys!
--
To unsubscribe from this list:
On Wed, Jun 12, 2013 at 1:34 AM, Andrew Morton
a...@linux-foundation.org wrote:
__GFP_NOWARN is frequently used by kernel code to probe for how big an
allocation can I get. That's a bit lame, but it's used on slow paths
and is pretty simple.
Applied to slab/urgent, thanks guys!
--
To
On Tue, 11 Jun 2013, Eric Dumazet wrote:
> Yes and no : adding a test to select vmalloc()/vfree() instead of
> kmalloc()/kfree() will slow down regular users asking 32 pages in their
> pipe.
But vmalloc would allow buffers larger than MAX_PAGE_ORDER. The allocation
would not fail. You could have
On Tue, 11 Jun 2013, Eric Dumazet wrote:
Yes and no : adding a test to select vmalloc()/vfree() instead of
kmalloc()/kfree() will slow down regular users asking 32 pages in their
pipe.
But vmalloc would allow buffers larger than MAX_PAGE_ORDER. The allocation
would not fail. You could have 1G
On Tue, 11 Jun 2013 18:16:08 +0300 Pekka Enberg wrote:
> On Tue, 11 Jun 2013, Sasha Levin wrote:
> >> I think that leaving the warning makes sense to catch similar
> >> things which are actually bugs - we had a similar issue with
> >> /dev/kmsg (if I remember correctly) which actually pointed to
On Tue, 11 Jun 2013, Christoph Lameter wrote:
> > I think that leaving the warning makes sense to catch similar
> > things which are actually bugs - we had a similar issue with
> > /dev/kmsg (if I remember correctly) which actually pointed to
> > a bug.
>
> Right. Requesting an allocation larger
On 06/11/2013 12:37 PM, Eric Dumazet wrote:
On Tue, 2013-06-11 at 12:19 -0400, Sasha Levin wrote:
It might be, but you need CAP_SYS_RESOURCE to go into the dangerous
zone (>pipe_max_size).
So if root (or someone with that cap) wants to go there, as Rusty says:
"Root asked, we do."
Yes and
On Tue, Jun 11, 2013 at 09:37:35AM -0700, Eric Dumazet wrote:
> On Tue, 2013-06-11 at 12:19 -0400, Sasha Levin wrote:
>
> > It might be, but you need CAP_SYS_RESOURCE to go into the dangerous
> > zone (>pipe_max_size).
> >
> > So if root (or someone with that cap) wants to go there, as
On Tue, 2013-06-11 at 12:19 -0400, Sasha Levin wrote:
> It might be, but you need CAP_SYS_RESOURCE to go into the dangerous
> zone (>pipe_max_size).
>
> So if root (or someone with that cap) wants to go there, as Rusty says:
> "Root asked, we do."
Yes and no : adding a test to select
On Tue, 11 Jun 2013, Eric Dumazet wrote:
> Allowing a pipe to store thousands of page refs seems quite useless and
> dangerous.
>
> Having to use vmalloc()/vfree() for every splice()/vmsplice() would be a
> performance loss anyway.
>
> (fs/splice.c splice_grow_spd() will also want to allocate big
On 06/11/2013 12:13 PM, Eric Dumazet wrote:
On Tue, 2013-06-11 at 11:44 -0400, Sasha Levin wrote:
On 06/11/2013 11:23 AM, Christoph Lameter wrote:
On Tue, 11 Jun 2013, Pekka Enberg wrote:
So you're OK with going forward with Sasha's patch? It's needed
because __GFP_NOWARN was specifically
On Tue, 2013-06-11 at 11:44 -0400, Sasha Levin wrote:
> On 06/11/2013 11:23 AM, Christoph Lameter wrote:
> > On Tue, 11 Jun 2013, Pekka Enberg wrote:
> >
> >> So you're OK with going forward with Sasha's patch? It's needed
> >> because __GFP_NOWARN was specifically added there to fix this
> >>
On 06/11/2013 11:23 AM, Christoph Lameter wrote:
On Tue, 11 Jun 2013, Pekka Enberg wrote:
So you're OK with going forward with Sasha's patch? It's needed
because __GFP_NOWARN was specifically added there to fix this
issue earlier.
Why dont we fix the call site to use vmalloc instead for
On Tue, 11 Jun 2013, Pekka Enberg wrote:
> So you're OK with going forward with Sasha's patch? It's needed
> because __GFP_NOWARN was specifically added there to fix this
> issue earlier.
Why dont we fix the call site to use vmalloc instead for larger allocs?
--
To unsubscribe from this list:
On Mon, 10 Jun 2013, Sasha Levin wrote:
> > There must be another reason. Lets fix this.
>
> My, I feel silly now.
>
> I was the one who added __GFP_NOFAIL in the first place in
> 2ccd4f4d ("pipe: fail cleanly when root tries F_SETPIPE_SZ
> with big size").
>
> What happens is that root can go
On Tue, 11 Jun 2013, Sasha Levin wrote:
I think that leaving the warning makes sense to catch similar
things which are actually bugs - we had a similar issue with
/dev/kmsg (if I remember correctly) which actually pointed to
a bug.
On 6/11/13 6:14 PM, Christoph Lameter wrote:
Right.
On Tue, 11 Jun 2013, Sasha Levin wrote:
> I think that leaving the warning makes sense to catch similar
> things which are actually bugs - we had a similar issue with
> /dev/kmsg (if I remember correctly) which actually pointed to
> a bug.
Right. Requesting an allocation larger than even
On 06/11/2013 02:28 AM, Pekka Enberg wrote:
Hi Sasha,
On Tue, Jun 11, 2013 at 3:54 AM, Sasha Levin wrote:
On 06/10/2013 07:40 PM, Christoph Lameter wrote:
On Mon, 10 Jun 2013, Sasha Levin wrote:
[ 1691.807621] Call Trace:
[ 1691.809473] [] dump_stack+0x4e/0x82
[ 1691.812783] []
Hi Sasha,
On Tue, Jun 11, 2013 at 3:54 AM, Sasha Levin wrote:
> On 06/10/2013 07:40 PM, Christoph Lameter wrote:
>>
>> On Mon, 10 Jun 2013, Sasha Levin wrote:
>>
>>> [ 1691.807621] Call Trace:
>>> [ 1691.809473] [] dump_stack+0x4e/0x82
>>> [ 1691.812783] [] warn_slowpath_common+0x82/0xb0
>>> [
Hi Sasha,
On Tue, Jun 11, 2013 at 3:54 AM, Sasha Levin sasha.le...@oracle.com wrote:
On 06/10/2013 07:40 PM, Christoph Lameter wrote:
On Mon, 10 Jun 2013, Sasha Levin wrote:
[ 1691.807621] Call Trace:
[ 1691.809473] [83ff4041] dump_stack+0x4e/0x82
[ 1691.812783]
On 06/11/2013 02:28 AM, Pekka Enberg wrote:
Hi Sasha,
On Tue, Jun 11, 2013 at 3:54 AM, Sasha Levin sasha.le...@oracle.com wrote:
On 06/10/2013 07:40 PM, Christoph Lameter wrote:
On Mon, 10 Jun 2013, Sasha Levin wrote:
[ 1691.807621] Call Trace:
[ 1691.809473] [83ff4041]
On Tue, 11 Jun 2013, Sasha Levin wrote:
I think that leaving the warning makes sense to catch similar
things which are actually bugs - we had a similar issue with
/dev/kmsg (if I remember correctly) which actually pointed to
a bug.
Right. Requesting an allocation larger than even supported
On Tue, 11 Jun 2013, Sasha Levin wrote:
I think that leaving the warning makes sense to catch similar
things which are actually bugs - we had a similar issue with
/dev/kmsg (if I remember correctly) which actually pointed to
a bug.
On 6/11/13 6:14 PM, Christoph Lameter wrote:
Right.
On Mon, 10 Jun 2013, Sasha Levin wrote:
There must be another reason. Lets fix this.
My, I feel silly now.
I was the one who added __GFP_NOFAIL in the first place in
2ccd4f4d (pipe: fail cleanly when root tries F_SETPIPE_SZ
with big size).
What happens is that root can go ahead and
On Tue, 11 Jun 2013, Pekka Enberg wrote:
So you're OK with going forward with Sasha's patch? It's needed
because __GFP_NOWARN was specifically added there to fix this
issue earlier.
Why dont we fix the call site to use vmalloc instead for larger allocs?
--
To unsubscribe from this list: send
On 06/11/2013 11:23 AM, Christoph Lameter wrote:
On Tue, 11 Jun 2013, Pekka Enberg wrote:
So you're OK with going forward with Sasha's patch? It's needed
because __GFP_NOWARN was specifically added there to fix this
issue earlier.
Why dont we fix the call site to use vmalloc instead for
On Tue, 2013-06-11 at 11:44 -0400, Sasha Levin wrote:
On 06/11/2013 11:23 AM, Christoph Lameter wrote:
On Tue, 11 Jun 2013, Pekka Enberg wrote:
So you're OK with going forward with Sasha's patch? It's needed
because __GFP_NOWARN was specifically added there to fix this
issue earlier.
On 06/11/2013 12:13 PM, Eric Dumazet wrote:
On Tue, 2013-06-11 at 11:44 -0400, Sasha Levin wrote:
On 06/11/2013 11:23 AM, Christoph Lameter wrote:
On Tue, 11 Jun 2013, Pekka Enberg wrote:
So you're OK with going forward with Sasha's patch? It's needed
because __GFP_NOWARN was specifically
On Tue, 11 Jun 2013, Eric Dumazet wrote:
Allowing a pipe to store thousands of page refs seems quite useless and
dangerous.
Having to use vmalloc()/vfree() for every splice()/vmsplice() would be a
performance loss anyway.
(fs/splice.c splice_grow_spd() will also want to allocate big
On Tue, 2013-06-11 at 12:19 -0400, Sasha Levin wrote:
It might be, but you need CAP_SYS_RESOURCE to go into the dangerous
zone (pipe_max_size).
So if root (or someone with that cap) wants to go there, as Rusty says:
Root asked, we do.
Yes and no : adding a test to select vmalloc()/vfree()
On Tue, Jun 11, 2013 at 09:37:35AM -0700, Eric Dumazet wrote:
On Tue, 2013-06-11 at 12:19 -0400, Sasha Levin wrote:
It might be, but you need CAP_SYS_RESOURCE to go into the dangerous
zone (pipe_max_size).
So if root (or someone with that cap) wants to go there, as Rusty says:
On 06/11/2013 12:37 PM, Eric Dumazet wrote:
On Tue, 2013-06-11 at 12:19 -0400, Sasha Levin wrote:
It might be, but you need CAP_SYS_RESOURCE to go into the dangerous
zone (pipe_max_size).
So if root (or someone with that cap) wants to go there, as Rusty says:
Root asked, we do.
Yes and no :
On Tue, 11 Jun 2013, Christoph Lameter wrote:
I think that leaving the warning makes sense to catch similar
things which are actually bugs - we had a similar issue with
/dev/kmsg (if I remember correctly) which actually pointed to
a bug.
Right. Requesting an allocation larger than even
On Tue, 11 Jun 2013 18:16:08 +0300 Pekka Enberg penb...@kernel.org wrote:
On Tue, 11 Jun 2013, Sasha Levin wrote:
I think that leaving the warning makes sense to catch similar
things which are actually bugs - we had a similar issue with
/dev/kmsg (if I remember correctly) which actually
On 06/10/2013 07:40 PM, Christoph Lameter wrote:
On Mon, 10 Jun 2013, Sasha Levin wrote:
[ 1691.807621] Call Trace:
[ 1691.809473] [] dump_stack+0x4e/0x82
[ 1691.812783] [] warn_slowpath_common+0x82/0xb0
[ 1691.817011] [] warn_slowpath_null+0x15/0x20
[ 1691.819936] []
On Mon, 10 Jun 2013, Sasha Levin wrote:
> [ 1691.807621] Call Trace:
> [ 1691.809473] [] dump_stack+0x4e/0x82
> [ 1691.812783] [] warn_slowpath_common+0x82/0xb0
> [ 1691.817011] [] warn_slowpath_null+0x15/0x20
> [ 1691.819936] [] kmalloc_slab+0x2f/0xb0
> [ 1691.824942] []
On 06/10/2013 03:31 PM, Pekka Enberg wrote:
Hello Sasha,
On Mon, Jun 10, 2013 at 10:18 PM, Sasha Levin wrote:
slab would still spew a warning when a big allocation happens with the
__GFP_NOWARN fleg is set. Prevent that to conform to __GFP_NOWARN.
Signed-off-by: Sasha Levin
---
Hello Sasha,
On Mon, Jun 10, 2013 at 10:18 PM, Sasha Levin wrote:
> slab would still spew a warning when a big allocation happens with the
> __GFP_NOWARN fleg is set. Prevent that to conform to __GFP_NOWARN.
>
> Signed-off-by: Sasha Levin
> ---
> mm/slab_common.c | 4 +++-
> 1 file changed, 3
slab would still spew a warning when a big allocation happens with the
__GFP_NOWARN fleg is set. Prevent that to conform to __GFP_NOWARN.
Signed-off-by: Sasha Levin
---
mm/slab_common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/slab_common.c b/mm/slab_common.c
slab would still spew a warning when a big allocation happens with the
__GFP_NOWARN fleg is set. Prevent that to conform to __GFP_NOWARN.
Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
mm/slab_common.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/slab_common.c
Hello Sasha,
On Mon, Jun 10, 2013 at 10:18 PM, Sasha Levin sasha.le...@oracle.com wrote:
slab would still spew a warning when a big allocation happens with the
__GFP_NOWARN fleg is set. Prevent that to conform to __GFP_NOWARN.
Signed-off-by: Sasha Levin sasha.le...@oracle.com
---
On 06/10/2013 03:31 PM, Pekka Enberg wrote:
Hello Sasha,
On Mon, Jun 10, 2013 at 10:18 PM, Sasha Levin sasha.le...@oracle.com wrote:
slab would still spew a warning when a big allocation happens with the
__GFP_NOWARN fleg is set. Prevent that to conform to __GFP_NOWARN.
Signed-off-by: Sasha
On Mon, 10 Jun 2013, Sasha Levin wrote:
[ 1691.807621] Call Trace:
[ 1691.809473] [83ff4041] dump_stack+0x4e/0x82
[ 1691.812783] [8111fe12] warn_slowpath_common+0x82/0xb0
[ 1691.817011] [8111fe55] warn_slowpath_null+0x15/0x20
[ 1691.819936] [81243dcf]
On 06/10/2013 07:40 PM, Christoph Lameter wrote:
On Mon, 10 Jun 2013, Sasha Levin wrote:
[ 1691.807621] Call Trace:
[ 1691.809473] [83ff4041] dump_stack+0x4e/0x82
[ 1691.812783] [8111fe12] warn_slowpath_common+0x82/0xb0
[ 1691.817011] [8111fe55]
44 matches
Mail list logo