commit 497c6eb673d94487cfde35c7077981733fe862fb Author: Greg Kroah-Hartman Date: Tue Aug 20 08:21:23 2013 -0700 Linux 3.0.92 commit c4e462a085dd8279af22493ad0858d73e0bcafe1 Author: Andreas Schwab Date: Fri Aug 9 15:14:08 2013 +0200 m68k: Truncate base in do_div() commit ea077b1b96e073eac5c3c5590529e964767fc5f7 upstream. Explicitly truncate the second operand of do_div() to 32 bits to guard against bogus code calling it with a 64-bit divisor. [Thorsten] After upgrading from 3.2 to 3.10, mounting a btrfs volume fails with: btrfs: setting nodatacow, compression disabled btrfs: enabling auto recovery btrfs: disk space caching is enabled *** ZERO DIVIDE *** FORMAT=2 Current process id is 722 BAD KERNEL TRAP: 00000000 Modules linked in: evdev mac_hid ext4 crc16 jbd2 mbcache btrfs xor lzo_compress zlib_deflate raid6_pq crc32c libcrc32c PC: [<319535b2>] __btrfs_map_block+0x11c/0x119a [btrfs] SR: 2000 SP: 30c1fab4 a2: 30f0faf0 d0: 00000000 d1: 00001000 d2: 00000000 d3: 00000000 d4: 00010000 d5: 00000000 a0: 3085c72c a1: 3085c72c Process mount (pid: 722, task=30f0faf0) Frame format=2 instr addr=319535ae Stack from 30c1faec: 00000000 00000020 00000000 00001000 00000000 01401000 30253928 300ffc00 00a843ac 3026f640 00000000 00010000 0009e250 00d106c0 00011220 00000000 00001000 301c6830 0009e32a 000000ff 00000009 3085c72c 00000000 00000000 30c1fd14 00000000 00000020 00000000 30c1fd14 0009e26c 00000020 00000003 00000000 0009dd8a 300b0b6c 30253928 00a843ac 00001000 00000000 00000000 0000a008 3194e76a 30253928 00a843ac 00001000 00000000 00000000 00000002 Call Trace: [<00001000>] kernel_pg_dir+0x0/0x1000 [...] Code: 222e ff74 2a2e ff5c 2c2e ff60 4c45 1402 <2d40> ff64 2d41 ff68 2205 4c2e 1800 ff68 4c04 0800 2041 d1c0 2206 4c2e 1400 ff68 [Geert] As diagnosed by Andreas, fs/btrfs/volumes.c:__btrfs_map_block() calls do_div(stripe_nr, stripe_len); with stripe_len u64, while do_div() assumes the divisor is a 32-bit number. Due to the lack of truncation in the m68k-specific implementation of do_div(), the division is performed using the upper 32-bit word of stripe_len, which is zero. This was introduced by commit 53b381b3abeb86f12787a6c40fee9b2f71edc23b ("Btrfs: RAID5 and RAID6"), which changed the divisor from map->stripe_len (struct map_lookup.stripe_len is int) to a 64-bit temporary. Reported-by: Thorsten Glaser Signed-off-by: Andreas Schwab Tested-by: Thorsten Glaser Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit 2a9a85d5fb90db72d8e0618a0fafa2069be86198 Author: Linus Torvalds Date: Sat Apr 27 13:25:38 2013 -0700 vm: add no-mmu vm_iomap_memory() stub commit 3c0b9de6d37a481673e81001c57ca0e410c72346 upstream. I think we could just move the full vm_iomap_memory() function into util.h or similar, but I didn't get any reply from anybody actually using nommu even to this trivial patch, so I'm not going to touch it any more than required. Here's the fairly minimal stub to make the nommu case at least potentially work. It doesn't seem like anybody cares, though. Signed-off-by: Linus Torvalds Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 0e69b54fa8b48e3cdc1a78f77beab3af763a33a1 Author: Linus Walleij Date: Tue Sep 6 07:45:46 2011 +0100 ARM: 7080/1: l2x0: make sure I&D are not locked down on init commit bac7e6ecf60933b68af910eb4c83a775a8b20b19 upstream. Fighting unfixed U-Boots and other beasts that may the cache in a locked-down state when starting the kernel, we make sure to disable all cache lock-down when initializing the l2x0 so we are in a known state. Reviewed-by: Santosh Shilimkar Reported-by: Jan Rinze Cc: Srinidhi Kasagar Cc: Rabin Vincent Cc: Adrian Bunk Cc: Rob Herring Cc: Catalin Marinas Cc: Will Deacon Tested-by: Robert Marklund Signed-off-by: Linus Walleij Signed-off-by: Russell King Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 3fa539e24c5d7077791a1d6bd8bb28bf86bef932 Author: Geert Uytterhoeven Date: Fri Jul 26 00:08:25 2013 +0200 m68k/atari: ARAnyM - Fix NatFeat module support commit e8184e10f89736a23ea6eea8e24cd524c5c513d2 upstream. As pointed out by Andreas Schwab, pointers passed to ARAnyM NatFeat calls should be physical addresses, not virtual addresses. Fortunately on Atari, physical and virtual kernel addresses are the same, as long as normal kernel memory is concerned, so this usually worked fine without conversion. But for modules, pointers to literal strings are located in vmalloc()ed memory. Depending on the version of ARAnyM, this causes the nf_get_id() call to just fail, or worse, crash ARAnyM itself with e.g. Gotcha! Illegal memory access. Atari PC = $968c This is a big issue for distro kernels, who want to have all drivers as loadable modules in an initrd. Add a wrapper for nf_get_id() that copies the literal to the stack to work around this issue. Reported-by: Thorsten Glaser Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit fc1e43e5cbee9f14ee940044d0e4e722370009d2 Author: Anton Blanchard Date: Thu Jun 30 13:55:27 2011 +0000 powerpc: Use -mtraceback=no commit af9719c3062dfe216a0c3de3fa52be6d22b4456c upstream. gcc 4.7 will be more strict about parsing the -mtraceback option: gcc: error: unrecognized argument in option '-mtraceback=none' gcc: note: valid arguments to '-mtraceback=' are: full no part gcc used to do a 2 char compare so both "no" and "none" would match. Switch to using -mtraceback=no should work everywhere. Signed-off-by: Anton Blanchard Signed-off-by: Benjamin Herrenschmidt Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 3a2f18948f8e7ef5b90c654c09e237027e1e0645 Author: David S. Miller Date: Sat May 19 15:27:01 2012 -0700 sparc32: Add ucmpdi2.o to obj-y instead of lib-y. commit 74c7b28953d4eaa6a479c187aeafcfc0280da5e8 upstream. Otherwise if no references exist in the static kernel image, we won't export the symbol properly to modules. Signed-off-by: David S. Miller Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit ec982038bd3b0620090e80075be2b5bb5dd26872 Author: Sam Ravnborg Date: Sat May 19 11:54:11 2012 +0200 sparc32: add ucmpdi2 commit de36e66d5fa52bc6e2dacd95c701a1762b5308a7 upstream. Based on copy from microblaze add ucmpdi2 implementation. This fixes build of niu driver which failed with: drivers/built-in.o: In function `niu_get_nfc': niu.c:(.text+0x91494): undefined reference to `__ucmpdi2' This driver will never be used on a sparc32 system, but patch added to fix build breakage with all*config builds. Signed-off-by: Sam Ravnborg Signed-off-by: David S. Miller Cc: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit d808cb7d6aacff9e39d6d1a4e4ad54ad0a47e901 Author: Johan Hovold Date: Tue Aug 13 13:27:34 2013 +0200 USB: mos7720: fix broken control requests commit ef6c8c1d733e244f0499035be0dabe1f4ed98c6f upstream. The parallel-port code of the drivers used a stack allocated control-request buffer for asynchronous (and possibly deferred) control requests. This not only violates the no-DMA-from-stack requirement but could also lead to corrupt control requests being submitted. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit fc1cabf00e9fd2fbfaf4d4df246f53138ccf3a0d Author: Oliver Neukum Date: Wed Aug 14 11:01:46 2013 +0200 usb: add two quirky touchscreen commit 304ab4ab079a8ed03ce39f1d274964a532db036b upstream. These devices tend to become unresponsive after S3 Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman commit bba2a9f0d381e510ba32f2f984e5ae1e705c90d1 Author: Johannes Berg Date: Tue Aug 13 09:04:05 2013 +0200 genetlink: fix family dump race commit 58ad436fcf49810aa006016107f494c9ac9013db upstream. When dumping generic netlink families, only the first dump call is locked with genl_lock(), which protects the list of families, and thus subsequent calls can access the data without locking, racing against family addition/removal. This can cause a crash. Fix it - the locking needs to be conditional because the first time around it's already locked. A similar bug was reported to me on an old kernel (3.4.47) but the exact scenario that happened there is no longer possible, on those kernels the first round wasn't locked either. Looking at the current code I found the race described above, which had also existed on the old kernel. Reported-by: Andrei Otcheretianski Signed-off-by: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e00f3fdc81f21fe6de883c647aff2efcd6945de4 Author: Nicolas Dichtel Date: Mon Feb 18 16:24:20 2013 +0100 af_key: initialize satype in key_notify_policy_flush() commit 85dfb745ee40232876663ae206cba35f24ab2a40 upstream. This field was left uninitialized. Some user daemons perform check against this field. Signed-off-by: Nicolas Dichtel Signed-off-by: Steffen Klassert Cc: Luis Henriques Signed-off-by: Greg Kroah-Hartman commit bd874f70e245977197782bc0e03c658f3e93573b Author: Jesper Nilsson Date: Mon Oct 24 11:19:25 2011 +0200 CRIS: Add _sdata to vmlinux.lds.S commit 473e162eea465e60578edb93341752e7f1c1dacc upstream. Fixes link error: LD vmlinux kernel/built-in.o: In function `core_kernel_data': (.text+0x13e44): undefined reference to `_sdata' Signed-off-by: Jesper Nilsson Cc: Guenter Roeck Cc: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman commit 481101ccce3d7cb2247ff29fc7b8ae1916deeae4 Author: Zhang Yi Date: Tue Jun 25 21:19:31 2013 +0800 futex: Take hugepages into account when generating futex_key commit 13d60f4b6ab5b702dc8d2ee20999f98a93728aec upstream. The futex_keys of process shared futexes are generated from the page offset, the mapping host and the mapping index of the futex user space address. This should result in an unique identifier for each futex. Though this is not true when futexes are located in different subpages of an hugepage. The reason is, that the mapping index for all those futexes evaluates to the index of the base page of the hugetlbfs mapping. So a futex at offset 0 of the hugepage mapping and another one at offset PAGE_SIZE of the same hugepage mapping have identical futex_keys. This happens because the futex code blindly uses page->index. Steps to reproduce the bug: 1. Map a file from hugetlbfs. Initialize pthread_mutex1 at offset 0 and pthread_mutex2 at offset PAGE_SIZE of the hugetlbfs mapping. The mutexes must be initialized as PTHREAD_PROCESS_SHARED because PTHREAD_PROCESS_PRIVATE mutexes are not affected by this issue as their keys solely depend on the user space address. 2. Lock mutex1 and mutex2 3. Create thread1 and in the thread function lock mutex1, which results in thread1 blocking on the locked mutex1. 4. Create thread2 and in the thread function lock mutex2, which results in thread2 blocking on the locked mutex2. 5. Unlock mutex2. Despite the fact that mutex2 got unlocked, thread2 still blocks on mutex2 because the futex_key points to mutex1. To solve this issue we need to take the normal page index of the page which contains the futex into account, if the futex is in an hugetlbfs mapping. In other words, we calculate the normal page mapping index of the subpage in the hugetlbfs mapping. Mappings which are not based on hugetlbfs are not affected and still use page->index. Thanks to Mel Gorman who provided a patch for adding proper evaluation functions to the hugetlbfs code to avoid exposing hugetlbfs specific details to the futex code. [ tglx: Massaged changelog ] Signed-off-by: Zhang Yi Reviewed-by: Jiang Biao Tested-by: Ma Chenggong Reviewed-by: 'Mel Gorman' Acked-by: 'Darren Hart' Cc: 'Peter Zijlstra' Link: http://lkml.kernel.org/r/000101ce71a6%24a83c5880%24f8b50980%24@com Signed-off-by: Thomas Gleixner Cc: Mike Galbraith Signed-off-by: Greg Kroah-Hartman