On Fri 06-01-17 15:36:04, Vlastimil Babka wrote:
> On 01/04/2017 03:20 PM, Michal Hocko wrote:
> > diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> > index 2ff499680cc6..0a5cc1237afe 100644
> > --- a/net/netfilter/x_tables.c
> > +++ b/net/netfilter/x_tables.c
> > @@ -712,17 +712,8
On 01/04/2017 03:20 PM, Michal Hocko wrote:
> diff --git a/net/netfilter/x_tables.c b/net/netfilter/x_tables.c
> index 2ff499680cc6..0a5cc1237afe 100644
> --- a/net/netfilter/x_tables.c
> +++ b/net/netfilter/x_tables.c
> @@ -712,17 +712,8 @@ EXPORT_SYMBOL(xt_check_entry_offsets);
> */
> unsigned
On Fri 06-01-17 14:29:33, Vlastimil Babka wrote:
> On 01/02/2017 02:37 PM, Michal Hocko wrote:
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -514,18 +514,9 @@ long vhost_dev_set_owner(struct vhost_dev *dev)
> > }
> > EXPORT_SYMBOL_GPL(vhost_dev_set_owner);
> >
> > -stat
On 01/02/2017 02:37 PM, Michal Hocko wrote:
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -514,18 +514,9 @@ long vhost_dev_set_owner(struct vhost_dev *dev)
> }
> EXPORT_SYMBOL_GPL(vhost_dev_set_owner);
>
> -static void *vhost_kvzalloc(unsigned long size)
> -{
> - void *n
OK, so I've checked the open coded implementations and converted most of
them. There are few which are either confused and need some special
handling or need double checking.
I can fold this into the original patch or keep it as a separate patch.
Whatever works better for others.
---
>From 72a8493
On Tue 03-01-17 11:23:04, Vlastimil Babka wrote:
> On 01/02/2017 02:37 PM, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Using kmalloc with the vmalloc fallback for larger allocations is a
> > common pattern in the kernel code. Yet we do not have any common helper
> > for that and so users h
On 01/02/2017 02:37 PM, Michal Hocko wrote:
From: Michal Hocko
Using kmalloc with the vmalloc fallback for larger allocations is a
common pattern in the kernel code. Yet we do not have any common helper
for that and so users have invented their own helpers. Some of them are
really creative when
On Mon 02-01-17 07:55:22, Joe Perches wrote:
> On Mon, 2017-01-02 at 14:37 +0100, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Using kmalloc with the vmalloc fallback for larger allocations is a
> > common pattern in the kernel code. Yet we do not have any common helper
> > for that and so
On Mon, 2017-01-02 at 14:37 +0100, Michal Hocko wrote:
> From: Michal Hocko
>
> Using kmalloc with the vmalloc fallback for larger allocations is a
> common pattern in the kernel code. Yet we do not have any common helper
> for that and so users have invented their own helpers. Some of them are
>
From: Michal Hocko
Using kmalloc with the vmalloc fallback for larger allocations is a
common pattern in the kernel code. Yet we do not have any common helper
for that and so users have invented their own helpers. Some of them are
really creative when doing so. Let's just add kv[mz]alloc and make
It seems that this email didn't get delivered due to some stupid gmail
spam policy. Let me try to repost via a different relay. Sorry to those
who have seen the original message and get a duplicate now.
On Wed 21-12-16 08:03:53, Michal Hocko wrote:
> On Tue 20-12-16 14:13:41, Andrew Morton wrote:
On Tue, 20 Dec 2016 09:38:22 -0800 Joe Perches wrote:
> > So what are we going to do about this patch?
>
> Well if Andrew doesn't object again, it should probably be applied.
> Unless his silence here acts like a pocket-veto.
>
> Andrew? Anything to add?
I guess we should give in to reality a
On Tue, 2016-12-20 at 14:50 +0100, Michal Hocko wrote:
> On Wed 14-12-16 09:59:16, Michal Hocko wrote:
> > On Tue 13-12-16 14:07:33, Joe Perches wrote:
> > > On Tue, 2016-12-13 at 11:14 +0100, Michal Hocko wrote:
> > > > Are there any more comments or objections to this patch? Is this a good
> > >
On Wed 14-12-16 09:59:16, Michal Hocko wrote:
> On Tue 13-12-16 14:07:33, Joe Perches wrote:
> > On Tue, 2016-12-13 at 11:14 +0100, Michal Hocko wrote:
> > > Are there any more comments or objections to this patch? Is this a good
> > > start or kv[mz]alloc has to provide a way to cover GFP_NOFS use
On Tue 13-12-16 13:55:46, Andreas Dilger wrote:
> On Dec 13, 2016, at 3:14 AM, Michal Hocko wrote:
> >
> > Are there any more comments or objections to this patch? Is this a good
> > start or kv[mz]alloc has to provide a way to cover GFP_NOFS users as
> > well in the initial version.
>
> I'm in
On Tue 13-12-16 14:07:33, Joe Perches wrote:
> On Tue, 2016-12-13 at 11:14 +0100, Michal Hocko wrote:
> > Are there any more comments or objections to this patch? Is this a good
> > start or kv[mz]alloc has to provide a way to cover GFP_NOFS users as
> > well in the initial version.
>
> Did Andrew
On Tue, 2016-12-13 at 11:14 +0100, Michal Hocko wrote:
> Are there any more comments or objections to this patch? Is this a good
> start or kv[mz]alloc has to provide a way to cover GFP_NOFS users as
> well in the initial version.
Did Andrew Morton ever comment on this?
I believe he was the primar
On Dec 13, 2016, at 3:14 AM, Michal Hocko wrote:
>
> Are there any more comments or objections to this patch? Is this a good
> start or kv[mz]alloc has to provide a way to cover GFP_NOFS users as
> well in the initial version.
I'm in favour of this cleanup as a starting point. I definitely agre
Are there any more comments or objections to this patch? Is this a good
start or kv[mz]alloc has to provide a way to cover GFP_NOFS users as
well in the initial version.
On Thu 08-12-16 11:33:00, Michal Hocko wrote:
> From: Michal Hocko
>
> Using kmalloc with the vmalloc fallback for larger allo
On Fri 09-12-16 06:38:04, Al Viro wrote:
> On Fri, Dec 09, 2016 at 07:22:25AM +0100, Michal Hocko wrote:
>
> > > Easier to handle those in vmalloc() itself.
> >
> > I think there were some attempts in the past but some of the code paths
> > are burried too deep and adding gfp_mask all the way dow
On Fri, Dec 09, 2016 at 07:22:25AM +0100, Michal Hocko wrote:
> > Easier to handle those in vmalloc() itself.
>
> I think there were some attempts in the past but some of the code paths
> are burried too deep and adding gfp_mask all the way down there seemed
> like a major surgery.
No need to pr
On Fri 09-12-16 02:00:17, Al Viro wrote:
> On Fri, Dec 09, 2016 at 12:44:17PM +1100, Dave Chinner wrote:
> > On Thu, Dec 08, 2016 at 11:33:00AM +0100, Michal Hocko wrote:
> > > From: Michal Hocko
> > >
> > > Using kmalloc with the vmalloc fallback for larger allocations is a
> > > common pattern
On Fri 09-12-16 12:44:17, Dave Chinner wrote:
> On Thu, Dec 08, 2016 at 11:33:00AM +0100, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Using kmalloc with the vmalloc fallback for larger allocations is a
> > common pattern in the kernel code. Yet we do not have any common helper
> > for that
On Fri, Dec 09, 2016 at 12:44:17PM +1100, Dave Chinner wrote:
> On Thu, Dec 08, 2016 at 11:33:00AM +0100, Michal Hocko wrote:
> > From: Michal Hocko
> >
> > Using kmalloc with the vmalloc fallback for larger allocations is a
> > common pattern in the kernel code. Yet we do not have any common hel
On Thu, Dec 08, 2016 at 11:33:00AM +0100, Michal Hocko wrote:
> From: Michal Hocko
>
> Using kmalloc with the vmalloc fallback for larger allocations is a
> common pattern in the kernel code. Yet we do not have any common helper
> for that and so users have invented their own helpers. Some of the
On Thu 08-12-16 14:00:20, David Hildenbrand wrote:
> Am 08.12.2016 um 11:33 schrieb Michal Hocko:
> > From: Michal Hocko
> >
> > Using kmalloc with the vmalloc fallback for larger allocations is a
> > common pattern in the kernel code. Yet we do not have any common helper
> > for that and so user
Am 08.12.2016 um 11:33 schrieb Michal Hocko:
From: Michal Hocko
Using kmalloc with the vmalloc fallback for larger allocations is a
common pattern in the kernel code. Yet we do not have any common helper
for that and so users have invented their own helpers. Some of them are
really creative whe
From: Michal Hocko
Using kmalloc with the vmalloc fallback for larger allocations is a
common pattern in the kernel code. Yet we do not have any common helper
for that and so users have invented their own helpers. Some of them are
really creative when doing so. Let's just add kv[mz]alloc and make
28 matches
Mail list logo
