| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <xa1toaojov0x.fsf@mina86.com>
Date: Tue, 24 Feb 2015 22:32:30 +0100
From: Michal Nazarewicz <mina86@...a86.com>
To: Stefan Strogin <s.strogin@...tner.samsung.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Cc: Stefan Strogin <s.strogin@...tner.samsung.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Marek Szyprowski <m.szyprowski@...sung.com>,
aneesh.kumar@...ux.vnet.ibm.com,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Dmitry Safonov <d.safonov@...tner.samsung.com>,
Pintu Kumar <pintu.k@...sung.com>,
Weijie Yang <weijie.yang@...sung.com>,
Laura Abbott <lauraa@...eaurora.org>,
SeongJae Park <sj38.park@...il.com>,
Hui Zhu <zhuhui@...omi.com>, Minchan Kim <minchan@...nel.org>,
Dyasly Sergey <s.dyasly@...sung.com>,
Vyacheslav Tyrtov <v.tyrtov@...sung.com>,
Aleksei Mateosian <a.mateosian@...sung.com>,
gregory.0xf0@...il.com, sasha.levin@...cle.com, gioh.kim@....com,
pavel@....cz, stefan.strogin@...il.com
Subject: Re: [PATCH v3 3/4] mm: cma: add list of currently allocated CMA buffers to debugfs
On Tue, Feb 24 2015, Stefan Strogin <s.strogin@...tner.samsung.com> wrote:
> When CONFIG_CMA_BUFFER_LIST is configured a file is added to debugfs:
> /sys/kernel/debug/cma/cma-<N>/buffers contains a list of currently allocated
> CMA buffers for each CMA region (N stands for number of CMA region).
>
> Format is:
> <base_phys_addr> - <end_phys_addr> (<size> kB), allocated by <PID> (<comm>)
>
> When CONFIG_CMA_ALLOC_STACKTRACE is configured then stack traces are saved when
> the allocations are made. The stack traces are added to cma/cma-<N>/buffers
> for each buffer list entry.
>
> Example:
>
> root@...ian:/sys/kernel/debug/cma# cat cma-0/buffers
> 0x2f400000 - 0x2f417000 (92 kB), allocated by pid 1 (swapper/0)
> [<c1142c4b>] cma_alloc+0x1bb/0x200
> [<c143d28a>] dma_alloc_from_contiguous+0x3a/0x40
> [<c10079d9>] dma_generic_alloc_coherent+0x89/0x160
> [<c14456ce>] dmam_alloc_coherent+0xbe/0x100
> [<c1487312>] ahci_port_start+0xe2/0x210
> [<c146e0e0>] ata_host_start.part.28+0xc0/0x1a0
> [<c1473650>] ata_host_activate+0xd0/0x110
> [<c14881bf>] ahci_host_activate+0x3f/0x170
> [<c14854e4>] ahci_init_one+0x764/0xab0
> [<c12e415f>] pci_device_probe+0x6f/0xd0
> [<c14378a8>] driver_probe_device+0x68/0x210
> [<c1437b09>] __driver_attach+0x79/0x80
> [<c1435eef>] bus_for_each_dev+0x4f/0x80
> [<c143749e>] driver_attach+0x1e/0x20
> [<c1437197>] bus_add_driver+0x157/0x200
> [<c14381bd>] driver_register+0x5d/0xf0
> <...>
>
> Signed-off-by: Stefan Strogin <s.strogin@...tner.samsung.com>
> --- a/mm/cma.h
> +++ b/mm/cma.h
> @@ -11,8 +13,32 @@ struct cma {
> struct hlist_head mem_head;
> spinlock_t mem_head_lock;
> #endif
> +#ifdef CONFIG_CMA_BUFFER_LIST
> + struct list_head buffer_list;
> + struct mutex list_lock;
> +#endif
> };
>
> +#ifdef CONFIG_CMA_BUFFER_LIST
> +struct cma_buffer {
> + unsigned long pfn;
> + unsigned long count;
> + pid_t pid;
> + char comm[TASK_COMM_LEN];
> +#ifdef CONFIG_CMA_ALLOC_STACKTRACE
> + unsigned long trace_entries[16];
> + unsigned int nr_entries;
> +#endif
> + struct list_head list;
> +};
This structure is only ever used in cma_debug.c so is there a reason
to define it in the header file?
> +
> +extern int cma_buffer_list_add(struct cma *cma, unsigned long pfn, int count);
> +extern void cma_buffer_list_del(struct cma *cma, unsigned long pfn, int count);
> +#else
> +#define cma_buffer_list_add(cma, pfn, count) { }
> +#define cma_buffer_list_del(cma, pfn, count) { }
> +#endif /* CONFIG_CMA_BUFFER_LIST */
> +
> extern struct cma cma_areas[MAX_CMA_AREAS];
> extern unsigned cma_area_count;
> +#ifdef CONFIG_CMA_BUFFER_LIST
> +static ssize_t cma_buffer_list_read(struct file *file, char __user *userbuf,
> + size_t count, loff_t *ppos)
> +{
> + struct cma *cma = file->private_data;
> + struct cma_buffer *cmabuf;
> + char *buf;
> + int ret, n = 0;
> +#ifdef CONFIG_CMA_ALLOC_STACKTRACE
> + struct stack_trace trace;
> +#endif
> +
> + if (*ppos < 0 || !count)
> + return -EINVAL;
> +
> + buf = vmalloc(count);
> + if (!buf)
> + return -ENOMEM;
> +
> + mutex_lock(&cma->list_lock);
> + list_for_each_entry(cmabuf, &cma->buffer_list, list) {
> + n += snprintf(buf + n, count - n,
> + "0x%llx - 0x%llx (%lu kB), allocated by pid %u (%s)\n",
> + (unsigned long long)PFN_PHYS(cmabuf->pfn),
> + (unsigned long long)PFN_PHYS(cmabuf->pfn +
> + cmabuf->count),
> + (cmabuf->count * PAGE_SIZE) >> 10, cmabuf->pid,
> + cmabuf->comm);
> +
> +#ifdef CONFIG_CMA_ALLOC_STACKTRACE
> + trace.nr_entries = cmabuf->nr_entries;
> + trace.entries = &cmabuf->trace_entries[0];
> + n += snprint_stack_trace(buf + n, count - n, &trace, 0);
> + n += snprintf(buf + n, count - n, "\n");
> +#endif
> + }
> + mutex_unlock(&cma->list_lock);
> +
> + ret = simple_read_from_buffer(userbuf, count, ppos, buf, n);
> + vfree(buf);
> +
> + return ret;
> +}
So in practice user space must allocate buffer big enough to read the
whole file into memory. Calling read(2) with some count will never read
anything past the first count bytes of the file.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +--<mpn@...gle.com>--<xmpp:mina86@...ber.org>--ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists