- 06 Aug, 2014 40 commits
-
-
Neal Cardwell authored
[ Upstream commit 2cd0d743 ] If there is an MSS change (or misbehaving receiver) that causes a SACK to arrive that covers the end of an skb but is less than one MSS, then tcp_match_skb_to_sack() was rounding up pkt_len to the full length of the skb ("Round if necessary..."), then chopping all bytes off the skb and creating a zero-byte skb in the write queue. This was visible now because the recently simplified TLP logic in bef1909e ("tcp: fixing TLP's FIN recovery") could find that 0-byte skb at the end of the write queue, and now that we do not check that skb's length we could send it as a TLP probe. Consider the following example scenario: mss: 1000 skb: seq: 0 end_seq: 4000 len: 4000 SACK: start_seq: 3999 end_seq: 4000 The tcp_match_skb_to_sack() code will compute: in_sack = false pkt_len = start_seq - TCP_SKB_CB(skb)->seq = 3999 - 0 = 3999 new_len = (pkt_len / mss) * mss = (3999/1000)*1000 = 3000 new_len += mss = 4000 Previously we would find the new_len > skb->len check failing, so we would fall through and set pkt_len = new_len = 4000 and chop off pkt_len of 4000 from the 4000-byte skb, leaving a 0-byte segment afterward in the write queue. With this new commit, we notice that the new new_len >= skb->len check succeeds, so that we return without trying to fragment. Fixes: adb92db8 ("tcp: Make SACK code to split only at mss boundaries") Reported-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Neal Cardwell <ncardwell@google.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Ilpo Jarvinen <ilpo.jarvinen@helsinki.fi> Acked-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Gavin Guo authored
commit bb86cf56 upstream. When using USB 3.0 pen drive with the [AMD] FCH USB XHCI Controller [1022:7814], the second hotplugging will experience the USB 3.0 pen drive is recognized as high-speed device. After bisecting the kernel, I found the commit number 41e7e056 (USB: Allow USB 3.0 ports to be disabled.) causes the bug. After doing some experiments, the bug can be fixed by avoiding executing the function hub_usb3_port_disable(). Because the port status with [AMD] FCH USB XHCI Controlleris [1022:7814] is already in RxDetect (I tried printing out the port status before setting to Disabled state), it's reasonable to check the port status before really executing hub_usb3_port_disable(). Fixes: 41e7e056 (USB: Allow USB 3.0 ports to be disabled.) Signed-off-by:
Gavin Guo <gavin.guo@canonical.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: use hub device as context for dev_dbg(), as hub ports are not devices in their own right] Signed-off-by:
-
Alex Deucher authored
commit 0ac66eff upstream. In some cases we fetch the edid in the detect() callback in order to determine what sort of monitor is connected. If that happens, don't fetch the edid again in the get_modes() callback or we will leak the edid. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Guenter Roeck authored
commit de12d6f4 upstream. Temperature limit registers are signed. Limits therefore need to be clamped to (-128, 127) degrees C and not to (0, 255) degrees C. Without this fix, writing a limit of 128 degrees C sets the actual limit to -128 degrees C. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Reviewed-by:
Axel Lin <axel.lin@ingics.com> [bwh: Backported to 3.2: driver was using SENSORS_LIMIT(), which we can replace with clamp_val()] Signed-off-by:
-
Peter Zijlstra authored
commit 4badad35 upstream. The optimistic spin code assumes regular stores and cmpxchg() play nice; this is found to not be true for at least: parisc, sparc32, tile32, metag-lock1, arc-!llsc and hexagon. There is further wreckage, but this in particular seemed easy to trigger, so blacklist this. Opt in for known good archs. Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Reported-by:
Mikulas Patocka <mpatocka@redhat.com> Cc: David Miller <davem@davemloft.net> Cc: Chris Metcalf <cmetcalf@tilera.com> Cc: James Bottomley <James.Bottomley@hansenpartnership.com> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Jason Low <jason.low2@hp.com> Cc: Waiman Long <waiman.long@hp.com> Cc: "James E.J. Bottomley" <jejb@parisc-linux.org> Cc: Paul McKenney <paulmck@linux.vnet.ibm.com> Cc: John David Anglin <dave.anglin@bell.net> Cc: James Hogan <james.hogan@imgtec.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Davidlohr Bueso <davidlohr@hp.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: sparclinux@vger.kernel.org Link: http://lkml.kernel.org/r/20140606175316.GV13930@laptop.programming.kicks-ass.netSigned-off-by:
Ingo Molnar <mingo@kernel.org> [bwh: Backported to 3.2: - Adjust context - Drop arm64 change] Signed-off-by:
-
Mateusz Guzik authored
commit b0ab99e7 upstream. proc_sched_show_task() does: if (nr_switches) do_div(avg_atom, nr_switches); nr_switches is unsigned long and do_div truncates it to 32 bits, which means it can test non-zero on e.g. x86-64 and be truncated to zero for division. Fix the problem by using div64_ul() instead. As a side effect calculations of avg_atom for big nr_switches are now correct. Signed-off-by:
Mateusz Guzik <mguzik@redhat.com> Signed-off-by:
-
Alex Shi authored
commit c2853c8d upstream. There is div64_long() to handle the s64/long division, but no mocro do u64/ul division. It is necessary in some scenarios, so add this function. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Alex Shi <alex.shi@intel.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Martin Lau authored
commit 97b8ee84 upstream. ring_buffer_poll_wait() should always put the poll_table to its wait_queue even there is immediate data available. Otherwise, the following epoll and read sequence will eventually hang forever: 1. Put some data to make the trace_pipe ring_buffer read ready first 2. epoll_ctl(efd, EPOLL_CTL_ADD, trace_pipe_fd, ee) 3. epoll_wait() 4. read(trace_pipe_fd) till EAGAIN 5. Add some more data to the trace_pipe ring_buffer 6. epoll_wait() -> this epoll_wait() will block forever ~ During the epoll_ctl(efd, EPOLL_CTL_ADD,...) call in step 2, ring_buffer_poll_wait() returns immediately without adding poll_table, which has poll_table->_qproc pointing to ep_poll_callback(), to its wait_queue. ~ During the epoll_wait() call in step 3 and step 6, ring_buffer_poll_wait() cannot add ep_poll_callback() to its wait_queue because the poll_table->_qproc is NULL and it is how epoll works. ~ When there is new data available in step 6, ring_buffer does not know it has to call ep_poll_callback() because it is not in its wait queue. Hence, block forever. Other poll implementation seems to call poll_wait() unconditionally as the very first thing to do. For example, tcp_poll() in tcp.c. Link: http://lkml.kernel.org/p/20140610060637.GA14045@devbig242.prn2.facebook.com Fixes: 2a2cc8f7 "ftrace: allow the event pipe to be polled" Reviewed-by:
Chris Mason <clm@fb.com> Signed-off-by:
Martin Lau <kafai@fb.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> [bwh: Backported to 3.2: the poll implementation looks rather different but does have a conditional return before and after the poll_wait() call; delete the return before it.] Signed-off-by:
-
Sasha Levin authored
commit 3cf521f7 upstream. The l2tp [get|set]sockopt() code has fallen back to the UDP functions for socket option levels != SOL_PPPOL2TP since day one, but that has never actually worked, since the l2tp socket isn't an inet socket. As David Miller points out: "If we wanted this to work, it'd have to look up the tunnel and then use tunnel->sk, but I wonder how useful that would be" Since this can never have worked so nobody could possibly have depended on that functionality, just remove the broken code and return -EINVAL. Reported-by:
Sasha Levin <sasha.levin@oracle.com> Acked-by:
James Chapman <jchapman@katalix.com> Acked-by:
-
Alex Deucher authored
commit f6be5e64 upstream. If there are error flags in the aux transaction return -EIO rather than -EBUSY. -EIO restarts the whole transaction while -EBUSY jus retries. Fixes problematic aux transfers. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=80684Signed-off-by:
-
Joe Thornber authored
commit 10f1d5d1 upstream. There's a race condition between the atomic_dec_and_test(&io->count) in dec_count() and the waking of the sync_io() thread. If the thread is spuriously woken immediately after the decrement it may exit, making the on stack io struct invalid, yet the dec_count could still be using it. Fix this race by using a completion in sync_io() and dec_count(). Reported-by:
Minfei Huang <huangminfei@ucloud.cn> Signed-off-by:
Joe Thornber <thornber@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Acked-by:
-
Stefan Assmann authored
commit 76252723 upstream. To properly re-initialize SR-IOV it is necessary to reset the device even if it is already down. Not doing this may result in Tx unit hangs. Signed-off-by:
Stefan Assmann <sassmann@kpanic.de> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
Bert Vermeulen authored
commit 5a7fbe7e upstream. This patch adds PID 0x0003 to the VID 0x128d (Testo). At least the Testo 435-4 uses this, likely other gear as well. Signed-off-by:
Bert Vermeulen <bert@biot.com> Cc: Johan Hovold <johan@kernel.org> Signed-off-by:
-
John Stultz authored
commit 16927776 upstream. Sharvil noticed with the posix timer_settime interface, using the CLOCK_REALTIME_ALARM or CLOCK_BOOTTIME_ALARM clockid, if the users tried to specify a relative time timer, it would incorrectly be treated as absolute regardless of the state of the flags argument. This patch corrects this, properly checking the absolute/relative flag, as well as adds further error checking that no invalid flag bits are set. Reported-by:
Sharvil Nanavati <sharvil@google.com> Signed-off-by:
John Stultz <john.stultz@linaro.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Sharvil Nanavati <sharvil@google.com> Link: http://lkml.kernel.org/r/1404767171-6902-1-git-send-email-john.stultz@linaro.orgSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Guenter Roeck authored
commit f6c2dd20 upstream. It is customary to clamp limits instead of bailing out with an error if a configured limit is out of the range supported by the driver. This simplifies limit configuration, since the user will not typically know chip and/or driver specific limits. Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
-
Miklos Szeredi authored
commit 233a01fa upstream. If the number in "user_id=N" or "group_id=N" mount options was larger than INT_MAX then fuse returned EINVAL. Fix this to handle all valid uid/gid values. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> [bwh: Backported to 3.2: no user namespace conversion] Signed-off-by:
-
Miklos Szeredi authored
commit 126b9d43 upstream. As suggested by checkpatch.pl, use time_before64() instead of direct comparison of jiffies64 values. Signed-off-by:
-
Guenter Roeck authored
commit 145e74a4 upstream. Upper limit for write operations to temperature limit registers was clamped to a fractional value. However, limit registers do not support fractional values. As a result, upper limits of 127.5 degrees C or higher resulted in a rounded limit of 128 degrees C. Since limit registers are signed, this was stored as -128 degrees C. Clamp limits to (-55, +127) degrees C to solve the problem. Value on writes to auto_temp[12]_min and auto_temp[12]_max were not clamped at all, but masked. As a result, out-of-range writes resulted in a more or less arbitrary limit. Clamp those attributes to (0, 127) degrees C for more predictable results. Cc: Axel Lin <axel.lin@ingics.com> Reviewed-by:
-
Lan Tianyu authored
commit 75646e75 upstream. Some machines (eg. Lenovo Z480) ECs are not stable during boot up and causes battery driver fails to be loaded due to failure of getting battery information from EC sometimes. After several retries, the operation will work. This patch is to retry to get battery information 5 times if the first try fails. Link: https://bugzilla.kernel.org/show_bug.cgi?id=75581Reported-and-tested-by:
naszar <naszar@ya.ru> Signed-off-by:
Lan Tianyu <tianyu.lan@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> [bwh: Backported to 3.2: acpi_battery_update() doesn't take a second parameter] Signed-off-by:
-
Lv Zheng authored
commit c0d65341 upstream. There is a race condition in ec_transaction_completed(). When ec_transaction_completed() is called in the GPE handler, it could return true because of (ec->curr == NULL). Then the wake_up() invocation could complete the next command unexpectedly since there is no lock between the 2 invocations. With the previous cleanup, the IBF=0 waiter race need not be handled any more. It's now safe to return a flag from advance_condition() to indicate the requirement of wakeup, the flag is returned from a locked context. The ec_transaction_completed() is now only invoked by the ec_poll() where the ec->curr is ensured to be different from NULL. After cleaning up, the EVT_SCI=1 check should be moved out of the wakeup condition so that an EVT_SCI raised with (ec->curr == NULL) can trigger a QR_SC command. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911Reported-and-tested-by:
Gareth Williams <gareth@garethwilliams.me.uk> Reported-and-tested-by:
Hans de Goede <jwrdegoede@fedoraproject.org> Reported-by:
Barton Xu <tank.xuhan@gmail.com> Tested-by:
Steffen Weber <steffen.weber@gmail.com> Tested-by:
Arthur Chen <axchen@nvidia.com> Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
-
Lv Zheng authored
commit 9b80f0f7 upstream. After we've added the first command byte write into advance_transaction(), the IBF=0 waiter is duplicated with the command completion waiter implemented in the ec_poll() because: If IBF=1 blocked the first command byte write invoked in the task context ec_poll(), it would be kicked off upon IBF=0 interrupt or timed out and retried again in the task context. Remove this seperate and duplicate IBF=0 waiter. By doing so we can reduce the overall number of times to access the EC_SC(R) status register. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911Reported-and-tested-by:
-
Lv Zheng authored
commit f92fca00 upstream. Move the first command byte write into advance_transaction() so that all EC register accesses that can affect the command processing state machine can happen in this asynchronous state machine advancement function. The advance_transaction() function then can be a complete implementation of an asyncrhonous transaction for a single command so that: 1. The first command byte can be written in the interrupt context; 2. The command completion waiter can also be used to wait the first command byte's timeout; 3. In BURST mode, the follow-up command bytes can be written in the interrupt context directly, so that it doesn't need to return to the task context. Returning to the task context reduces the throughput of the BURST mode and in the worst cases where the system workload is very high, this leads to the hardware driven automatic BURST mode exit. In order not to increase memory consumption, convert 'done' into 'flags' to contain multiple indications: 1. ACPI_EC_COMMAND_COMPLETE: converting from original 'done' condition, indicating the completion of the command transaction. 2. ACPI_EC_COMMAND_POLL: indicating the availability of writing the first command byte. A new command can utilize this flag to compete for the right of accessing the underlying hardware. There is a follow-up bug fix that has utilized this new flag. The 2 flags are important because it also reflects a key concept of IO programs' design used in the system softwares. Normally an IO program running in the kernel should first be implemented in the asynchronous way. And the 2 flags are the most common way to implement its synchronous operations on top of the asynchronous operations: 1. POLL: This flag can be used to block until the asynchronous operations can happen. 2. COMPLETE: This flag can be used to block until the asynchronous operations have completed. By constructing code cleanly in this way, many difficult problems can be solved smoothly. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911Reported-and-tested-by:
-
Feng Tang authored
commit a3cd8d27 upstream. Currently when advance_transaction() is called in EC interrupt handler, if there is nothing driver can do with the interrupt, it will be taken as a false one. But this is not always true, as there may be a SCI EC interrupt fired during normal read/write operation, which should not be counted as a false one. This patch fixes the problem. Signed-off-by:
Feng Tang <feng.tang@intel.com> Signed-off-by:
-
Lv Zheng authored
commit 66b42b78 upstream. The advance_transaction() will be invoked from the IRQ context GPE handler and the task context ec_poll(). The handling of this function is locked so that the EC state machine are ensured to be advanced sequentially. But there is a problem. Before invoking advance_transaction(), EC_SC(R) is read. Then for advance_transaction(), there could be race condition around the lock from both contexts. The first one reading the register could fail this race and when it passes the stale register value to the state machine advancement code, the hardware condition is totally different from when the register is read. And the hardware accesses determined from the wrong hardware status can break the EC state machine. And there could be cases that the functionalities of the platform firmware are seriously affected. For example: 1. When 2 EC_DATA(W) writes compete the IBF=0, the 2nd EC_DATA(W) write may be invalid due to IBF=1 after the 1st EC_DATA(W) write. Then the hardware will either refuse to respond a next EC_SC(W) write of the next command or discard the current WR_EC command when it receives a EC_SC(W) write of the next command. 2. When 1 EC_SC(W) write and 1 EC_DATA(W) write compete the IBF=0, the EC_DATA(W) write may be invalid due to IBF=1 after the EC_SC(W) write. The next EC_DATA(R) could never be responded by the hardware. This is the root cause of the reported issue. Fix this issue by moving the EC_SC(R) access into the lock so that we can ensure that the state machine is advanced consistently. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70891 Link: https://bugzilla.kernel.org/show_bug.cgi?id=63931 Link: https://bugzilla.kernel.org/show_bug.cgi?id=59911Reported-and-tested-by:
-
Puneet Kumar authored
commit 36b15875 upstream. A bug was introduced by commit b76b51ba ('ACPI / EC: Add more debug info and trivial code cleanup') that erroneously caused the struct member to be accessed before acquiring the required lock. This change fixes it by ensuring the lock acquisition is done first. Found by Aaron Durbin <adurbin@chromium.org> Fixes: b76b51ba ('ACPI / EC: Add more debug info and trivial code cleanup') References: http://crbug.com/319019Signed-off-by:
Puneet Kumar <puneetster@chromium.org> Reviewed-by:
Aaron Durbin <adurbin@chromium.org> [olof: Commit message reworded a bit] Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Feng Tang authored
commit b76b51ba upstream. Add more debug info for EC transaction debugging, like the interrupt status register value, the detail info of a EC transaction. Signed-off-by:
-
Bernd Wachter authored
commit 3d28bd84 upstream. Add ID of the Telewell 4G v2 hardware to option driver to get legacy serial interface working Signed-off-by:
Bernd Wachter <bernd.wachter@jolla.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Andras Kovacs authored
commit b9326057 upstream. Corsair USB Dongles are shipped with Corsair AXi series PSUs. These are cp210x serial usb devices, so make driver detect these. I have a program, that can get information from these PSUs. Tested with 2 different dongles shipped with Corsair AX860i and AX1200i units. Signed-off-by:
Andras Kovacs <andras@sth.sze.hu> Signed-off-by:
-
Eric Sandeen authored
commit 5dd21424 upstream. The mount manpage says of the max_batch_time option, This optimization can be turned off entirely by setting max_batch_time to 0. But the code doesn't do that. So fix the code to do that. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 3.2: option parsing looks different] Signed-off-by:
-
Theodore Ts'o authored
commit ae0f78de upstream. Make it clear that values printed are times, and that it is error since last fsck. Also add note about fsck version required. Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Andreas Dilger <adilger@dilger.ca> Signed-off-by:
-
Axel Lin authored
commit 1035a9e3 upstream. Writing to fanX_div does not clear the cache. As a result, reading from fanX_div may return the old value for up to two seconds after writing a new value. This patch ensures the fan_div cache is updated in set_fan_div(). Reported-by:
-
Axel Lin authored
commit df86754b upstream. temp2_input should not be writable, fix it. Reported-by:
-
Thomas Hellstrom authored
commit 4e578080 upstream. Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register: SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to SVGA_REG_PITCHLOCK. This patch is Cc'd stable because of the unknown effects writing to this register might have, particularly on older device versions. v2: Updated log message. Cc: Christopher Friedt <chrisfriedt@gmail.com> Tested-by:
Christopher Friedt <chrisfriedt@gmail.com> Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com> Signed-off-by:
-
Emmanuel Grumbach authored
commit 43d826ca upstream. We should always prefer to use full RTS protection. Using CTS to self gives a meaningless improvement, but this flow is much harder for the firmware which is likely to have issues with it. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> [bwh: Backported to 3.2: - Adjust filename - Condition for RXON_FLG_SELF_CTS_EN in iwlagn_commit_rxon() was different] Signed-off-by:
-
David Vrabel authored
commit 1b647823 upstream. Calling xen_console_resume() in xen_suspend() causes a warning because it locks irq_mapping_update_lock (a mutex) and this may sleep. If a userspace process is using the evtchn device then this mutex may be locked at the point of the stop_machine() call and xen_console_resume() would then deadlock. Resuming the console after stop_machine() returns avoids this deadlock. Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
NeilBrown authored
commit 133d4527 upstream. When we write to a degraded array which has a bitmap, we make sure the relevant bit in the bitmap remains set when the write completes (so a 're-add' can quickly rebuilt a temporarily-missing device). If, immediately after such a write starts, we incorporate a spare, commence recovery, and skip over the region where the write is happening (because the 'needs recovery' flag isn't set yet), then that write will not get to the new device. Once the recovery finishes the new device will be trusted, but will have incorrect data, leading to possible corruption. We cannot set the 'needs recovery' flag when we start the write as we do not know easily if the write will be "degraded" or not. That depends on details of the particular raid level and particular write request. This patch fixes a corruption issue of long standing and so it suitable for any -stable kernel. It applied correctly to 3.0 at least and will minor editing to earlier kernels. Reported-by:
Bill <billstuff2001@sbcglobal.net> Tested-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
HATAYAMA Daisuke authored
commit b292d7a1 upstream. Currently, any NMI is falsely handled by a NMI handler of NMI watchdog if CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR is set. For example, we use external NMI to make system panic to get crash dump, but in this case, the external NMI is falsely handled do to the issue. This commit deals with the issue simply by ignoring CondChgd bit. Here is explanation in detail. On x86 NMI watchdog uses performance monitoring feature to periodically signal NMI each time performance counter gets overflowed. intel_pmu_handle_irq() is called as a NMI_LOCAL handler from a NMI handler of NMI watchdog, perf_event_nmi_handler(). It identifies an owner of a given NMI by looking at overflow status bits in MSR_CORE_PERF_GLOBAL_STATUS MSR. If some of the bits are set, then it handles the given NMI as its own NMI. The problem is that the intel_pmu_handle_irq() doesn't distinguish CondChgd bit from other bits. Unlike the other status bits, CondChgd bit doesn't represent overflow status for performance counters. Thus, CondChgd bit cannot be thought of as a mark indicating a given NMI is NMI watchdog's. As a result, if CondChgd bit is set, any NMI is falsely handled by the NMI handler of NMI watchdog. Also, if type of the falsely handled NMI is either NMI_UNKNOWN, NMI_SERR or NMI_IO_CHECK, the corresponding action is never performed until CondChgd bit is cleared. I noticed this behavior on systems with Ivy Bridge processors: Intel Xeon CPU E5-2630 v2 and Intel Xeon CPU E7-8890 v2. On both systems, CondChgd bit in MSR_CORE_PERF_GLOBAL_STATUS MSR has already been set in the beginning at boot. Then the CondChgd bit is immediately cleared by next wrmsr to MSR_CORE_PERF_GLOBAL_CTRL MSR and appears to remain 0. On the other hand, on older processors such as Nehalem, Xeon E7540, CondChgd bit is not set in the beginning at boot. I'm not sure about exact behavior of CondChgd bit, in particular when this bit is set. Although I read Intel System Programmer's Manual to figure out that, the descriptions I found are: In 18.9.1: "The MSR_PERF_GLOBAL_STATUS MSR also provides a ¡sticky bit¢ to indicate changes to the state of performancmonitoring hardware" In Table 35-2 IA-32 Architectural MSRs 63 CondChg: status bits of this register has changed. These are different from the bahviour I see on the actual system as I explained above. At least, I think ignoring CondChgd bit should be enough for NMI watchdog perspective. Signed-off-by:
HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> Acked-by:
Don Zickus <dzickus@redhat.com> Signed-off-by:
-
Alan Stern authored
commit b14bf2d0 upstream. Some buggy JMicron USB-ATA bridges don't know how to translate the FUA bit in READs or WRITEs. This patch adds an entry in unusual_devs.h and a blacklist flag to tell the sd driver not to use FUA. Signed-off-by:
Michael Büsch <m@bues.ch> Tested-by:
James Bottomley <James.Bottomley@HansenPartnership.com> CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net> Signed-off-by:
-
Michal Nazarewicz authored
commit f35f7124 upstream. It appears that no one ever run ffs-test on a big-endian machine, since it used cpu-endianess for fs_count and hs_count fields which should be in little-endian format. Fix by wrapping the numbers in cpu_to_le32. Signed-off-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
J. Bruce Fields authored
commit 76f47128 upstream. An NFS operation that creates a new symlink includes the symlink data, which is xdr-encoded as a length followed by the data plus 0 to 3 bytes of zero-padding as required to reach a 4-byte boundary. The vfs, on the other hand, wants null-terminated data. The simple way to handle this would be by copying the data into a newly allocated buffer with space for the final null. The current nfsd_symlink code tries to be more clever by skipping that step in the (likely) case where the byte following the string is already 0. But that assumes that the byte following the string is ours to look at. In fact, it might be the first byte of a page that we can't read, or of some object that another task might modify. Worse, the NFSv4 code tries to fix the problem by actually writing to that byte. In the NFSv2/v3 cases this actually appears to be safe: - nfs3svc_decode_symlinkargs explicitly null-terminates the data (after first checking its length and copying it to a new page). - NFSv2 limits symlinks to 1k. The buffer holding the rpc request is always at least a page, and the link data (and previous fields) have maximum lengths that prevent the request from reaching the end of a page. In the NFSv4 case the CREATE op is potentially just one part of a long compound so can end up on the end of a page if you're unlucky. The minimal fix here is to copy and null-terminate in the NFSv4 case. The nfsd_symlink() interface here seems too fragile, though. It should really either do the copy itself every time or just require a null-terminated string. Reported-by:
Jeff Layton <jlayton@primarydata.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
