Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp221036ybx; Mon, 4 Nov 2019 19:06:12 -0800 (PST) X-Google-Smtp-Source: APXvYqzjXLoBkmMN2tDhOv9TxZe01Q/8LevaH7ugiI699NQCPWvpb2GqpZKSPeB2Oqo8SOGBVumg X-Received: by 2002:a17:906:9c1:: with SMTP id r1mr26391740eje.217.1572923172335; Mon, 04 Nov 2019 19:06:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1572923172; cv=none; d=google.com; s=arc-20160816; b=cLULgVYCqnpy11y+3R0qpV4YvPlmYp06QNafrVbUOvzzhycGT8hgy6x6odf1+XwPrp KqimK9vt1rEd7UJNN2Sb0NZIDOMJpiPc0W08K5tbvWqegM+4Z7Q140aZcqx8btDP2mU8 BTPY5L5SPiYwXriB+a0UdV4Xv5BvGrrg2DYFtc9P+kv+Ko7o3d9F33/ygwL+icBGR1Y3 B5ooSjRieRxGoC1HMdbw/Hgil3t7bB5Fo+mBckX1qZe4mmT9vg5yGKdhhXNQmR+vdFSZ 79eJOkgAZ4HVOfqKgLRBSv0U5mB984mJoNfB3CfSRKhynStGs36uzY5EeDcAfCBTWARU +iIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=Zwj4kn5TVqgDd9P4MWo4EBNcmmY7SJQgfAdtiwRGh3w=; b=syBs5OKDZXH7vZE/db4RfOevWtA704aUmQlVfI1C6tBGMOzAFDmNQ4FYEtMXO5v4F8 TyZk+TOjUfDOD9lD3RvBeLamPN71DjU4PSu+DE0L/ogTLfzpcBC4fuKc2BRmLy0HdgAI u0euoP4Niynu0Q4b+QeZy9OLWJELq6AOj4cp/Gr/nOvxZzKz8BGAdCScdtxQV0NMFfFf /wkfKdG5IZi9cK8J4Y4e6b1wQmzx+6J+VYGQ2hIH/wFwicQWqyXmbaIh0VPybl33hNuZ JZn02OmGzxG+s6kMWT38V3urAFoEq67rVeL/F+aKVMeLZId3w4bS7/U7ceuW2IwZqyIV JT6w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=M4fbfC66; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r4si9737347edx.365.2019.11.04.19.05.43; Mon, 04 Nov 2019 19:06:12 -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; dkim=pass header.i=@kernel.org header.s=default header.b=M4fbfC66; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729644AbfKEDEx (ORCPT + 99 others); Mon, 4 Nov 2019 22:04:53 -0500 Received: from mail.kernel.org ([198.145.29.99]:35292 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727861AbfKEDEx (ORCPT ); Mon, 4 Nov 2019 22:04:53 -0500 Received: from localhost (unknown [104.132.0.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BF300206B8; Tue, 5 Nov 2019 03:04:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572923092; bh=ayQqU8Qbemc32/HIUooa1m/XuTOUikPJAAUvS/qaxjU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=M4fbfC66Tih/uZITmA1N9W/HcX5rt9+ugMU/5Z3rcTE3omxFQXy4jw67GFv8tbBg9 tACLhT3w+YOkMDSBb9ubrP70uZKwt5Wva5IeHIprFRpTdoXop48AZfklA245kBm7C6 3XQ8sPBdy+FZrB11Cbde8HdqVp896Z/3h0f9SFKg= Date: Mon, 4 Nov 2019 19:04:51 -0800 From: Jaegeuk Kim To: Chao Yu Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net Subject: Re: [PATCH 3/3] Revert "f2fs: use kvmalloc, if kmalloc is failed" Message-ID: <20191105030451.GA55090@jaegeuk-macbookpro.roam.corp.google.com> References: <20191101095324.9902-1-yuchao0@huawei.com> <20191101095324.9902-3-yuchao0@huawei.com> <20191105000249.GA46956@jaegeuk-macbookpro.roam.corp.google.com> <40d0df3f-cc55-d31a-474b-76f57d96bd89@huawei.com> <20191105023835.GD692@sol.localdomain> <00ade77c-5451-4953-0232-89342a029f33@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ade77c-5451-4953-0232-89342a029f33@huawei.com> User-Agent: Mutt/1.8.2 (2017-04-18) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/05, Chao Yu wrote: > On 2019/11/5 10:38, Eric Biggers wrote: > > On Tue, Nov 05, 2019 at 10:17:41AM +0800, Chao Yu wrote: > >> On 2019/11/5 8:02, Jaegeuk Kim wrote: > >>> On 11/01, Chao Yu wrote: > >>>> This reverts commit 5222595d093ebe80329d38d255d14316257afb3e. > >>>> > >>>> As discussed with Eric, as kvmalloc() will try kmalloc() first, so > >>>> when we need allocate large size memory, it'd better to use > >>>> f2fs_kvmalloc() directly rather than adding additional fallback > >>>> logic to call kvmalloc() after we failed in f2fs_kmalloc(). > >>>> > >>>> In order to avoid allocation failure described in original commit, > >>>> I change to use f2fs_kvmalloc() for .free_nid_bitmap bitmap memory. > >>> > >>> Is there any problem in the previous flow? > >> > >> No existing problem, however, it's redundant to introduce fallback flow in > >> f2fs_kmalloc() like vmalloc() did, since we can call f2fs_vmalloc() directly in > >> places where we need large memory. > >> > >> Thanks, > >> > > > > f2fs_kmalloc() also violated the naming convention used everywhere else in the > > kernel since it could return both kmalloc and vmalloc memory, not just kmalloc > > memory. That's really error-prone since people would naturally assume it's safe > > to free the *_kmalloc()-ed memory with kfree(). > > Agreed. Then, why not just keeping f2fs_kvmalloc() and replace all f2fs_kmalloc() with f2fs_kvmalloc()? f2fs_kvmalloc() - call kmalloc() - vmalloc(), if failed I'd like to keep the allocation behavior first. Thanks,