From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by kanga.kvack.org (Postfix) with ESMTP id 0CB646B0072 for ; Wed, 18 Feb 2015 05:06:27 -0500 (EST) Received: by pdbnh10 with SMTP id nh10so63722pdb.11 for ; Wed, 18 Feb 2015 02:06:26 -0800 (PST) Received: from mailout2.w1.samsung.com (mailout2.w1.samsung.com. [210.118.77.12]) by mx.google.com with ESMTPS id te3si23959175pab.230.2015.02.18.02.06.25 for (version=TLSv1 cipher=RC4-MD5 bits=128/128); Wed, 18 Feb 2015 02:06:26 -0800 (PST) Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NJY005OHPLAGR60@mailout2.w1.samsung.com> for linux-mm@kvack.org; Wed, 18 Feb 2015 10:10:22 +0000 (GMT) Message-id: <54E4641A.9050709@partner.samsung.com> Date: Wed, 18 Feb 2015 13:06:18 +0300 From: Stefan Strogin MIME-version: 1.0 Subject: Re: [PATCH 1/4] mm: cma: add currently allocated CMA buffers list to debugfs References: <20150213031613.GJ6592@js1304-P5Q-DELUXE> In-reply-to: <20150213031613.GJ6592@js1304-P5Q-DELUXE> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Marek Szyprowski , Michal Nazarewicz , aneesh.kumar@linux.vnet.ibm.com, Laurent Pinchart , Dmitry Safonov , Pintu Kumar , Weijie Yang , Laura Abbott , SeongJae Park , Hui Zhu , Minchan Kim , Dyasly Sergey , Vyacheslav Tyrtov , gregory.0xf0@gmail.com, sasha.levin@oracle.com, gioh.kim@lge.com, pavel@ucw.cz, stefan.strogin@gmail.com Hello On 13/02/15 06:16, Joonsoo Kim wrote: > On Fri, Feb 13, 2015 at 01:15:41AM +0300, Stefan Strogin wrote: >> static int cma_debugfs_get(void *data, u64 *val) >> { >> unsigned long *p = data; >> @@ -125,6 +221,52 @@ static int cma_alloc_write(void *data, u64 val) >> >> DEFINE_SIMPLE_ATTRIBUTE(cma_alloc_fops, NULL, cma_alloc_write, "%llu\n"); >> >> +static int cma_buffers_read(struct file *file, char __user *userbuf, >> + size_t count, loff_t *ppos) >> +{ >> + struct cma *cma = file->private_data; >> + struct cma_buffer *cmabuf; >> + struct stack_trace trace; >> + char *buf; >> + int ret, n = 0; >> + >> + if (*ppos < 0 || !count) >> + return -EINVAL; >> + >> + buf = kmalloc(count, GFP_KERNEL); >> + if (!buf) >> + return -ENOMEM; > > Is count limited within proper size boundary for kmalloc()? > If it can exceed page size, using vmalloc() is better than this. > > Thanks. > You are right. On my systems it is always much bigger than page size. Thanks. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752351AbbBRKGZ (ORCPT ); Wed, 18 Feb 2015 05:06:25 -0500 Received: from mailout2.w1.samsung.com ([210.118.77.12]:20651 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751035AbbBRKGX (ORCPT ); Wed, 18 Feb 2015 05:06:23 -0500 X-AuditID: cbfec7f5-b7fc86d0000066b7-e6-54e463883a5a Message-id: <54E4641A.9050709@partner.samsung.com> Date: Wed, 18 Feb 2015 13:06:18 +0300 From: Stefan Strogin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-version: 1.0 To: Joonsoo Kim Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Marek Szyprowski , Michal Nazarewicz , aneesh.kumar@linux.vnet.ibm.com, Laurent Pinchart , Dmitry Safonov , Pintu Kumar , Weijie Yang , Laura Abbott , SeongJae Park , Hui Zhu , Minchan Kim , Dyasly Sergey , Vyacheslav Tyrtov , gregory.0xf0@gmail.com, sasha.levin@oracle.com, gioh.kim@lge.com, pavel@ucw.cz, stefan.strogin@gmail.com Subject: Re: [PATCH 1/4] mm: cma: add currently allocated CMA buffers list to debugfs References: <20150213031613.GJ6592@js1304-P5Q-DELUXE> In-reply-to: <20150213031613.GJ6592@js1304-P5Q-DELUXE> Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJIsWRmVeSWpSXmKPExsVy+t/xy7odyU9CDLa8VbeYs34Nm8Xj1/NY LD6tfMpm8azpC6PFtOkbWC1WdjezWWzvnMFu0TlxCbvF5V1z2CzurfnParH2yF12iwXHW1gt ln19z25x99RRNou+74fZLSbPlrL4dnIOs8XiI7eZLa7t6GeyuPzmP7vF1Bk/2C1ObjjLarGh mctB3ONyXy+Tx85Zd9k9ZnfMZPXYtKqTzWPTp0nsHl1vrzB5nJjxm8XjwaHNLB7r/rxi8vj4 9BaLx8F3e5g8+rasYvRYsfo7u8fnTXIeXRt/sQbwR3HZpKTmZJalFunbJXBlXDn/k73gF3vF vZtz2RsYZ7F1MXJySAiYSOz6fpgRwhaTuHBvPVhcSGApo8TOBhMI+yOjxPyzzF2MHBy8AkYS l56bgYRZBFQlejbfZwax2YDGHLswHWyMqECExPxjr8HivAKCEj8m32MBsUUENCRWr9oMFOfi YBZ4wCpxYM1KsJnCAuESB34Ug8SFBI4xSmyYOgcszilgJvHiqDOIySygJ3H/ohbIGGYBeYnN a94yT2AUmIVkwyyEqllIqhYwMq9iFE0tTS4oTkrPNdIrTswtLs1L10vOz93ECInurzsYlx6z OsQowMGoxMO7cMGjECHWxLLiytxDjBIczEoivPHxT0KEeFMSK6tSi/Lji0pzUosPMTJxcEo1 MCZrxe/M8eQPWXXyyB2VdZKc7e+itJYHsGcs+P7kUVpog97m9Qm3wuPZzNWWMWvWh2oKy/YU h947Gyz/flb7FoegY6kf4jRVhJzEEtYYRrIsdAm7kignqzxJN9n3atqhk3UBPRml0su9HVc5 BjRMv662aKl/mFVB/8wNUw7ur6hK7dCr2eCpxFKckWioxVxUnAgAi31idswCAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello On 13/02/15 06:16, Joonsoo Kim wrote: > On Fri, Feb 13, 2015 at 01:15:41AM +0300, Stefan Strogin wrote: >> static int cma_debugfs_get(void *data, u64 *val) >> { >> unsigned long *p = data; >> @@ -125,6 +221,52 @@ static int cma_alloc_write(void *data, u64 val) >> >> DEFINE_SIMPLE_ATTRIBUTE(cma_alloc_fops, NULL, cma_alloc_write, "%llu\n"); >> >> +static int cma_buffers_read(struct file *file, char __user *userbuf, >> + size_t count, loff_t *ppos) >> +{ >> + struct cma *cma = file->private_data; >> + struct cma_buffer *cmabuf; >> + struct stack_trace trace; >> + char *buf; >> + int ret, n = 0; >> + >> + if (*ppos < 0 || !count) >> + return -EINVAL; >> + >> + buf = kmalloc(count, GFP_KERNEL); >> + if (!buf) >> + return -ENOMEM; > > Is count limited within proper size boundary for kmalloc()? > If it can exceed page size, using vmalloc() is better than this. > > Thanks. > You are right. On my systems it is always much bigger than page size. Thanks.