- 14 Mar, 2013 21 commits
-
-
Jeff Layton authored
commit ce2ac521 upstream. Kjell Braden reported this oops: [ 833.211970] BUG: unable to handle kernel NULL pointer dereference at (null) [ 833.212816] IP: [< (null)>] (null) [ 833.213280] PGD 1b9b2067 PUD e9f7067 PMD 0 [ 833.213874] Oops: 0010 [#1] SMP [ 833.214344] CPU 0 [ 833.214458] Modules linked in: des_generic md4 nls_utf8 cifs vboxvideo drm snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq bnep rfcomm snd_timer bluetooth snd_seq_device ppdev snd vboxguest parport_pc joydev mac_hid soundcore snd_page_alloc psmouse i2c_piix4 serio_raw lp parport usbhid hid e1000 [ 833.215629] [ 833.215629] Pid: 1752, comm: mount.cifs Not tainted 3.0.0-rc7-bisectcifs-fec11dd9+ #18 innotek GmbH VirtualBox/VirtualBox [ 833.215629] RIP: 0010:[<0000000000000000>] [< (null)>] (null) [ 833.215629] RSP: 0018:ffff8800119c9c50 EFLAGS: 00010282 [ 833.215629] RAX: ffffffffa02186c0 RBX: ffff88000c427780 RCX: 0000000000000000 [ 833.215629] RDX: 0000000000000000 RSI: ffff88000c427780 RDI: ffff88000c4362e8 [ 833.215629] RBP: ffff8800119c9c88 R08: ffff88001fc15e30 R09: 00000000d69515c7 [ 833.215629] R10: ffffffffa0201972 R11: ffff88000e8f6a28 R12: ffff88000c4362e8 [ 833.215629] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88001181aaa6 [ 833.215629] FS: 00007f2986171700(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000 [ 833.215629] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 833.215629] CR2: 0000000000000000 CR3: 000000001b982000 CR4: 00000000000006f0 [ 833.215629] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 833.215629] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 833.215629] Process mount.cifs (pid: 1752, threadinfo ffff8800119c8000, task ffff88001c1c16f0) [ 833.215629] Stack: [ 833.215629] ffffffff8116a9b5 ffff8800119c9c88 ffffffff81178075 0000000000000286 [ 833.215629] 0000000000000000 ffff88000c4276c0 ffff8800119c9ce8 ffff8800119c9cc8 [ 833.215629] ffffffff8116b06e ffff88001bc6fc00 ffff88000c4276c0 ffff88000c4276c0 [ 833.215629] Call Trace: [ 833.215629] [<ffffffff8116a9b5>] ? d_alloc_and_lookup+0x45/0x90 [ 833.215629] [<ffffffff81178075>] ? d_lookup+0x35/0x60 [ 833.215629] [<ffffffff8116b06e>] __lookup_hash.part.14+0x9e/0xc0 [ 833.215629] [<ffffffff8116b1d6>] lookup_one_len+0x146/0x1e0 [ 833.215629] [<ffffffff815e4f7e>] ? _raw_spin_lock+0xe/0x20 [ 833.215629] [<ffffffffa01eef0d>] cifs_do_mount+0x26d/0x500 [cifs] [ 833.215629] [<ffffffff81163bd3>] mount_fs+0x43/0x1b0 [ 833.215629] [<ffffffff8117d41a>] vfs_kern_mount+0x6a/0xd0 [ 833.215629] [<ffffffff8117e584>] do_kern_mount+0x54/0x110 [ 833.215629] [<ffffffff8117fdc2>] do_mount+0x262/0x840 [ 833.215629] [<ffffffff81108a0e>] ? __get_free_pages+0xe/0x50 [ 833.215629] [<ffffffff8117f9ca>] ? copy_mount_options+0x3a/0x180 [ 833.215629] [<ffffffff8118075d>] sys_mount+0x8d/0xe0 [ 833.215629] [<ffffffff815ece82>] system_call_fastpath+0x16/0x1b [ 833.215629] Code: Bad RIP value. [ 833.215629] RIP [< (null)>] (null) [ 833.215629] RSP <ffff8800119c9c50> [ 833.215629] CR2: 0000000000000000 [ 833.238525] ---[ end trace ec00758b8d44f529 ]--- When walking down the path on the server, it's possible to hit a symlink. The path walking code assumes that the caller will handle that situation properly, but cifs_get_root() isn't set up for it. This patch prevents the oops by simply returning an error. A better solution would be to try and chase the symlinks here, but that's fairly complicated to handle. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=53221Reported-and-tested-by:
Kjell Braden <afflux@pentabarf.de> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Josef Bacik authored
commit 124fe663 upstream. Apparently when we do inline extents we allow the data to overlap the last chunk of the btrfs_file_extent_item, which means that we can possibly have a btrfs_file_extent_item that isn't actually as large as a btrfs_file_extent_item. This messes with us when we try to overwrite the extent when logging new extents since we expect for it to be the right size. To fix this just delete the item and try to do the insert again which will give us the proper sized btrfs_file_extent_item. This fixes a panic where map_private_extent_buffer would blow up because we're trying to write past the end of the leaf. Thanks, Signed-off-by:
Josef Bacik <jbacik@fusionio.com> Signed-off-by:
-
Josef Bacik authored
commit bdc20e67 upstream. I noticed while looking into a tree logging bug that we aren't logging inline extents properly. Since this requires copying and it shouldn't happen too often just force us to copy everything for the inode into the tree log when we have an inline extent. With this patch we have valid data after a crash when we write an inline extent. Thanks, Signed-off-by:
-
Thomas Gleixner authored
commit 1cba0cdf upstream. __btrfs_close_devices() clones btrfs device structs with memcpy(). Some of the fields in the clone are reinitialized, but it's missing to init io_lock. In mainline this goes unnoticed, but on RT it leaves the plist pointing to the original about to be freed lock struct. Initialize io_lock after cloning, so no references to the original struct are left. Reported-and-tested-by:
Mike Galbraith <efault@gmx.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Chris Mason <chris.mason@fusionio.com> Signed-off-by:
-
Lukas Czerner authored
commit 810da240 upstream. We're using macro EXT4_B2C() to convert number of blocks to number of clusters for bigalloc file systems. However, we should be using EXT4_NUM_B2C(). Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
Nicholas Bellinger authored
commit fd3a9025 upstream. This patch addresses a v3.5+ regression in iscsi-target where TX thread process context -> handle_response_queue() execution is allowed to run unbounded while servicing constant outgoing flow of ISTATE_SEND_DATAIN response state. This ends up preventing memory release of StatSN acknowledged commands in a timely manner when under heavy large block streaming DATAIN workloads. The regression bug was initially introduced with: commit 6f3c0e69 Author: Andy Grover <agrover@redhat.com> Date: Tue Apr 3 15:51:09 2012 -0700 target/iscsi: Refactor target_tx_thread immediate+response queue loops Go ahead and follow original iscsi_target_tx_thread() logic and check to break for immediate queue processing after each DataIN Sequence and/or Response PDU has been sent. Reported-by:
Benjamin ESTRABAUD <be@mpstor.com> Cc: Andy Grover <agrover@redhat.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Asias He authored
commit 472b72f2 upstream. The page++ is wrong. It makes bio_add_pc_page() pointing to a wrong page address if the 'while (len > 0 && data_len > 0) { ... }' loop is executed more than one once. Signed-off-by:
Asias He <asias@redhat.com> Signed-off-by:
-
K. Y. Srinivasan authored
commit 9d2696e6 upstream. Properly initialize scatterlist before using it. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Dan Carpenter authored
commit 208afec4 upstream. This bug was introduced back in bitkeeper days in 2003. We use "dcb->dev_mode" before it has been initialized. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Oliver Neukum <oliver@neukum.org> Signed-off-by:
-
Mattia Dongili authored
commit 3ec1c398 upstream. The call to handlers 0x124 and 0x135 (rfkill control) seems to take a bitmask to control various states of the device. For our rfkill we need a fully on/off. SVZ1311Z9R/X's LTE modem needs more bits up. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47751Signed-off-by:
Mattia Dongili <malattia@linux.it> Signed-off-by:
Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by:
-
Takahisa Tanaka authored
commit 41adafbd upstream. In case of SP5100 or SB7x0 chipsets, the sp5100_tco module writes zero to reserved bits. The module, however, shouldn't depend on specific default value, and should perform a read-merge-write operation for the reserved bits. This patch makes the sp5100_tco module perform a read-merge-write operation on all the chipset (sp5100, sb7x0, sb8x0 or later). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176Signed-off-by:
Takahisa Tanaka <mc74hc00@gmail.com> Tested-by:
Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Signed-off-by:
-
Takahisa Tanaka authored
commit 10ab329b upstream. In case of SB800 or later chipset and re-programming MMIO address(*), sp5100_tco module may read incorrect value of reserved bit, because the module reads a value from an incorrect I/O address. However, this bug doesn't cause a problem, because when re-programming MMIO address, by chance the module writes zero (this is BIOS's default value) to the low three bits of register. * In most cases, PC with SB8x0 or later chipset doesn't need to re-programming MMIO address, because such PC can enable AcpiMmio and can use 0xfed80b00 for watchdog register base address. This patch fixes this bug. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43176Signed-off-by:
-
Randy Dunlap authored
commit 12a5c05c upstream. DA9055_WATCHDOG (introduced in v3.8) needs to select WATCHDOG_CORE so that it will build cleanly. Fixes these build errors: da9055_wdt.c:(.text+0xe9bc7): undefined reference to `watchdog_unregister_device' da9055_wdt.c:(.text+0xe9f4b): undefined reference to `watchdog_register_device' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: David Dajun Chen <dchen@diasemi.com> Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit 884ac297 upstream. There is no hypercall to setup multiple MSI per PCI device. As such with these two new commits: - 08261d87 PCI/MSI: Enable multiple MSIs with pci_enable_msi_block_auto() - 5ca72c4f AHCI: Support multiple MSIs we would call the PHYSDEVOP_map_pirq 'nvec' times with the same contents of the PCI device. Sander discovered that we would get the same PIRQ value 'nvec' times and return said values to the caller. That of course meant that the device was configured only with one MSI and AHCI would fail with: ahci 0000:00:11.0: version 3.0 xen: registering gsi 19 triggering 0 polarity 1 xen: --> pirq=19 -> irq=19 (gsi=19) (XEN) [2013-02-27 19:43:07] IOAPIC[0]: Set PCI routing entry (6-19 -> 0x99 -> IRQ 19 Mode:1 Active:1) ahci 0000:00:11.0: AHCI 0001.0200 32 slots 4 ports 6 Gbps 0xf impl SATA mode ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ahci: probe of 0000:00:11.0 failed with error -22 That is b/c in ahci_host_activate the second call to devm_request_threaded_irq would return -EINVAL as we passed in (on the second run) an IRQ that was never initialized. Reported-and-Tested-by:
Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
-
Konrad Rzeszutek Wilk authored
commit c79c4982 upstream. The git commit 8eaffa67 (xen/pat: Disable PAT support for now) explains in details why we want to disable PAT for right now. However that change was not enough and we should have also disabled the pat_enabled value. Otherwise we end up with: mmap-example:3481 map pfn expected mapping type write-back for [mem 0x00010000-0x00010fff], got uncached-minus ------------[ cut here ]------------ WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774 untrack_pfn+0xb8/0xd0() mem 0x00010000-0x00010fff], got uncached-minus ------------[ cut here ]------------ WARNING: at /build/buildd/linux-3.8.0/arch/x86/mm/pat.c:774 untrack_pfn+0xb8/0xd0() ... Pid: 3481, comm: mmap-example Tainted: GF 3.8.0-6-generic #13-Ubuntu Call Trace: [<ffffffff8105879f>] warn_slowpath_common+0x7f/0xc0 [<ffffffff810587fa>] warn_slowpath_null+0x1a/0x20 [<ffffffff8104bcc8>] untrack_pfn+0xb8/0xd0 [<ffffffff81156c1c>] unmap_single_vma+0xac/0x100 [<ffffffff81157459>] unmap_vmas+0x49/0x90 [<ffffffff8115f808>] exit_mmap+0x98/0x170 [<ffffffff810559a4>] mmput+0x64/0x100 [<ffffffff810560f5>] dup_mm+0x445/0x660 [<ffffffff81056d9f>] copy_process.part.22+0xa5f/0x1510 [<ffffffff81057931>] do_fork+0x91/0x350 [<ffffffff81057c76>] sys_clone+0x16/0x20 [<ffffffff816ccbf9>] stub_clone+0x69/0x90 [<ffffffff816cc89d>] ? system_call_fastpath+0x1a/0x1f ---[ end trace 4918cdd0a4c9fea4 ]--- (a similar message shows up if you end up launching 'mcelog') The call chain is (as analyzed by Liu, Jinsong): do_fork --> copy_process --> dup_mm --> dup_mmap --> copy_page_range --> track_pfn_copy --> reserve_pfn_range --> line 624: flags != want_flags It comes from different memory types of page table (_PAGE_CACHE_WB) and MTRR (_PAGE_CACHE_UC_MINUS). Stefan Bader dug in this deep and found out that: "That makes it clearer as this will do reserve_memtype(...) --> pat_x_mtrr_type --> mtrr_type_lookup --> __mtrr_type_lookup And that can return -1/0xff in case of MTRR not being enabled/initialized. Which is not the case (given there are no messages for it in dmesg). This is not equal to MTRR_TYPE_WRBACK and thus becomes _PAGE_CACHE_UC_MINUS. It looks like the problem starts early in reserve_memtype: if (!pat_enabled) { /* This is identical to page table setting without PAT */ if (new_type) { if (req_type == _PAGE_CACHE_WC) *new_type = _PAGE_CACHE_UC_MINUS; else *new_type = req_type & _PAGE_CACHE_MASK; } return 0; } This would be what we want, that is clearing the PWT and PCD flags from the supported flags - if pat_enabled is disabled." This patch does that - disabling PAT. Reported-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
-
Steven Noonan authored
commit 45e27161 upstream. Adding an include of linux/mm.h resolves this: drivers/xen/xenbus/xenbus_client.c: In function ‘xenbus_map_ring_valloc_hvm’: drivers/xen/xenbus/xenbus_client.c:532:66: error: implicit declaration of function ‘page_to_section’ [-Werror=implicit-function-declaration] Signed-off-by:
Steven Noonan <steven@uplinklabs.net> Signed-off-by:
-
Alan Stern authored
commit 221f8dfc upstream. This patch (as1649) reverts commit 55bcdce8 (USB: EHCI: remove ASS/PSS polling timeout). That commit was written under the assumption that some controllers may take a very long time to turn off their async and periodic schedules. It now appears that in fact the schedules do get turned off reasonably quickly, but some controllers occasionally leave the schedules' status bits turned on and consequently ehci-hcd can't tell that the schedules are off. VIA controllers in particular have this problem. ehci-hcd tells the hardware to turn off the async schedule, the schedule does get turned off, but the status bit remains on. Since the EHCI spec requires that the schedules not be re-enabled until the previous disable has taken effect, with an unlimited timeout the async schedule never gets turned back on. The resulting symptom is that the system is unable to communicate with USB devices. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by:
Ronald <ronald645@gmail.com> Reported-and-tested-by:
Paul Hartman <paul.hartman@gmail.com> Reported-and-tested-by:
Dieter Nützel <dieter@nuetzel-hh.de> Reported-and-tested-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Catalin Marinas authored
commit 69dde4c5 upstream. Following commit 26ffd0d4 (ARM: mm: introduce present, faulting entries for PAGE_NONE), if a page has been mapped as PROT_NONE, the L_PTE_VALID bit is cleared by the set_pte_ext() code. With LPAE the software and hardware pte share the same location and subsequent modifications of pte range (change_protection()) will leave the L_PTE_VALID bit cleared. This patch adds the L_PTE_VALID bit to the newprot mask in pte_modify(). Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Reported-by:
Subash Patel <subash.rp@samsung.com> Tested-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Nicolas Pitre authored
commit 70264367 upstream. When udelay() is implemented using an architected timer, it is wrong to scale loops_per_jiffy when changing the CPU clock frequency since the timer clock remains constant. The lpj should probably become an implementation detail relevant to the CPU loop based delay routine only and more confined to it. In the mean time this is the minimal fix needed to have expected delays with the timer based implementation when cpufreq is also in use. Reported-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Nicolas Pitre <nico@linaro.org> Tested-by:
Liviu Dudau <Liviu.Dudau@arm.com> Signed-off-by:
-
Russell King authored
commit b255188f upstream. Paolo Pisati reports that IPv6 triggers this warning: BUG: scheduling while atomic: swapper/0/0/0x40000100 Modules linked in: [<c001b1c4>] (unwind_backtrace+0x0/0xf0) from [<c0503c5c>] (__schedule_bug+0x48/0x5c) [<c0503c5c>] (__schedule_bug+0x48/0x5c) from [<c0508608>] (__schedule+0x700/0x740) [<c0508608>] (__schedule+0x700/0x740) from [<c007007c>] (__cond_resched+0x24/0x34) [<c007007c>] (__cond_resched+0x24/0x34) from [<c05086dc>] (_cond_resched+0x3c/0x44) [<c05086dc>] (_cond_resched+0x3c/0x44) from [<c0021f6c>] (do_alignment+0x178/0x78c) [<c0021f6c>] (do_alignment+0x178/0x78c) from [<c00083e0>] (do_DataAbort+0x34/0x98) [<c00083e0>] (do_DataAbort+0x34/0x98) from [<c0509a60>] (__dabt_svc+0x40/0x60) Exception stack(0xc0763d70 to 0xc0763db8) 3d60: e97e805e e97e806e 2c000000 11000000 3d80: ea86bb00 0000002c 00000011 e97e807e c076d2a8 e97e805e e97e806e 0000002c 3da0: 3d000000 c0763dbc c04b98fc c02a8490 00000113 ffffffff [<c0509a60>] (__dabt_svc+0x40/0x60) from [<c02a8490>] (__csum_ipv6_magic+0x8/0xc8) Fix this by using probe_kernel_address() stead of __get_user(). Reported-by:
Paolo Pisati <p.pisati@gmail.com> Tested-by:
-
Russell King authored
commit 5e4ba617 upstream. Martin Storsjö reports that the sequence: ee312ac1 vsub.f32 s4, s3, s2 ee702ac0 vsub.f32 s5, s1, s0 e59f0028 ldr r0, [pc, #40] ee111a90 vmov r1, s3 on Raspberry Pi (implementor 41 architecture 1 part 20 variant b rev 5) where s3 is a denormal and s2 is zero results in incorrect behaviour - the instruction "vsub.f32 s5, s1, s0" is not executed: VFP: bounce: trigger ee111a90 fpexc d0000780 VFP: emulate: INST=0xee312ac1 SCR=0x00000000 ... As we can see, the instruction triggering the exception is the "vmov" instruction, and we emulate the "vsub.f32 s4, s3, s2" but fail to properly take account of the FPEXC_FP2V flag in FPEXC. This is because the test for the second instruction register being valid is bogus, and will always skip emulation of the second instruction. Reported-by:
Martin Storsjö <martin@martin.st> Tested-by:
-
- 03 Mar, 2013 19 commits
-
-
Greg Kroah-Hartman authored
-
Dave Chinner authored
commit 1e82379b upstream. When we are converting local data to an extent format as a result of adding an attribute, the type of data contained in the local fork determines the behaviour that needs to occur. xfs_bmap_add_attrfork_local() already handles the directory data case specially by using S_ISDIR() and calling out to xfs_dir2_sf_to_block(), but with verifiers we now need to handle each different type of metadata specially and different metadata formats require different verifiers (and eventually block header initialisation). There is only a single place that we add and attribute fork to the inode, but that is in the attribute code and it knows nothing about the specific contents of the data fork. It is only the case of local data that is the issue here, so adding code to hadnle this case in the attribute specific code is wrong. Hence we are really stuck trying to detect the data fork contents in xfs_bmap_add_attrfork_local() and performing the correct callout there. Luckily the current cases can be determined by S_IS* macros, and we can push the work off to data specific callouts, but each of those callouts does a lot of work in common with xfs_bmap_local_to_extents(). The only reason that this fails for symlinks right now is is that xfs_bmap_local_to_extents() assumes the data fork contains extent data, and so attaches a a bmap extent data verifier to the buffer and simply copies the data fork information straight into it. To fix this, allow us to pass a "formatting" callback into xfs_bmap_local_to_extents() which is responsible for setting the buffer type, initialising it and copying the data fork contents over to the new buffer. This allows callers to specify how they want to format the new buffer (which is necessary for the upcoming CRC enabled metadata blocks) and hence make xfs_bmap_local_to_extents() useful for any type of data fork content. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Mark Tinguely <tinguely@sgi.com> Signed-off-by:
Ben Myers <bpm@sgi.com> Signed-off-by:
-
Matt Fleming authored
commit da27a243 upstream. It makes no sense to treat the following filenames as unique, VarName-abcdefab-abcd-abcd-abcd-abcdefabcdef VarName-ABCDEFAB-ABCD-ABCD-ABCD-ABCDEFABCDEF VarName-ABcDEfAB-ABcD-ABcD-ABcD-ABcDEfABcDEf VarName-aBcDEfAB-aBcD-aBcD-aBcD-aBcDEfaBcDEf ... etc ... since the guid will be converted into a binary representation, which has no case. Roll our own dentry operations so that we can treat the variable name part of filenames ("VarName" in the above example) as case-sensitive, but the guid portion as case-insensitive. That way, efivarfs will refuse to create the above files if any one already exists. Reported-by:
Lingzhu Xiang <lxiang@redhat.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jeremy.kerr@canonical.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Signed-off-by:
-
Matt Fleming authored
commit 47f531e8 upstream. The only thing that efivarfs does to enforce a valid filename is ensure that the name isn't too short. We need to strongly sanitise any filenames, not least because variable creation is delayed until efivarfs_file_write(), which means we can't rely on the firmware to inform us of an invalid name, because if the file is never written to we'll never know it's invalid. Perform a couple of steps before agreeing to create a new file, * hex_to_bin() returns a value indicating whether or not it was able to convert its arguments to a binary representation - we should check it. * Ensure that the GUID portion of the filename is the correct length and format. * The variable name portion of the filename needs to be at least one character in size. Reported-by:
-
Thomas Renninger authored
commit 565d956a upstream. Reflect this dependency in Kconfig, to prevent build failures. Shorten the config description as suggested by Borislav Petkov. Finding a suitable memory area to store the modified table(s) has been taken over from arch/x86/kernel/setup.c and makes use of max_low_pfn_mapped: memblock_find_in_range(0, max_low_pfn_mapped,...) This one is X86 specific. It may not be hard to extend this functionality for other ACPI aware architectures if there is need for. For now make this feature only available for X86 to avoid build failures on IA64, compare with: https://bugzilla.kernel.org/show_bug.cgi?id=54091Signed-off-by:
Thomas Renninger <trenn@suse.de> Link: http://lkml.kernel.org/r/1361538742-67599-3-git-send-email-trenn@suse.deSigned-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
Lee, Chun-Yi authored
commit deb94101 upstream. When initrd file didn't put at the same place with stub kernel, we need give the file path of initrd, but need use backslash to separate directory and file. It's not friendly to unix/linux user, and not so intuitive for bootloader forward paramters to efi stub kernel by chainloading. This patch add support to handle_ramdisks for allow slash in file path of initrd, it convert slash to backlash when parsing path. In additional, this patch also separates print code of efi_char16_t from efi_printk, and print out the path/filename of initrd when failed to open initrd file. It's good for debug and discover typo. Signed-off-by:
Lee, Chun-Yi <jlee@suse.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by:
-
Alexey Klimov authored
commit 0322bd39 upstream. Don't let Masterkit MA901 USB radio be handled by usb hid drivers. This device will be handled by radio-ma901.c driver. Signed-off-by:
Alexey Klimov <klimov.linux@gmail.com> Acked-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
James Ralston authored
commit 151743fd upstream. This patch adds the AHCI-mode SATA Device IDs for the Intel Wellsburg PCH Signed-off-by:
James Ralston <james.d.ralston@intel.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Seth Heasley authored
commit 29e674dd upstream. This patch adds the AHCI and RAID-mode SATA DeviceIDs for the Intel Avoton SOC. Signed-off-by:
Seth Heasley <seth.heasley@intel.com> Signed-off-by:
-
James Ralston authored
commit 3aee8bc5 upstream. This patch adds the IDE-mode SATA Device IDs for the Intel Wellsburg PCH Signed-off-by:
-
Seth Heasley authored
commit aaa51527 upstream. This patch adds the IDE-mode SATA DeviceIDs for the Intel Avoton SOC. Signed-off-by:
-
Ian Abbott authored
commit cc400e18 upstream. Some low-level comedi drivers (incorrectly) point `dev->read_subdev` or `dev->write_subdev` to a subdevice that does not support asynchronous commands. Comedi's poll(), read() and write() file operation handlers assume these subdevices do support asynchronous commands. In particular, they assume `s->async` is valid (where `s` points to the read or write subdevice), which it won't be if it has been set incorrectly. This can lead to a NULL pointer dereference. Check `s->async` is non-NULL in `comedi_poll()`, `comedi_read()` and `comedi_write()` to avoid the bug. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Joseph Salisbury authored
commit 66f2fda9 upstream. This patch adds a quirk to allow the Sony VGN-FW41E_H to suspend/resume properly. References: http://bugs.launchpad.net/bugs/1113547Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Rajanikanth H.V authored
commit eeb0751c upstream. Power supply subsystem creates thermal zone device for the property 'POWER_SUPPLY_PROP_TEMP' which requires thermal subsystem to be ready before 'ab8500 battery temperature monitor' driver is initialized. ab8500 btemp driver is initialized with subsys_initcall whereas thermal subsystem is initialized with fs_initcall which causes thermal_zone_device_register(...) to crash since the required structure 'thermal_class' is not initialized yet: Unable to handle kernel NULL pointer dereference at virtual address 000000a4 pgd = c0004000 [000000a4] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 Tainted: G W (3.8.0-rc4-00001-g632fda8-dirty #1) PC is at _raw_spin_lock+0x18/0x54 LR is at get_device_parent+0x50/0x1b8 pc : [<c02f1dd0>] lr : [<c01cb248>] psr: 60000013 sp : ef04bdc8 ip : 00000000 fp : c0446180 r10: ef216e38 r9 : c03af5d0 r8 : ef275c18 r7 : 00000000 r6 : c0476c14 r5 : ef275c18 r4 : ef095840 r3 : ef04a000 r2 : 00000001 r1 : 00000000 r0 : 000000a4 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c5787d Table: 0000404a DAC: 00000015 Process swapper/0 (pid: 1, stack limit = 0xef04a238) Stack: (0xef04bdc8 to 0xef04c000) [...] [<c02f1dd0>] (_raw_spin_lock+0x18/0x54) from [<c01cb248>] (get_device_parent+0x50/0x1b8) [<c01cb248>] (get_device_parent+0x50/0x1b8) from [<c01cb8d8>] (device_add+0xa4/0x574) [<c01cb8d8>] (device_add+0xa4/0x574) from [<c020b91c>] (thermal_zone_device_register+0x118/0x938) [<c020b91c>] (thermal_zone_device_register+0x118/0x938) from [<c0202030>] (power_supply_register+0x170/0x1f8) [<c0202030>] (power_supply_register+0x170/0x1f8) from [<c02055ec>] (ab8500_btemp_probe+0x208/0x47c) [<c02055ec>] (ab8500_btemp_probe+0x208/0x47c) from [<c01cf0dc>] (platform_drv_probe+0x14/0x18) [<c01cf0dc>] (platform_drv_probe+0x14/0x18) from [<c01cde70>] (driver_probe_device+0x74/0x20c) [<c01cde70>] (driver_probe_device+0x74/0x20c) from [<c01ce094>] (__driver_attach+0x8c/0x90) [<c01ce094>] (__driver_attach+0x8c/0x90) from [<c01cc640>] (bus_for_each_dev+0x4c/0x80) [<c01cc640>] (bus_for_each_dev+0x4c/0x80) from [<c01cd6b4>] (bus_add_driver+0x16c/0x23c) [<c01cd6b4>] (bus_add_driver+0x16c/0x23c) from [<c01ce54c>] (driver_register+0x78/0x14c) [<c01ce54c>] (driver_register+0x78/0x14c) from [<c00086ac>] (do_one_initcall+0xfc/0x164) [<c00086ac>] (do_one_initcall+0xfc/0x164) from [<c02e89c8>] (kernel_init+0x120/0x2b8) [<c02e89c8>] (kernel_init+0x120/0x2b8) from [<c000e358>] (ret_from_fork+0x14/0x3c) Code: e3c3303f e5932004 e2822001 e5832004 (e1903f9f) ---[ end trace ed9df72941b5bada ]--- Signed-off-by:
Rajanikanth H.V <rajanikanth.hv@stericsson.com> Signed-off-by:
Anton Vorontsov <anton@enomsg.org> Signed-off-by:
-
Lee Jones authored
commit e3455002 upstream. Only root should have write permission on sysfs file ab8500_chargalg/chargalg. Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
NeilBrown authored
commit bde83b9a upstream. commit a66f59ba bq27x00_battery: Add support for BQ27425 chip introduced 2 bugs. 1/ 'chip' was set to BQ27425 unconditionally - breaking support for other devices; 2/ BQ27425 does not support cycle count, how the code still tries to get the cycle count for BQ27425, and now does it twice for other chips. Signed-off-by:
NeilBrown <neilb@suse.de> Cc: Saranya Gopal <saranya.gopal@intel.com> Signed-off-by:
-
Li Zefan authored
commit 71b5707e upstream. In cgroup_exit() put_css_set_taskexit() is called without any lock, which might lead to accessing a freed cgroup: thread1 thread2 --------------------------------------------- exit() cgroup_exit() put_css_set_taskexit() atomic_dec(cgrp->count); rmdir(); /* not safe !! */ check_for_release(cgrp); rcu_read_lock() can be used to make sure the cgroup is alive. Signed-off-by:
Li Zefan <lizefan@huawei.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Li Zefan authored
commit 63f43f55 upstream. rename() will change dentry->d_name. The result of this race can be worse than seeing partially rewritten name, but we might access a stale pointer because rename() will re-allocate memory to hold a longer name. It's safe in the protection of dentry->d_lock. v2: check NULL dentry before acquiring dentry lock. Signed-off-by:
-
Seiji Aguchi authored
commit 9f244e9c upstream. [Issue] When pstore is in panic and emergency-restart paths, it may be blocked in those paths because it simply takes spin_lock. This is an example scenario which pstore may hang up in a panic path: - cpuA grabs psinfo->buf_lock - cpuB panics and calls smp_send_stop - smp_send_stop sends IRQ to cpuA - after 1 second, cpuB gives up on cpuA and sends an NMI instead - cpuA is now in an NMI handler while still holding buf_lock - cpuB is deadlocked This case may happen if a firmware has a bug and cpuA is stuck talking with it more than one second. Also, this is a similar scenario in an emergency-restart path: - cpuA grabs psinfo->buf_lock and stucks in a firmware - cpuB kicks emergency-restart via either sysrq-b or hangcheck timer. And then, cpuB is deadlocked by taking psinfo->buf_lock again. [Solution] This patch avoids the deadlocking issues in both panic and emergency_restart paths by introducing a function, is_non_blocking_path(), to check if a cpu can be blocked in current path. With this patch, pstore is not blocked even if another cpu has taken a spin_lock, in those paths by changing from spin_lock_irqsave to spin_trylock_irqsave. In addition, according to a comment of emergency_restart() in kernel/sys.c, spin_lock shouldn't be taken in an emergency_restart path to avoid deadlock. This patch fits the comment below. <snip> /** * emergency_restart - reboot the system * * Without shutting down any hardware or taking any locks * reboot the system. This is called when we know we are in * trouble so this is our best effort to reboot. This is * safe to call in interrupt context. */ void emergency_restart(void) <snip> Signed-off-by:
Seiji Aguchi <seiji.aguchi@hds.com> Acked-by:
Don Zickus <dzickus@redhat.com> Signed-off-by:
Tony Luck <tony.luck@intel.com> Cc: CAI Qian <caiqian@redhat.com> Signed-off-by:
-
