linux-kernel - Re: [PATCH mmotm 1/5] nilfs2: fix problems of memory allocation in ioctl

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Dec 2008 21:24:11 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Ryusuke Konishi <konishi.ryusuke@....ntt.co.jp>
Cc:	andi@...stfloor.org, akpm@...ux-foundation.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH mmotm 1/5] nilfs2: fix problems of memory allocation in ioctl

> By the way, is there any recommended way to exchange such a large
> amount of data items between user space and kernel space?
> 
> In the current interface, each data item is copied twice: one is to
> the allocated memory from user space (via copy_from_user), and another

For such large copies it is better to use multiple smaller (e.g. 4K) 
copy user, that gives better real time preempt latencies. Each cfu has a 
cond_resched(), but only one, not multiple times in the inner loop.

> is to on-memory structures or to buffers/pages from the allocated
> memory.

It depends how performance critical it is.

One way for example is to grab the user pages using get_user_pages()
and then reference those pages directly using kmap().
But you would be at the mercy of the user process not modifying in 
parallel then. Normally it is safer to work from copies in kernel
space to avoid races. As long as it doesn't happen too often a few
copies are also usually not a problem. I wouldn't worry about them
unless you see them prominently in profiler logs.

-Andi

-- 
ak@...ux.intel.com
--
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/