From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Wang Subject: Re: [PATCH net V3 2/2] ptr_ring: fail on large queue size (>64K) Date: Fri, 9 Feb 2018 11:50:31 +0800 Message-ID: <36f407ba-14db-e6b8-42e6-f0eacf6da3b2@redhat.com> References: <1518062365-8596-1-git-send-email-jasowang@redhat.com> <1518062365-8596-2-git-send-email-jasowang@redhat.com> <20180208064602-mutt-send-email-mst@kernel.org> <118d4e49-ac55-c4d3-13ed-8828b9d110a2@redhat.com> <20180208173024-mutt-send-email-mst@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cc: netdev@vger.kernel.org To: "Michael S. Tsirkin" Return-path: Received: from mx3-rdu2.redhat.com ([66.187.233.73]:60032 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752465AbeBIDuk (ORCPT ); Thu, 8 Feb 2018 22:50: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 682C28182D17 for ; Fri, 9 Feb 2018 03:50:39 +0000 (UTC) In-Reply-To: <20180208173024-mutt-send-email-mst@kernel.org> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 2018年02月08日 23:50, Michael S. Tsirkin wrote: > On Thu, Feb 08, 2018 at 03:11:22PM +0800, Jason Wang wrote: >> On 2018年02月08日 12:52, Michael S. Tsirkin wrote: >>> 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. >> Ok. >> >>>> +#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). >> I agree the number is arbitrary, so I still prefer the KMALLOC_MAX_SIZE >> especially consider it was used by pfifo_fast now. Try to limit it to an >> arbitrary may break lots of exist setups. E.g just google "txqueuelen >> 100000" can give me a lots of search results. >> >> We can do any kind of optimization on top but not for -net now. >> >> Thanks > Interesting. I have an idea for fixing this, but maybe > for now KMALLOC_MAX_SIZE does make sense. It's unfortunate that > this value is architecture dependent. > > The patch still needs code comments though, and fix the math to > use the proper size. > Yes. Thanks