- 17 Jan, 2013 40 commits
-
-
Alex Deucher authored
commit 93927f9c upstream. Need to use the adjusted mode since we are sending native timing and using the scaler for non-native modes. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Alex Deucher authored
commit a02dc74b upstream. Fixes flickering with some high res montiors. Signed-off-by:
-
Christian König authored
commit ae133a11 upstream. Redirect invalid memory accesses to the default page instead of locking up the memory controller. Also enable the invalid memory access interrupts and start spamming system log with it. v2 (agd5f): fix up against 2 level PT changes Signed-off-by:
Christian König <deathsimple@vodafone.de> Signed-off-by:
-
Woodhouse, David authored
commit 6491d4d0 upstream. The dma_pte_free_pagetable() function will only free a page table page if it is asked to free the *entire* 2MiB range that it covers. So if a page table page was used for one or more small mappings, it's likely to end up still present in the page tables... but with no valid PTEs. This was fine when we'd only be repopulating it with 4KiB PTEs anyway but the same virtual address range can end up being reused for a *large-page* mapping. And in that case were were trying to insert the large page into the second-level page table, and getting a complaint from the sanity check in __domain_mapping() because there was already a corresponding entry. This was *relatively* harmless; it led to a memory leak of the old page table page, but no other ill-effects. Fix it by calling dma_pte_clear_range (hopefully redundant) and dma_pte_free_pagetable() before setting up the new large page. Signed-off-by:
David Woodhouse <David.Woodhouse@intel.com> Tested-by:
Ravi Murty <Ravi.Murty@intel.com> Tested-by:
Sudeep Dutt <sudeep.dutt@intel.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dan Williams authored
commit 999a7c57 upstream. Add device IDs for WiMAX function of Intel 6150 cards. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Alexey Khoroshilov authored
commit 2cbba75a upstream. Users of jffs2_do_reserve_space() expect they still held erase_completion_lock after call to it. But there is a path where jffs2_do_reserve_space() leaves erase_completion_lock unlocked. The patch fixes it. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Signed-off-by:
-
Trond Myklebust authored
commit 87ed5003 upstream. If the rpc_task exits while holding the socket write lock before it has allocated an rpc slot, then the usual mechanism for releasing the write lock in xprt_release() is defeated. The problem occurs if the call to xprt_lock_write() initially fails, so that the rpc_task is put on the xprt->sending wait queue. If the task exits after being assigned the lock by __xprt_lock_write_func, but before it has retried the call to xprt_lock_and_alloc_slot(), then it calls xprt_release() while holding the write lock, but will immediately exit due to the test for task->tk_rqstp != NULL. Reported-by:
Chris Perl <chris.perl@gmail.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Trond Myklebust authored
commit c6567ed1 upstream. This patch ensures that we free the rpc_task after the cleanup callbacks are done in order to avoid a deadlock problem that can be triggered if the callback needs to wait for another workqueue item to complete. Signed-off-by:
-
J. Bruce Fields authored
commit 621eb19c upstream. Commit bbf43dc8 "sunrpc/cache.h: replace simple_strtoul" introduced new range-checking which could cause get_int to fail on unsigned integers too large to be represented as an int. We could parse them as unsigned instead--but it turns out svcgssd is actually passing down "-1" in some cases. Which is perhaps stupid, but there's nothing we can do about it now. So just revert back to the previous "sloppy" behavior that accepts either representation. Reported-by:
Sven Geggus <lists@fuchsschwanzdomain.de> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Stanislav Kinsbursky authored
commit cd6c5968 upstream. There are SUNRPC clients, which program doesn't have pipe_dir_name. These clients can be skipped on PipeFS events, because nothing have to be created or destroyed. But instead of breaking in case of such a client was found, search for suitable client over clients list have to be continued. Otherwise some clients could not be covered by PipeFS event handler. Signed-off-by:
Stanislav Kinsbursky <skinsbursky@parallels.com> Signed-off-by:
-
Trond Myklebust authored
commit 642fe4d0 upstream. rpc_kill_sb() must defer calling put_net() until after the notifier has been called, since most (all?) of the notifier callbacks assume that sb->s_fs_info points to a valid net namespace. It also must not call put_net() if the call to rpc_fill_super was unsuccessful. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=48421Signed-off-by:
-
Tomi Valkeinen authored
commit ca2e16fa upstream. The i2c handling in tfp410 driver, which handles converting parallel RGB to DVI, was changed in 958f2717 (OMAPDSS: TFP410: pdata rewrite). The patch changed what value the driver considers as invalid/undefined. Before the patch, 0 was the invalid value, but as 0 is a valid bus number, the patch changed this to -1. However, the fact was missed that many board files do not define the bus number at all, thus it's left to 0. This causes the driver to fail to get the i2c bus, exiting from the driver's probe with an error, meaning that the DVI output does not work for those boards. This patch fixes the issue by changing the i2c_bus number field in the driver's platform data from u16 to int, and setting the bus number to -1 in the board files for the boards that did not define the bus. The exception is devkit8000, for which the bus is set to 1, which is the correct bus for that board. The bug exists in v3.5+ kernels. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Reported-by:
Thomas Weber <thomas@tomweber.eu> Cc: Thomas Weber <thomas@tomweber.eu> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Pawel Moll authored
commit bd1ee804 upstream. Since commit 1f2bfbd0 "kbuild: link of vmlinux moved to a script" make clean with M=<dir> argument (so cleaning external module) removes vmlinux, System.map and couple of other files from the *main* kernel build directory! This not what was happening before and almost certainly not what one would expect. This patch moves makes the clean target of the script called only when !KBUILD_EXTMOD. Signed-off-by:
Pawel Moll <pawel.moll@arm.com> Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Wolfram Sang authored
commit 6f2a6a52 upstream. It could happen (1 out of 100 times) that NAND did not start up correctly after warm rebooting, so the kernel could not find the UBI or DMA timed out due to a stalled BCH. When resetting BCH together with GPMI, the issue could not be observed anymore (after 10000+ reboots). We probably need the consistent state already before sending any command to NAND, even when no ECC is needed. I chose to keep the extra reset for BCH when changing the flash layout to be on the safe side. Signed-off-by:
Wolfram Sang <w.sang@pengutronix.de> Acked-by:
Huang Shijie <b32955@freescale.com> Signed-off-by:
-
Nathan Williams authored
commit d1f3b65d upstream. Loading cs553x_nand with Hynix H27U1G8F2BTR NAND flash causes this bug: kernel BUG at drivers/mtd/nand/nand_base.c:3345! invalid opcode: 0000 [#1] Modules linked in: cs553x_nand(+) vfat fat usb_storage ehci_hcd usbcore usb_comr Pid: 436, comm: modprobe Not tainted 3.6.7 #1 EIP: 0060:[<c118d205>] EFLAGS: 00010296 CPU: 0 EIP is at nand_scan_tail+0x64c/0x69c EAX: 00000034 EBX: cea6ed98 ECX: 00000000 EDX: 00000000 ESI: cea6ec00 EDI: cea6ec00 EBP: 20000000 ESP: cdd17e48 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 CR0: 8005003b CR2: 0804e119 CR3: 0d850000 CR4: 00000090 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Process modprobe (pid: 436, ti=cdd16000 task=cdd1c320 task.ti=cdd16000) Stack: c12e962c c118f7ef 00000003 cea6ed98 d014b25c 20000000 fffff007 00000001 00000000 cdd53b00 d014b000 c1001021 cdd53b00 d01493c0 cdd53b00 cdd53b00 d01493c0 c1047f83 d014b4a0 00000000 cdd17f9c ce4be454 cdd17f48 cdd1c320 Call Trace: [<c118f7ef>] ? nand_scan+0x1b/0x4d [<d014b25c>] ? init_module+0x25c/0x2de [cs553x_nand] [<d014b000>] ? 0xd014afff [<c1001021>] ? do_one_initcall+0x21/0x111 [<c1047f83>] ? sys_init_module+0xe4/0x1261 [<c1031207>] ? task_work_run+0x36/0x43 [<c1265ced>] ? syscall_call+0x7/0xb Code: fa ff ff c7 86 d8 00 00 00 01 00 00 00 e9 5f fc ff ff 68 f8 26 2e c1 e8 a7 EIP: [<c118d205>] nand_scan_tail+0x64c/0x69c SS:ESP 0068:cdd17e48 Initialising ecc.strength before the call to nand_scan() fixes this. Signed-off-by:
Nathan Williams <nathan@traverse.com.au> Acked-by:
Brian Norris <computersforpeace@gmail.com> Acked-by:
Mike Dunn <mikedunn@newsguy.com> Signed-off-by:
-
Theodore Ts'o authored
commit aeb1e5d6 upstream. Commit fa77dcfa introduces block bitmap checksum calculation into ext4_new_inode() in the case that block group was uninitialized. However we brelse() the bitmap buffer before we attempt to checksum it so we have no guarantee that the buffer is still there. Fix this by releasing the buffer after the possible checksum computation. Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Acked-by:
Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by:
-
Eugene Shatokhin authored
commit 24ec19b0 upstream. In ext4_xattr_set_acl(), if ext4_journal_start() returns an error, posix_acl_release() will not be called for 'acl' which may result in a memory leak. This patch fixes that. Reviewed-by:
Eugene Shatokhin <eugene.shatokhin@rosalab.ru> Signed-off-by:
-
Geert Uytterhoeven authored
commit 90a38d99 upstream. Older gcc (< 4.4) doesn't like files starting with Unicode BOMs: include/linux/mfd/da9055/core.h:1: error: stray ‘\357’ in program include/linux/mfd/da9055/core.h:1: error: stray ‘\273’ in program include/linux/mfd/da9055/core.h:1: error: stray ‘\277’ in program include/linux/mfd/da9055/pdata.h:1: error: stray ‘\357’ in program include/linux/mfd/da9055/pdata.h:1: error: stray ‘\273’ in program include/linux/mfd/da9055/pdata.h:1: error: stray ‘\277’ in program include/linux/mfd/da9055/reg.h:1: error: stray ‘\357’ in program include/linux/mfd/da9055/reg.h:1: error: stray ‘\273’ in program include/linux/mfd/da9055/reg.h:1: error: stray ‘\277’ in program Remove the BOMs, the rest of the files is plain ASCII anyway. Output of "file" before: include/linux/mfd/da9055/core.h: UTF-8 Unicode (with BOM) C program text include/linux/mfd/da9055/pdata.h: UTF-8 Unicode (with BOM) C program text include/linux/mfd/da9055/reg.h: UTF-8 Unicode (with BOM) C program text Output of "file" after: include/linux/mfd/da9055/core.h: ASCII C program text include/linux/mfd/da9055/pdata.h: ASCII C program text include/linux/mfd/da9055/reg.h: ASCII C program text Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Charles Keepax authored
commit b9fbb62e upstream. mfd_remove_devices would iterate over all devices sharing a parent with an mfd device regardless of whether they were allocated by the mfd core or not. This especially caused problems when the device structure was not contained within a platform_device, because to_platform_device is used on each device pointer. This patch defines a device_type for mfd devices and checks this is present from mfd_remove_devices_fn before processing the device. Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Tested-by:
Peter Tyser <ptyser@xes-inc.com> Reviewed-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Mark Brown authored
commit fee546ce upstream. This is supported identically to the previous revisions. Signed-off-by:
-
Chris Boot authored
commit e1fe2060 upstream. If the TPG memory is allocated successfully, but we fail further along in the function, a dangling pointer to freed memory is left in the TPort structure. This is mostly harmless, but does prevent re-trying the operation without first removing the TPort altogether. Reported-by:
Chen Gang <gang.chen@asianux.com> Signed-off-by:
Chris Boot <bootc@bootc.net> Cc: Andy Grover <agrover@redhat.com> Cc: Nicholas A. Bellinger <nab@linux-iscsi.org> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Yi Zou authored
commit 9f4ad44b upstream. The lockdep warning below is in theory correct but it will be in really weird rare situation that ends up that deadlock since the tcm fc session is hashed based the rport id. Nonetheless, the complaining below is about rcu callback that does the transport_deregister_session() is happening in softirq, where transport_register_session() that happens earlier is not. This triggers the lockdep warning below. So, just fix this to make lockdep happy by disabling the soft irq before calling transport_register_session() in ft_prli. BTW, this was found in FCoE VN2VN over two VMs, couple of create and destroy would get this triggered. v1: was enforcing register to be in softirq context which was not righ. See, http://www.spinics.net/lists/target-devel/msg03614.html v2: following comments from Roland&Nick (thanks), it seems we don't have to do transport_deregister_session() in rcu callback, so move it into ft_sess_free() but still do kfree() of the corresponding ft_sess struct in rcu callback to make sure the ft_sess is not freed till the rcu callback. ... [ 1328.370592] scsi2 : FCoE Driver [ 1328.383429] fcoe: No FDMI support. [ 1328.384509] host2: libfc: Link up on port (000000) [ 1328.934229] host2: Assigned Port ID 00a292 [ 1357.232132] host2: rport 00a393: Remove port [ 1357.232568] host2: rport 00a393: Port sending LOGO from Ready state [ 1357.233692] host2: rport 00a393: Delete port [ 1357.234472] host2: rport 00a393: work event 3 [ 1357.234969] host2: rport 00a393: callback ev 3 [ 1357.235979] host2: rport 00a393: Received a LOGO response closed [ 1357.236706] host2: rport 00a393: work delete [ 1357.237481] [ 1357.237631] ================================= [ 1357.238064] [ INFO: inconsistent lock state ] [ 1357.238450] 3.7.0-rc7-yikvm+ #3 Tainted: G O [ 1357.238450] --------------------------------- [ 1357.238450] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. [ 1357.238450] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE0:SE0] takes: [ 1357.238450] (&(&se_tpg->session_lock)->rlock){+.?...}, at: [<ffffffffa01eacd4>] transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] {SOFTIRQ-ON-W} state was registered at: [ 1357.238450] [<ffffffff810834f5>] mark_held_locks+0x6d/0x95 [ 1357.238450] [<ffffffff8108364a>] trace_hardirqs_on_caller+0x12d/0x197 [ 1357.238450] [<ffffffff810836c1>] trace_hardirqs_on+0xd/0xf [ 1357.238450] [<ffffffff8149caba>] _raw_spin_unlock_irq+0x2d/0x45 [ 1357.238450] [<ffffffffa01e8d10>] __transport_register_session+0xb8/0x122 [target_core_mod] [ 1357.238450] [<ffffffffa01e8dbe>] transport_register_session+0x44/0x5a [target_core_mod] [ 1357.238450] [<ffffffffa018e32c>] ft_prli+0x1e3/0x275 [tcm_fc] [ 1357.238450] [<ffffffffa0160e8d>] fc_rport_recv_req+0x95e/0xdc5 [libfc] [ 1357.238450] [<ffffffffa015be88>] fc_lport_recv_els_req+0xc4/0xd5 [libfc] [ 1357.238450] [<ffffffffa015c778>] fc_lport_recv_req+0x12f/0x18f [libfc] [ 1357.238450] [<ffffffffa015a6d7>] fc_exch_recv+0x8ba/0x981 [libfc] [ 1357.238450] [<ffffffffa0176d7a>] fcoe_percpu_receive_thread+0x47a/0x4e2 [fcoe] [ 1357.238450] [<ffffffff810549f1>] kthread+0xb1/0xb9 [ 1357.238450] [<ffffffff814a40ec>] ret_from_fork+0x7c/0xb0 [ 1357.238450] irq event stamp: 275411 [ 1357.238450] hardirqs last enabled at (275410): [<ffffffff810bb6a0>] rcu_process_callbacks+0x229/0x42a [ 1357.238450] hardirqs last disabled at (275411): [<ffffffff8149c2f7>] _raw_spin_lock_irqsave+0x22/0x8e [ 1357.238450] softirqs last enabled at (275394): [<ffffffff8103d669>] __do_softirq+0x246/0x26f [ 1357.238450] softirqs last disabled at (275399): [<ffffffff8103d6bb>] run_ksoftirqd+0x29/0x62 [ 1357.238450] [ 1357.238450] other info that might help us debug this: [ 1357.238450] Possible unsafe locking scenario: [ 1357.238450] [ 1357.238450] CPU0 [ 1357.238450] ---- [ 1357.238450] lock(&(&se_tpg->session_lock)->rlock); [ 1357.238450] <Interrupt> [ 1357.238450] lock(&(&se_tpg->session_lock)->rlock); [ 1357.238450] [ 1357.238450] *** DEADLOCK *** [ 1357.238450] [ 1357.238450] no locks held by ksoftirqd/0/3. [ 1357.238450] [ 1357.238450] stack backtrace: [ 1357.238450] Pid: 3, comm: ksoftirqd/0 Tainted: G O 3.7.0-rc7-yikvm+ #3 [ 1357.238450] Call Trace: [ 1357.238450] [<ffffffff8149399a>] print_usage_bug+0x1f5/0x206 [ 1357.238450] [<ffffffff8100da59>] ? save_stack_trace+0x2c/0x49 [ 1357.238450] [<ffffffff81082aae>] ? print_irq_inversion_bug.part.14+0x1ae/0x1ae [ 1357.238450] [<ffffffff81083336>] mark_lock+0x106/0x258 [ 1357.238450] [<ffffffff81084e34>] __lock_acquire+0x2e7/0xe53 [ 1357.238450] [<ffffffff8102903d>] ? pvclock_clocksource_read+0x48/0xb4 [ 1357.238450] [<ffffffff810ba6a3>] ? rcu_process_gp_end+0xc0/0xc9 [ 1357.238450] [<ffffffffa01eacd4>] ? transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] [<ffffffff81085ef1>] lock_acquire+0x119/0x143 [ 1357.238450] [<ffffffffa01eacd4>] ? transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] [<ffffffff8149c329>] _raw_spin_lock_irqsave+0x54/0x8e [ 1357.238450] [<ffffffffa01eacd4>] ? transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] [<ffffffffa01eacd4>] transport_deregister_session+0x41/0x148 [target_core_mod] [ 1357.238450] [<ffffffff810bb6a0>] ? rcu_process_callbacks+0x229/0x42a [ 1357.238450] [<ffffffffa018ddc5>] ft_sess_rcu_free+0x17/0x24 [tcm_fc] [ 1357.238450] [<ffffffffa018ddae>] ? ft_sess_free+0x1b/0x1b [tcm_fc] [ 1357.238450] [<ffffffff810bb6d7>] rcu_process_callbacks+0x260/0x42a [ 1357.238450] [<ffffffff8103d55d>] __do_softirq+0x13a/0x26f [ 1357.238450] [<ffffffff8149b34e>] ? __schedule+0x65f/0x68e [ 1357.238450] [<ffffffff8103d6bb>] run_ksoftirqd+0x29/0x62 [ 1357.238450] [<ffffffff8105c83c>] smpboot_thread_fn+0x1a5/0x1aa [ 1357.238450] [<ffffffff8105c697>] ? smpboot_unregister_percpu_thread+0x47/0x47 [ 1357.238450] [<ffffffff810549f1>] kthread+0xb1/0xb9 [ 1357.238450] [<ffffffff8149b49d>] ? wait_for_common+0xbb/0x10a [ 1357.238450] [<ffffffff81054940>] ? __init_kthread_worker+0x59/0x59 [ 1357.238450] [<ffffffff814a40ec>] ret_from_fork+0x7c/0xb0 [ 1357.238450] [<ffffffff81054940>] ? __init_kthread_worker+0x59/0x59 [ 1417.440099] rport-2:0-0: blocked FC remote port time out: removing rport Signed-off-by:
Yi Zou <yi.zou@intel.com> Cc: Open-FCoE <devel@open-fcoe.org> Cc: Nicholas A. Bellinger <nab@risingtidesystems.com> Signed-off-by:
-
Sebastian Andrzej Siewior authored
commit 40ff2c3b upstream. This patch changes vectored file I/O to use kmap + kunmap when mapping incoming SGL memory -> struct iovec in order to properly support 32-bit highmem configurations. This is because an extra bounce buffer may be required when processing scatterlist pages allocated with GFP_KERNEL. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Xiaotian Feng authored
commit 26cd4d65 upstream. Following oops were observed when disk error happened: [ 4272.896937] sd 0:0:0:0: [sda] Unhandled error code [ 4272.896939] sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK [ 4272.896942] sd 0:0:0:0: [sda] CDB: Read(10): 28 00 00 5a de a7 00 00 08 00 [ 4272.896951] end_request: I/O error, dev sda, sector 5955239 [ 4291.574947] BUG: unable to handle kernel NULL pointer dereference at (null) [ 4291.658305] IP: [] ahci_activity_show+0x1/0x40 [ 4291.730090] PGD 76dbbc067 PUD 6c4fba067 PMD 0 [ 4291.783408] Oops: 0000 [#1] SMP [ 4291.822100] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/sw_activity [ 4291.934235] CPU 9 [ 4291.958301] Pid: 27942, comm: hwinfo ...... ata_scsi_find_dev could return NULL, so ata_scsi_activity_{show,store} should check if atadev is NULL. Signed-off-by:
Xiaotian Feng <dannyfeng@tencent.com> Cc: James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Jeff Garzik <jgarzik@redhat.com> Signed-off-by:
-
Aaron Lu authored
commit 5416912a upstream. ata_device->dma_mode's initial value is zero, which is not a valid dma mode, but ata_dma_enabled will return true for this value. This patch sets dma_mode to 0xff in reset function, so that ata_dma_enabled will not return true for this case, or it will cause problem for pata_acpi. The corrsponding bugzilla page is at: https://bugzilla.kernel.org/show_bug.cgi?id=49151Reported-by:
Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Tested-by:
Szymon Janc <szymon@janc.net.pl> Tested-by:
Dutra Julio <dutra.julio@gmail.com> Acked-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
-
Maxime Bizon authored
commit b042e474 upstream. record_size / console_size / ftrace_size can be 0 (this is how you disable the feature), but rounddown_pow_of_two(0) is undefined. As suggested by Kees Cook, use !is_power_of_2() as a condition to call rounddown_pow_of_two and avoid its undefined behavior on the value 0. This issue has been present since commit 1894a253 (ramoops: Move to fs/pstore/ram.c). Signed-off-by:
Maxime Bizon <mbizon@freebox.fr> Signed-off-by:
Florian Fainelli <ffainelli@freebox.fr> Acked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Anton Vorontsov <anton.vorontsov@linaro.org> Signed-off-by:
-
Jack Morgenstein authored
commit 311f813a upstream. The slave_state_lock spinlock is used in both interrupt context and process context, hence irq locking must be used. Found by lockdep. Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Jack Morgenstein authored
commit ceb7decb upstream. lockdep warns about taking a hard-irq-unsafe lock (sriov->id_map_lock) inside a hard-irq-safe lock (sriov->going_down_lock). Since id_map_lock is never taken in the interrupt context, we can simply reverse the order of taking the two spinlocks, thus avoiding the warning and the depencency. Signed-off-by:
-
Mattia Dongili authored
commit dcbeec26 upstream. SN06 in some cases returns an Integer instead of a buffer. While the code handling the return value was trying to cope with the difference, the memcpy call was not making any difference between the two types of acpi_object union. This regression was introduced in 3.5. While there also rework the return value logic to improve readability. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=48671 Cc: Fabrizio Narni <shibotto@gmail.com> Cc: <mus.svz@gmail.com> Signed-off-by:
Mattia Dongili <malattia@linux.it> Signed-off-by:
Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by:
-
Mikael Pettersson authored
commit 3100d49d upstream. sata_promise's pdc_hard_reset_port() needs to serialize because it flips a port-specific bit in controller register that's shared by all ports. The code takes the ata host lock for this, but that's broken because an interrupt may arrive on our irq during the hard reset sequence, and that too will take the ata host lock. With lockdep enabled a big nasty warning is seen. Fixed by adding private state to the ata host structure, containing a second lock used only for serializing the hard reset sequences. This eliminated the lockdep warnings both on my test rig and on the original reporter's machine. Signed-off-by:
Mikael Pettersson <mikpe@it.uu.se> Tested-by:
Adko Branil <adkobranil@yahoo.com> Signed-off-by:
-
Steve Hodgson authored
commit 06e97b48 upstream. Search through the list of pending commands on the session list to find the command the initiator is actually aborting, so that we can pass the correct LUN to the core TMR handling code. (nab: Allow abort requests to work to LUN=0 with mainline target code) Signed-off-by:
Steve Hodgson <steve@purestorage.com> Signed-off-by:
Nicholas Bellinger <nab@risingtidesystems.com> Signed-off-by:
-
Wei Yongjun authored
commit 3c989d76 upstream. The function iscsit_build_conn_drop_async_message() is called from iscsit_close_connection() with spin lock 'sess->conn_lock' held, so we should use GFP_ATOMIC instead of GFP_KERNEL. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
Roland Dreier authored
commit 1c5c12c6 upstream. There are some cases, for example when the initiator sends an out-of-bounds ErrorRecoveryLevel value, where the iSCSI target terminates the connection without sending back any error. Audit the login path and add appropriate iscsit_tx_login_rsp() calls to make sure this doesn't happen. Signed-off-by:
-
Steve Hodgson authored
commit 64c13330 upstream. This patch fixes a bug in the hanlding of initiator provided ExpStatSN and individual iscsi_cmd->stat_sn comparision during iscsi_conn->stat_sn wrap-around within iscsit_ack_from_expstatsn() code. This bug would manifest itself as iscsi_cmd descriptors not being Acked by a lower ExpStatSn, causing them to be leaked until an iSCSI connection or session reinstatement event occurs to release all commands. Also fix up two other uses of incorrect CmdSN SNA comparison to use wrapper usage from include/scsi/iscsi_proto.h. Signed-off-by:
-
Steve Hodgson authored
commit 9bceab4e upstream. Signed-off-by:
Armen Baloyan <armen.baloyan@qlogic.com> Signed-off-by:
Saurav Kashyap <saurav.kashyap@qlogic.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Giridhar Malavali authored
SCSI: qla2xxx: Change in setting UNLOADING flag and FC vports logout sequence while unloading qla2xxx driver. commit 220d36b4 upstream. Signed-off-by:
Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by:
-
David Jeffery authored
commit a394aac8 upstream. When the qla2xxx driver loses access to multiple, remote ports, there is a race condition which can occur which will keep the request stuck on a scsi request queue indefinitely. This bad state occurred do to a race condition with how the FCPORT_UPDATE_NEEDED bit is set in qla2x00_schedule_rport_del(), and how it is cleared in qla2x00_do_dpc(). The problem port has its drport pointer set, but it has never been processed by the driver to inform the fc transport that the port has been lost. qla2x00_schedule_rport_del() sets drport, and then sets the FCPORT_UPDATE_NEEDED bit. In qla2x00_do_dpc(), the port lists are walked and any drport pointer is handled and the fc transport informed of the port loss, then the FCPORT_UPDATE_NEEDED bit is cleared. This leaves a race where the dpc thread is processing one port removal, another port removal is marked with a call to qla2x00_schedule_rport_del(), and the dpc thread clears the bit for both removals, even though only the first removal was actually handled. Until another event occurs to set FCPORT_UPDATE_NEEDED, the later port removal is never finished and qla2xxx stays in a bad state which causes requests to become stuck on request queues. This patch updates the driver to test and clear FCPORT_UPDATE_NEEDED atomically. This ensures the port state changes are processed and not lost. Signed-off-by:
David Jeffery <djeffery@redhat.com> Signed-off-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
-
Armen Baloyan authored
commit 63ea923a upstream. FC transport on receiving bsg_job submission failure, calls bsg_job->job_done() and sets the bsg_job->reply->result the returned value. In contrast, when the success code (0) is returned fc transport doesn't call bsg_job->job_done() and doesn't populate bsg_job->reply->result. Signed-off-by:
-
Sasha Levin authored
commit 072f19b4 upstream. store_host_reset() has tried to re-invent the wheel to compare sysfs strings. Unfortunately it did so poorly and never bothered to check the input from userspace before overwriting stack with it, so something simple as: echo "WoopsieWoopsie" > /sys/devices/pseudo_0/adapter0/host0/scsi_host/host0/host_reset would result in: [ 316.310101] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81f5bac7 [ 316.310101] [ 316.320051] Pid: 6655, comm: sh Tainted: G W 3.7.0-rc5-next-20121114-sasha-00016-g5c9d68d-dirty #129 [ 316.320051] Call Trace: [ 316.340058] pps pps0: PPS event at 1352918752.620355751 [ 316.340062] pps pps0: capture assert seq #303 [ 316.320051] [<ffffffff83b3856b>] panic+0xcd/0x1f4 [ 316.320051] [<ffffffff81f5bac7>] ? store_host_reset+0xd7/0x100 [ 316.320051] [<ffffffff8110b996>] __stack_chk_fail+0x16/0x20 [ 316.320051] [<ffffffff81f5bac7>] store_host_reset+0xd7/0x100 [ 316.320051] [<ffffffff81e55bb3>] dev_attr_store+0x13/0x30 [ 316.320051] [<ffffffff812f7db1>] sysfs_write_file+0x101/0x170 [ 316.320051] [<ffffffff8127acc8>] vfs_write+0xb8/0x180 [ 316.320051] [<ffffffff8127ae80>] sys_write+0x50/0xa0 [ 316.320051] [<ffffffff83c03418>] tracesys+0xe1/0xe6 Fix this by uninventing whatever was going on there and just use sysfs_streq. Bug introduced by 29443691 ("[SCSI] scsi: Added support for adapter and firmware reset"). [jejb: added necessary const to prevent compile warnings] Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
Xi Wang authored
commit beecadea upstream. The macro bit(n) is defined as ((u32)1 << n), and thus it doesn't work with n >= 32, such as in mvs_94xx_assign_reg_set(): if (i >= 32) { mvi->sata_reg_set |= bit(i); ... } The shift ((u32)1 << n) with n >= 32 also leads to undefined behavior. The result varies depending on the architecture. This patch changes bit(n) to do a 64-bit shift. It also simplifies mv_ffc64() using __ffs64(), since invoking ffz() with ~0 is undefined. Signed-off-by:
Xi Wang <xi.wang@gmail.com> Acked-by:
Xiangliang Yu <yuxiangl@marvell.com> Signed-off-by:
-
