Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1526050imu; Tue, 11 Dec 2018 22:52:23 -0800 (PST) X-Google-Smtp-Source: AFSGD/VI+x7H1YowgSYOGr4B5xBhPnTzw7phN3vIMAiittewqReGkRmLOe0oe8E7T4hiBtUcuD2A X-Received: by 2002:a62:ca9c:: with SMTP id y28mr19027993pfk.236.1544597543721; Tue, 11 Dec 2018 22:52:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544597543; cv=none; d=google.com; s=arc-20160816; b=f1PoJnw7LFPXU4rqs5rBejCxAwaa2PF/TCfcT51ZRIVz7B2dvqUpqm+aEkB1Ib5sKJ D2ss41nAbamBTn9y8MR3u3CO9bCmMAewGxeN0U+qPz5z9dR1gcXkMhIaQynfm8++iqHD IlN5aM+74PlnoZeZLqfGe1xdY4Amb7VB3o7sch1D2k+CD1Nme3b9u6KZaAEdtEjM/fYd EObgwNmWrkfhEtj7uCl6aPLvZyxc0Oj6Qx3x/xUZRgpnbIWWJIKeqCk4aYYhlnqV7pcx DsD63qCgsWMeQAYgHW2GtNaSfvH3FG6rZKl207r4XgsxN+YJr60kHNhigcYFU5z2ECIP h5Pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=q6KcznJ/cBaZ0Nt8SrpkfGSpK0JOX9iyUqIbXMKXszg=; b=uXU+EfomFv4/J+jWo67a06ex2TcAnwoVGCM/L4Z+ILzRzQhYR22iZVDBIIf20dQqv8 R1lySLoSX5xcKZrpH656ouzdPIEGELZCuzXNyMgvB+DKsnyN852YiZdWLgc0yFunOIRq hTCnCRlmURsgQ83jOT/01YKt07kmOVxbRx62D2ksQbEdgawgL23kwiyv5FZR1qvRLzmU N4OYn5O7eBi5wkCPnXgFvK5zlgSHzuE3T1+y6XxbdE4i2UkHXtKk4rUNp/0efEfInnNr FvJXtQyFTS4qJoChotjWch5s0mWok5jBx99glGjv0rbr9JXNUbKahc3RRmG7T+33TCFJ kYqw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m38si13930706pgl.125.2018.12.11.22.52.07; Tue, 11 Dec 2018 22:52:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726598AbeLLGuC (ORCPT + 99 others); Wed, 12 Dec 2018 01:50:02 -0500 Received: from shards.monkeyblade.net ([23.128.96.9]:51226 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726242AbeLLGuC (ORCPT ); Wed, 12 Dec 2018 01:50:02 -0500 Received: from localhost (unknown [IPv6:2601:601:9f80:35cd::bf5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id A039D1455330F; Tue, 11 Dec 2018 22:50:01 -0800 (PST) Date: Tue, 11 Dec 2018 22:50:00 -0800 (PST) Message-Id: <20181211.225000.726755542677275663.davem@davemloft.net> To: lucien.xin@gmail.com Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, linux-sctp@vger.kernel.org, marcelo.leitner@gmail.com, nhorman@tuxdriver.com, dave.hansen@linux.intel.com, rientjes@google.com, eparis@redhat.com, khorenko@virtuozzo.com Subject: Re: [PATCHv2 net 0/3] net: add support for flex_array_resize in flex_array From: David Miller In-Reply-To: References: X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Tue, 11 Dec 2018 22:50:02 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Xin Long Date: Fri, 7 Dec 2018 14:30:32 +0800 > Without the support for the total_nr_elements's growing or shrinking > dynamically, flex_array is not that 'flexible'. Like when users want > to change the size, they have to redo flex_array_alloc and copy all > the elements from the old to the new one. The worse thing is every > element's memory gets changed. > > To implement flex_array_resize based on current code, the difficult > thing is to process the size border of FLEX_ARRAY_BASE_BYTES_LEFT, > where the base data memory may change to an array for the 2nd level > data memory for growing, likewise for shrinking. > > To make this part easier, we separate the base data memory and define > FLEX_ARRAY_BASE_SIZE as a same value of FLEX_ARRAY_PART_SIZE, as Neil > suggested. When new size is crossing the border, the base memory is > allocated as the array for the 2nd level data memory and its part[0] > is pointed to the old base memory, and do the opposite for shrinking. > > But it doesn't do any memory allocation or shrinking for elements in > flex_array_resize, as which should be done by flex_array_prealloc or > flex_array_shrink called by users. No memory leaks can be caused by > that. > > SCTP has benefited a lot from flex_array_resize() for managing its > stream memory so far. > > v1->v2: > Cc LKML and more developers. So I don't know what to do about this series. One of the responses stated that it has been proposed to remove flex_array and I don't know what to make of that, nor can I tell if that makes this series inappropriate or not.