- 16 Jan, 2015 40 commits
-
-
Hans de Goede authored
commit d27eb793 upstream. Protocol v7 uses the middle / right button bits on clickpads to communicate "location" information of a 3th touch (and possible 4th) touch on clickpads. Specifically when 3 touches are down, if one of the 3 touches is in the left / right button area, this will get reported in the middle / right button bits and the touchpad will still send a TWO type packet rather then a MULTI type packet, so when this happens we must add the finger reported in the button area to the finger count. Likewise we must also add fingers reported this way to the finger count when we get MULTI packets. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Tested-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hans de Goede authored
commit 7091c443 upstream. The v7 proto differentiates between a primary touch (with high precision) and a secondary touch (with lower precision). Normally when 2 fingers are down and one is lifted the still present touch becomes the primary touch, but some traces have shown that this does not happen always. This commit deals with this by making alps_get_mt_count() not stop at the first empty mt slot, and if a touch is present in mt[1] and not mt[0] moving the data to mt[0] (for input_mt_assign_slots). BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338Signed-off-by:
-
Hans de Goede authored
commit 8b238115 upstream. NEW packets are send to indicate a discontinuity in the finger coordinate reporting. Specifically a finger may have moved from slot 0 to 1 or vice versa. INPUT_MT_TRACK takes care of this for us. NEW packets have 3 problems: 1) They do not contain middle / right button info (on non clickpads) this can be worked around by preserving the old button state 2) They do not contain an accurate fingercount, and they are typically send when the number of fingers changes. We cannot use the old finger count as that may mismatch with the amount of touch coordinates we've available in the NEW packet 3) Their x data for the second touch is inaccurate leading to a possible jump of the x coordinate by 16 units when the first non NEW packet comes in Since problems 2 & 3 cannot be worked around, just ignore them. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=86338Signed-off-by:
-
Rafael J. Wysocki authored
commit 1b1f3e16 upstream. If an ACPI device object whose _STA returns 0 (not present and not functional) has _PR0 or _PS0, its power_manageable flag will be set and acpi_bus_init_power() will return 0 for it. Consequently, if such a device object is passed to the ACPI device PM functions, they will attempt to carry out the requested operation on the device, although they should not do that for devices that are not present. To fix that problem make acpi_bus_init_power() return an error code for devices that are not present which will cause power_manageable to be cleared for them as appropriate in acpi_bus_get_power_flags(). However, the lists of power resources should not be freed for the device in that case, so modify acpi_bus_get_power_flags() to keep those lists even if acpi_bus_init_power() returns an error. Accordingly, when deciding whether or not the lists of power resources need to be freed, acpi_free_power_resources_lists() should check the power.flags.power_resources flag instead of flags.power_manageable, so make that change too. Furthermore, if acpi_bus_attach() sees that flags.initialized is unset for the given device, it should reset the power management settings of the device and re-initialize them from scratch instead of relying on the previous settings (the device may have appeared after being not present previously, for example), so make it use the 'valid' flag of the D0 power state as the initial value of flags.power_manageable for it and call acpi_bus_init_power() to discover its current power state. Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Aaron Lu authored
commit 7d0b9349 upstream. Several Samsung laptop models (SAMSUNG 870Z5E/880Z5E/680Z5E and SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V) do not have a working native backlight control interface so restore their acpi_videoX interface. Link: https://bugzilla.kernel.org/show_bug.cgi?id=84221 Link: https://bugzilla.kernel.org/show_bug.cgi?id=84651 For SAMSUNG 870Z5E/880Z5E/680Z5E: Reported-and-tested-by:
Brent Saner <brent.saner@gmail.com> Reported-by:
Vitaliy Filippov <vitalif@yourcmc.ru> Reported-by:
Laszlo KREKACS <laszlo.krekacs.list@gmail.com> For SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V: Reported-by:
Vladimir Perepechin <vovochka13@gmail.com> Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
-
J. Bruce Fields authored
commit 49a068f8 upstream. A struct xdr_stream at a page boundary might point to the end of one page or the beginning of the next, but xdr_truncate_encode isn't prepared to handle the former. This can cause corruption of NFSv4 READDIR replies in the case that a readdir entry that would have exceeded the client's dircount/maxcount limit would have ended exactly on a 4k page boundary. You're more likely to hit this case on large directories. Other xdr_truncate_encode callers are probably also affected. Reported-by:
Holger Hoffstätte <holger.hoffstaette@googlemail.com> Tested-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Pavel Machek authored
commit 4bf9636c upstream. Commit 9fc2105a ("ARM: 7830/1: delay: don't bother reporting bogomips in /proc/cpuinfo") breaks audio in python, and probably elsewhere, with message FATAL: cannot locate cpu MHz in /proc/cpuinfo I'm not the first one to hit it, see for example https://theredblacktree.wordpress.com/2014/08/10/fatal-cannot-locate-cpu-mhz-in-proccpuinfo/ https://devtalk.nvidia.com/default/topic/765800/workaround-for-fatal-cannot-locate-cpu-mhz-in-proc-cpuinf/?offset=1 Reading original changelog, I have to say "Stop breaking working setups. You know who you are!". Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Nishanth Menon authored
commit 9008d83f upstream. Commit 705814b5 ("ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5") Moved logic generic for OMAP5+ as part of the init routine by introducing omap4_pm_init. However, the patch left the powerdomain initial setup, an unused omap4430 es1.0 check and a spurious log "Power Management for TI OMAP4." in the original code. Remove the duplicate code which is already present in omap4_pm_init from omap4_init_static_deps. As part of this change, also move the u-boot version print out of the static dependency function to the omap4_pm_init function. Fixes: 705814b5 ("ARM: OMAP4+: PM: Consolidate OMAP4 PM code to re-use it for OMAP5") Signed-off-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Tomasz Figa authored
commit 5e794de5 upstream. The PWM block is required for system clock source so it must be always enabled. This patch fixes boot issues on SMDK6410 which did not have the node enabled explicitly for other purposes. Fixes: eeb93d02 ("clocksource: of: Respect device tree node status") Signed-off-by:
Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by:
Kukjin Kim <kgene.kim@samsung.com> Signed-off-by:
-
Lokesh Vutla authored
commit be668835 upstream. OMAP wdt driver supports only ti,omap3-wdt compatible. In DRA7 dt wdt compatible property is defined as ti,omap4-wdt by mistake instead of ti,omap3-wdt. Correcting the typo. Fixes: 6e58b8f1 ("ARM: dts: DRA7: Add the dts files for dra7 SoC and dra7-evm board") Signed-off-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
-
Viresh Kumar authored
commit 9d312cd1 upstream. CONFIG_GENERIC_CPUFREQ_CPU0 disappeared with commit bbcf0719 ("cpufreq: cpu0: rename driver and internals to 'cpufreq_dt'") and some defconfigs are still using it instead of the new one. Use the renamed CONFIG_CPUFREQ_DT generic driver. Reported-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Kevin Hilman <khilman@linaro.org> Signed-off-by:
-
Tomi Valkeinen authored
commit d73f825e upstream. The lcd0 node for am437x-sk-evm.dts contains bad LCD timings, and while they seem to work with a quick test, doing for example blank/unblank will give you a black display. This patch updates the timings to the 'typical' values from the LCD spec sheet. Also, the compatible string is completely bogus, as "osddisplays,osd057T0559-34ts" is _not_ a 480x272 panel. The panel on the board is a newhaven one. Update the compatible string to reflect this. Note that this hasn't caused any issues, as the "panel-dpi" matches the driver. Tested-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Felipe Balbi authored
commit 58230c2c upstream. Caused by a copy & paste error. Note that even with this bug AM437x SK display still works because GPIO mux mode is always enabled. It's still wrong to mux somebody else's pin. Luckily ball D25 (offset 0x238 - gpio5_8) on AM437x isn't used for anything. While at that, also replace a pullup with a pulldown as that gpio should be normally low, not high. Acked-by:
-
Andy Lutomirski authored
commit fd7de1e8 upstream. Locklessly doing is_idle_task(rq->curr) is only okay because of RCU protection. The older variant of the broken code checked rq->curr == rq->idle instead and therefore didn't need RCU. Fixes: f6be8af1 ("sched: Add new API wake_up_if_idle() to wake up the idle cpu") Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Reviewed-by:
Chuansheng Liu <chuansheng.liu@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/729365dddca178506dfd0a9451006344cd6808bc.1417277372.git.luto@amacapital.netSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Luca Abeni authored
commit 269ad801 upstream. The dl_runtime_exceeded() function is supposed to ckeck if a SCHED_DEADLINE task must be throttled, by checking if its current runtime is <= 0. However, it also checks if the scheduling deadline has been missed (the current time is larger than the current scheduling deadline), further decreasing the runtime if this happens. This "double accounting" is wrong: - In case of partitioned scheduling (or single CPU), this happens if task_tick_dl() has been called later than expected (due to small HZ values). In this case, the current runtime is also negative, and replenish_dl_entity() can take care of the deadline miss by recharging the current runtime to a value smaller than dl_runtime - In case of global scheduling on multiple CPUs, scheduling deadlines can be missed even if the task did not consume more runtime than expected, hence penalizing the task is wrong This patch fix this problem by throttling a SCHED_DEADLINE task only when its runtime becomes negative, and not modifying the runtime Signed-off-by:
Luca Abeni <luca.abeni@unitn.it> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by:
Juri Lelli <juri.lelli@gmail.com> Cc: Dario Faggioli <raistlin@linux.it> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: http://lkml.kernel.org/r/1418813432-20797-3-git-send-email-luca.abeni@unitn.itSigned-off-by:
-
Luca Abeni authored
commit 6a503c3b upstream. According to global EDF, tasks should be migrated between runqueues without checking if their scheduling deadlines and runtimes are valid. However, SCHED_DEADLINE currently performs such a check: a migration happens doing: deactivate_task(rq, next_task, 0); set_task_cpu(next_task, later_rq->cpu); activate_task(later_rq, next_task, 0); which ends up calling dequeue_task_dl(), setting the new CPU, and then calling enqueue_task_dl(). enqueue_task_dl() then calls enqueue_dl_entity(), which calls update_dl_entity(), which can modify scheduling deadline and runtime, breaking global EDF scheduling. As a result, some of the properties of global EDF are not respected: for example, a taskset {(30, 80), (40, 80), (120, 170)} scheduled on two cores can have unbounded response times for the third task even if 30/80+40/80+120/170 = 1.5809 < 2 This can be fixed by invoking update_dl_entity() only in case of wakeup, or if this is a new SCHED_DEADLINE task. Signed-off-by:
-
Johannes Berg authored
commit 7b990789 upstream. The change from \d+ to .+ inside __aligned() means that the following structure: struct test { u8 a __aligned(2); u8 b __aligned(2); }; essentially gets modified to struct test { u8 a; }; for purposes of kernel-doc, thus dropping a struct member, which in turns causes warnings and invalid kernel-doc generation. Fix this by replacing the catch-all (".") with anything that's not a semicolon ("[^;]"). Fixes: 9dc30918 ("scripts/kernel-doc: handle struct member __aligned without numbers") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Cc: Nishanth Menon <nm@ti.com> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Michal Marek <mmarek@suse.cz> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Ryusuke Konishi authored
commit 705304a8 upstream. Same story as in commit 41080b5a ("nfsd race fixes: ext2") (similar ext2 fix) except that nilfs2 needs to use insert_inode_locked4() instead of insert_inode_locked() and a bug of a check for dead inodes needs to be fixed. If nilfs_iget() is called from nfsd after nilfs_new_inode() calls insert_inode_locked4(), nilfs_iget() will wait for unlock_new_inode() at the end of nilfs_mkdir()/nilfs_create()/etc to unlock the inode. If nilfs_iget() is called before nilfs_new_inode() calls insert_inode_locked4(), it will create an in-core inode and read its data from the on-disk inode. But, nilfs_iget() will find i_nlink equals zero and fail at nilfs_read_inode_common(), which will lead it to call iget_failed() and cleanly fail. However, this sanity check doesn't work as expected for reused on-disk inodes because they leave a non-zero value in i_mode field and it hinders the test of i_nlink. This patch also fixes the issue by removing the test on i_mode that nilfs2 doesn't need. Signed-off-by:
Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Roger Quadros authored
commit 775a9134 upstream. 3430LDP has NAND flash with 32 bytes OOB size which is sufficient to hold BCH8 codes but the small page check introduced in commit b491da72 ("mtd: nand: omap: clean-up ecc layout for BCH ecc schemes") considers anything below 64 bytes unsuitable for BCH4/8/16. There is another bug in that code where it doesn't skip the check for OMAP_ECC_HAM1_CODE_SW. Get rid of that small page check code as it is insufficient and redundant because we are checking for OOB available bytes vs ecc layout before calling nand_scan_tail(). Fixes: b491da72 ("mtd: nand: omap: clean-up ecc layout for BCH ecc schemes") Reported-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Alison Chaiken authored
commit 834b6865 upstream. As stated in a5b7616c, "mtd: m25p80,spi-nor: Fix module aliases for m25p80", m25p_ids[] in m25p80.c needs to be kept in sync with spi_nor_ids[] in spi-nor.c. The change here corrects a misalignment. (We were missing m25px80 and we had a duplicate w25q128.) Signed-off-by:
Alison Chaiken <alison_chaiken@mentor.com> Signed-off-by:
-
Brian Norris authored
commit 68f29815 upstream. The torture test should quit once it actually induces an error in the flash. This step was accidentally removed during refactoring. Without this fix, the torturetest just continues infinitely, or until the maximum cycle count is reached. e.g.: ... [ 7619.218171] mtd_test: error -5 while erasing EB 100 [ 7619.297981] mtd_test: error -5 while erasing EB 100 [ 7619.377953] mtd_test: error -5 while erasing EB 100 [ 7619.457998] mtd_test: error -5 while erasing EB 100 [ 7619.537990] mtd_test: error -5 while erasing EB 100 ... Fixes: 6cf78358 ("mtd: mtd_torturetest: use mtd_test helpers") Signed-off-by:
-
Dan Carpenter authored
commit 021b77be upstream. Probably this code was syncing a lot more often then intended because the do_sync variable wasn't set to zero. Fixes: c62988ec ('ceph: avoid meaningless calling ceph_caps_revoking if sync_mode == WB_SYNC_ALL.') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Ilya Dryomov <idryomov@redhat.com> Signed-off-by:
-
Aaron Lu authored
commit b4df4636 upstream. If the firmware has declared more than 8 video output devices, and the one that control the internal panel's backlight is listed after the first 8 output devices, the _DOD will not include it due to the current i915 operation region implementation. As a result, we will not create a backlight device for it while we should. Solve this problem by special case the firmware that has 8+ output devices in that if we see such a firmware, we do not test if the device is in _DOD list. The creation of the backlight device will also enable the firmware to emit events on backlight hotkey press when the acpi_osi= cmdline option is specified on those affected ASUS laptops. Link: https://bugzilla.kernel.org/show_bug.cgi?id=70241Reported-and-tested-by:
Oleksij Rempel <linux@rempel-privat.de> Reported-and-tested-by:
Dmitry Tunin <hanipouspilot@gmail.com> Reported-and-tested-by:
Jimbo <jaime.91@hotmail.es> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Jeff Layton authored
commit 94ae1db2 upstream. Currently, nfs4_set_delegation takes a reference to an existing delegation and then checks to see if there is a conflict. If there is one, then it doesn't release that reference. Change the code to take the reference after the check and only if there is no conflict. Signed-off-by:
Jeff Layton <jlayton@primarydata.com> Signed-off-by:
-
Benjamin Coddington authored
commit bf7491f1 upstream. Fix a bug where nfsd4_encode_components_esc() incorrectly calculates the length of server array in fs_location4--note that it is a count of the number of array elements, not a length in bytes. Signed-off-by:
Benjamin Coddington <bcodding@redhat.com> Fixes: 082d4bd7 (nfsd4: "backfill" using write_bytes_to_xdr_buf) Signed-off-by:
-
Benjamin Coddington authored
commit 5a64e569 upstream. Fix a bug where nfsd4_encode_components_esc() includes the esc_end char as an additional string encoding. Signed-off-by:
-
Rasmus Villemoes authored
commit ef17af2a upstream. Bugs similar to the one in acbbe6fb (kcmp: fix standard comparison bug) are in rich supply. In this variant, the problem is that struct xdr_netobj::len has type unsigned int, so the expression o1->len - o2->len _also_ has type unsigned int; it has completely well-defined semantics, and the result is some non-negative integer, which is always representable in a long long. But this means that if the conditional triggers, we are guaranteed to return a positive value from compare_blob. In this case it could be fixed by - res = o1->len - o2->len; + res = (long long)o1->len - (long long)o2->len; but I'd rather eliminate the usually broken 'return a - b;' idiom. Reviewed-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by:
-
Vitaly Kuznetsov authored
commit 31d4ea1a upstream. An attempt to fix fcopy on i586 (bc5a5b02 Drivers: hv: util: Properly pack the data for file copy functionality) led to a regression on x86_64 (and actually didn't fix i586 breakage). Fcopy messages from Hyper-V host come in the following format: struct do_fcopy_hdr | 36 bytes 0000 | 4 bytes offset | 8 bytes size | 4 bytes data | 6144 bytes On x86_64 struct hv_do_fcopy matched this format without ' __attribute__((packed))' and on i586 adding ' __attribute__((packed))' to it doesn't change anything. Keep the structure packed and add padding to match re reality. Tested both i586 and x86_64 on Hyper-V Server 2012 R2. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Vitaly Kuznetsov authored
commit 04a258c1 upstream. When build with Debug the following crash is sometimes observed: Call Trace: [<ffffffff812b9600>] string+0x40/0x100 [<ffffffff812bb038>] vsnprintf+0x218/0x5e0 [<ffffffff810baf7d>] ? trace_hardirqs_off+0xd/0x10 [<ffffffff812bb4c1>] vscnprintf+0x11/0x30 [<ffffffff8107a2f0>] vprintk+0xd0/0x5c0 [<ffffffffa0051ea0>] ? vmbus_process_rescind_offer+0x0/0x110 [hv_vmbus] [<ffffffff8155c71c>] printk+0x41/0x45 [<ffffffffa004ebac>] vmbus_device_unregister+0x2c/0x40 [hv_vmbus] [<ffffffffa0051ecb>] vmbus_process_rescind_offer+0x2b/0x110 [hv_vmbus] ... This happens due to the following race: between 'if (channel->device_obj)' check in vmbus_process_rescind_offer() and pr_debug() in vmbus_device_unregister() the device can disappear. Fix the issue by taking an additional reference to the device before proceeding to vmbus_device_unregister(). Signed-off-by:
-
Christian Riesch authored
commit 8bfbe2de upstream. Commit 19e2ad6a ("n_tty: Remove overflow tests from receive_buf() path") moved the increment of read_head into the arguments list of read_buf_addr(). Function calls represent a sequence point in C. Therefore read_head is incremented before the character c is placed in the buffer. Since the circular read buffer is a lock-less design since commit 6d76bd26 ("n_tty: Make N_TTY ldisc receive path lockless"), this creates a race condition that leads to communication errors. This patch modifies the code to increment read_head _after_ the data is placed in the buffer and thus fixes the race for non-SMP machines. To fix the problem for SMP machines, memory barriers must be added in a separate patch. Signed-off-by:
Christian Riesch <christian.riesch@omicron.at> Signed-off-by:
-
Jiri Slaby authored
commit fa0c5540 upstream. When resirefs is trying to mount a partition, it creates a commit workqueue (sbi->commit_wq). But when mount fails later, the workqueue is not freed. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Reported-by: auxsvr@gmail.com Reported-by:
Benoît Monin <benoit.monin@gmx.fr> Cc: Jan Kara <jack@suse.cz> Cc: reiserfs-devel@vger.kernel.org Fixes: 797d9016Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Max Filippov authored
commit ff009ab6 upstream. Replace PAGE_KERNEL with PAGE_KERNEL_EXEC to allow copy_to_user_page invalidate icache for pages mapped with kmap. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> Signed-off-by:
-
Robert Baldyga authored
commit 1ff383a4 upstream. This patch adds waiting until transmit buffer and shifter will be empty before clock disabling. Without this fix it's possible to have clock disabled while data was not transmited yet, which causes unproper state of TX line and problems in following data transfers. Signed-off-by:
Robert Baldyga <r.baldyga@samsung.com> Signed-off-by:
-
Axel Lin authored
commit 6b1f40cf upstream. The mcb_device_id table is supposed to be zero-terminated. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit aee4e5f3 upstream. When recording the state of a task for the sched_switch tracepoint a check of task_preempt_count() is performed to see if PREEMPT_ACTIVE is set. This is because, technically, a task being preempted is really in the TASK_RUNNING state, and that is what should be recorded when tracing a sched_switch, even if the task put itself into another state (it hasn't scheduled out in that state yet). But with the change to use per_cpu preempt counts, the task_thread_info(p)->preempt_count is no longer used, and instead task_preempt_count(p) is used. The problem is that this does not use the current preempt count but a stale one from a previous sched_switch. The task_preempt_count(p) uses saved_preempt_count and not preempt_count(). But for tracing sched_switch, if p is current, we really want preempt_count(). I hit this bug when I was tracing sleep and the call from do_nanosleep() scheduled out in the "RUNNING" state. sleep-4290 [000] 537272.259992: sched_switch: sleep:4290 [120] R ==> swapper/0:0 [120] sleep-4290 [000] 537272.260015: kernel_stack: <stack trace> => __schedule (ffffffff8150864a) => schedule (ffffffff815089f8) => do_nanosleep (ffffffff8150b76c) => hrtimer_nanosleep (ffffffff8108d66b) => SyS_nanosleep (ffffffff8108d750) => return_to_handler (ffffffff8150e8e5) => tracesys_phase2 (ffffffff8150c844) After a bit of hair pulling, I found that the state was really TASK_INTERRUPTIBLE, but the saved_preempt_count had an old PREEMPT_ACTIVE set and caused the sched_switch tracepoint to show it as RUNNING. Link: http://lkml.kernel.org/r/20141210174428.3cb7542a@gandalf.local.homeAcked-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Tejun Heo authored
commit 9c6ac78e upstream. After invoking ->dirty_inode(), __mark_inode_dirty() does smp_mb() and tests inode->i_state locklessly to see whether it already has all the necessary I_DIRTY bits set. The comment above the barrier doesn't contain any useful information - memory barriers can't ensure "changes are seen by all cpus" by itself. And it sure enough was broken. Please consider the following scenario. CPU 0 CPU 1 ------------------------------------------------------------------------------- enters __writeback_single_inode() grabs inode->i_lock tests PAGECACHE_TAG_DIRTY which is clear enters __set_page_dirty() grabs mapping->tree_lock sets PAGECACHE_TAG_DIRTY releases mapping->tree_lock leaves __set_page_dirty() enters __mark_inode_dirty() smp_mb() sees I_DIRTY_PAGES set leaves __mark_inode_dirty() clears I_DIRTY_PAGES releases inode->i_lock Now @inode has dirty pages w/ I_DIRTY_PAGES clear. This doesn't seem to lead to an immediately critical problem because requeue_inode() later checks PAGECACHE_TAG_DIRTY instead of I_DIRTY_PAGES when deciding whether the inode needs to be requeued for IO and there are enough unintentional memory barriers inbetween, so while the inode ends up with inconsistent I_DIRTY_PAGES flag, it doesn't fall off the IO list. The lack of explicit barrier may also theoretically affect the other I_DIRTY bits which deal with metadata dirtiness. There is no guarantee that a strong enough barrier exists between I_DIRTY_[DATA]SYNC clearing and write_inode() writing out the dirtied inode. Filesystem inode writeout path likely has enough stuff which can behave as full barrier but it's theoretically possible that the writeout may not see all the updates from ->dirty_inode(). Fix it by adding an explicit smp_mb() after I_DIRTY clearing. Note that I_DIRTY_PAGES needs a special treatment as it always needs to be cleared to be interlocked with the lockless test on __mark_inode_dirty() side. It's cleared unconditionally and reinstated after smp_mb() if the mapping still has dirty pages. Also add comments explaining how and why the barriers are paired. Lightly tested. Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Mikulas Patocka <mpatocka@redhat.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Al Viro <viro@zeniv.linux.org.uk> Reviewed-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Philipp Reisner authored
commit 9581f97a upstream. A connection timeout affects all volumes of a resource! Under the following conditions: A resource with multiple volumes AND ko-count >=1 AND a write request triggers the timeout (ko-count * timeout) DRBD's internal state gets confused. That in turn may lead to very miss leading follow up failures. E.g. "BUG: scheduling while atomic" Signed-off-by:
Philipp Reisner <philipp.reisner@linbit.com> Signed-off-by:
Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by:
-
Lars Ellenberg authored
commit 3b9d35d7 upstream. This was not noticed for many years. Affects operation if md raid is used a backing device for DRBD. Signed-off-by:
-
Oliver Neukum authored
commit d908f847 upstream. If probe() fails not only the attributes need to be removed but also the memory freed. Reported-by:
Ahmed Tamrawi <ahmedtamrawi@gmail.com> Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
-
Jens Axboe authored
commit 5fabcb4c upstream. We can get here from blkdev_ioctl() -> blkpg_ioctl() -> add_partition() with a user passed in partno value. If we pass in 0x7fffffff, the new target in disk_expand_part_tbl() overflows the 'int' and we access beyond the end of ptbl->part[] and even write to it when we do the rcu_assign_pointer() to assign the new partition. Reported-by:
David Ramos <daramos@stanford.edu> Signed-off-by:
-
