- 04 Dec, 2013 40 commits
-
-
Nicholas Bellinger authored
commit 04d9cd12 upstream. This patch avoids a duplicate iscsit_increment_maxcmdsn() call for ISER_IB_RDMA_WRITE within isert_map_rdma() + isert_reg_rdma_frwr(), which will already be occuring once during isert_put_datain() -> iscsit_build_rsp_pdu() operation. It also removes the local conn->stat_sn assignment + increment, and changes the third parameter to iscsit_build_rsp_pdu() to signal this should be done by iscsi_target_mode code. Tested-by:
Moussa Ba <moussaba@micron.com> Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jerome Glisse authored
commit 97b6ff6b upstream. GPU with low amount of ram can fails at pinning new framebuffer before unpinning old one. On such failure, retry with unpinning old one before pinning new one allowing to work around the issue. This is somewhat ugly but only affect those old GPU we care about. Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 958b84fb upstream. Adjust some of the TN dpm settings for stability. Enabling these features causes hangs and other stability problems on certain boards. v2: leave uvd dpm enabled Bug: https://bugzilla.kernel.org/show_bug.cgi?id=63101Signed-off-by:
-
Samuel Li authored
commit 7272c9d2 upstream. Fixes crashes when handling atif events due to the lack of a callback being registered. Signed-off-by:
Samuel Li <samuel.li@amd.com> Signed-off-by:
-
Jerome Glisse authored
commit fae009d1 upstream. Useless to count the register index in number of bytes we are writing. Fixes a regression with hw i2c enabled. Signed-off-by:
-
Alex Deucher authored
commit 70471860 upstream. Sharing PPLLs seems to cause problems on some boards. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=45334Signed-off-by:
-
Christian König authored
commit 727ddc84 upstream. The parameter is in bytes not dwords. Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Christian König authored
commit c154a763 upstream. Make sure the UVD clocks are still active before sending the destroy message, otherwise the hw might hang. Signed-off-by:
-
Alex Deucher authored
commit d5693761 upstream. Typo in the register offset. Noticed-by:
Sylvain BERTRAND <sylware@legeek.net> Signed-off-by:
-
Ben Skeggs authored
commit 9360bd11 upstream. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Daniel Vetter authored
commit 10214420 upstream. Haswell's DDI encoders have their own ->get_config callback and in commit c6cd2ee2 Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Oct 21 10:52:07 2013 +0300 drm/i915/dp: workaround BIOS eDP bpp clamping issue we've forgotten to replicate this hack. So let's do it that. Note for backporters: The above commit and all it's depencies need to be backported first. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71049Tested-by:
Gökçen Eraslan <gokcen.eraslan@gmail.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
commit ef46e0d2 upstream. Some BIOS just leak the forcewak bits, which we clean up. Unfortunately this has been broken in commit 521198a2 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Aug 23 16:52:30 2013 +0300 drm/i915: sanitize forcewake registers on reset To make this work both for resets and for BIOS takeover just add the forcewake clearing call back to intel_uncore_early_sanitize. We need to clear the forcewake in early sanitize so that the forcewak dance in intel_uncore_init (to figure out whether we have mt or legacy forcewake on ivb) works. That cleanup fits in nicely with the general topic of early_sanitize to prepare for the very first mmio ops. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by:
Jörg Otte <jrg.otte@gmail.com> Cc: Jörg Otte <jrg.otte@gmail.com> References: https://lkml.org/lkml/2013/11/16/40Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
commit b2ea8ef5 upstream. Apparently they need the same treatment as primary planes. This fixes modesetting failures because of stuck cursors (!) on Thomas' i830M machine. I've figured while at it I'll also roll it out for the ivb 3 pipe version of this function. I didn't do this for i845/i865 since Bspec says the update mechanism works differently, and there's some additional rules about what can be updated in which order. Tested-by:
Thomas Richter <thor@math.tu-berlin.de> Cc: Thomas Richter <thor@math.tu-berlin.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
commit 48f34e10 upstream. The ns2501 controller seems to need the dpll and dvo port to accept the timing update commands. Quick testing on my x30 here seems to indicate that other dvo controllers don't mind. So let's move the ->mode_set callback to a place where we have the port up and running already. Tested-by:
-
Thomas Hellstrom authored
commit da95c788 upstream. All error paths will want to keep the mm node, so handle this at the function exit. This fixes an ioremap failure error path. Also add some comments to make the function a bit easier to understand. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com> Signed-off-by:
-
Jakob Bornecrantz authored
commit 9a0599dd upstream. Fix the case where the ttm pointer may be NULL causing a NULL pointer dereference. Signed-off-by:
-
Thomas Hellstrom authored
commit 59c8e663 upstream. Also check the busy placements before deciding to move a buffer object. Failing to do this may result in a completely unneccessary move within a single memory type. Signed-off-by:
-
Thomas Hellstrom authored
commit ea029c28 upstream. Fix an error message that was incorrectly blaming device resource id shortage. Also make sure we correctly catch resource eviction errors, that could otherwise lead to evictable resources temporarily not being on the LRU list. Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 8a56d776 upstream. Commit 8c4f3c3f "ftrace: Check module functions being traced on reload" fixed module loading and unloading with respect to function tracing, but it missed the function graph tracer. If you perform the following # cd /sys/kernel/debug/tracing # echo function_graph > current_tracer # modprobe nfsd # echo nop > current_tracer You'll get the following oops message: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 2910 at /linux.git/kernel/trace/ftrace.c:1640 __ftrace_hash_rec_update.part.35+0x168/0x1b9() Modules linked in: nfsd exportfs nfs_acl lockd ipt_MASQUERADE sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables uinput snd_hda_codec_idt CPU: 2 PID: 2910 Comm: bash Not tainted 3.13.0-rc1-test #7 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007 0000000000000668 ffff8800787efcf8 ffffffff814fe193 ffff88007d500000 0000000000000000 ffff8800787efd38 ffffffff8103b80a 0000000000000668 ffffffff810b2b9a ffffffff81a48370 0000000000000001 ffff880037aea000 Call Trace: [<ffffffff814fe193>] dump_stack+0x4f/0x7c [<ffffffff8103b80a>] warn_slowpath_common+0x81/0x9b [<ffffffff810b2b9a>] ? __ftrace_hash_rec_update.part.35+0x168/0x1b9 [<ffffffff8103b83e>] warn_slowpath_null+0x1a/0x1c [<ffffffff810b2b9a>] __ftrace_hash_rec_update.part.35+0x168/0x1b9 [<ffffffff81502f89>] ? __mutex_lock_slowpath+0x364/0x364 [<ffffffff810b2cc2>] ftrace_shutdown+0xd7/0x12b [<ffffffff810b47f0>] unregister_ftrace_graph+0x49/0x78 [<ffffffff810c4b30>] graph_trace_reset+0xe/0x10 [<ffffffff810bf393>] tracing_set_tracer+0xa7/0x26a [<ffffffff810bf5e1>] tracing_set_trace_write+0x8b/0xbd [<ffffffff810c501c>] ? ftrace_return_to_handler+0xb2/0xde [<ffffffff811240a8>] ? __sb_end_write+0x5e/0x5e [<ffffffff81122aed>] vfs_write+0xab/0xf6 [<ffffffff8150a185>] ftrace_graph_caller+0x85/0x85 [<ffffffff81122dbd>] SyS_write+0x59/0x82 [<ffffffff8150a185>] ftrace_graph_caller+0x85/0x85 [<ffffffff8150a2d2>] system_call_fastpath+0x16/0x1b ---[ end trace 940358030751eafb ]--- The above mentioned commit didn't go far enough. Well, it covered the function tracer by adding checks in __register_ftrace_function(). The problem is that the function graph tracer circumvents that (for a slight efficiency gain when function graph trace is running with a function tracer. The gain was not worth this). The problem came with ftrace_startup() which should always be called after __register_ftrace_function(), if you want this bug to be completely fixed. Anyway, this solution moves __register_ftrace_function() inside of ftrace_startup() and removes the need to call them both. Reported-by:
Dave Wysochanski <dwysocha@redhat.com> Fixes: ed926f9b ("ftrace: Use counters to enable functions to trace") Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Mattia Dongili authored
commit b975dc36 upstream. Follow-up to commit 294d31e8 ("sony-laptop: don't change keyboard backlight settings"): avoid messing up the state on resume. Leave it to what was before suspending as it's anyway likely that we still don't know what value we should write to the EC registers. This fix is also required in 3.12 Tested-by:
Karol Babioch <karol@babioch.de> Signed-off-by:
Mattia Dongili <malattia@linux.it> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Tim Harvey authored
commit 88baf714 upstream. prior to week 08 of 2013 Freescale misprogrammed between 1 and 3% of PFUZE1000 parts with a ID=0x8 instead of the expected ID=0x0 Signed-off-by:
Tim Harvey <tharvey@gateworks.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Dan Williams authored
commit 8e3ffa47 upstream. Userspace uses the netdev devtype for stuff like device naming and type detection. Be nice and set it. Remove the pointless #if/#endif around SET_NETDEV_DEV too. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Peter Hurley authored
commit 42458f41 upstream. A departing reader must restart a flush_to_ldisc() worker _before_ the next reader enters the read loop; this is to avoid the new reader concluding no more i/o is available and prematurely exiting, when the old reader simply hasn't re-started the worker yet. Signed-off-by:
Peter Hurley <peter@hurleysoftware.com> Signed-off-by:
-
Peter Hurley authored
commit d4855e1f upstream. A common security idiom is to hangup the current tty (via vhangup()) after forking but before execing a root shell. This hangs up any existing opens which other processes may have and ensures subsequent opens have the necessary permissions to open the root shell tty/pty. Reset the TTY_HUPPED state after the driver has successfully returned the opened tty (perform the reset while the tty is locked to avoid racing with concurrent hangups). Reported-by:
Heorhi Valakhanovich <valahanovich@tut.by> Signed-off-by:
-
Peter Hurley authored
commit 6f222536 upstream. Commit cbfd0340, 'n_tty: Process echoes in blocks', introduced an error when consuming the echo buffer tail to prevent buffer overrun, where the incorrect operation code byte is checked to determine how far to advance the tail to the next echo byte. Check the correct byte for the echo operation code byte. Signed-off-by:
-
Roel Kluin authored
commit c476f658 upstream. test echo_buf() result for ECHO_OP_START Signed-off-by:
Roel Kluin <roel.kluin@gmail.com> Acked-by:
-
Peter Hurley authored
commit c77569d2 upstream. Although the maximum allowable canonical line is specified to be 255 bytes (MAX_CANON), the practical limit has actually been the size of the line discipline read buffer (N_TTY_BUF_SIZE == 4096). Commit 32f13521, n_tty: Line copy to user buffer in canonical mode, limited the line copy to 4095 bytes. With a completely full line discipline read buffer and a userspace buffer > 4095, _no_ data was copied, and the read() syscall returned 0, indicating EOF. Fix the interval arithmetic to compute the correct number of bytes to copy to userspace in the range [1..4096]. Signed-off-by:
-
Andreas Bießmann authored
commit d617b338 upstream. This patch fixes following error (for big kernels): ---8<--- arch/avr32/boot/u-boot/head.o: In function `no_tag_table': (.init.text+0x44): relocation truncated to fit: R_AVR32_22H_PCREL against symbol `panic' defined in .text.unlikely section in kernel/built-in.o arch/avr32/kernel/built-in.o: In function `bad_return': (.ex.text+0x236): relocation truncated to fit: R_AVR32_22H_PCREL against symbol `panic' defined in .text.unlikely section in kernel/built-in.o --->8--- It comes up when the kernel increases and 'panic()' is too far away to fit in the +/- 2MiB range. Which in turn issues from the 21-bit displacement in 'br{cond4}' mnemonic which is one of the two ways to do jumps (rjmp has just 10-bit displacement and therefore a way smaller range). This fact was stated before in 8d29b7b9. One solution to solve this is to add a local storage for the symbol address and just load the $pc with that value. Signed-off-by:
Andreas Bießmann <andreas@biessmann.de> Acked-by:
Hans-Christian Egtvedt <egtvedt@samfundet.no> Cc: Haavard Skinnemoen <hskinnemoen@gmail.com> Signed-off-by:
-
Andreas Bießmann authored
commit 7a2a74f4 upstream. Before the CRT was (fully) set up in kernel_entry (bss cleared before in _start, but also not before jump to panic() in no_tag_table case). This patch fixes this up to have a fully working CRT when branching to panic() in no_tag_table. Signed-off-by:
-
Paul Moore authored
commit 42d64e1a upstream. The SELinux/NetLabel glue code has a locking bug that affects systems with NetLabel enabled, see the kernel error message below. This patch corrects this problem by converting the bottom half socket lock to a more conventional, and correct for this call-path, lock_sock() call. =============================== [ INFO: suspicious RCU usage. ] 3.11.0-rc3+ #19 Not tainted ------------------------------- net/ipv4/cipso_ipv4.c:1928 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 2 locks held by ping/731: #0: (slock-AF_INET/1){+.-...}, at: [...] selinux_netlbl_socket_connect #1: (rcu_read_lock){.+.+..}, at: [<...>] netlbl_conn_setattr stack backtrace: CPU: 1 PID: 731 Comm: ping Not tainted 3.11.0-rc3+ #19 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 0000000000000001 ffff88006f659d28 ffffffff81726b6a ffff88003732c500 ffff88006f659d58 ffffffff810e4457 ffff88006b845a00 0000000000000000 000000000000000c ffff880075aa2f50 ffff88006f659d90 ffffffff8169bec7 Call Trace: [<ffffffff81726b6a>] dump_stack+0x54/0x74 [<ffffffff810e4457>] lockdep_rcu_suspicious+0xe7/0x120 [<ffffffff8169bec7>] cipso_v4_sock_setattr+0x187/0x1a0 [<ffffffff8170f317>] netlbl_conn_setattr+0x187/0x190 [<ffffffff8170f195>] ? netlbl_conn_setattr+0x5/0x190 [<ffffffff8131ac9e>] selinux_netlbl_socket_connect+0xae/0xc0 [<ffffffff81303025>] selinux_socket_connect+0x135/0x170 [<ffffffff8119d127>] ? might_fault+0x57/0xb0 [<ffffffff812fb146>] security_socket_connect+0x16/0x20 [<ffffffff815d3ad3>] SYSC_connect+0x73/0x130 [<ffffffff81739a85>] ? sysret_check+0x22/0x5d [<ffffffff810e5e2d>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [<ffffffff81373d4e>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff815d52be>] SyS_connect+0xe/0x10 [<ffffffff81739a59>] system_call_fastpath+0x16/0x1b Signed-off-by:
Paul Moore <pmoore@redhat.com> Signed-off-by:
-
Toshi Kani authored
commit ca499fc8 upstream. The PCI host bridge scan handler installs its own notify handler, handle_hotplug_event_root(), by itself. Nevertheless, the ACPI hotplug framework also installs the common notify handler, acpi_hotplug_notify_cb(), for PCI root bridges. This causes acpi_hotplug_notify_cb() to call _OST method with unsupported error as hotplug.enabled is not set. To address this issue, introduce hotplug.ignore flag, which indicates that the scan handler installs its own notify handler by itself. The ACPI hotplug framework does not install the common notify handler when this flag is set. Signed-off-by:
Toshi Kani <toshi.kani@hp.com> [rjw: Changed the name of the new flag] Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Yinghai Lu authored
commit e7cc5cf7 upstream. The pcie_portdrv .probe() method calls pci_enable_device() once, in pcie_port_device_register(), but the .remove() method calls pci_disable_device() twice, in pcie_port_device_remove() and in pcie_portdrv_remove(). That causes a "disabling already-disabled device" warning when removing a PCIe port device. This happens all the time when removing Thunderbolt devices, but is also easy to reproduce with, e.g., "echo 0000:00:1c.3 > /sys/bus/pci/drivers/pcieport/unbind" This patch removes the disable from pcie_portdrv_remove(). [bhelgaas: changelog, tag for stable] Reported-by:
David Bulkow <David.Bulkow@stratus.com> Reported-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Yinghai Lu <yinghai@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Jeff Layton authored
commit d3aea84a upstream. ...to make it clear what the intent behind each record's operation was. In many cases you can infer this, based on the context of the syscall and the result. In other cases it's not so obvious. For instance, in the case where you have a file being renamed over another, you'll have two different records with the same filename but different inode info. By logging this information we can clearly tell which one was created and which was deleted. This fixes what was broken in commit bfcec708. Commit 79f6530c should also be backported to stable v3.7+. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Eric Paris <eparis@redhat.com> Signed-off-by:
Richard Guy Briggs <rgb@redhat.com> Signed-off-by:
-
Jeff Layton authored
commit 14e972b4 upstream. Historically, when a syscall that creates a dentry fails, you get an audit record that looks something like this (when trying to create a file named "new" in "/tmp/tmp.SxiLnCcv63"): type=PATH msg=audit(1366128956.279:965): item=0 name="/tmp/tmp.SxiLnCcv63/new" inode=2138308 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 This record makes no sense since it's associating the inode information for "/tmp/tmp.SxiLnCcv63" with the path "/tmp/tmp.SxiLnCcv63/new". The recent patch I posted to fix the audit_inode call in do_last fixes this, by making it look more like this: type=PATH msg=audit(1366128765.989:13875): item=0 name="/tmp/tmp.DJ1O8V3e4f/" inode=141 dev=fd:02 mode=040700 ouid=0 ogid=0 rdev=00:00 obj=staff_u:object_r:user_tmp_t:s15:c0.c1023 While this is more correct, if the creation of the file fails, then we have no record of the filename that the user tried to create. This patch adds a call to audit_inode_child to may_create. This creates an AUDIT_TYPE_CHILD_CREATE record that will sit in place until the create succeeds. When and if the create does succeed, then this record will be updated with the correct inode info from the create. This fixes what was broken in commit bfcec708. Commit 79f6530c should also be backported to stable v3.7+. Signed-off-by:
-
Mathias Krause authored
commit 64fbff9a upstream. We leak 4 bytes of kernel stack in response to an AUDIT_GET request as we miss to initialize the mask member of status_set. Fix that. Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric Paris <eparis@redhat.com> Signed-off-by:
Mathias Krause <minipli@googlemail.com> Signed-off-by:
-
Mathias Krause authored
commit 4d8fe737 upstream. Using the nlmsg_len member of the netlink header to test if the message is valid is wrong as it includes the size of the netlink header itself. Thereby allowing to send short netlink messages that pass those checks. Use nlmsg_len() instead to test for the right message length. The result of nlmsg_len() is guaranteed to be non-negative as the netlink message already passed the checks of nlmsg_ok(). Also switch to min_t() to please checkpatch.pl. Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric Paris <eparis@redhat.com> Signed-off-by:
-
Tyler Hicks authored
commit 0868a5e1 upstream. When the audit=1 kernel parameter is absent and auditd is not running, AUDIT_USER_AVC messages are being silently discarded. AUDIT_USER_AVC messages should be sent to userspace using printk(), as mentioned in the commit message of 4a4cd633 ("AUDIT: Optimise the audit-disabled case for discarding user messages"). When audit_enabled is 0, audit_receive_msg() discards all user messages except for AUDIT_USER_AVC messages. However, audit_log_common_recv_msg() refuses to allocate an audit_buffer if audit_enabled is 0. The fix is to special case AUDIT_USER_AVC messages in both functions. It looks like commit 50397bd1 ("[AUDIT] clean up audit_receive_msg()") introduced this bug. Signed-off-by:
Tyler Hicks <tyhicks@canonical.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric Paris <eparis@redhat.com> Cc: linux-audit@redhat.com Acked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
-
Ujjal Roy authored
commit 8d93f1f3 upstream. The eth_hdr is never defined in this driver but it gets compiled without any warning/error because kernel has defined eth_hdr. Fix it by defining our own p_ethhdr and use it instead of eth_hdr. Signed-off-by:
Ujjal Roy <royujjal@gmail.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
-
Avinash Patil authored
commit d03b4aa7 upstream. While receiving a packet on SDIO interface, we allocate skb with size multiple of SDIO block size. We need to resize this skb after RX using packet length from RX header. Signed-off-by:
Avinash Patil <patila@marvell.com> Signed-off-by:
-
Pavel Shilovsky authored
commit eb85d94b upstream. Now we treat any reparse point as a symbolic link and map it to a Unix one that is not true in a common case due to many reparse point types supported by SMB servers. Distinguish reparse point types into two groups: 1) that can be accessed directly through a reparse point (junctions, deduplicated files, NFS symlinks); 2) that need to be processed manually (Windows symbolic links, DFS); and map only Windows symbolic links to Unix ones. Acked-by:
Joao Correia <joaomiguelcorreia@gmail.com> Signed-off-by:
Pavel Shilovsky <piastry@etersoft.ru> Signed-off-by:
Steve French <smfrench@gmail.com> Signed-off-by:
-
