Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp4081751imm; Mon, 18 Jun 2018 08:51:48 -0700 (PDT) X-Google-Smtp-Source: ADUXVKJKWDczC5/UyT45mX+hxa6s1lojNYcLkafuaP7uj36sEmCQFL5AtvQ9Tshud1ZhEXODxocy X-Received: by 2002:a63:4b18:: with SMTP id y24-v6mr11548645pga.54.1529337108925; Mon, 18 Jun 2018 08:51:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529337108; cv=none; d=google.com; s=arc-20160816; b=KqZth3Dxm1P/WQvEpq6WMIjr3LIBKub2t1l6bT0tFF9t+H/SCOp0NQNSdUImID4YCj H7RNv7PgTmvwk6C1PTT0b4d7jqF0Dps8x2C5P/0CXC4b5qYC6b5Z5dclK4gdQ4/3gaHN D0JJt7DY+9ROSkkrZSUh7mFSchegTiVEay0vQCSxWlGpWXhKreOJo1y4OJUh7vYg4gL1 Z9Tp74UrGvyixGqRja0tuLufoGXRSagmqnjLYNe428EyoNMM4hado591nWtYhPqGuo7g 2zUiLurOj8Bd56cFZHN6Ie6HX7M7NPJ/evLQL4Nve6OzrqUA4V9QKfEaANfy/TBsQzzX z8nw== 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:date:cc:to:from:subject:message-id :arc-authentication-results; bh=ce9UMD+4nZM3IHaMz5FToKJUYqm8qwIHPutT+u83O6c=; b=sOlGcGiznIuWLUvaCvSMusfgYam87ds3IcucCmAjJfYXbEGEvp5Npwx7Z2XBZLnl1a R2nQcaEzEp4MYrgNQTjmo+vGTZCsWTFBb56vNODRlCz7041zEkipupN38TCOql3XQ9YG tHbrR6utcvXUnHs3I0AiknvErWEEOBkanhRB/L6ZxjzdPXB6MIVyVyPu16DzMgacR/TE 1XjYAnkrbFdQxt/jp9UT0eb2C5724m5473Ag5xaHme4L2jsYG/kiLZLJvBqU0CKxHSsN z0c/yr3OhcozM16CekCEZpoS6EzH7kSFv+sR9YTQvrHfUJsj9LKjB+KieNeAAGnbij1f tuRg== 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 k28-v6si15799141pfh.50.2018.06.18.08.51.35; Mon, 18 Jun 2018 08:51:48 -0700 (PDT) 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 S1755119AbeFRPto (ORCPT + 99 others); Mon, 18 Jun 2018 11:49:44 -0400 Received: from smtprelay0082.hostedemail.com ([216.40.44.82]:60970 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754587AbeFRPtm (ORCPT ); Mon, 18 Jun 2018 11:49:42 -0400 Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay08.hostedemail.com (Postfix) with ESMTP id 5D248182CF66E; Mon, 18 Jun 2018 15:49:41 +0000 (UTC) X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,joe@perches.com,:::::::::::::::::::::::::,RULES_HIT:41:355:379:541:599:960:966:973:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:2196:2199:2393:2553:2559:2562:2693:2828:2895:3138:3139:3140:3141:3142:3354:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:4321:4385:4605:5007:6119:7903:10004:10400:10848:11026:11232:11658:11914:12740:12760:12895:13069:13095:13311:13357:13439:14659:14721:21080:21433:21611:21627:21740:30012:30029:30054:30060:30070:30079:30090:30091,0,RBL:47.151.150.235:@perches.com:.lbl8.mailshell.net-62.14.0.100 64.201.201.201,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:25,LUA_SUMMARY:none X-HE-Tag: lunch59_8e7db6f41a00e X-Filterd-Recvd-Size: 3267 Received: from XPS-9350.home (unknown [47.151.150.235]) (Authenticated sender: joe@perches.com) by omf13.hostedemail.com (Postfix) with ESMTPA; Mon, 18 Jun 2018 15:49:39 +0000 (UTC) Message-ID: <780cba4e119110f2d2a81e237874592cff4d7868.camel@perches.com> Subject: Re: [PATCH v2 5/5] Input: evdev - Switch to bitmap_zalloc() From: Joe Perches To: Andy Shevchenko , Andy Shevchenko , Yury Norov Cc: agk@redhat.com, Mike Snitzer , dm-devel@redhat.com, shli@kernel.org, linux-raid@vger.kernel.org, Dmitry Torokhov , linux-input , Andrew Morton , Linux Kernel Mailing List , Mika Westerberg Date: Mon, 18 Jun 2018 08:49:37 -0700 In-Reply-To: <8cfbdf809f531f8aa315fe1679c3273858038f41.camel@linux.intel.com> References: <20180615132017.23889-1-andriy.shevchenko@linux.intel.com> <20180615132017.23889-6-andriy.shevchenko@linux.intel.com> <20180615214231.GA371@yury-thinkpad> <0a3d86d7746792a2f848cef386941fc182653515.camel@perches.com> <8cfbdf809f531f8aa315fe1679c3273858038f41.camel@linux.intel.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.28.1-2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2018-06-18 at 15:02 +0300, Andy Shevchenko wrote: > On Sat, 2018-06-16 at 12:16 -0700, Joe Perches wrote: > > On Sat, 2018-06-16 at 21:45 +0300, Andy Shevchenko wrote: > > > On Sat, Jun 16, 2018 at 12:46 AM Yury Norov > > om> wrote: > > > > On Fri, Jun 15, 2018 at 04:20:17PM +0300, Andy Shevchenko wrote: > > > > > Switch to bitmap_zalloc() to show clearly what we are > > > > > allocating. > > > > > Besides that it returns pointer of bitmap type instead of opaque > > > > > void *. > > > > > > > > > > > + mem = bitmap_alloc(maxbit, GFP_KERNEL); > > > > > if (!mem) > > > > > return -ENOMEM; > > > > > > > > But in commit message you say you switch to bitmap_zalloc(). IIUC > > > > bitmap_alloc() is OK here. But could you please update comment to > > > > avoid confusing. > > > > > > There are two places, one with alloc, another with zalloc. > > > I will clarify this in commit message of next version. > > > > > > > > + mask = bitmap_zalloc(cnt, GFP_KERNEL); > > > > > if (!mask) > > > > > return -ENOMEM; > > > > > > > > > > error = bits_from_user(mask, cnt - 1, codes_size, codes, > > > > > compat); > > > > > > > > If my understanding of bits_from_user() correct, here you can also > > > > use > > > > bitmap_alloc(), true? > > > > Also it might be useful to have a separate bitmap_from_user > > to alloc and copy. > > Maybe. I didn't check if there are such users except this driver. > > Anyway, it's out of scope of the series. That seems incorrect as you are introducing alloc/free helpers. Perhaps bitmap_dup_user [or some better name] could or should be one of the helpers.