- 17 Jan, 2013 40 commits
-
-
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:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
Eugene Shatokhin <eugene.shatokhin@rosalab.ru> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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:
-
Sangbeom Kim authored
commit f7ebaaeb upstream. This patch fix the abnormal ramp delay setting. The shift operation was wrong. Signed-off-by:
Sangbeom Kim <sbkim73@samsung.com> Signed-off-by:
-
Lars-Peter Clausen authored
commit a3adb143 upstream. The 'addr' field of the sigma_action struct is stored as big endian in the firmware file. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Mark Brown authored
commit 72222be3 upstream. Signed-off-by:
-
Bjørn Mork authored
commit 3935e895 upstream. Commit 8d451690 ("watchdog: Fix CPU hotplug regression") causes an oops or hard lockup when doing echo 0 > /proc/sys/kernel/nmi_watchdog echo 1 > /proc/sys/kernel/nmi_watchdog and the kernel is booted with nmi_watchdog=1 (default) Running laptop-mode-tools and disconnecting/connecting AC power will cause this to trigger, making it a common failure scenario on laptops. Instead of bailing out of watchdog_disable() when !watchdog_enabled we can initialize the hrtimer regardless of watchdog_enabled status. This makes it safe to call watchdog_disable() in the nmi_watchdog=0 case, without the negative effect on the enabled => disabled => enabled case. All these tests pass with this patch: - nmi_watchdog=1 echo 0 > /proc/sys/kernel/nmi_watchdog echo 1 > /proc/sys/kernel/nmi_watchdog - nmi_watchdog=0 echo 0 > /sys/devices/system/cpu/cpu1/online - nmi_watchdog=0 echo mem > /sys/power/state Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=51661Signed-off-by:
Bjørn Mork <bjorn@mork.no> Cc: Norbert Warmuth <nwarmuth@t-online.de> Cc: Joseph Salisbury <joseph.salisbury@canonical.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Stephan Gatzka authored
commit 9d237342 upstream. This patch fixes both the transmit and receive portion of sending fragmented mutlicast and broadcast packets. The transmit section was broken because the offset for INTFRAG and LASTFRAG packets were just miscalculated by IEEE1394_GASP_HDR_SIZE (which was reserved with skb_push() in fwnet_send_packet). The receive section was broken because in fwnet_incoming_packet is a call to fwnet_peer_find_by_node_id(). Called with generation == -1 it will not find a peer and the partial datagrams are associated to a peer. [Stefan R: The fix to use context->card->generation is not perfect. It relies on the IR tasklet which processes packets from the prior bus generation to run before the self-ID-complete worklet which sets the current card generation. Alas, there is no simple way of a race-free implementation. Let's do it this way for now.] Signed-off-by:
Stephan Gatzka <stephan.gatzka@gmail.com> Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Christian Lamparter authored
commit 6c653f66 upstream. Sean reported that as of 3.7, his AR9170 device no longer works because the driver fails during initialization. He noted this is due to: "In carl9170/fw.c, ar->hw->wiphy is tagged with NL80211_IFTYPE_MESH_POINT support if the firmware has Content after Beacon Queuing. This is both in interface_modes and the only iface_combinations entry. If CONFIG_MAC80211_MESH is not set, ieee80211_register_hw removes NL80211_IFTYPE_MESH_POINT from interface_modes, but not iface_combinations. wiphy_register then checks to see if every interface type in every interface combination is in interface_modes. NL80211_IFTYPE_MESH_POINT was removed, so you get a WARN_ON warning and it returns -EINVAL, giving up." Unfortunately, the iface_combination (types) feature bitmap in ieee80211_iface_limit is part of a const member in the ieee80211_iface_combination struct. Hence, the MESH_POINT feature flag can't be masked by wiphy_register in the same way as interface_modes in ieee80211_register_hw. Reported-by:
Sean Patrick Santos <quantheory@gmail.com> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Tested-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit 5b632fe8 upstream. Commit f0425bed "mac80211: retry sending failed BAR frames later instead of tearing down aggr" caused regression on rt2x00 hardware (connection hangs). This regression was fixed by commit be03d4a4 "rt2x00: Don't let mac80211 send a BAR when an AMPDU subframe fails". But the latter commit caused yet another problem reported in https://bugzilla.kernel.org/show_bug.cgi?id=42828#c22 After long discussion in this thread: http://mid.gmane.org/20121018075615.GA18212@redhat.com and testing various alternative solutions, which failed on one or other setup, we have no other good fix for the issues like just revert both mentioned earlier commits. To do not affect other hardware which benefit from commit f0425bed, instead of reverting it, introduce flag that when used will restore mac80211 behaviour before the commit. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> [replaced link with mid.gmane.org that has message-id] Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Sujith Manoharan authored
commit a796a1dd upstream. Populate iniModesRxGain with the correct initvals array for AR9485 v1.1 Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Felix Fietkau authored
commit b7c0c238 upstream. While AR_PHY_CCA_NOM_VAL_* does contain the expected internal noise floor for a chip measured in clean air, it refers to the lowest expected reading. Depending on the frequency, this measurement can vary by about 6db, thus causing a higher reported channel noise and signal strength. Factor in the 6db offset when converting internal noisefloor to channel noise. This patch makes the reported values more accurate for all chips without affecting NF calibration behavior. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
-
Gabor Juhos authored
commit b3cd8021 upstream. Trying to access the OTP memory on the AR9340 causes a data bus error like this: Data bus error, epc == 86e84164, ra == 86e84164 Oops[#1]: Cpu 0 $ 0 : 00000000 00000061 deadc0de 00000000 $ 4 : b8115f18 00015f18 00000007 00000004 $ 8 : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c $12 : 7c7c3c7c 001f0041 00000000 7c7c7c3c $16 : 86ee0000 00015f18 00000000 00000007 $20 : 00000004 00000064 00000004 86d71c44 $24 : 00000000 86e6ca00 $28 : 86d70000 86d71b20 86ece0c0 86e84164 Hi : 00000000 Lo : 00000064 epc : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw] Tainted: G O ra : 86e84164 ath9k_hw_wait+0x58/0xb0 [ath9k_hw] Status: 1100d403 KERNEL EXL IE Cause : 4080801c PrId : 0001974c (MIPS 74Kc) Modules linked in: ath9k(O+) ath9k_common(O) ath9k_hw(O) ath(O) ar934x_nfc mac80211(O) usbcore usb_common scsi_mod nls_base nand nand_ecc nand_ids crc_ccitt cfg80211(O) compat(O) arc4 aes_generic crypto_blkcipher cryptomgr aead crypto_hash crypto_algapi ledtrig_timer ledtrig_default_on leds_gpio Process insmod (pid: 459, threadinfo=86d70000, task=87942140, tls=779ac440) Stack : 802fb500 000200da 804db150 804e0000 87816130 86ee0000 00010000 86d71b88 86d71bc0 00000004 00000003 86e9fcd0 80305300 0002c0d0 86e74c50 800b4c20 000003e8 00000001 00000000 86ee0000 000003ff 86e9fd64 80305300 80123938 fffffffc 00000004 000058bc 00000000 86ea0000 86ee0000 000001ff 878d6000 99999999 86e9fdc0 86ee0fcc 86e9e664 0000c0d0 86ee0000 0000700000007000 ... Call Trace: [<86e84164>] ath9k_hw_wait+0x58/0xb0 [ath9k_hw] [<86e9fcd0>] ath9k_hw_setup_statusring+0x16b8/0x1c7c [ath9k_hw] Code: 0000a812 0040f809 00000000 <00531024> 1054000b 24020001 0c05b5dc 2404000a 26520001 The cause of the error is that the OTP register offsets are different on the AR9340 than the actually used values. Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Signed-off-by:
-
Felix Fietkau authored
commit 9c170e06 upstream. This reverts commit f74b9d36. Turns out reverting commit a240dc7b "ath9k_hw: Updated AR9003 tx gain table for 5GHz" was not enough to bring the tx power back to normal levels on devices like the Buffalo WZR-HP-G450H, this one needs to be reverted as well. This revert improves tx power by ~10 db on that device Signed-off-by:
-
Rajkumar Manoharan authored
commit 16802602 upstream. This reduced the power consumption to half in full and network sleep. Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Cc: Paul Stewart <pstew@chromium.org> Signed-off-by:
-
Max Filippov authored
commit 10d73e65 upstream. Currently free_all_bootmem_core ignores that node_min_pfn may be not multiple of BITS_PER_LONG. Eg commit 6dccdcbe ("mm: bootmem: fix checking the bitmap when finally freeing bootmem") shifts vec by lower bits of start instead of lower bits of idx. Also if (IS_ALIGNED(start, BITS_PER_LONG) && vec == ~0UL) assumes that vec bit 0 corresponds to start pfn, which is only true when node_min_pfn is a multiple of BITS_PER_LONG. Also loop in the else clause can double-free pages (e.g. with node_min_pfn == start == 1, map[0] == ~0 on 32-bit machine page 32 will be double-freed). This bug causes the following message during xtensa kernel boot: bootmem::free_all_bootmem_core nid=0 start=1 end=8000 BUG: Bad page state in process swapper pfn:00001 page:d04bd020 count:0 mapcount:-127 mapping: (null) index:0x2 page flags: 0x0() Call Trace: bad_page+0x8c/0x9c free_pages_prepare+0x5e/0x88 free_hot_cold_page+0xc/0xa0 __free_pages+0x24/0x38 __free_pages_bootmem+0x54/0x56 free_all_bootmem_core$part$11+0xeb/0x138 free_all_bootmem+0x46/0x58 mem_init+0x25/0xa4 start_kernel+0x11e/0x25c should_never_return+0x0/0x3be7 The fix is the following: - always align vec so that its bit 0 corresponds to start - provide BITS_PER_LONG bits in vec, if those bits are available in the map - don't free pages past next start position in the else clause. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Cc: Gavin Shan <shangw@linux.vnet.ibm.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Tejun Heo <tj@kernel.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Joonsoo Kim <js1304@gmail.com> Cc: Prasad Koya <prasad.koya@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Laura Abbott authored
commit c060f943 upstream. The current calculation in pfn_to_bitidx assumes that (pfn - zone->zone_start_pfn) >> pageblock_order will return the same bit for all pfn in a pageblock. If zone_start_pfn is not aligned to pageblock_nr_pages, this may not always be correct. Consider the following with pageblock order = 10, zone start 2MB: pfn | pfn - zone start | (pfn - zone start) >> page block order ---------------------------------------------------------------- 0x26000 | 0x25e00 | 0x97 0x26100 | 0x25f00 | 0x97 0x26200 | 0x26000 | 0x98 0x26300 | 0x26100 | 0x98 This means that calling {get,set}_pageblock_migratetype on a single page will not set the migratetype for the full block. Fix this by rounding down zone_start_pfn when doing the bitidx calculation. For our use case, the effects of this bug were mostly tied to the fact that CMA allocations would either take a long time or fail to happen. Depending on the driver using CMA, this could result in anything from visual glitches to application failures. Signed-off-by:
Laura Abbott <lauraa@codeaurora.org> Acked-by:
Mel Gorman <mgorman@suse.de> Signed-off-by:
-
Jason Liu authored
commit 7964c06d upstream. when run the folloing command under shell, it will return error sh/$ echo 1 > /proc/sys/vm/compact_memory sh/$ sh: write error: Bad address After strace, I found the following log: ... write(1, "1\n", 2) = 3 write(1, "", 4294967295) = -1 EFAULT (Bad address) write(2, "echo: write error: Bad address\n", 31echo: write error: Bad address ) = 31 This tells system return 3(COMPACT_COMPLETE) after write data to compact_memory. The fix is to make the system just return 0 instead 3(COMPACT_COMPLETE) from sysctl_compaction_handler after compaction_nodes finished. Signed-off-by:
Jason Liu <r64343@freescale.com> Suggested-by:
David Rientjes <rientjes@google.com> Acked-by:
-
Huacai Chen authored
commit 8add1ecb upstream. When poweroff machine, kernel_power_off() call disable_nonboot_cpus(). And if we have HOTPLUG_CPU configured, disable_nonboot_cpus() is not an empty function but attempt to actually disable the nonboot cpus. Since system state is SYSTEM_POWER_OFF, play_dead() won't be called and thus disable_nonboot_cpus() hangs. Therefore, we make this patch to avoid poweroff failure. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Signed-off-by:
Hongliang Tao <taohl@lemote.com> Signed-off-by:
Hua Yan <yanh@lemote.com> Cc: Yong Zhang <yong.zhang@windriver.com> Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/4211/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
