http://blog.gmane.org/gmane.linux.kernel.next hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.kernel.next/27491 <pre> Something should be posted by the end of the day. Sorry for the delay. </pre> Eric Paris 2013-05-17T19:08:59 http://permalink.gmane.org/gmane.linux.kernel.next/27489 <pre> I agree with whoever suggested that more be moved into /lib. E.g., drivers/misc/vmw_vmci/Kconfig uses "depends on NET" because the code there uses both memcpy_toiovec() and memcpy_fromiovec(). See commit ID 6d4f0139d642c45411a47879325891ce2a7c164a. </pre> Randy Dunlap 2013-05-17T04:42:33 http://permalink.gmane.org/gmane.linux.kernel.next/27483 <pre> Need to also add select CRYPTO for CRC_T10DIF. Updated fix below: Signed-off-by: Tim Chen &lt;tim.c.chen&lt; at &gt;linux.intel.com&gt; --- diff --git a/crypto/Kconfig b/crypto/Kconfig index d1ca631..015df24 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig &lt; at &gt;&lt; at &gt; -379,6 +379,7 &lt; at &gt;&lt; at &gt; config CRYPTO_CRC32_PCLMUL config CRYPTO_CRCT10DIF tristate "CRCT10DIF algorithm" select CRYPTO_HASH +depends on CRC_T10DIF help CRC T10 Data Integrity Field computation is being cast as a crypto transform. This allows for faster crc t10 diff diff --git a/lib/Kconfig b/lib/Kconfig index 0cee056..6407793 100644 --- a/lib/Kconfig +++ b/lib/Kconfig &lt; at &gt;&lt; at &gt; -63,7 +63,8 &lt; at &gt;&lt; at &gt; config CRC16 config CRC_T10DIF tristate "CRC calculation for the T10 Data Integrity Field" -select CRYPTO_CRCT10DIF +select CRYPTO +select CRYPTO_HASH help This option is only needed if a module that's not in the kernel tree needs to calculate CRC checks for use with the </pre> Tim Chen 2013-05-16T18:03:32 http://permalink.gmane.org/gmane.linux.kernel.next/27482 <pre>On Thu, May 16, 2013 at 1:19 PM, Andrew Morton &lt;akpm&lt; at &gt;linux-foundation.org&gt; wrote: It is exactly the same as PF_MEMALLOC. We've got an effectively asynchronous event (shrinking) that can occur while you are holding locks requisite to that shrinking. Given that the shrinkage is best effort, a trylock actually communicates the intent pretty well: "If possible, grab this lock and shrink." I think the idiomatic fix is to introduce a GFP_SHMEM but that seems overkill. Lots of the GFP flags are really just preventing recursing into the shrinkage code and it seems ill-designed that we require developers to know where they might end up. But we can disagree. :) Unfortunately I think ashmem_shrink would need to grab the per-object lock too; it needs to update the ranges. I'm sure we could re-design this but I don't think it is as easy as simply pushing the locking into the objects. Robert </pre> Robert Love 2013-05-16T17:28:52 http://permalink.gmane.org/gmane.linux.kernel.next/27481 <pre> Not really. The need for a trylock is often an indication that a subsystem has a locking misdesign. That is indeed the case here. Well, it's not exactly a ton of work, but adding a per-ashmem_area lock to protect -&gt;file would rather be putting lipstick on a pig. I suppose we can put the trylock in there and run away, but it wouldn't hurt to drop in a big fat comment somewhere explaining that the driver should be migrated to a per-object locking scheme. </pre> Andrew Morton 2013-05-16T17:19:07 http://permalink.gmane.org/gmane.linux.kernel.next/27480 <pre>On Thu, May 16, 2013 at 12:45 PM, Andrew Morton &lt;akpm&lt; at &gt;linux-foundation.org&gt; wrote: I don't like this proposal, either. Many of the existing GFP flags already exist to prevent recurse into that flag's respective shrinker. This problem seems a rare proper use of mutex_trylock. Right. The locking is "crude" because I optimized for space, not time, and there was (and is) no indication we were suffering lock contention due to the global lock. I haven't thought through the implications of pushing locking into the ashmem_area and ashmem_range objects, but it does look like we'd end up often grabbing all of the locks ... ... but not, as you note, in ashmem_mmap. The main race there is around the allocation of asma-&gt;file. That could definitely be a lock local to ashmem_area. I'm OK if anyone wants to take that on but it seems a lot of work for a driver with an unclear future. Robert </pre> Robert Love 2013-05-16T17:08:17 http://permalink.gmane.org/gmane.linux.kernel.next/27478 <pre> s/won't work/impractical/ A better approach would be to add a new __GFP_NOSHRINKERS, but it's all variations on a theme. The mutex_trylock(ashmem_mutex) will actually have the best performance, because it skips the least amount of memory reclaim opportunities. But it still sucks! The real problem is that there exists a lock called "ashmem_mutex", taken by both the high-level mmap() and by the low-level shrinker. And taken by everything else too! The ashmem locking is pretty crude... What is the mutex_lock() in ashmem_mmap() actually protecting? I don't see much, apart from perhaps some incidental races around the contents of the file's ashmem_area, and those could/should be protected by a per-object lock, not a global one? </pre> Andrew Morton 2013-05-16T16:45:59 http://permalink.gmane.org/gmane.linux.kernel.next/27476 <pre> There is no debate about the nature of the bug. Only the fix. My mutex_trylock patch fixes the problem. I prefer that solution. Andrew's suggestion of GFP_ATOMIC won't work as we'd have to propagate that down into shmem and elsewhere. Using PF_MEMALLOC will work. You'd want to define something like: static int set_memalloc(void) { if (current-&gt;flags &amp; PF_MEMALLOC) return 0; current-&gt;flags |= PF_MEMALLOC; return 1; } static void clear_memalloc(int memalloc) { if (memalloc) current-&gt;flags &amp;= ~PF_MEMALLOC; } and then set/clear PF_MEMALLOC around every memory allocation and function that descends into a memory allocation. As said I prefer my solution but if someone wants to put together a patch with this approach, fine by me. Robert </pre> Robert Love 2013-05-16T13:44:49 http://permalink.gmane.org/gmane.linux.kernel.next/27474 <pre>2013/5/14 Raul Xiong &lt;raulxiong&lt; at &gt;gmail.com&gt; Hi Andrew, Greg, Any feedback? The issue happens in such sequence: ashmem_mmap acquired ashmem_mutex --&gt; ashmem_mutex:shmem_file_setup called kmem_cache_alloc --&gt; shrink due to low memory --&gt; ashmem_shrink tries to acquire the same ashmem_mutex -- it blocks here. I think this reports the bug clearly. Please have a look. Thanks, Raul Xiong </pre> Raul Xiong 2013-05-16T08:15:49 http://permalink.gmane.org/gmane.linux.kernel.next/27473 <pre> This is a library symbol, so "select CRC_T10DIF"? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert&lt; at &gt;linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds </pre> Geert Uytterhoeven 2013-05-16T07:22:30 http://permalink.gmane.org/gmane.linux.kernel.next/27469 <pre>Hi Simon, On Thu, 16 May 2013 14:04:53 +0900 Simon Horman &lt;horms&lt; at &gt;verge.net.au&gt; wrote: Excellent, thanks. </pre> Stephen Rothwell 2013-05-16T06:12:19 http://permalink.gmane.org/gmane.linux.kernel.next/27468 <pre>Hi all, Changes since 20130515: New tree: mvebu The renesas tree gained a conflict against Linus' tree. The akpm tree lost a patch that turned up elsewhere. ---------------------------------------------------------------------------- I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 226 trees (counting Linus' and 31 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. </pre> Stephen Rothwell 2013-05-16T05:08:49 http://permalink.gmane.org/gmane.linux.kernel.next/27465 <pre> On Wed, 15 May 2013, Randy Dunlap wrote: just try. From: Xiong Zhou &lt;jencce.kernel&lt; at &gt;gmail.com&gt; Try to fix randconfig build error reported by Randy Dunlap: on x86_64: crypto/built-in.o: In function `chksum_digest': crct10dif.c:(.text+0x2789f): undefined reference to `crc_t10dif_generic' crypto/built-in.o: In function `chksum_finup': crct10dif.c:(.text+0x278c7): undefined reference to `crc_t10dif_generic' crypto/built-in.o: In function `chksum_update': crct10dif.c:(.text+0x278ef): undefined reference to `crc_t10dif_generic' CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRC_T10DIF=m Cc: Randy Dunlap &lt;rdunlap&lt; at &gt;infradead.org&gt; Signed-off-by: Xiong Zhou &lt;jencce.kernel&lt; at &gt;gmail.com&gt; --- crypto/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 25b5209..28655bc 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig &lt; at &gt;&lt; at &gt; -378,6 +378,7 &lt; at &gt;&lt; at &gt; config CRYPTO_CRC32_PCLMUL config CRYPTO_CRCT10DIF tristate "CRCT10DIF algorithm" +depends on CRC_T10DIF select CRYPTO_HASH help CRC T10 Data Integrity Field computation is being cast as </pre> Xiong Zhou 2013-05-16T03:57:48 http://permalink.gmane.org/gmane.linux.kernel.next/27463 <pre> If this isn't the only symbol causing the problem, then this should be mentioned in the changelog. If it is, it should be fixed: we have plenty of time for that. Either way, your commit message or the commit itself needs to justify it! Heh... I originally wrote an explanation, then found it a bit insulting: I knew I didn't need to tell you :) How's this? From: Rusty Russell &lt;rusty&lt; at &gt;rustcorp.com.au&gt; Subject: Hoist memcpy_fromiovec into lib/ ERROR: "memcpy_fromiovec" [drivers/vhost/vhost_scsi.ko] undefined! That function is only present with CONFIG_NET. Turns out that crypto/algif_skcipher.c also uses that outside net, but it actually needs sockets anyway. socket.h already include uio.h, so no callers need updating. Reported-by: Randy Dunlap &lt;rdunlap&lt; at &gt;infradead.org&gt; Signed-off-by: Rusty Russell &lt;rusty&lt; at &gt;rustcorp.com.au&gt; diff --git a/include/linux/socket.h b/include/linux/socket.h index 428c37a..7266775 100644 --- a/include/linux/socket.h +++ b/include/linux/socket.h &lt; at &gt;&lt; at &gt; -305,7 +305,6 &lt; at &gt;&lt; at &gt; struct ucred { extern void cred_to_ucred(struct pid *pid, const struct cred *cred, struct ucred *ucred); -extern int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len); extern int memcpy_fromiovecend(unsigned char *kdata, const struct iovec *iov, int offset, int len); extern int csum_partial_copy_fromiovecend(unsigned char *kdata, diff --git a/include/linux/uio.h b/include/linux/uio.h index 629aaf5..21628d3 100644 --- a/include/linux/uio.h +++ b/include/linux/uio.h &lt; at &gt;&lt; at &gt; -35,4 +35,6 &lt; at &gt;&lt; at &gt; static inline size_t iov_length(const struct iovec *iov, unsigned long nr_segs) } unsigned long iov_shorten(struct iovec *iov, unsigned long nr_segs, size_t to); + +int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len); #endif diff --git a/lib/Makefile b/lib/Makefile index e9c52e1..2377211 100644 --- a/lib/Makefile +++ b/lib/Makefile &lt; at &gt;&lt; at &gt; -9,7 +9,7 &lt; at &gt;&lt; at &gt; endif lib-y := ctype.o string.o vsprintf.o cmdline.o \ rbtree.o radix-tree.o dump_stack.o timerqueue.o\ - idr.o int_sqrt.o extable.o \ + idr.o int_sqrt.o extable.o iovec.o \ sha1.o md5.o irq_regs.o reciprocal_div.o argv_split.o \ proportions.o flex_proportions.o prio_heap.o ratelimit.o show_mem.o \ is_single_threaded.o plist.o decompress.o kobject_uevent.o \ diff --git a/lib/iovec.c b/lib/iovec.c new file mode 100644 index 0000000..632c5ea --- /dev/null +++ b/lib/iovec.c &lt; at &gt;&lt; at &gt; -0,0 +1,29 &lt; at &gt;&lt; at &gt; +#include &lt;linux/uaccess.h&gt; +#include &lt;linux/export.h&gt; +#include &lt;linux/uio.h&gt; + +/* + *Copy iovec to kernel. Returns -EFAULT on error. + * + *Note: this modifies the original iovec. + */ + +int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len) +{ +while (len &gt; 0) { +if (iov-&gt;iov_len) { +int copy = min_t(unsigned int, len, iov-&gt;iov_len); +if (copy_from_user(kdata, iov-&gt;iov_base, copy)) +return -EFAULT; +len -= copy; +kdata += copy; +iov-&gt;iov_base += copy; +iov-&gt;iov_len -= copy; +} +iov++; +} + +return 0; +} +EXPORT_SYMBOL(memcpy_fromiovec); + diff --git a/net/core/iovec.c b/net/core/iovec.c index 7e7aeb0..d81257f 100644 --- a/net/core/iovec.c +++ b/net/core/iovec.c &lt; at &gt;&lt; at &gt; -125,31 +125,6 &lt; at &gt;&lt; at &gt; int memcpy_toiovecend(const struct iovec *iov, unsigned char *kdata, EXPORT_SYMBOL(memcpy_toiovecend); /* - *Copy iovec to kernel. Returns -EFAULT on error. - * - *Note: this modifies the original iovec. - */ - -int memcpy_fromiovec(unsigned char *kdata, struct iovec *iov, int len) -{ -while (len &gt; 0) { -if (iov-&gt;iov_len) { -int copy = min_t(unsigned int, len, iov-&gt;iov_len); -if (copy_from_user(kdata, iov-&gt;iov_base, copy)) -return -EFAULT; -len -= copy; -kdata += copy; -iov-&gt;iov_base += copy; -iov-&gt;iov_len -= copy; -} -iov++; -} - -return 0; -} -EXPORT_SYMBOL(memcpy_fromiovec); - -/* *Copy iovec from kernel. Returns -EFAULT on error. */ </pre> Rusty Russell 2013-05-16T03:34:58 http://permalink.gmane.org/gmane.linux.kernel.next/27462 <pre>Hi Simon, Today's linux-next merge of the renesas tree got a conflict in arch/arm/mach-shmobile/board-lager.c between commit 65be2de17aae ("ARM: shmobile: use r8a7790 timer setup code on Lager") from Linus' tree and commit 993340a1390d ("ARM: shmobile: use r8a7790 timer setup code on Lager") from the renesas tree. These are the same patch but different commits :-( and there are further commits touching this file in the renesas tree. Please clean up your tree and remove anything that has already gone upstream as different patches. I used the renesas tree version of this file. </pre> Stephen Rothwell 2013-05-16T03:22:53 http://permalink.gmane.org/gmane.linux.kernel.next/27455 <pre>Hi Eric, On Wed, May 15, 2013 at 09:32:42AM -0400, Eric Paris wrote: I don't think so, I am still using gcc 4.6 for this build but it is a 32 bit build ... </pre> Stephen Rothwell 2013-05-15T22:25:27 http://permalink.gmane.org/gmane.linux.kernel.next/27454 <pre>From: Randy Dunlap &lt;rdunlap&lt; at &gt;infradead.org&gt; Fix build error in amilo-rfkill.c by making it dependent on SERIO_I8042: drivers/built-in.o: In function `amilo_a1655_rfkill_set_block': amilo-rfkill.c:(.text+0x264a89): undefined reference to `i8042_lock_chip' amilo-rfkill.c:(.text+0x264a97): undefined reference to `i8042_command' amilo-rfkill.c:(.text+0x264a9e): undefined reference to `i8042_unlock_chip' Signed-off-by: Randy Dunlap &lt;rdunlap&lt; at &gt;infradead.org&gt; Cc: Ben Hutchings &lt;ben&lt; at &gt;decadent.org.uk&gt; --- drivers/platform/x86/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20130515.orig/drivers/platform/x86/Kconfig +++ linux-next-20130515/drivers/platform/x86/Kconfig &lt; at &gt;&lt; at &gt; -175,7 +175,7 &lt; at &gt;&lt; at &gt; config FUJITSU_TABLET config AMILO_RFKILL tristate "Fujitsu-Siemens Amilo rfkill support" -depends on RFKILL +depends on RFKILL &amp;&amp; SERIO_I8042 ---help--- This is a driver for enabling wifi on some Fujitsu-Siemens Amilo laptops. </pre> Randy Dunlap 2013-05-15T21:03:35 http://permalink.gmane.org/gmane.linux.kernel.next/27452 <pre> on x86_64: drivers/built-in.o: In function `brcms_led_unregister': (.text+0x136f0e): undefined reference to `led_classdev_unregister' drivers/built-in.o: In function `brcms_led_register': (.text+0x1370b5): undefined reference to `led_classdev_register' when CONFIG_NEW_LEDS is not enabled. </pre> Randy Dunlap 2013-05-15T17:42:19 http://permalink.gmane.org/gmane.linux.kernel.next/27451 <pre> Thank you, I'll fix it up. What am I likely missing that I don't see it on my builds? I'm using gcc 4.8. Is there a config option that enables additional warnings? </pre> Eric Paris 2013-05-15T13:32:42 http://permalink.gmane.org/gmane.linux.kernel.next/27450 <pre> I thought I would newer rebase the for-next branch to allow people to pull from it. But I can see that it looks much cleaner in the linux-next tree if you can do a git log stable..master and see what is really in linux-next. So I reset it to v3.10-rc1 now. Michal </pre> Michal Marek 2013-05-15T12:25:38 http://permalink.gmane.org/gmane.linux.kernel.next/27449 <pre>Hi, Now in the -nmw tree. Will push to -fixes once it has had a few days to sit in -nmw/-next. Thanks, Steve. On Tue, 2013-05-14 at 10:02 -0700, Randy Dunlap wrote: </pre> Steven Whitehouse 2013-05-15T10:05:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel.next