Is there anything more to be done before this can get merged? I would
relly like to target this to the next merge window. I already have some
more changes which depend on this.
--
Michal Hocko
SUSE Labs
Is there anything more to be done before this can get merged? I would
relly like to target this to the next merge window. I already have some
more changes which depend on this.
--
Michal Hocko
SUSE Labs
On 01/30/2017 05:28 PM, Michal Hocko wrote:
On Mon 30-01-17 17:15:08, Daniel Borkmann wrote:
On 01/30/2017 08:56 AM, Michal Hocko wrote:
On Fri 27-01-17 21:12:26, Daniel Borkmann wrote:
On 01/27/2017 11:05 AM, Michal Hocko wrote:
On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
[...]
So to
On 01/30/2017 05:28 PM, Michal Hocko wrote:
On Mon 30-01-17 17:15:08, Daniel Borkmann wrote:
On 01/30/2017 08:56 AM, Michal Hocko wrote:
On Fri 27-01-17 21:12:26, Daniel Borkmann wrote:
On 01/27/2017 11:05 AM, Michal Hocko wrote:
On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
[...]
So to
On 01/30/2017 08:56 AM, Michal Hocko wrote:
On Fri 27-01-17 21:12:26, Daniel Borkmann wrote:
On 01/27/2017 11:05 AM, Michal Hocko wrote:
On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
[...]
So to answer your second email with the bpf and netfilter hunks, why
not replacing them with
On 01/30/2017 08:56 AM, Michal Hocko wrote:
On Fri 27-01-17 21:12:26, Daniel Borkmann wrote:
On 01/27/2017 11:05 AM, Michal Hocko wrote:
On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
[...]
So to answer your second email with the bpf and netfilter hunks, why
not replacing them with
On Mon 30-01-17 17:15:08, Daniel Borkmann wrote:
> On 01/30/2017 08:56 AM, Michal Hocko wrote:
> > On Fri 27-01-17 21:12:26, Daniel Borkmann wrote:
> > > On 01/27/2017 11:05 AM, Michal Hocko wrote:
> > > > On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
> > [...]
> > > > > So to answer your
On Mon 30-01-17 17:15:08, Daniel Borkmann wrote:
> On 01/30/2017 08:56 AM, Michal Hocko wrote:
> > On Fri 27-01-17 21:12:26, Daniel Borkmann wrote:
> > > On 01/27/2017 11:05 AM, Michal Hocko wrote:
> > > > On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
> > [...]
> > > > > So to answer your
Hi,
this has been previously posted here [1] and it received quite some
feedback. As a result the number of patches has grown again. We are at
9 patches right now. I have rebased the series on top of the current
next-20170130. There were some changes since the last posting, namely
a7f6c1b63b86
Hi,
this has been previously posted here [1] and it received quite some
feedback. As a result the number of patches has grown again. We are at
9 patches right now. I have rebased the series on top of the current
next-20170130. There were some changes since the last posting, namely
a7f6c1b63b86
On Fri 27-01-17 21:12:26, Daniel Borkmann wrote:
> On 01/27/2017 11:05 AM, Michal Hocko wrote:
> > On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
[...]
> > > So to answer your second email with the bpf and netfilter hunks, why
> > > not replacing them with kvmalloc() and __GFP_NORETRY flag and
On Fri 27-01-17 21:12:26, Daniel Borkmann wrote:
> On 01/27/2017 11:05 AM, Michal Hocko wrote:
> > On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
[...]
> > > So to answer your second email with the bpf and netfilter hunks, why
> > > not replacing them with kvmalloc() and __GFP_NORETRY flag and
On 01/27/2017 11:05 AM, Michal Hocko wrote:
On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
On 01/26/2017 02:40 PM, Michal Hocko wrote:
[...]
But realistically, how big is this problem really? Is it really worth
it? You said this is an admin only interface and admin can kill the
machine by
On 01/27/2017 11:05 AM, Michal Hocko wrote:
On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
On 01/26/2017 02:40 PM, Michal Hocko wrote:
[...]
But realistically, how big is this problem really? Is it really worth
it? You said this is an admin only interface and admin can kill the
machine by
On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
> On 01/26/2017 02:40 PM, Michal Hocko wrote:
[...]
> > But realistically, how big is this problem really? Is it really worth
> > it? You said this is an admin only interface and admin can kill the
> > machine by OOM and other means already.
> >
>
On Thu 26-01-17 21:34:04, Daniel Borkmann wrote:
> On 01/26/2017 02:40 PM, Michal Hocko wrote:
[...]
> > But realistically, how big is this problem really? Is it really worth
> > it? You said this is an admin only interface and admin can kill the
> > machine by OOM and other means already.
> >
>
On 01/26/2017 02:40 PM, Michal Hocko wrote:
On Thu 26-01-17 14:10:06, Daniel Borkmann wrote:
On 01/26/2017 12:58 PM, Michal Hocko wrote:
On Thu 26-01-17 12:33:55, Daniel Borkmann wrote:
On 01/26/2017 11:08 AM, Michal Hocko wrote:
[...]
If you disagree I can drop the bpf part of course...
On 01/26/2017 02:40 PM, Michal Hocko wrote:
On Thu 26-01-17 14:10:06, Daniel Borkmann wrote:
On 01/26/2017 12:58 PM, Michal Hocko wrote:
On Thu 26-01-17 12:33:55, Daniel Borkmann wrote:
On 01/26/2017 11:08 AM, Michal Hocko wrote:
[...]
If you disagree I can drop the bpf part of course...
On Thu 26-01-17 14:40:04, Michal Hocko wrote:
> On Thu 26-01-17 14:10:06, Daniel Borkmann wrote:
> > On 01/26/2017 12:58 PM, Michal Hocko wrote:
> > > On Thu 26-01-17 12:33:55, Daniel Borkmann wrote:
> > > > On 01/26/2017 11:08 AM, Michal Hocko wrote:
> > > [...]
> > > > > If you disagree I can
On Thu 26-01-17 14:40:04, Michal Hocko wrote:
> On Thu 26-01-17 14:10:06, Daniel Borkmann wrote:
> > On 01/26/2017 12:58 PM, Michal Hocko wrote:
> > > On Thu 26-01-17 12:33:55, Daniel Borkmann wrote:
> > > > On 01/26/2017 11:08 AM, Michal Hocko wrote:
> > > [...]
> > > > > If you disagree I can
On Thu 26-01-17 14:10:06, Daniel Borkmann wrote:
> On 01/26/2017 12:58 PM, Michal Hocko wrote:
> > On Thu 26-01-17 12:33:55, Daniel Borkmann wrote:
> > > On 01/26/2017 11:08 AM, Michal Hocko wrote:
> > [...]
> > > > If you disagree I can drop the bpf part of course...
> > >
> > > If we could
On Thu 26-01-17 14:10:06, Daniel Borkmann wrote:
> On 01/26/2017 12:58 PM, Michal Hocko wrote:
> > On Thu 26-01-17 12:33:55, Daniel Borkmann wrote:
> > > On 01/26/2017 11:08 AM, Michal Hocko wrote:
> > [...]
> > > > If you disagree I can drop the bpf part of course...
> > >
> > > If we could
On 01/26/2017 12:58 PM, Michal Hocko wrote:
On Thu 26-01-17 12:33:55, Daniel Borkmann wrote:
On 01/26/2017 11:08 AM, Michal Hocko wrote:
[...]
If you disagree I can drop the bpf part of course...
If we could consolidate these spots with kvmalloc() eventually, I'm
all for it. But even if
On 01/26/2017 12:58 PM, Michal Hocko wrote:
On Thu 26-01-17 12:33:55, Daniel Borkmann wrote:
On 01/26/2017 11:08 AM, Michal Hocko wrote:
[...]
If you disagree I can drop the bpf part of course...
If we could consolidate these spots with kvmalloc() eventually, I'm
all for it. But even if
On Thu 26-01-17 04:14:37, Joe Perches wrote:
> On Thu, 2017-01-26 at 11:32 +0100, Michal Hocko wrote:
> > So I have folded the following to the patch 1. It is in line with
> > kvmalloc and hopefully at least tell more than the current code.
> []
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> []
>
On Thu 26-01-17 04:14:37, Joe Perches wrote:
> On Thu, 2017-01-26 at 11:32 +0100, Michal Hocko wrote:
> > So I have folded the following to the patch 1. It is in line with
> > kvmalloc and hopefully at least tell more than the current code.
> []
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> []
>
On Thu, 2017-01-26 at 11:32 +0100, Michal Hocko wrote:
> So I have folded the following to the patch 1. It is in line with
> kvmalloc and hopefully at least tell more than the current code.
[]
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
[]
> @@ -1741,6 +1741,13 @@ void
On Thu, 2017-01-26 at 11:32 +0100, Michal Hocko wrote:
> So I have folded the following to the patch 1. It is in line with
> kvmalloc and hopefully at least tell more than the current code.
[]
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
[]
> @@ -1741,6 +1741,13 @@ void
On Thu 26-01-17 12:33:55, Daniel Borkmann wrote:
> On 01/26/2017 11:08 AM, Michal Hocko wrote:
[...]
> > If you disagree I can drop the bpf part of course...
>
> If we could consolidate these spots with kvmalloc() eventually, I'm
> all for it. But even if __GFP_NORETRY is not covered down to all
On Thu 26-01-17 12:33:55, Daniel Borkmann wrote:
> On 01/26/2017 11:08 AM, Michal Hocko wrote:
[...]
> > If you disagree I can drop the bpf part of course...
>
> If we could consolidate these spots with kvmalloc() eventually, I'm
> all for it. But even if __GFP_NORETRY is not covered down to all
On Thu 26-01-17 12:04:13, Daniel Borkmann wrote:
> On 01/26/2017 11:32 AM, Michal Hocko wrote:
> > On Thu 26-01-17 11:08:02, Michal Hocko wrote:
> > > On Thu 26-01-17 10:36:49, Daniel Borkmann wrote:
> > > > On 01/26/2017 08:43 AM, Michal Hocko wrote:
> > > > > On Wed 25-01-17 21:16:42, Daniel
On Thu 26-01-17 12:04:13, Daniel Borkmann wrote:
> On 01/26/2017 11:32 AM, Michal Hocko wrote:
> > On Thu 26-01-17 11:08:02, Michal Hocko wrote:
> > > On Thu 26-01-17 10:36:49, Daniel Borkmann wrote:
> > > > On 01/26/2017 08:43 AM, Michal Hocko wrote:
> > > > > On Wed 25-01-17 21:16:42, Daniel
On 01/26/2017 11:08 AM, Michal Hocko wrote:
On Thu 26-01-17 10:36:49, Daniel Borkmann wrote:
On 01/26/2017 08:43 AM, Michal Hocko wrote:
On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
[...]
I assume that kvzalloc() is still the same from [1], right? If so, then
it would unfortunately
On 01/26/2017 11:08 AM, Michal Hocko wrote:
On Thu 26-01-17 10:36:49, Daniel Borkmann wrote:
On 01/26/2017 08:43 AM, Michal Hocko wrote:
On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
[...]
I assume that kvzalloc() is still the same from [1], right? If so, then
it would unfortunately
On 01/26/2017 11:32 AM, Michal Hocko wrote:
On Thu 26-01-17 11:08:02, Michal Hocko wrote:
On Thu 26-01-17 10:36:49, Daniel Borkmann wrote:
On 01/26/2017 08:43 AM, Michal Hocko wrote:
On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
[...]
I assume that kvzalloc() is still the same from [1],
On 01/26/2017 11:32 AM, Michal Hocko wrote:
On Thu 26-01-17 11:08:02, Michal Hocko wrote:
On Thu 26-01-17 10:36:49, Daniel Borkmann wrote:
On 01/26/2017 08:43 AM, Michal Hocko wrote:
On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
[...]
I assume that kvzalloc() is still the same from [1],
On Thu 26-01-17 11:08:02, Michal Hocko wrote:
> On Thu 26-01-17 10:36:49, Daniel Borkmann wrote:
> > On 01/26/2017 08:43 AM, Michal Hocko wrote:
> > > On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
> [...]
> > > > I assume that kvzalloc() is still the same from [1], right? If so, then
> > > > it
On Thu 26-01-17 11:08:02, Michal Hocko wrote:
> On Thu 26-01-17 10:36:49, Daniel Borkmann wrote:
> > On 01/26/2017 08:43 AM, Michal Hocko wrote:
> > > On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
> [...]
> > > > I assume that kvzalloc() is still the same from [1], right? If so, then
> > > > it
On Thu 26-01-17 10:36:49, Daniel Borkmann wrote:
> On 01/26/2017 08:43 AM, Michal Hocko wrote:
> > On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
[...]
> > > I assume that kvzalloc() is still the same from [1], right? If so, then
> > > it would unfortunately (partially) reintroduce the issue
On Thu 26-01-17 10:36:49, Daniel Borkmann wrote:
> On 01/26/2017 08:43 AM, Michal Hocko wrote:
> > On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
[...]
> > > I assume that kvzalloc() is still the same from [1], right? If so, then
> > > it would unfortunately (partially) reintroduce the issue
From: Daniel Borkmann
> Sent: 26 January 2017 09:37
...
> >> I assume that kvzalloc() is still the same from [1], right? If so, then
> >> it would unfortunately (partially) reintroduce the issue that was fixed.
> >> If you look above at flags, they're also passed to __vmalloc() to not
> >> trigger
From: Daniel Borkmann
> Sent: 26 January 2017 09:37
...
> >> I assume that kvzalloc() is still the same from [1], right? If so, then
> >> it would unfortunately (partially) reintroduce the issue that was fixed.
> >> If you look above at flags, they're also passed to __vmalloc() to not
> >> trigger
On 01/26/2017 08:43 AM, Michal Hocko wrote:
On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
On 01/25/2017 07:14 PM, Alexei Starovoitov wrote:
On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote:
On Wed 25-01-17 14:10:06, Michal Hocko wrote:
On Tue 24-01-17 11:17:21,
On 01/26/2017 08:43 AM, Michal Hocko wrote:
On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
On 01/25/2017 07:14 PM, Alexei Starovoitov wrote:
On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote:
On Wed 25-01-17 14:10:06, Michal Hocko wrote:
On Tue 24-01-17 11:17:21, Alexei Starovoitov
On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
> On 01/25/2017 07:14 PM, Alexei Starovoitov wrote:
> > On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote:
> > > On Wed 25-01-17 14:10:06, Michal Hocko wrote:
> > > > On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
> [...]
On Wed 25-01-17 21:16:42, Daniel Borkmann wrote:
> On 01/25/2017 07:14 PM, Alexei Starovoitov wrote:
> > On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote:
> > > On Wed 25-01-17 14:10:06, Michal Hocko wrote:
> > > > On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
> [...]
> > > > > > Are
On 01/25/2017 07:14 PM, Alexei Starovoitov wrote:
On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote:
On Wed 25-01-17 14:10:06, Michal Hocko wrote:
On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
[...]
Are there any more comments? I would really appreciate to hear
On 01/25/2017 07:14 PM, Alexei Starovoitov wrote:
On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote:
On Wed 25-01-17 14:10:06, Michal Hocko wrote:
On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
[...]
Are there any more comments? I would really appreciate to hear from
networking folks
On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote:
> On Wed 25-01-17 14:10:06, Michal Hocko wrote:
>> On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
>> > On Tue, Jan 24, 2017 at 04:17:52PM +0100, Michal Hocko wrote:
>> > > On Thu 12-01-17 16:37:11, Michal Hocko wrote:
>>
On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko wrote:
> On Wed 25-01-17 14:10:06, Michal Hocko wrote:
>> On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
>> > On Tue, Jan 24, 2017 at 04:17:52PM +0100, Michal Hocko wrote:
>> > > On Thu 12-01-17 16:37:11, Michal Hocko wrote:
>> > > > Hi,
>> > > >
On Wed 25-01-17 14:10:06, Michal Hocko wrote:
> On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
> > On Tue, Jan 24, 2017 at 04:17:52PM +0100, Michal Hocko wrote:
> > > On Thu 12-01-17 16:37:11, Michal Hocko wrote:
> > > > Hi,
> > > > this has been previously posted as a single patch [1] but
On Wed 25-01-17 14:10:06, Michal Hocko wrote:
> On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
> > On Tue, Jan 24, 2017 at 04:17:52PM +0100, Michal Hocko wrote:
> > > On Thu 12-01-17 16:37:11, Michal Hocko wrote:
> > > > Hi,
> > > > this has been previously posted as a single patch [1] but
On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
> On Tue, Jan 24, 2017 at 04:17:52PM +0100, Michal Hocko wrote:
> > On Thu 12-01-17 16:37:11, Michal Hocko wrote:
> > > Hi,
> > > this has been previously posted as a single patch [1] but later on more
> > > built on top. It turned out that there
On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
> On Tue, Jan 24, 2017 at 04:17:52PM +0100, Michal Hocko wrote:
> > On Thu 12-01-17 16:37:11, Michal Hocko wrote:
> > > Hi,
> > > this has been previously posted as a single patch [1] but later on more
> > > built on top. It turned out that there
On Tue 24-01-17 08:00:26, Eric Dumazet wrote:
> On Tue, 2017-01-24 at 16:17 +0100, Michal Hocko wrote:
> > On Thu 12-01-17 16:37:11, Michal Hocko wrote:
>
> > Are there any more comments? I would really appreciate to hear from
> > networking folks before I resubmit the series.
>
> I do not see
On Tue 24-01-17 08:00:26, Eric Dumazet wrote:
> On Tue, 2017-01-24 at 16:17 +0100, Michal Hocko wrote:
> > On Thu 12-01-17 16:37:11, Michal Hocko wrote:
>
> > Are there any more comments? I would really appreciate to hear from
> > networking folks before I resubmit the series.
>
> I do not see
On Tue, Jan 24, 2017 at 04:17:52PM +0100, Michal Hocko wrote:
> On Thu 12-01-17 16:37:11, Michal Hocko wrote:
> > Hi,
> > this has been previously posted as a single patch [1] but later on more
> > built on top. It turned out that there are users who would like to have
> > __GFP_REPEAT semantic.
On Tue, Jan 24, 2017 at 04:17:52PM +0100, Michal Hocko wrote:
> On Thu 12-01-17 16:37:11, Michal Hocko wrote:
> > Hi,
> > this has been previously posted as a single patch [1] but later on more
> > built on top. It turned out that there are users who would like to have
> > __GFP_REPEAT semantic.
On Tue, 2017-01-24 at 16:17 +0100, Michal Hocko wrote:
> On Thu 12-01-17 16:37:11, Michal Hocko wrote:
> Are there any more comments? I would really appreciate to hear from
> networking folks before I resubmit the series.
I do not see any issues right now.
I am happy to see this thing finally
On Tue, 2017-01-24 at 16:17 +0100, Michal Hocko wrote:
> On Thu 12-01-17 16:37:11, Michal Hocko wrote:
> Are there any more comments? I would really appreciate to hear from
> networking folks before I resubmit the series.
I do not see any issues right now.
I am happy to see this thing finally
On Thu 12-01-17 16:37:11, Michal Hocko wrote:
> Hi,
> this has been previously posted as a single patch [1] but later on more
> built on top. It turned out that there are users who would like to have
> __GFP_REPEAT semantic. This is currently implemented for costly >64B
> requests. Doing the same
On Thu 12-01-17 16:37:11, Michal Hocko wrote:
> Hi,
> this has been previously posted as a single patch [1] but later on more
> built on top. It turned out that there are users who would like to have
> __GFP_REPEAT semantic. This is currently implemented for costly >64B
> requests. Doing the same
Hi,
this has been previously posted as a single patch [1] but later on more
built on top. It turned out that there are users who would like to have
__GFP_REPEAT semantic. This is currently implemented for costly >64B
requests. Doing the same for smaller requests would require to redefine
Hi,
this has been previously posted as a single patch [1] but later on more
built on top. It turned out that there are users who would like to have
__GFP_REPEAT semantic. This is currently implemented for costly >64B
requests. Doing the same for smaller requests would require to redefine
64 matches
Mail list logo