From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Michael S. Tsirkin" Subject: Re: [PATCH net V3 2/2] ptr_ring: fail on large queue size (>64K) Date: Thu, 8 Feb 2018 06:52:39 +0200 Message-ID: <20180208064602-mutt-send-email-mst@kernel.org> References: <1518062365-8596-1-git-send-email-jasowang@redhat.com> <1518062365-8596-2-git-send-email-jasowang@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: netdev@vger.kernel.org To: Jason Wang Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:48086 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750810AbeBHEwk (ORCPT ); Wed, 7 Feb 2018 23:52:40 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A8B014022906 for ; Thu, 8 Feb 2018 04:52:39 +0000 (UTC) Content-Disposition: inline In-Reply-To: <1518062365-8596-2-git-send-email-jasowang@redhat.com> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Feb 08, 2018 at 11:59:25AM +0800, Jason Wang wrote: > We need limit the maximum size of queue, otherwise it may cause > several side effects e.g slab will warn when the size exceeds > KMALLOC_MAX_SIZE. Using KMALLOC_MAX_SIZE still looks too so this patch > tries to limit it to 64K. This value could be revisited if we found a > real case that needs more. > > Reported-by: syzbot+e4d4f9ddd4295539735d@syzkaller.appspotmail.com > Fixes: 2e0ab8ca83c12 ("ptr_ring: array based FIFO for pointers") > Signed-off-by: Jason Wang > --- > include/linux/ptr_ring.h | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/include/linux/ptr_ring.h b/include/linux/ptr_ring.h > index 2af71a7..5858d48 100644 > --- a/include/linux/ptr_ring.h > +++ b/include/linux/ptr_ring.h > @@ -44,6 +44,8 @@ struct ptr_ring { > void **queue; > }; > Seems like a weird location for a define. Either put defines on top of the file, or near where they are used. I prefer the second option. > +#define PTR_RING_MAX_ALLOC 65536 > + I guess it's an arbitrary number. Seems like a sufficiently large one, but pls add a comment so readers don't wonder. And please explain what it does: /* Callers can create ptr_ring structures with userspace-supplied * parameters. This sets a limit on the size to make that usecase * safe. If you ever change this, make sure to audit all callers. */ Also I think we should generally use either hex 0x10000 or (1 << 16). > /* Note: callers invoking this in a loop must use a compiler barrier, > * for example cpu_relax(). > * > @@ -466,6 +468,8 @@ static inline int ptr_ring_consume_batched_bh(struct ptr_ring *r, > > static inline void **__ptr_ring_init_queue_alloc(unsigned int size, gfp_t gfp) > { > + if (size > PTR_RING_MAX_ALLOC) > + return NULL; > return kvmalloc_array(size, sizeof(void *), gfp | __GFP_ZERO); > } > > -- > 2.7.4