e is a
risk of harm IIUC and this is not much different than other fault
injecting paths.
--
Michal Hocko
SUSE Labs
would
explain why the kernel package cannot add a boot option. Maybe there are
some but I do not see them right now.
--
Michal Hocko
SUSE Labs
On Tue 24-04-18 13:28:49, Mikulas Patocka wrote:
>
>
> On Tue, 24 Apr 2018, Michal Hocko wrote:
>
> > On Tue 24-04-18 13:00:11, Mikulas Patocka wrote:
> > >
> > >
> > > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > >
&
On Tue 24-04-18 13:00:11, Mikulas Patocka wrote:
>
>
> On Tue, 24 Apr 2018, Michal Hocko wrote:
>
> > On Tue 24-04-18 11:50:30, Mikulas Patocka wrote:
> > >
> > >
> > > On Tue, 24 Apr 2018, Michal Hocko wrote:
> > >
&
On Tue 24-04-18 10:12:42, Michal Hocko wrote:
> On Tue 24-04-18 11:30:40, Mikulas Patocka wrote:
> >
> >
> > On Tue, 24 Apr 2018, Michal Hocko wrote:
> >
> > > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote:
> > >
> > > > Fixi
On Tue 24-04-18 11:50:30, Mikulas Patocka wrote:
>
>
> On Tue, 24 Apr 2018, Michal Hocko wrote:
>
> > On Mon 23-04-18 20:06:16, Mikulas Patocka wrote:
> > [...]
> > > @@ -404,6 +405,12 @@ void *kvmalloc_node(size_t size, gfp_t f
> > >*
On Tue 24-04-18 11:30:40, Mikulas Patocka wrote:
>
>
> On Tue, 24 Apr 2018, Michal Hocko wrote:
>
> > On Mon 23-04-18 20:25:15, Mikulas Patocka wrote:
> >
> > > Fixing __vmalloc code
> > > is easy and it doesn't require cooperation with main
On Mon 23-04-18 20:25:15, Mikulas Patocka wrote:
>
>
> On Mon, 23 Apr 2018, Michal Hocko wrote:
>
> > On Mon 23-04-18 10:06:08, Mikulas Patocka wrote:
> >
> > > > > He didn't want to fix vmalloc(GFP_NOIO)
> > > >
> > > > I do
; +#ifdef CONFIG_DEBUG_SG
> +do_vmalloc:
> +#endif
> return __vmalloc_node_flags_caller(size, node, flags,
> __builtin_return_address(0));
> }
--
Michal Hocko
SUSE Labs
04:54:53PM -0400, Mikulas Patocka wrote:
> > > > > On Fri, 20 Apr 2018, Michal Hocko wrote:
> > > > > > No way. This is just wrong! First of all, you will explode most
> > > > > > likely
> > > > > > on many allocations of small sizes. S
The testing people won't set it up. They install the "kernel-debug"
> package and run the tests in it.
>
> If you introduce a hidden option that no one knows about, no one will use
> it.
then make sure people know about it. Fuzzers already do test fault
injections.
--
Michal Hocko
SUSE Labs
On Sat 21-04-18 07:47:57, Matthew Wilcox wrote:
> On Fri, Apr 20, 2018 at 05:21:26PM -0400, Mikulas Patocka wrote:
> > On Fri, 20 Apr 2018, Matthew Wilcox wrote:
> > > On Fri, Apr 20, 2018 at 04:54:53PM -0400, Mikulas Patocka wrote:
> > > > On Fri, 20 Apr 2018, Michal
On Fri 20-04-18 06:41:36, Matthew Wilcox wrote:
> On Fri, Apr 20, 2018 at 03:08:52PM +0200, Michal Hocko wrote:
> > > In order to detect these bugs reliably I submit this patch that changes
> > > kvmalloc to always use vmalloc if CONFIG_DEBUG_VM is turned on.
> >
>
all sizes. Second, CONFIG_DEBUG_VM tends to be
enabled quite often.
> Signed-off-by: Mikulas Patocka <mpato...@redhat.com>
Nacked-by: Michal Hocko <mho...@suse.com>
> ---
> mm/util.c |2 ++
> 1 file changed, 2 insertions(+)
>
> Index: linux-2.6/mm/util.c
> =
On Wed 14-02-18 18:34:51, Jesper Dangaard Brouer wrote:
> On Wed, 14 Feb 2018 16:06:40 +0100
> Michal Hocko <mho...@kernel.org> wrote:
>
> > On Wed 14-02-18 22:17:34, Jason Wang wrote:
> > > There're several implications after commit 0bf7800f1799 ("ptr_rin
40cdb1f4cc8881...@syzkaller.appspotmail.com
> Fixes: 0bf7800f1799 ("ptr_ring: try vmalloc() when kmalloc() fails")
> Cc: Michal Hocko <mho...@kernel.org>
> Cc: Daniel Borkmann <dan...@iogearbox.net>
> Cc: Matthew Wilcox <wi...@infradead.org>
> Cc:
On Wed 14-02-18 19:47:30, Jason Wang wrote:
>
>
> On 2018年02月14日 17:28, Daniel Borkmann wrote:
> > [ +Jason, +Jesper ]
> >
> > On 02/14/2018 09:43 AM, Michal Hocko wrote:
> > > On Tue 13-02-18 18:55:33, Matthew Wilcox wrote:
> > > > On Tue
the MM people ;-)
Yes. kvmalloc (the vmalloc part) doesn't support GFP_ATOMIC semantic.
--
Michal Hocko
SUSE Labs
On Tue 30-01-18 11:27:45, Andrew Morton wrote:
> On Tue, 30 Jan 2018 15:01:04 +0100 Michal Hocko <mho...@kernel.org> wrote:
>
> > > Well, this is not about syzkaller, it merely pointed out a potential
> > > DoS... And that has to be addressed somehow.
> >
>
ETRY has been used for both kmalloc and vmalloc paths.
So it is more a quick band aid than a longterm solution.
[1] http://lkml.kernel.org/r/20180129165722.gf5...@breakpoint.cc
--
Michal Hocko
SUSE Labs
On Tue 30-01-18 15:01:11, Florian Westphal wrote:
> > From d48e950f1b04f234b57b9e34c363bdcfec10aeee Mon Sep 17 00:00:00 2001
> > From: Michal Hocko <mho...@suse.com>
> > Date: Tue, 30 Jan 2018 14:51:07 +0100
> > Subject: [PATCH] net/netfilter/x_tables.c: make allocat
On Tue 30-01-18 10:57:39, Michal Hocko wrote:
> On Tue 30-01-18 10:02:34, Dmitry Vyukov wrote:
> > On Tue, Jan 30, 2018 at 9:28 AM, Kirill A. Shutemov
> > <kir...@shutemov.name> wrote:
> > > On Tue, Jan 30, 2018 at 09:11:27AM +0100, Florian Westphal wrote:
> >
On Tue 30-01-18 10:02:34, Dmitry Vyukov wrote:
> On Tue, Jan 30, 2018 at 9:28 AM, Kirill A. Shutemov
> <kir...@shutemov.name> wrote:
> > On Tue, Jan 30, 2018 at 09:11:27AM +0100, Florian Westphal wrote:
> >> Michal Hocko <mho...@kernel.org> wrote:
> >> &g
On Tue 30-01-18 09:11:27, Florian Westphal wrote:
> Michal Hocko <mho...@kernel.org> wrote:
> > On Mon 29-01-18 23:35:22, Florian Westphal wrote:
> > > Kirill A. Shutemov <kir...@shutemov.name> wrote:
> > [...]
> > > > I hate what I'm saying, but I g
t wouldn't resolve it other than kill all tasks in the affected
memcg/container. Whether this is sufficient or not, I dunno. It sounds
quite suboptimal to me. But it is true this would be less tricky then
adding a global knob...
--
Michal Hocko
SUSE Labs
t; >
> > Just supressing OOM kill is a bad idea. We still leave a way to allocate
> > arbitrary large buffer in kernel.
>
> Isn't that what we do everywhere in network stack?
>
> I think we should try to allocate whatever amount of memory is needed
> for the given xtables ruleset, given that is what admin requested us to do.
If this is a root only thing then __GFP_NORETRY sounds like the most
straightforward way to go.
--
Michal Hocko
SUSE Labs
On Fri 15-09-17 18:12:15, Ben Hutchings wrote:
> On Thu, 2017-09-14 at 10:59 +0200, Michal Hocko wrote:
> > On Wed 13-09-17 18:58:13, Jorgen S. Hansen wrote:
> > [...]
> > > The patch series look good to me.
> >
> > Thanks for double checking. Ben, could you
On Wed 13-09-17 18:58:13, Jorgen S. Hansen wrote:
[...]
> The patch series look good to me.
Thanks for double checking. Ben, could you merge this to 3.16 stable
branch, please?
--
Michal Hocko
SUSE Labs
ockdep enabled.
Reviewed-by: Thomas Hellstrom <thellst...@vmware.com>
Signed-off-by: Jorgen Hansen <jhan...@vmware.com>
Signed-off-by: David S. Miller <da...@davemloft.net>
Signed-off-by: Michal Hocko <mho...@suse.com>
---
net/vmw_vsock/vmci_transport.c | 2 +-
1 file chang
d-by: Thomas Hellstrom <thellst...@vmware.com>
Signed-off-by: Jorgen Hansen <jhan...@vmware.com>
Signed-off-by: David S. Miller <da...@davemloft.net>
Signed-off-by: Michal Hocko <mho...@suse.com>
---
net/vmw_vsock/vmci_transport.c | 173 -
a peer on a different
socket would cause an active stream socket to register a detach.
Reviewed-by: George Zhang <georgezh...@vmware.com>
Signed-off-by: Jorgen Hansen <jhan...@vmware.com>
Signed-off-by: David S. Miller <da...@davemloft.net>
Signed-off-by: Michal Hocko <mho...@s
On Wed 13-09-17 15:07:26, Jorgen S. Hansen wrote:
>
> > On Sep 12, 2017, at 11:08 AM, Michal Hocko <mho...@kernel.org> wrote:
> >
> > Hi,
> > we are seeing the following splat with Debian 3.16 stable kernel
> >
> > BUG: scheduling while atomi
sport.h
@@ -119,10 +119,12 @@ struct vmci_transport {
u64 queue_pair_size;
u64 queue_pair_min_size;
u64 queue_pair_max_size;
- u32 attach_sub_id;
u32 detach_sub_id;
union vmci_transport_notify notify;
struct vmci_transport_notify_ops *notify_ops;
+ struct list_head elem;
+ struct sock *sk;
+ spinlock_t lock; /* protects sk. */
};
int vmci_transport_register(void);
--
Michal Hocko
SUSE Labs
On Mon 03-07-17 18:57:14, Mikulas Patocka wrote:
>
>
> On Mon, 3 Jul 2017, Michal Hocko wrote:
>
> > We can add a warning (or move it from kvmalloc) and hope that the
> > respective maintainers will fix those places properly. The reason I
> > didn't add t
On Fri 30-06-17 20:36:12, Mikulas Patocka wrote:
>
>
> On Fri, 30 Jun 2017, Michal Hocko wrote:
>
> > On Fri 30-06-17 14:11:57, Mikulas Patocka wrote:
> > >
> > >
> > > On Fri, 30 Jun 2017, Michal Hocko wrote:
> > >
&
On Fri 30-06-17 14:11:57, Mikulas Patocka wrote:
>
>
> On Fri, 30 Jun 2017, Michal Hocko wrote:
>
> > On Thu 29-06-17 22:25:09, Mikulas Patocka wrote:
> > > The __vmalloc function has a parameter gfp_mask with the allocation flags,
> > > however i
/*
> - * __vmalloc() will allocate data pages and auxillary structures (e.g.
> - * pagetables) with GFP_KERNEL, yet we may be under GFP_NOFS context
> - * here. Hence we need to tell memory reclaim that we are in such a
> - * context via PF_MEMALLOC_NOFS to prevent memory reclaim re-entering
> - * the filesystem here and potentially deadlocking.
> - */
> - if (flags & KM_NOFS)
> - nofs_flag = memalloc_nofs_save();
> -
> lflags = kmem_flags_convert(flags);
> ptr = __vmalloc(size, lflags | __GFP_ZERO, PAGE_KERNEL);
>
> - if (flags & KM_NOFS)
> - memalloc_nofs_restore(nofs_flag);
> -
> return ptr;
> }
>
--
Michal Hocko
SUSE Labs
On Thu 29-06-17 22:13:26, Mikulas Patocka wrote:
>
>
> On Thu, 29 Jun 2017, Michal Hocko wrote:
[...]
> > > Index: linux-2.6/kernel/bpf/syscall.c
> > > ===
> > > --- linux-2.6.orig/kernel/bpf/sysc
From: Michal Hocko <mho...@suse.com>
xgbe_map_rx_buffer is rather confused about what PAGE_ALLOC_COSTLY_ORDER
means. It uses PAGE_ALLOC_COSTLY_ORDER-1 assuming that
PAGE_ALLOC_COSTLY_ORDER is the first costly order which is not the case
actually because orders larger than that are
On Thu 06-04-17 09:33:44, Adrian Hunter wrote:
> On 05/04/17 14:39, Vlastimil Babka wrote:
> > On 04/05/2017 01:36 PM, Richard Weinberger wrote:
> >> Michal,
> >>
> >> Am 05.04.2017 um 13:31 schrieb Michal Hocko:
> >>> On Wed 05-04-17 09:47:0
On Wed 05-04-17 13:39:16, Vlastimil Babka wrote:
> On 04/05/2017 01:36 PM, Richard Weinberger wrote:
> > Michal,
> >
> > Am 05.04.2017 um 13:31 schrieb Michal Hocko:
> >> On Wed 05-04-17 09:47:00, Vlastimil Babka wrote:
> >>> Nandsim has own f
;
> - int err, memalloc;
> + int err;
> + unsigned int noreclaim_flag;
>
> err = get_pages(ns, file, count, pos);
> if (err)
> return err;
> - memalloc = set_memalloc();
> + noreclaim_flag = memalloc_noreclaim_save();
> tx = kernel_write(file, buf, count, pos);
> - clear_memalloc(memalloc);
> + memalloc_noreclaim_restore(noreclaim_flag);
> put_pages(ns);
> return tx;
> }
> --
> 2.12.2
--
Michal Hocko
SUSE Labs
, but the change makes it
> more
> robust.
>
> Suggested-by: Michal Hocko <mho...@suse.com>
> Signed-off-by: Vlastimil Babka <vba...@suse.cz>
One could argue that tsk_restore_flags() could be extended to provide
tsk_set_flags() and use it for all allocation related PF fl
@suse.com>
> Cc: Chris Leech <cle...@redhat.com>
> Cc: "David S. Miller" <da...@davemloft.net>
> Cc: Eric Dumazet <eduma...@google.com>
Acked-by: Michal Hocko <mho...@suse.com>
> ---
> drivers/block/nbd.c | 7 ---
> drivers/scsi/iscsi_t
in <aryabi...@virtuozzo.com>
> Signed-off-by: Vlastimil Babka <vba...@suse.cz>
> Cc: <sta...@vger.kernel.org>
Acked-by: Michal Hocko <mho...@suse.com>
> ---
> mm/page_alloc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/m
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:
> &g
From: Michal Hocko <mho...@suse.com>
fq_alloc_node, alloc_netdev_mqs and netif_alloc* open code kmalloc
with vmalloc fallback. Use the kvmalloc variant instead. Keep the
__GFP_REPEAT flag based on explanation from Eric:
"
At the time, tests on the hardware I had in my labs showed t
From: Michal Hocko <mho...@suse.com>
There are many code paths opencoding kvmalloc. Let's use the helper
instead. The main difference to kvmalloc is that those users are usually
not considering all the aspects of the memory allocator. E.g. allocation
requests <= 32kB (with
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 kvmall
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 an
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:
> > >
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 o
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/
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 c
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:
> > &g
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 stil
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 (parti
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 <mho...@kernel.org> wrote:
> > > On Wed 25-01-17 14:10:06, Michal Hocko wrote:
> > > > On Tue 24-01-1
On Wed 25-01-17 12:15:59, Vlastimil Babka wrote:
> On 01/24/2017 04:00 PM, Michal Hocko wrote:
> > > > Well, I am not opposed to kvmalloc_array but I would argue that this
> > > > conversion cannot introduce new overflow issues. The code would have
> > > > t
On Fri 20-01-17 14:41:37, Vlastimil Babka wrote:
> On 01/12/2017 06:37 PM, Michal Hocko wrote:
> > On Thu 12-01-17 09:26:09, Kees Cook wrote:
> >> On Thu, Jan 12, 2017 at 7:37 AM, Michal Hocko <mho...@kernel.org> wrote:
> > [...]
> >>> diff --git a/arch/s3
On Wed 18-01-17 14:18:50, Tejun Heo wrote:
> Hello, Michal.
>
> On Tue, Jan 17, 2017 at 02:58:30PM +0100, Michal Hocko wrote:
> > This would require using hierarchical cgroup iterators to iterate over
>
> It does behave hierarchically.
>
> > tasks. As per An
On Tue 17-01-17 14:32:04, Peter Zijlstra wrote:
> On Tue, Jan 17, 2017 at 02:03:03PM +0100, Michal Hocko wrote:
> > On Sun 15-01-17 20:19:01, Tejun Heo wrote:
> > [...]
> > > So, what's proposed is a proper part of bpf. In terms of
> > > implementation, cgr
force that the cgroup has to be a leaf one and no further
children groups can be created once there is BPF program attached?
This should break the existing usecases AFAIU and it would allow future
changes without major API surprises.
--
Michal Hocko
SUSE Labs
- rtn = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
- if (!rtn)
- rtn = vzalloc(size);
- return rtn;
+ return kvzalloc(GFP_KERNEL, size);
}
static inline u32 mlx5_base_mkey(const u32 key)
--
Michal Hocko
SUSE Labs
On Thu 12-01-17 09:26:09, Kees Cook wrote:
> On Thu, Jan 12, 2017 at 7:37 AM, Michal Hocko <mho...@kernel.org> wrote:
[...]
> > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> > index 4f74511015b8..e6bbb33d2956 100644
> > --- a/arch/s390/kvm/kvm-s39
Ilya has noticed that I've screwed up some k[zc]alloc conversions and
didn't use the kvzalloc. This is an updated patch with some acks
collected on the way
---
>From a7b89c6d0a3c685045e37740c8f97b065f37e0a4 Mon Sep 17 00:00:00 2001
From: Michal Hocko <mho...@suse.com>
Date: Wed, 4 Jan 2
On Thu 12-01-17 17:54:34, Ilya Dryomov wrote:
> On Thu, Jan 12, 2017 at 4:37 PM, Michal Hocko <mho...@kernel.org> wrote:
> > From: Michal Hocko <mho...@suse.com>
> >
> > There are many code paths opencoding kvmalloc. Let's use the helper
> > instead. The ma
From: Michal Hocko <mho...@suse.com>
fq_alloc_node, alloc_netdev_mqs and netif_alloc* open code kmalloc
with vmalloc fallback. Use the kvmalloc variant instead. Keep the
__GFP_REPEAT flag based on explanation from Eric:
"
At the time, tests on the hardware I had in my labs showed t
From: Michal Hocko <mho...@suse.com>
There are many code paths opencoding kvmalloc. Let's use the helper
instead. The main difference to kvmalloc is that those users are usually
not considering all the aspects of the memory allocator. E.g. allocation
requests < 64kB are basically neve
alloc_get(sk), skb->truesize);
> - atomic_add(skb->truesize, >sk_wmem_alloc);
> + skb = alloc_skb(size, GFP_KERNEL);
> + if (skb) {
> + pr_debug("%d += %d\n", sk_wmem_alloc_get(sk), skb->truesize);
> + atomic_add(skb->truesize, >sk_wmem_alloc);
> + }
> return skb;
> }
>
> --
> 2.5.5
--
Michal Hocko
SUSE Labs
On Wed 11-01-17 20:45:25, Michal Hocko wrote:
> On Wed 11-01-17 09:37:06, Chas Williams wrote:
> > On Mon, 2017-01-09 at 18:20 +0100, Andrey Konovalov wrote:
> > > Hi!
> > >
> > > I've got the following error report while running the syzk
debug("%d += %d\n", sk_wmem_alloc_get(sk), skb->truesize);
> atomic_add(skb->truesize, >sk_wmem_alloc);
Blee, this code is just horrendous. But the "fix" is obviously broken!
schedule() is just a noop if you do not change the task state and what
you are just asking for is a never failing non sleeping allocation - aka
a busy loop in the kernel!
--
Michal Hocko
SUSE Labs
; unsigned int *xt_alloc_entry_offsets(unsigned int size)
> {
> if (size < (SIZE_MAX / sizeof(unsigned int)))
> - return kvmalloc(size * sizeof(unsigned int), GFP_KERNEL);;
> + return kvmalloc(size * sizeof(unsigned int), GFP_KERNEL);
>
> return NULL;
>
--
Michal Hocko
SUSE Labs
he root.)
>
> So from what I understand the proposed cgroup is not in fact
> hierarchical at all.
>
> @TJ, I thought you were enforcing all new cgroups to be properly
> hierarchical, that would very much include this one.
I would be interested in that as well. We have made that mistake in
From: Michal Hocko <mho...@suse.com>
Andrey Konovalov has reported the following warning triggered by
the syzkaller fuzzer.
WARNING: CPU: 1 PID: 9935 at mm/page_alloc.c:3511
__alloc_pages_nodemask+0x159c/0x1e20
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 9935 Com
Hi,
this is the second version of the patchset previously posted here [1].
Alexei has insisted on the patches reordering which I've done in this
series. I've also updated the changelog of the second patch to mention
why KMALLOC_SHIFT_MAX has been used.
Andrey has revealed a discrepancy between
From: Michal Hocko <mho...@suse.com>
01b3f52157ff ("bpf: fix allocation warnings in bpf maps and integer
overflow") has added checks for the maximum allocateable size. It
(ab)used KMALLOC_SHIFT_MAX for that purpose. While this is not incorrect
it is not very clean because
On Fri 16-12-16 16:28:21, Alexei Starovoitov wrote:
> On Sat, Dec 17, 2016 at 12:39:17AM +0100, Michal Hocko wrote:
> > On Fri 16-12-16 15:23:42, Alexei Starovoitov wrote:
> > > On Fri, Dec 16, 2016 at 11:02:35PM +0100, Michal Hocko wrote:
> > > > On Fri 16-12-16 10:0
On Fri 16-12-16 15:23:42, Alexei Starovoitov wrote:
> On Fri, Dec 16, 2016 at 11:02:35PM +0100, Michal Hocko wrote:
> > On Fri 16-12-16 10:02:10, Alexei Starovoitov wrote:
> > > On Thu, Dec 15, 2016 at 05:47:21PM +0100, Michal Hocko wrote:
> > > > From:
On Fri 16-12-16 10:02:10, Alexei Starovoitov wrote:
> On Thu, Dec 15, 2016 at 05:47:21PM +0100, Michal Hocko wrote:
> > From: Michal Hocko <mho...@suse.com>
> >
> > 01b3f52157ff ("bpf: fix allocation warnings in bpf maps and integer
> > overflow") ha
On Wed 19-10-16 10:23:55, Dave Hansen wrote:
> On 10/19/2016 10:01 AM, Michal Hocko wrote:
> > The question I had earlier was whether this has to be an explicit FOLL
> > flag used by g-u-p users or we can just use it internally when mm !=
> > current->mm
>
>
On Wed 19-10-16 09:49:43, Dave Hansen wrote:
> On 10/19/2016 02:07 AM, Michal Hocko wrote:
> > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
> >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> >>> I am wondering whether we can go further. E.g. it i
On Wed 19-10-16 10:06:46, Lorenzo Stoakes wrote:
> On Wed, Oct 19, 2016 at 10:52:05AM +0200, Michal Hocko wrote:
> > yes this is the desirable and expected behavior.
> >
> > > wonder if this is desirable behaviour or whether this ought to be limited
> > > to
>
On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> > I am wondering whether we can go further. E.g. it is not really clear to
> > me whether we need an explicit FOLL_REMOTE when we can in fact check
> > mm !=
would require
FOLL_FORCE for access_remote_vm? I mean FOLL_FORCE is a really
non-trivial thing. It doesn't obey vma permissions so we should really
minimize its usage. Do all of those users really need FOLL_FORCE?
Anyway I would rather see the flag explicit and used at more places than
hidden behind a helper function.
--
Michal Hocko
SUSE Labs
On Wed 19-10-16 09:40:45, Lorenzo Stoakes wrote:
> On Wed, Oct 19, 2016 at 10:13:52AM +0200, Michal Hocko wrote:
> > On Wed 19-10-16 09:59:03, Jan Kara wrote:
> > > On Thu 13-10-16 01:20:18, Lorenzo Stoakes wrote:
> > > > This patch removes the write par
_FORCE users was always a nightmare
and the flag behavior is really subtle so we should better be explicit
about it. I haven't gone through each patch separately but rather
applied the whole series and checked the resulting diff. This all seems
OK to me and feel free to add
Acked-by: Michal Hocko <mho
imil Babka <vba...@suse.cz>
Yes this makes sense to me. It could be argued that this could be
simplified to not rely on high order allocations at all but this is
simple enough (and backportable to stable trees) and should work
reasonably well.
So FWIW
Acked-by: Michal Hocko <mho...@suse.com>
mem_cgroup_sockets_enabled)
> - sock_update_memcg(sk);
> sk_sockets_allocated_inc(sk);
> local_bh_enable();
> }
> diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
> index 04b989328558..b8fc74a66299 100644
> --- a/net/ipv4/tcp_ipv4.c
> +++ b/net/ipv4/tcp_ipv4.c
> @@ -1872,9 +1872,6 @@ void tcp_v4_destroy_sock(struct sock *sk)
> local_bh_disable();
> sk_sockets_allocated_dec(sk);
> local_bh_enable();
> -
> - if (mem_cgroup_sockets_enabled && sk->sk_memcg)
> - sock_release_memcg(sk);
> }
> EXPORT_SYMBOL(tcp_v4_destroy_sock);
>
> --
> 2.9.3
--
Michal Hocko
SUSE Labs
w_smp_processor_id();
> atomic64_set(>sk_cookie, 0);
> +
> + cgroup_sk_alloc(>sk_cgrp_data);
> +
> /*
>* Before updating sk_refcnt, we must commit prior changes to
> memory
>* (Documentation/RCU/rculist_nulls.txt for details)
> --
> 2.9.3
--
Michal Hocko
SUSE Labs
oller")
> Cc: <sta...@vger.kernel.org> # 4.5+
> Signed-off-by: Johannes Weiner <han...@cmpxchg.org>
Acked-by: Michal Hocko <mho...@suse.com>
> ---
> mm/memcontrol.c | 31 ++-
> 1 file changed, 22 insertions(+), 9 deletions(-)
>
&g
f it) accounting enabled. Whether we account
also netns related data structures sufficiently is a question. I haven't
checked. But it would be worth trying and fix.
--
Michal Hocko
SUSE Labs
ncharge(>tcp_mem.memory_allocated, nr_pages);
> +#ifdef CONFIG_MEMCG_KMEM
> + if (!cgroup_subsys_on_dfl(memory_cgrp_subsys)) {
> + page_counter_uncharge(>tcp_mem.memory_allocated,
> + nr_pages);
> + return;
> +
On Wed 02-12-15 22:43:31, Chris Snook wrote:
> On Tue, Dec 1, 2015 at 12:35 PM David Miller <da...@davemloft.net> wrote:
>
> > From: Michal Hocko <mho...@kernel.org>
> > Date: Mon, 30 Nov 2015 14:21:29 +0100
> >
> > > On Sat 28-11-15 15:51:13, P
called from .open() function, and
> already uses GFP_KERNEL, so this change is safe.
Thanks for updating the changelog
> Signed-off-by: Pavel Machek <pa...@ucw.cz>
Acked-by: Michal Hocko <mho...@suse.com>
>
> diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main
gned-off-by: Pavel Machek <pa...@ucw.cz>
Anyway
Reviewed-by: Michal Hocko <mho...@suse.com>
>
> diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> b/drivers/net/ethernet/atheros/atl1c/atl1c_main.c
> index 2795d6d..afb71e0 100644
> --- a/drivers/net/ethernet/a
OSTLY_ORDER but it would increase chances
considerably. Also a vmalloc fallback can be used then more safely.
> if (unlikely(!ring_header->desc)) {
> dev_err(>dev, "pci_alloc_consistend failed\n");
> goto err_nomem;
> }
>
>
ip_rcv
> __netif_receive_skb_core
> __netif_receive_skb
> netif_receive_skb_internal
> napi_gro_complete
>
> The runs vary too much for this to be measurable in elapsed time.
--
Michal Hocko
SUSE Labs
--
To un
On Mon 16-11-15 13:18:10, Johannes Weiner wrote:
> On Mon, Nov 16, 2015 at 04:59:25PM +0100, Michal Hocko wrote:
> > On Thu 12-11-15 18:41:32, Johannes Weiner wrote:
> > > Socket memory can be a significant share of overall memory consumed by
> > > common workloads. In
nosocket should be documented (at least in
Documentation/kernel-parameters.txt)
Other than that
Acked-by: Michal Hocko <mho...@suse.com>
> ---
> include/linux/memcontrol.h | 12 -
> mm/memcontrol.c| 131
> +
> 2
1 - 100 of 124 matches
Mail list logo
