commit a7c079f995c84a2d82e841098d6090483f30bd21 Author: Greg Kroah-Hartman Date: Fri Apr 12 09:39:02 2013 -0700 Linux 3.4.40 commit 678721a4794583c4d2c930b4390c472c8531171a Author: Tim Gardner Date: Mon Feb 18 12:56:28 2013 -0700 rt2x00: rt2x00pci_regbusy_read() - only print register access failure once commit 83589b30f1e1dc9898986293c9336b8ce1705dec upstream. BugLink: http://bugs.launchpad.net/bugs/1128840 It appears that when this register read fails it never recovers, so I think there is no need to repeat the same error message ad infinitum. Signed-off-by: Tim Gardner Cc: Ivo van Doorn Cc: Gertjan van Wingerde Cc: Helmut Schaa Cc: "John W. Linville" Cc: linux-wireless@vger.kernel.org Cc: users@rt2x00.serialmonkey.com Cc: netdev@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman commit 91c1bf8376b6536d98b1b5baa45aea151067fe7b Author: Wei Yongjun Date: Tue Apr 9 14:16:04 2013 +0800 can: gw: use kmem_cache_free() instead of kfree() commit 3480a2125923e4b7a56d79efc76743089bf273fc upstream. Memory allocated by kmem_cache_alloc() should be freed using kmem_cache_free(), not kfree(). Signed-off-by: Wei Yongjun Acked-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 0502f20f996b9f755a7356f744e844b82580d6a0 Author: Greg Kroah-Hartman Date: Wed Apr 10 15:21:39 2013 -0700 Revert "mwifiex: cancel cmd timer and free curr_cmd in shutdown process revert commit b9f1f48ce20a1b923429c216669d03b5a900a8cf which is commit 084c7189acb3f969c855536166042e27f5dd703f upstream. It shouldn't have been applied to the 3.4-stable tree. Reported-by: Ben Hutchings Cc: Marco Cesarano Reported-by: Bing Zhao Signed-off-by: Greg Kroah-Hartman commit cdc8958a19b38773292cb6916f77f1e3bdf6d0fc Author: Jan Stancek Date: Mon Apr 8 13:00:02 2013 -0700 mm: prevent mmap_cache race in find_vma() commit b6a9b7f6b1f21735a7456d534dc0e68e61359d2c upstream. find_vma() can be called by multiple threads with read lock held on mm->mmap_sem and any of them can update mm->mmap_cache. Prevent compiler from re-fetching mm->mmap_cache, because other readers could update it in the meantime: thread 1 thread 2 | find_vma() | find_vma() struct vm_area_struct *vma = NULL; | vma = mm->mmap_cache; | if (!(vma && vma->vm_end > addr | && vma->vm_start <= addr)) { | | mm->mmap_cache = vma; return vma; | ^^ compiler may optimize this | local variable out and re-read | mm->mmap_cache | This issue can be reproduced with gcc-4.8.0-1 on s390x by running mallocstress testcase from LTP, which triggers: kernel BUG at mm/rmap.c:1088! Call Trace: ([<000003d100c57000>] 0x3d100c57000) [<000000000023a1c0>] do_wp_page+0x2fc/0xa88 [<000000000023baae>] handle_pte_fault+0x41a/0xac8 [<000000000023d832>] handle_mm_fault+0x17a/0x268 [<000000000060507a>] do_protection_exception+0x1e2/0x394 [<0000000000603a04>] pgm_check_handler+0x138/0x13c [<000003fffcf1f07a>] 0x3fffcf1f07a Last Breaking-Event-Address: [<000000000024755e>] page_add_new_anon_rmap+0xc2/0x168 Thanks to Jakub Jelinek for his insight on gcc and helping to track this down. Signed-off-by: Jan Stancek Acked-by: David Rientjes Signed-off-by: Hugh Dickins Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 5592a94b44df6e6d48e34cfe596844637a2976ac Author: Vikram Mulukutla Date: Mon Jul 30 14:39:58 2012 -0700 panic: fix a possible deadlock in panic() commit 190320c3b6640d4104650f55ff69611e050ea06b upstream. panic_lock is meant to ensure that panic processing takes place only on one cpu; if any of the other cpus encounter a panic, they will spin waiting to be shut down. However, this causes a regression in this scenario: 1. Cpu 0 encounters a panic and acquires the panic_lock and proceeds with the panic processing. 2. There is an interrupt on cpu 0 that also encounters an error condition and invokes panic. 3. This second invocation fails to acquire the panic_lock and enters the infinite while loop in panic_smp_self_stop. Thus all panic processing is stopped, and the cpu is stuck for eternity in the while(1) inside panic_smp_self_stop. To address this, disable local interrupts with local_irq_disable before acquiring the panic_lock. This will prevent interrupt handlers from executing during the panic processing, thus avoiding this particular problem. Signed-off-by: Vikram Mulukutla Reviewed-by: Stephen Boyd Cc: Michael Holzheu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Cc: Paul Gortmaker Signed-off-by: Greg Kroah-Hartman commit ddcd89f15f9e85d5cd37c866a1c5da9a3ca204d1 Author: Richard Guy Briggs Date: Tue Feb 12 19:39:44 2013 +0000 thermal: return an error on failure to register thermal class commit da28d966f6aa942ae836d09729f76a1647932309 upstream. The return code from the registration of the thermal class is used to unallocate resources, but this failure isn't passed back to the caller of thermal_init. Return this failure back to the caller. This bug was introduced in changeset 4cb18728 which overwrote the return code when the variable was re-used to catch the return code of the registration of the genetlink thermal socket family. Signed-off-by: Richard Guy Briggs Signed-off-by: Zhang Rui Cc: Jonghwan Choi Signed-off-by: Greg Kroah-Hartman commit 1be4ce3c085dea6763036764db495149b8a00498 Author: Jan Beulich Date: Wed Apr 3 15:47:33 2013 +0100 x86: Fix rebuild with EFI_STUB enabled commit 918708245e92941df16a634dc201b407d12bcd91 upstream. eboot.o and efi_stub_$(BITS).o didn't get added to "targets", and hence their .cmd files don't get included by the build machinery, leading to the files always getting rebuilt. Rather than adding the two files individually, take the opportunity and add $(VMLINUX_OBJS) to "targets" instead, thus allowing the assignment at the top of the file to be shrunk quite a bit. At the same time, remove a pointless flags override line - the variable assigned to was misspelled anyway, and the options added are meaningless for assembly sources. [ hpa: the patch is not minimal, but I am taking it for -urgent anyway since the excess impact of the patch seems to be small enough. ] Signed-off-by: Jan Beulich Link: http://lkml.kernel.org/r/515C5D2502000078000CA6AD@nat28.tlf.novell.com Cc: Matthew Garrett Cc: Matt Fleming Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 2570f532003a1e9b955799e3c48041e08e9a189e Author: Arnd Bergmann Date: Wed Apr 3 21:53:57 2013 +0200 block: avoid using uninitialized value in from queue_var_store commit c678ef5286ddb5cf70384ad5af286b0afc9b73e1 upstream. As found by gcc-4.8, the QUEUE_SYSFS_BIT_FNS macro creates functions that use a value generated by queue_var_store independent of whether that value was set or not. block/blk-sysfs.c: In function 'queue_store_nonrot': block/blk-sysfs.c:244:385: warning: 'val' may be used uninitialized in this function [-Wmaybe-uninitialized] Unlike most other such warnings, this one is not a false positive, writing any non-number string into the sysfs files indeed has an undefined result, rather than returning an error. Signed-off-by: Arnd Bergmann Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 972595ab7bfc0f84a7408732ccadbb7cca8a9661 Author: Jussi Kivilinna Date: Thu Mar 28 21:54:03 2013 +0200 crypto: gcm - fix assumption that assoc has one segment commit d3dde52209ab571e4e2ec26c66f85ad1355f7475 upstream. rfc4543(gcm(*)) code for GMAC assumes that assoc scatterlist always contains only one segment and only makes use of this first segment. However ipsec passes assoc with three segments when using 'extended sequence number' thus in this case rfc4543(gcm(*)) fails to function correctly. Patch fixes this issue. Reported-by: Chaoxing Lin Tested-by: Chaoxing Lin Signed-off-by: Jussi Kivilinna Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit a227904b82c591bf9531b9deac1e60fbe96abfed Author: Linus Torvalds Date: Tue Apr 9 10:48:33 2013 -0700 spinlocks and preemption points need to be at least compiler barriers commit 386afc91144b36b42117b0092893f15bc8798a80 upstream. In UP and non-preempt respectively, the spinlocks and preemption disable/enable points are stubbed out entirely, because there is no regular code that can ever hit the kind of concurrency they are meant to protect against. However, while there is no regular code that can cause scheduling, we _do_ end up having some exceptional (literally!) code that can do so, and that we need to make sure does not ever get moved into the critical region by the compiler. In particular, get_user() and put_user() is generally implemented as inline asm statements (even if the inline asm may then make a call instruction to call out-of-line), and can obviously cause a page fault and IO as a result. If that inline asm has been scheduled into the middle of a preemption-safe (or spinlock-protected) code region, we obviously lose. Now, admittedly this is *very* unlikely to actually ever happen, and we've not seen examples of actual bugs related to this. But partly exactly because it's so hard to trigger and the resulting bug is so subtle, we should be extra careful to get this right. So make sure that even when preemption is disabled, and we don't have to generate any actual *code* to explicitly tell the system that we are in a preemption-disabled region, we need to at least tell the compiler not to move things around the critical region. This patch grew out of the same discussion that caused commits 79e5f05edcbf ("ARC: Add implicit compiler barrier to raw_local_irq* functions") and 3e2e0d2c222b ("tile: comment assumption about __insn_mtspr for ") to come about. Note for stable: use discretion when/if applying this. As mentioned, this bug may never have actually bitten anybody, and gcc may never have done the required code motion for it to possibly ever trigger in practice. Signed-off-by: Linus Torvalds Cc: Steven Rostedt Cc: Peter Zijlstra Signed-off-by: Greg Kroah-Hartman commit 261c874090bde0efb5040608d8123d5f0fadcac8 Author: Li Fei Date: Fri Apr 5 21:20:36 2013 +0800 hwspinlock: fix __hwspin_lock_request error path commit c10b90d85a5126d25c89cbaa50dc9fdd1c4d001a upstream. Even in failed case of pm_runtime_get_sync, the usage_count is incremented. In order to keep the usage_count with correct value and runtime power management to behave correctly, call pm_runtime_put_noidle in such case. In __hwspin_lock_request, module_put is also called before return in pm_runtime_get_sync failed case. Signed-off-by Liu Chuansheng Signed-off-by: Li Fei [edit commit log] Signed-off-by: Ohad Ben-Cohen Signed-off-by: Greg Kroah-Hartman commit cb96c7c61655ef19d33339f718287a2c2a321e1b Author: Paul Moore Date: Fri Feb 15 12:21:43 2013 -0500 x86: remove the x32 syscall bitmask from syscall_get_nr() commit 8b4b9f27e57584f3d90e0bb84cf800ad81cfe3a1 upstream. Commit fca460f95e928bae373daa8295877b6905bc62b8 simplified the x32 implementation by creating a syscall bitmask, equal to 0x40000000, that could be applied to x32 syscalls such that the masked syscall number would be the same as a x86_64 syscall. While that patch was a nice way to simplify the code, it went a bit too far by adding the mask to syscall_get_nr(); returning the masked syscall numbers can cause confusion with callers that expect syscall numbers matching the x32 ABI, e.g. unmasked syscall numbers. This patch fixes this by simply removing the mask from syscall_get_nr() while preserving the other changes from the original commit. While there are several syscall_get_nr() callers in the kernel, most simply check that the syscall number is greater than zero, in this case this patch will have no effect. Of those remaining callers, they appear to be few, seccomp and ftrace, and from my testing of seccomp without this patch the original commit definitely breaks things; the seccomp filter does not correctly filter the syscalls due to the difference in syscall numbers in the BPF filter and the value from syscall_get_nr(). Applying this patch restores the seccomp BPF filter functionality on x32. I've tested this patch with the seccomp BPF filters as well as ftrace and everything looks reasonable to me; needless to say general usage seemed fine as well. Signed-off-by: Paul Moore Link: http://lkml.kernel.org/r/20130215172143.12549.10292.stgit@localhost Cc: Will Drewry Cc: H. Peter Anvin Signed-off-by: H. Peter Anvin Signed-off-by: Greg Kroah-Hartman commit 97bab7f423c780683542c953aa2c16088c036a4a Author: Michael Wolf Date: Fri Apr 5 10:41:40 2013 +0000 powerpc: pSeries_lpar_hpte_remove fails from Adjunct partition being performed before the ANDCOND test commit 9fb2640159f9d4f5a2a9d60e490482d4cbecafdb upstream. Some versions of pHyp will perform the adjunct partition test before the ANDCOND test. The result of this is that H_RESOURCE can be returned and cause the BUG_ON condition to occur. The HPTE is not removed. So add a check for H_RESOURCE, it is ok if this HPTE is not removed as pSeries_lpar_hpte_remove is looking for an HPTE to remove and not a specific HPTE to remove. So it is ok to just move on to the next slot and try again. Signed-off-by: Michael Wolf Signed-off-by: Stephen Rothwell Signed-off-by: Greg Kroah-Hartman commit b81d3241838167667fc1ec9bb5670d5f661a3628 Author: Jan Kiszka Date: Tue Mar 26 17:53:03 2013 +0100 ftrace: Consistently restore trace function on sysctl enabling commit 5000c418840b309251c5887f0b56503aae30f84c upstream. If we reenable ftrace via syctl, we currently set ftrace_trace_function based on the previous simplistic algorithm. This is inconsistent with what update_ftrace_function does. So better call that helper instead. Link: http://lkml.kernel.org/r/5151D26F.1070702@siemens.com Signed-off-by: Jan Kiszka Signed-off-by: Steven Rostedt Signed-off-by: Greg Kroah-Hartman commit b26bcbe0a7bba3321cefa4c9936e05cb58df03cb Author: Youquan Song Date: Wed Mar 6 10:49:05 2013 -0500 ata_piix: Fix DVD not dectected at some Haswell platforms commit b55f84e2d527182e7c611d466cd0bb6ddce201de upstream. There is a quirk patch 5e5a4f5d5a08c9c504fe956391ac3dae2c66556d "ata_piix: make DVD Drive recognisable on systems with Intel Sandybridge chipsets(v2)" fixing the 4 ports IDE controller 32bit PIO mode. We've hit a problem with DVD not recognized on Haswell Desktop platform which includes Lynx Point 2-port SATA controller. This quirk patch disables 32bit PIO on this controller in IDE mode. v2: Change spelling error in statememnt pointed by Sergei Shtylyov. v3: Change comment statememnt and spliting line over 80 characters pointed by Libor Pechacek and also rebase the patch against 3.8-rc7 kernel. Tested-by: Lee, Chun-Yi Signed-off-by: Youquan Song Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 5a5fdfaf6f334302f0857537debedd381013d3d4 Author: Jay Estabrook Date: Sun Apr 7 21:36:09 2013 +1200 alpha: Add irongate_io to PCI bus resources commit aa8b4be3ac049c8b1df2a87e4d1d902ccfc1f7a9 upstream. Fixes a NULL pointer dereference at boot on UP1500. Reviewed-and-Tested-by: Matt Turner Signed-off-by: Jay Estabrook Signed-off-by: Matt Turner Signed-off-by: Michael Cree Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 284aeebb312c2b2464673bf68b9a32e415b5145a Author: Shan Hai Date: Mon Mar 18 10:30:44 2013 +0800 libata: Set max sector to 65535 for Slimtype DVD A DS8A8SH drive commit a32450e127fc6e5ca6d958ceb3cfea4d30a00846 upstream. The Slimtype DVD A DS8A8SH drive locks up when max sector is smaller than 65535, and the blow backtrace is observed on locking up: INFO: task flush-8:32:1130 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. flush-8:32 D ffffffff8180cf60 0 1130 2 0x00000000 ffff880273aef618 0000000000000046 0000000000000005 ffff880273aee000 ffff880273aee000 ffff880273aeffd8 ffff880273aee010 ffff880273aee000 ffff880273aeffd8 ffff880273aee000 ffff88026e842ea0 ffff880274a10000 Call Trace: [] schedule+0x5d/0x70 [] io_schedule+0x8c/0xd0 [] get_request+0x731/0x7d0 [] ? cfq_allow_merge+0x50/0x90 [] ? wake_up_bit+0x40/0x40 [] ? bio_attempt_back_merge+0x33/0x110 [] blk_queue_bio+0x23a/0x3f0 [] generic_make_request+0xc6/0x120 [] submit_bio+0x138/0x160 [] ? bio_alloc_bioset+0x96/0x120 [] submit_bh+0x1f1/0x220 [] __block_write_full_page+0x228/0x340 [] ? attach_nobh_buffers+0xc0/0xc0 [] ? I_BDEV+0x10/0x10 [] ? I_BDEV+0x10/0x10 [] block_write_full_page_endio+0xe6/0x100 [] block_write_full_page+0x15/0x20 [] blkdev_writepage+0x18/0x20 [] __writepage+0x17/0x40 [] write_cache_pages+0x34a/0x4a0 [] ? set_page_dirty+0x70/0x70 [] generic_writepages+0x51/0x80 [] do_writepages+0x20/0x50 [] __writeback_single_inode+0xa6/0x2b0 [] writeback_sb_inodes+0x311/0x4d0 [] __writeback_inodes_wb+0x86/0xd0 [] wb_writeback+0x1a3/0x330 [] ? _raw_spin_lock_irqsave+0x3f/0x50 [] ? get_nr_inodes+0x52/0x70 [] wb_do_writeback+0x1dc/0x260 [] ? schedule_timeout+0x204/0x240 [] bdi_writeback_thread+0x102/0x2b0 [] ? wb_do_writeback+0x260/0x260 [] kthread+0xc0/0xd0 [] ? kthread_worker_fn+0x1b0/0x1b0 [] ret_from_fork+0x7c/0xb0 [] ? kthread_worker_fn+0x1b0/0x1b0 The above trace was triggered by "dd if=/dev/zero of=/dev/sr0 bs=2048 count=32768" It was previously working by accident, since another bug introduced by 4dce8ba94c7 (libata: Use 'bool' return value for ata_id_XXX) caused all drives to use maxsect=65535. Signed-off-by: Shan Hai Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 57b41f6193014b2a4a67c270dd77d801fd337d98 Author: Shan Hai Date: Mon Mar 18 10:30:43 2013 +0800 libata: Use integer return value for atapi_command_packet_set commit d8668fcb0b257d9fdcfbe5c172a99b8d85e1cd82 upstream. The function returns type of ATAPI drives so it should return integer value. The commit 4dce8ba94c7 (libata: Use 'bool' return value for ata_id_XXX) since v2.6.39 changed the type of return value from int to bool, the change would cause all of the ATAPI class drives to be treated as TYPE_TAPE and the max_sectors of the drives to be set to 65535 because of the commit f8d8e5799b7(libata: increase 128 KB / cmd limit for ATAPI tape drives), for the function would return true for all ATAPI class drives and the TYPE_TAPE is defined as 0x01. Signed-off-by: Shan Hai Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman commit 91777f102bc6c5d72bf637281b74ba96c1447850 Author: Yinghai Lu Date: Mon Apr 1 11:48:59 2013 -0600 EISA/PCI: Fix bus res reference commit 2cfda637e29ce9e3df31b59f64516b2e571cc985 upstream. Matthew found that 3.8.3 is having problems with an old (ancient) PCI-to-EISA bridge, the Intel 82375. It worked with the 3.2 kernel. He identified the 82375, but doesn't assign the struct resource *res pointer inside the struct eisa_root_device, and panics. pci_eisa_init() was using bus->resource[] directly instead of pci_bus_resource_n(). The bus->resource[] array is a PCI-internal implementation detail, and after commit 45ca9e97 (PCI: add helpers for building PCI bus resource lists) and commit 0efd5aab (PCI: add struct pci_host_bridge_window with CPU/bus address offset), bus->resource[] is not used for PCI root buses any more. The 82375 is a subtractive-decode PCI device, so handle it the same way we handle PCI-PCI bridges in subtractive-decode mode in pci_read_bridge_bases(). [bhelgaas: changelog] Reported-by: Matthew Whitehead Tested-by: Matthew Whitehead Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 27bd92ff68526e05f50490a708693e319c29f332 Author: Yinghai Lu Date: Wed Mar 27 21:28:05 2013 -0700 EISA/PCI: Init EISA early, before PNP commit c5fb301ae83bec6892e54984e6ec765c47df8e10 upstream. Matthew reported kernels fail the pci_eisa probe and are later successful with the virtual_eisa_root_init force probe without slot0. The reason for that is: PNP probing is before pci_eisa_init gets called as pci_eisa_init is called via pci_driver. pnp 00:0f has 0xc80 - 0xc84 reserved. [ 9.700409] pnp 00:0f: [io 0x0c80-0x0c84] so eisa_probe will fail from pci_eisa_init ==>eisa_root_register ==>eisa_probe path. as force_probe is not set in pci_eisa_root, it will bail early when slot0 is not probed and initialized. Try to use subsys_initcall_sync instead, and will keep following sequence: pci_subsys_init pci_eisa_init_early pnpacpi_init/isapnp_init After this patch EISA can be initialized properly, and PNP overlapping resource will not be reserved. [ 10.104434] system 00:0f: [io 0x0c80-0x0c84] could not be reserved Reported-by: Matthew Whitehead Tested-by: Matthew Whitehead Signed-off-by: Yinghai Lu Signed-off-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 54144193ab339572e21719ca327afb6583cda537 Author: David Henningsson Date: Thu Apr 4 11:47:13 2013 +0200 ALSA: hda - fix typo in proc output commit aeb3a97222832e5457c4b72d72235098ce4bfe8d upstream. Rename "Digitial In" to "Digital In". This function is only used for proc output, so should not cause any problems to change. Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3379d5230307b19c32401da4ac05d95770e80872 Author: Rainer Koenig Date: Thu Apr 4 08:40:38 2013 +0200 ALSA: hda - Enabling Realtek ALC 671 codec commit 1d87caa69c04008e09f5ff47b5e6acb6116febc7 upstream. * Added the device ID to the modalias list and assinged ALC662 patches for it * Added 4 port support for the device ID 0671 in alc662_parse_auto_config Signed-off-by: Rainer Koenig Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 276674490c2f110d12c7009bb6d74757a678cd0c Author: Mengdong Lin Date: Thu Mar 28 05:20:22 2013 -0400 ALSA: hda - bug fix on return value when getting HDMI ELD info commit 2ef5692efad330b67a234e2c49edad38538751e7 upstream. In function snd_hdmi_get_eld(), the variable 'ret' should be initialized to 0. Otherwise it will be returned uninitialized as non-zero after ELD info is got successfully. Thus hdmi_present_sense() will always assume ELD info is invalid by mistake, and /proc file system cannot show the proper ELD info. Signed-off-by: Mengdong Lin Acked-by: David Henningsson Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b57644a59a635af74fde8e4548754de338752422 Author: Jan Kara Date: Fri Mar 29 15:39:16 2013 +0100 reiserfs: Fix warning and inode leak when deleting inode with xattrs commit 35e5cbc0af240778e61113286c019837e06aeec6 upstream. After commit 21d8a15a (lookup_one_len: don't accept . and ..) reiserfs started failing to delete xattrs from inode. This was due to a buggy test for '.' and '..' in fill_with_dentries() which resulted in passing '.' and '..' entries to lookup_one_len() in some cases. That returned error and so we failed to iterate over all xattrs of and inode. Fix the test in fill_with_dentries() along the lines of the one in lookup_one_len(). Reported-by: Pawel Zawora Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 0d18994cb19855aa6ea892985c19aa54e4192fb0 Author: Artem Bityutskiy Date: Thu Mar 14 10:49:23 2013 +0200 UBIFS: make space fixup work in the remount case commit 67e753ca41782913d805ff4a8a2b0f60b26b7915 upstream. The UBIFS space fixup is a useful feature which allows to fixup the "broken" flash space at the time of the first mount. The "broken" space is usually the result of using a "dumb" industrial flasher which is not able to skip empty NAND pages and just writes all 0xFFs to the empty space, which has grave side-effects for UBIFS when UBIFS trise to write useful data to those empty pages. The fix-up feature works roughly like this: 1. mkfs.ubifs sets the fixup flag in UBIFS superblock when creating the image (see -F option) 2. when the file-system is mounted for the first time, UBIFS notices the fixup flag and re-writes the entire media atomically, which may take really a lot of time. 3. UBIFS clears the fixup flag in the superblock. This works fine when the file system is mounted R/W for the very first time. But it did not really work in the case when we first mount the file-system R/O, and then re-mount R/W. The reason was that we started the fixup procedure too late, which we cannot really do because we have to fixup the space before it starts being used. Signed-off-by: Artem Bityutskiy Reported-by: Mark Jackson Signed-off-by: Greg Kroah-Hartman commit a41c384e8308a7d25fa778f0b24656ef50e05766 Author: Anatolij Gustschin Date: Wed Mar 13 14:57:43 2013 +0100 spi/mpc512x-psc: optionally keep PSC SS asserted across xfer segmensts commit 1ad849aee5f53353ed88d9cd3d68a51b03a7d44f upstream. Some SPI slave devices require asserted chip select signal across multiple transfer segments of an SPI message. Currently the driver always de-asserts the internal SS signal for every single transfer segment of the message and ignores the 'cs_change' flag of the transfer description. Disable the internal chip select (SS) only if this is needed and indicated by the 'cs_change' flag. Without this change, each partial transfer of a surrounding multi-part SPI transaction might erroneously change the SS signal, which might prevent slaves from answering the request that was sent in a previous transfer segment because the transaction could be considered aborted (SS was de-asserted before reading the response). Reported-by: Gerhard Sittig Signed-off-by: Anatolij Gustschin Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit c8c76a4e4615ae959543cc8332339384ccb4f192 Author: Girish K S Date: Wed Mar 13 12:13:30 2013 +0530 spi/s3c64xx: modified error interrupt handling and init commit 375981f2e14868be16cafbffd34a4f16a6ee01c6 upstream. The status of the interrupt is available in the status register, so reading the clear pending register and writing back the same value will not actually clear the pending interrupts. This patch modifies the interrupt handler to read the status register and clear the corresponding pending bit in the clear pending register. Modified the hwInit function to clear all the pending interrupts. Signed-off-by: Girish K S Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 6ec0e8e15ecc310464185db7820c5d30be409d1e Author: Lars-Peter Clausen Date: Wed Mar 13 16:38:33 2013 +0100 regmap: cache Fix regcache-rbtree sync commit 8abac3ba51b5525354e9b2ec0eed1c9e95c905d9 upstream. The last register block, which falls into the specified range, is not handled correctly. The formula which calculates the number of register which should be synced is inverse (and off by one). E.g. if all registers in that block should be synced only one is synced, and if only one should be synced all (but one) are synced. To calculate the number of registers that need to be synced we need to subtract the number of the first register in the block from the max register number and add one. This patch updates the code accordingly. The issue was introduced in commit ac8d91c ("regmap: Supply ranges to the sync operations"). Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 93c86c4916e247e5e8de4d98c0e855d664e41468 Author: Lars-Peter Clausen Date: Fri Mar 15 11:26:15 2013 +0100 ASoC: dma-sh7760: Fix compile error commit 417a1178f1bf3cdc606376b3ded3a22489fbb3eb upstream. The dma-sh7760 currently fails with the following compile error: sound/soc/sh/dma-sh7760.c:346:2: error: unknown field 'pcm_ops' specified in initializer sound/soc/sh/dma-sh7760.c:346:2: warning: initialization from incompatible pointer type sound/soc/sh/dma-sh7760.c:347:2: error: unknown field 'pcm_new' specified in initializer sound/soc/sh/dma-sh7760.c:347:2: warning: initialization makes integer from pointer without a cast sound/soc/sh/dma-sh7760.c:348:2: error: unknown field 'pcm_free' specified in initializer sound/soc/sh/dma-sh7760.c:348:2: warning: initialization from incompatible pointer type sound/soc/sh/dma-sh7760.c: In function 'sh7760_soc_platform_probe': sound/soc/sh/dma-sh7760.c:353:2: warning: passing argument 2 of 'snd_soc_register_platform' from incompatible pointer type include/sound/soc.h:368:5: note: expected 'struct snd_soc_platform_driver *' but argument is of type 'struct snd_soc_platform *' This is due the misnaming of the snd_soc_platform_driver type name and 'ops' field. The issue was introduced in commit f0fba2a("ASoC: multi-component - ASoC Multi-Component Support"). Signed-off-by: Lars-Peter Clausen Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman