summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* UBI: Fix trivial typo in __schedule_ubi_workRichard Weinberger2014-09-301-1/+1
| | | | | | | s/of/if/ Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: wl: Rename cancel flag to shutdownRichard Weinberger2014-09-262-15/+18
| | | | | | | | | | | | It confused me more than once that the cancel flag of the work function does not indicate the cancellation of a single work. In fact it indicates the WL sub-system shutdown and therefore worker functions have to free their wl_entries too. That's why you cannot cancel a single work, you can only shutdown all works. Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: ubi_eba_read_leb: Remove in vain variable assignmentRichard Weinberger2014-09-261-3/+2
| | | | | | | | | | There is no need to set err, it will be overwritten in any case later at: if (scrub) err = ubi_wl_scrub_peb(ubi, pnum); Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBIFS: Align the dump messages of SB_NODEhujianyang2014-09-261-2/+2
| | | | | | | | I found the dump messages of UBIFS_SB_NODE is not aligned. This patch remove the extra space from the line which is retracted. Signed-off-by: hujianyang <hujianyang@huawei.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: Fix livelock in produce_free_peb()Richard Weinberger2014-09-241-1/+1
| | | | | | | | | | | | The while loop in produce_free_peb() assumes that each work will produce a free PEB. This is not true. If ubi->works_count is 1 and the only scheduled work is the wear_leveling_worker() produce_free_peb() can loop forever in case nobody schedules an erase work. Fix this issue by checking in the while loop whether work is scheduled. Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: return on error in rename_volumes()Dan Carpenter2014-09-191-1/+1
| | | | | | | | | | I noticed this during a code review. We are checking that the strlen() of ->name is not less than the ->name_len which the user gave us. I believe this bug is harmless but clearly we meant to return here instead of setting an error code and then not using it. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: Improve comment on work_semRichard Weinberger2014-09-191-1/+2
| | | | | | | | Make clear what work_sem really does. Suggested-by: Artem Bityutskiy <dedekind1@gmail.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBIFS: Remove bogus assertRichard Weinberger2014-09-191-4/+3
| | | | | | | | | | This assertion was only correct before UBIFS had xattr support. Now with xattr support also a directory node can carry data and can act as host node. Suggested-by: Artem Bityutskiy <dedekind1@gmail.com> Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: Dispatch update notification if the volume is updatedEzequiel Garcia2014-09-161-1/+3
| | | | | | | | | | | | | | The UBI_IOCVOLUP ioctl is used to start an update and also to truncate a volume. In the first case, a "volume updated" notification is dispatched when the update is done. This commit adds the "volume updated" notification to be also sent when the volume is truncated. This is required for UBI block and gluebi to get notified about the new volume size. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: stable@vger.kernel.org # v3.15+
* UBI: block: Add support for the UBI_VOLUME_UPDATED notificationEzequiel Garcia2014-09-161-2/+14
| | | | | | | | | | Static volumes can change its 'used_bytes' when they get updated, and so the block interface must listen to the UBI_VOLUME_UPDATED notification to resize the block device accordingly. Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: stable@vger.kernel.org # v3.15+
* UBI: block: Fix block device size settingEzequiel Garcia2014-09-161-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are currently taking the block device size from the ubi_volume_info.size field. However, this is not the amount of data in the volume, but the number of reserved physical eraseblocks, and hence leads to an incorrect representation of the volume. In particular, this produces I/O errors on static volumes as the block interface may attempt to read unmapped PEBs: $ cat /dev/ubiblock0_0 > /dev/null UBI error: ubiblock_read_to_buf: ubiblock0_0 ubi_read error -22 end_request: I/O error, dev ubiblock0_0, sector 9536 Buffer I/O error on device ubiblock0_0, logical block 2384 [snip] Fix this by using the ubi_volume_info.used_bytes field which is set to the actual number of data bytes for both static and dynamic volumes. While here, improve the error message to be less stupid and more useful: UBI error: ubiblock_read_to_buf: ubiblock0_1 ubi_read error -9 on LEB=0, off=15872, len=512 It's worth noticing that the 512-byte sector representation of the volume is only correct if the volume size is multiple of 512-bytes. This is true for virtually any NAND device, given eraseblocks and pages are 512-byte multiple and hence so is the LEB size. Artem: tweak the error message and make it look more like other UBI error messages. Fixes: 9d54c8a33eec ("UBI: R/O block driver on top of UBI volumes") Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com> Cc: stable@vger.kernel.org # v3.15+
* UBI: block: fix dereference on uninitialized devColin Ian King2014-09-161-5/+6
| | | | | | | | | | | | | | | | commit 4df38926f337 ("UBI: block: Avoid disk size integer overflow") introduced a dereference on dev (which is not initialized at that point) when printing a warning message. Re-order disk_capacity check after the dev is found. Found by cppcheck: [drivers/mtd/ubi/block.c:509]: (error) Uninitialized variable: dev Artem: tweak the error message a bit Signed-off-by: Colin Ian King <colin.king@canonical.com> Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBI: add missing kmem_cache_free() in process_pool_aeb error pathRichard Genoud2014-09-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | I ran into this error after a ubiupdatevol, because I forgot to backport e9110361a9a4 UBI: fix the volumes tree sorting criteria. UBI error: process_pool_aeb: orphaned volume in fastmap pool UBI error: ubi_scan_fastmap: Attach by fastmap failed, doing a full scan! kmem_cache_destroy ubi_ainf_peb_slab: Slab cache still has objects CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.18-00053-gf05cac8dbf85 #1 [<c000d298>] (unwind_backtrace) from [<c000baa8>] (show_stack+0x10/0x14) [<c000baa8>] (show_stack) from [<c01b7a68>] (destroy_ai+0x230/0x244) [<c01b7a68>] (destroy_ai) from [<c01b8fd4>] (ubi_attach+0x98/0x1ec) [<c01b8fd4>] (ubi_attach) from [<c01ade90>] (ubi_attach_mtd_dev+0x2b8/0x868) [<c01ade90>] (ubi_attach_mtd_dev) from [<c038b510>] (ubi_init+0x1dc/0x2ac) [<c038b510>] (ubi_init) from [<c0008860>] (do_one_initcall+0x94/0x140) [<c0008860>] (do_one_initcall) from [<c037aadc>] (kernel_init_freeable+0xe8/0x1b0) [<c037aadc>] (kernel_init_freeable) from [<c02730ac>] (kernel_init+0x8/0xe4) [<c02730ac>] (kernel_init) from [<c00093f0>] (ret_from_fork+0x14/0x24) UBI: scanning is finished Freeing the cache in the error path fixes the Slab error. Tested on at91sam9g35 (3.14.18+fastmap backports) Signed-off-by: Richard Genoud <richard.genoud@gmail.com> Cc: stable <stable@vger.kernel.org> # 3.10+
* UBIFS: fix free log space calculationArtem Bityutskiy2014-09-081-2/+6
| | | | | | | | | | | | | | | | | | | | | Hu (hujianyang <hujianyang@huawei.com>) discovered an issue in the 'empty_log_bytes()' function, which calculates how many bytes are left in the log: " If 'c->lhead_lnum + 1 == c->ltail_lnum' and 'c->lhead_offs == c->leb_size', 'h' would equalent to 't' and 'empty_log_bytes()' would return 'c->log_bytes' instead of 0. " At this point it is not clear what would be the consequences of this, and whether this may lead to any problems, but this patch addresses the issue just in case. Cc: stable@vger.kernel.org Tested-by: hujianyang <hujianyang@huawei.com> Reported-by: hujianyang <hujianyang@huawei.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* UBIFS: fix a race conditionArtem Bityutskiy2014-09-082-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Hu (hujianyang@huawei.com) discovered a race condition which may lead to a situation when UBIFS is unable to mount the file-system after an unclean reboot. The problem is theoretical, though. In UBIFS, we have the log, which basically a set of LEBs in a certain area. The log has the tail and the head. Every time user writes data to the file-system, the UBIFS journal grows, and the log grows as well, because we append new reference nodes to the head of the log. So the head moves forward all the time, while the log tail stays at the same position. At any time, the UBIFS master node points to the tail of the log. When we mount the file-system, we scan the log, and we always start from its tail, because this is where the master node points to. The only occasion when the tail of the log changes is the commit operation. The commit operation has 2 phases - "commit start" and "commit end". The former is relatively short, and does not involve much I/O. During this phase we mostly just build various in-memory lists of the things which have to be written to the flash media during "commit end" phase. During the commit start phase, what we do is we "clean" the log. Indeed, the commit operation will index all the data in the journal, so the entire journal "disappears", and therefore the data in the log become unneeded. So we just move the head of the log to the next LEB, and write the CS node there. This LEB will be the tail of the new log when the commit operation finishes. When the "commit start" phase finishes, users may write more data to the file-system, in parallel with the ongoing "commit end" operation. At this point the log tail was not changed yet, it is the same as it had been before we started the commit. The log head keeps moving forward, though. The commit operation now needs to write the new master node, and the new master node should point to the new log tail. After this the LEBs between the old log tail and the new log tail can be unmapped and re-used again. And here is the possible problem. We do 2 operations: (a) We first update the log tail position in memory (see 'ubifs_log_end_commit()'). (b) And then we write the master node (see the big lock of code in 'do_commit()'). But nothing prevents the log head from moving forward between (a) and (b), and the log head may "wrap" now to the old log tail. And when the "wrap" happens, the contends of the log tail gets erased. Now a power cut happens and we are in trouble. We end up with the old master node pointing to the old tail, which was erased. And replay fails because it expects the master node to point to the correct log tail at all times. This patch merges the abovementioned (a) and (b) operations by moving the master node change code to the 'ubifs_log_end_commit()' function, so that it runs with the log mutex locked, which will prevent the log from being changed benween operations (a) and (b). Cc: stable@vger.kernel.org # 07e19df UBIFS: remove mst_mutex Cc: stable@vger.kernel.org Reported-by: hujianyang <hujianyang@huawei.com> Tested-by: hujianyang <hujianyang@huawei.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
* Linux 3.17-rc4v3.17-rc4Linus Torvalds2014-09-071-1/+1
|
* Documentation: new page link in SubmittingPatchesSudip Mukherjee2014-09-071-0/+1
| | | | | | | | new link for - How to piss off a Linux kernel subsystem maintainer Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Documentation: NFS/RDMA: Document separate Kconfig symbolsPaul Bolle2014-09-071-7/+9
| | | | | | | | | | | | | | The NFS/RDMA Kconfig symbol was split into separate options for client and server in commit 2e8c12e1b765 ("xprtrdma: add separate Kconfig options for NFSoRDMA client and server support"). Update the documentation to reflect this split. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: "J. Bruce Fields" <bfields@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Documentation: misc-devices: Rename freefall.c from hpfall.c in lis2lv02dMasanari Iida2014-09-071-1/+1
| | | | | | | | | hpfall.c was renamed to freefall.c in 3.16, but this file still refer to hpfall.c instead of freefall.c Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Documentation: i2c: rename variable "register" to "reg"Jose Manuel Alarcon Roldan2014-09-071-5/+5
| | | | | | | | | | | | | | | | | | | | | | The example code provided with the i2c device interface documentation won't compile since it uses the reserved word "register" to name a variable. The compiler fails with this error message: error: expected identifier or '(' before '=' token __u8 register = 0x20; /* Device register to access */ ^ Rename the variable "register" to simply "reg" in the example code. Another couple of typos has been fixed as well. [Change "! =" to "!=".] Signed-off-by: Jose Alarcon Roldan <jose.alarcon.roldan@gmail.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Documentation: seq_file: Document seq_open_private(), seq_release_private()Rob Jones2014-09-071-0/+33
| | | | | | | | | | | | | Despite the fact that these functions have been around for years, they are little used (only 15 uses in 13 files at the preseht time) even though many other files use work-arounds to achieve the same result. By documenting them, hopefully they will become more widely used. Signed-off-by: Rob Jones <rob.jones@codethink.co.uk> Acked-by: Steven Whitehouse <swhiteho@redhat.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge tag 'pm+acpi-3.17-rc4' of ↵Linus Torvalds2014-09-0712-34/+122
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and power management fixes from Rafael Wysocki: "These are regression fixes (ACPI sysfs, ACPI video, suspend test), ACPI cpuidle deadlock fix, missing runtime validation of ACPI _DSD output, a fix and a new CPU ID for the RAPL driver, new blacklist entry for the ACPI EC driver and a couple of trivial cleanups (intel_pstate and generic PM domains). Specifics: - Fix for recently broken test_suspend= command line argument (Rafael Wysocki). - Fixes for regressions related to the ACPI video driver caused by switching the default to native backlight handling in 3.16 from Hans de Goede. - Fix for a sysfs attribute of ACPI device objects that returns stale values sometimes due to the fact that they are cached instead of executing the appropriate method (_SUN) every time (broken in 3.14). From Yasuaki Ishimatsu. - Fix for a deadlock between cpuidle_lock and cpu_hotplug.lock in the ACPI processor driver from Jiri Kosina. - Runtime output validation for the ACPI _DSD device configuration object missing from the support for it that has been introduced recently. From Mika Westerberg. - Fix for an unuseful and misleading RAPL (Running Average Power Limit) domain detection message in the RAPL driver from Jacob Pan. - New Intel Haswell CPU ID for the RAPL driver from Jason Baron. - New Clevo W350etq blacklist entry for the ACPI EC driver from Lan Tianyu. - Cleanup for the intel_pstate driver and the core generic PM domains code from Gabriele Mazzotta and Geert Uytterhoeven" * tag 'pm+acpi-3.17-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ACPI / cpuidle: fix deadlock between cpuidle_lock and cpu_hotplug.lock ACPI / scan: not cache _SUN value in struct acpi_device_pnp cpufreq: intel_pstate: Remove unneeded variable powercap / RAPL: change domain detection message powercap / RAPL: add support for CPU model 0x3f PM / domains: Make generic_pm_domain.name const PM / sleep: Fix test_suspend= command line option ACPI / EC: Add msi quirk for Clevo W350etq ACPI / video: Disable native_backlight on HP ENVY 15 Notebook PC ACPI / video: Add a disable_native_backlight quirk ACPI / video: Fix use_native_backlight selection logic ACPICA: ACPI 5.1: Add support for runtime validation of _DSD package.
| *-----. Merge branches 'pm-sleep', 'powercap', 'pm-domains' and 'pm-cpufreq'Rafael J. Wysocki2014-09-056-22/+26
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * pm-sleep: PM / sleep: Fix test_suspend= command line option * powercap: powercap / RAPL: change domain detection message powercap / RAPL: add support for CPU model 0x3f * pm-domains: PM / domains: Make generic_pm_domain.name const * pm-cpufreq: cpufreq: intel_pstate: Remove unneeded variable
| | | | | * cpufreq: intel_pstate: Remove unneeded variableGabriele Mazzotta2014-09-031-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It should have been removed with commit d1b6848590af ("cpufreq / intel_pstate: Optimize intel_pstate_set_policy") Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | | | * | PM / domains: Make generic_pm_domain.name constGeert Uytterhoeven2014-09-031-1/+1
| | | | |/ | | | | | | | | | | | | | | | | | | | | Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | | * | powercap / RAPL: change domain detection messageJacob Pan2014-09-031-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many CPUs do not support complete set of RAPL domains, as a result this detection failed message is very misleading and can be annoying. [ 5.082632] intel_rapl: RAPL domain core detection failed [ 5.088370] intel_rapl: RAPL domain uncore detection failed So lower the warning message to info and only print out the RAPL domains that are supported. Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | | * | powercap / RAPL: add support for CPU model 0x3fJason Baron2014-09-031-0/+1
| | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've confirmed that monitoring the package power usage as well as setting power limits appear to be working as expected. Supports the package and dram domains. Tested aginst cpu: Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz Signed-off-by: Jason Baron <jbaron@akamai.com> Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * | PM / sleep: Fix test_suspend= command line optionRafael J. Wysocki2014-09-033-13/+21
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After commit d431cbc53cb7 (PM / sleep: Simplify sleep states sysfs interface code) the pm_states[] array is not populated initially, which causes setup_test_suspend() to always fail and the suspend testing during boot doesn't work any more. Fix the problem by using pm_labels[] instead of pm_states[] in setup_test_suspend() and storing a pointer to the label of the sleep state to test rather than the number representing it, because the connection between the state numbers and labels is only established by suspend_set_ops(). Fixes: d431cbc53cb7 (PM / sleep: Simplify sleep states sysfs interface code) Reported-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | |
| | \
| *-. \ Merge branches 'acpi-video' and 'acpi-ec'Rafael J. Wysocki2014-09-052-2/+47
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpi-video: ACPI / video: Disable native_backlight on HP ENVY 15 Notebook PC ACPI / video: Add a disable_native_backlight quirk ACPI / video: Fix use_native_backlight selection logic * acpi-ec: ACPI / EC: Add msi quirk for Clevo W350etq
| | | * | ACPI / EC: Add msi quirk for Clevo W350etqLan Tianyu2014-09-021-0/+4
| | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clevo W350etq's EC will not produce GPE interrupt some time after booting. The ACPI notify event won't trigger when the issue takes place. After debugging, adding msi quirk for the machine can fix the issue. This patch is to add msi quirk for the machine. Link: https://bugzilla.kernel.org/show_bug.cgi?id=77431 Reported-and-tested-by: qbanin@gmail.com Signed-off-by: Lan Tianyu <tianyu.lan@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * | ACPI / video: Disable native_backlight on HP ENVY 15 Notebook PCHans de Goede2014-09-021-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Link: https://bugs.freedesktop.org/show_bug.cgi?id=81515 Reported-and-tested-by: Hohahiu <rakothedin@gmail.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * | ACPI / video: Add a disable_native_backlight quirkHans de Goede2014-09-021-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some laptops have a working acpi_video backlight control, and using native backlight on these causes a regression where backlight control does not work when userspace is not handling brightness key events. Disable native_backlight on these to fix this. Link: https://bugzilla.kernel.org/show_bug.cgi?id=81691 Reported-and-tested-by: Andre Müller <andre.muller@web.de> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * | ACPI / video: Fix use_native_backlight selection logicHans de Goede2014-09-021-2/+2
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 751109aad583 ("ACPI / video: Change the default for video.use_native_backlight to 1") has changed the default for use_native_backlight from 0 to 1, but instead of changing use_native_backlight_dmi to true, and leaving use_native_backlight_param at -1, it has changed use_native_backlight_param to 1. This causes acpi_video_use_native_backlight() to always think that a value was specified through the param, making it impossible to add a dmi based quirk to force 0 now that the default is 1. This fixes this by restoring the use_native_backlight_param default to -1, and instead setting the use_native_backlight_dmi default to true. Fixes: 751109aad583 (ACPI / video: Change the default for video.use_native_backlight to 1) Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | |
| | \
| *-. \ Merge branches 'acpica', 'acpi-processor' and 'acpi-scan'Rafael J. Wysocki2014-09-053-10/+10
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * acpica: ACPICA: ACPI 5.1: Add support for runtime validation of _DSD package. * acpi-processor: ACPI / cpuidle: fix deadlock between cpuidle_lock and cpu_hotplug.lock * acpi-scan: ACPI / scan: not cache _SUN value in struct acpi_device_pnp
| | | * | ACPI / scan: not cache _SUN value in struct acpi_device_pnpYasuaki Ishimatsu2014-09-032-8/+8
| | | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The _SUN device indentification object is not guaranteed to return the same value every time it is executed, so we should not cache its return value, but rather execute it every time as needed. If it is cached, an incorrect stale value may be used in some situations. This issue was exposed by commit 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace). Fix it by avoiding to cache the return value of _SUN. Fixes: 202317a573b2 (ACPI / scan: Add acpi_device objects for all device nodes in the namespace) Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| | * | ACPI / cpuidle: fix deadlock between cpuidle_lock and cpu_hotplug.lockJiri Kosina2014-09-031-2/+2
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is a following AB-BA dependency between cpu_hotplug.lock and cpuidle_lock: 1) cpu_hotplug.lock -> cpuidle_lock enable_nonboot_cpus() _cpu_up() cpu_hotplug_begin() LOCK(cpu_hotplug.lock) cpu_notify() ... acpi_processor_hotplug() cpuidle_pause_and_lock() LOCK(cpuidle_lock) 2) cpuidle_lock -> cpu_hotplug.lock acpi_os_execute_deferred() workqueue ... acpi_processor_cst_has_changed() cpuidle_pause_and_lock() LOCK(cpuidle_lock) get_online_cpus() LOCK(cpu_hotplug.lock) Fix this by reversing the order acpi_processor_cst_has_changed() does thigs -- let it first execute the protection against CPU hotplug by calling get_online_cpus() and obtain the cpuidle lock only after that (and perform the symmentric change when allowing CPUs hotplug again and dropping cpuidle lock). Spotted by lockdep. Signed-off-by: Jiri Kosina <jkosina@suse.cz> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
| * | ACPICA: ACPI 5.1: Add support for runtime validation of _DSD package.Mika Westerberg2014-09-021-0/+39
| |/ | | | | | | | | | | | | | | | | | | | | Adds ACPICA kernel runtime support to validate contents/format of the _DSD package, similar to the iASL support. Ported by Mika Westerberg. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge branch 'for-linus' of ↵Linus Torvalds2014-09-074-14/+18
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull filesystem fixes from Al Viro: "Several bugfixes (all of them -stable fodder). Alexey's one deals with double mutex_lock() in UFS (apparently, nobody has tried to test "ufs: sb mutex merge + mutex_destroy" on something like file creation/removal on ufs). Mine deal with two kinds of umount bugs, in umount propagation and in handling of automounted submounts, both resulting in bogus transient EBUSY from umount" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: ufs: fix deadlocks introduced by sb mutex merge fix EBUSY on umount() from MNT_SHRINKABLE get rid of propagate_umount() mistakenly treating slaves as busy.
| * | ufs: fix deadlocks introduced by sb mutex mergeAlexey Khoroshilov2014-09-072-13/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 0244756edc4b ("ufs: sb mutex merge + mutex_destroy") introduces deadlocks in ufs_new_inode() and ufs_free_inode(). Most callers of that functions acqure the mutex by themselves and ufs_{new,free}_inode() do that via lock_ufs(), i.e we have an unavoidable double lock. The patch proposes to resolve the issue by making sure that ufs_{new,free}_inode() are not called with the mutex held. Found by Linux Driver Verification project (linuxtesting.org). Cc: stable@vger.kernel.org # 3.16 Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| * | fix EBUSY on umount() from MNT_SHRINKABLEAl Viro2014-08-301-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need the parents of victims alive until namespace_unlock() gets to dput() of the (ex-)mountpoints. However, that screws up the "is it busy" checks in case when we have shrinkable mounts that need to be killed. Solution: go ahead and decrement refcounts of parents right in umount_tree(), increment them again just before dropping rwsem in namespace_unlock() (and let the loop in the end of namespace_unlock() finally drop those references for good, as we do now). Parents can't get freed until we drop rwsem - at least one reference is kept until then, both in case when parent is among the victims and when it is not. So they'll still be around when we get to namespace_unlock(). Cc: stable@vger.kernel.org # 3.12+ Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
| * | get rid of propagate_umount() mistakenly treating slaves as busy.Al Viro2014-08-302-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The check in __propagate_umount() ("has somebody explicitly mounted something on that slave?") is done *before* taking the already doomed victims out of the child lists. Cc: stable@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
* | | Merge branch 'core-urgent-for-linus' of ↵Linus Torvalds2014-09-072-12/+12
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull RCU fix from Ingo Molnar: "A boot hang fix for the offloaded callback RCU model (RCU_NOCB_CPU=y && (TREE_CPU=y || TREE_PREEMPT_RC)) in certain bootup scenarios" * 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: rcu: Make nocb leader kthreads process pending callbacks after spawning
| * \ \ Merge branch 'rcu/urgent' of ↵Ingo Molnar2014-09-032-12/+12
| |\ \ \ | | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu into core/urgent Pull an RCU fix from Paul E. McKenney: "This series contains a single commit fixing an initialization bug reported by Amit Shah and fixed by Pranith Kumar (and tested by Amit). This bug results in a boot-time hang in callback-offloaded configurations where callbacks were posted before the offloading ('rcuo') kthreads were created." Signed-off-by: Ingo Molnar <mingo@kernel.org>
| | * | rcu: Make nocb leader kthreads process pending callbacks after spawningPranith Kumar2014-08-282-12/+12
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The nocb callbacks generated before the nocb kthreads are spawned are enqueued in the nocb queue for later processing. Commit fbce7497ee5af ("rcu: Parallelize and economize NOCB kthread wakeups") introduced nocb leader kthreads which checked the nocb_leader_wake flag to see if there were any such pending callbacks. A case was reported in which newly spawned leader kthreads were not processing the pending callbacks as this flag was not set, which led to a boot hang. The following commit ensures that the newly spawned nocb kthreads process the pending callbacks by allowing the kthreads to run immediately after spawning instead of waiting. This is done by inverting the logic of nocb_leader_wake tests to nocb_leader_sleep which allows us to use the default initialization of this flag to 0 to let the kthreads run. Reported-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Pranith Kumar <bobby.prani@gmail.com> Link: http://www.spinics.net/lists/kernel/msg1802899.html [ paulmck: Backported to v3.17-rc2. ] Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Tested-by: Amit Shah <amit.shah@redhat.com>
* | | Merge branch 'timers-urgent-for-linus' of ↵Linus Torvalds2014-09-074-11/+39
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fixes from Thomas Gleixner: "Three fixlets from the timer departement: - Update the timekeeper before updating vsyscall and pvclock. This fixes the kvm-clock regression reported by Chris and Paolo. - Use the proper irq work interface from NMI. This fixes the regression reported by Catalin and Dave. - Clarify the compat_nanosleep error handling mechanism to avoid future confusion" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: timekeeping: Update timekeeper before updating vsyscall and pvclock compat: nanosleep: Clarify error handling nohz: Restore NMI safe local irq work for local nohz kick
| * | | timekeeping: Update timekeeper before updating vsyscall and pvclockThomas Gleixner2014-09-061-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The update_walltime() code works on the shadow timekeeper to make the seqcount protected region as short as possible. But that update to the shadow timekeeper does not update all timekeeper fields because it's sufficient to do that once before it becomes life. One of these fields is tkr.base_mono. That stays stale in the shadow timekeeper unless an operation happens which copies the real timekeeper to the shadow. The update function is called after the update calls to vsyscall and pvclock. While not correct, it did not cause any problems because none of the invoked update functions used base_mono. commit cbcf2dd3b3d4 (x86: kvm: Make kvm_get_time_and_clockread() nanoseconds based) changed that in the kvm pvclock update function, so the stale mono_base value got used and caused kvm-clock to malfunction. Put the update where it belongs and fix the issue. Reported-by: Chris J Arges <chris.j.arges@canonical.com> Reported-by: Paolo Bonzini <pbonzini@redhat.com> Cc: Gleb Natapov <gleb@kernel.org> Cc: John Stultz <john.stultz@linaro.org> Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1409050000570.3333@nanos Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * | | compat: nanosleep: Clarify error handlingThomas Gleixner2014-09-061-3/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The error handling in compat_sys_nanosleep() is correct, but completely non obvious. Document it and restrict it to the -ERESTART_RESTARTBLOCK return value for clarity. Reported-by: Kees Cook <keescook@chromium.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
| * | | nohz: Restore NMI safe local irq work for local nohz kickFrederic Weisbecker2014-09-042-6/+15
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The local nohz kick is currently used by perf which needs it to be NMI-safe. Recent commit though (7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9) changed its implementation to fire the local kick using the remote kick API. It was convenient to make the code more generic but the remote kick isn't NMI-safe. As a result: WARNING: CPU: 3 PID: 18062 at kernel/irq_work.c:72 irq_work_queue_on+0x11e/0x140() CPU: 3 PID: 18062 Comm: trinity-subchil Not tainted 3.16.0+ #34 0000000000000009 00000000903774d1 ffff880244e06c00 ffffffff9a7f1e37 0000000000000000 ffff880244e06c38 ffffffff9a0791dd ffff880244fce180 0000000000000003 ffff880244e06d58 ffff880244e06ef8 0000000000000000 Call Trace: <NMI> [<ffffffff9a7f1e37>] dump_stack+0x4e/0x7a [<ffffffff9a0791dd>] warn_slowpath_common+0x7d/0xa0 [<ffffffff9a07930a>] warn_slowpath_null+0x1a/0x20 [<ffffffff9a17ca1e>] irq_work_queue_on+0x11e/0x140 [<ffffffff9a10a2c7>] tick_nohz_full_kick_cpu+0x57/0x90 [<ffffffff9a186cd5>] __perf_event_overflow+0x275/0x350 [<ffffffff9a184f80>] ? perf_event_task_disable+0xa0/0xa0 [<ffffffff9a01a4cf>] ? x86_perf_event_set_period+0xbf/0x150 [<ffffffff9a187934>] perf_event_overflow+0x14/0x20 [<ffffffff9a020386>] intel_pmu_handle_irq+0x206/0x410 [<ffffffff9a0b54d3>] ? arch_vtime_task_switch+0x63/0x130 [<ffffffff9a01937b>] perf_event_nmi_handler+0x2b/0x50 [<ffffffff9a007b72>] nmi_handle+0xd2/0x390 [<ffffffff9a007aa5>] ? nmi_handle+0x5/0x390 [<ffffffff9a0d131b>] ? lock_release+0xab/0x330 [<ffffffff9a008062>] default_do_nmi+0x72/0x1c0 [<ffffffff9a0c925f>] ? cpuacct_account_field+0xcf/0x200 [<ffffffff9a008268>] do_nmi+0xb8/0x100 Lets fix this by restoring the use of local irq work for the nohz local kick. Reported-by: Catalin Iacob <iacobcatalin@gmail.com> Reported-and-tested-by: Dave Jones <davej@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
* | | Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds2014-09-068-17/+28
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull kvm fixes from Paolo Bonzini: "A smattering of bug fixes across most architectures" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: powerpc/kvm/cma: Fix panic introduces by signed shift operation KVM: s390/mm: Fix guest storage key corruption in ptep_set_access_flags KVM: s390/mm: Fix storage key corruption during swapping arm/arm64: KVM: Complete WFI/WFE instructions ARM/ARM64: KVM: Nuke Hyp-mode tlbs before enabling MMU KVM: s390/mm: try a cow on read only pages for key ops KVM: s390: Fix user triggerable bug in dead code
| * | | powerpc/kvm/cma: Fix panic introduces by signed shift operationLaurent Dufour2014-09-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fc95ca7284bc54953165cba76c3228bd2cdb9591 introduces a memset in kvmppc_alloc_hpt since the general CMA doesn't clear the memory it allocates. However, the size argument passed to memset is computed from a signed value and its signed bit is extended by the cast the compiler is doing. This lead to extremely large size value when dealing with order value >= 31, and almost all the memory following the allocated space is cleaned. As a consequence, the system is panicing and may even fail spawning the kdump kernel. This fix makes use of an unsigned value for the memset's size argument to avoid sign extension. Among this fix, another shift operation which may lead to signed extended value too is also fixed. Cc: Alexey Kardashevskiy <aik@ozlabs.ru> Cc: Paul Mackerras <paulus@samba.org> Cc: Alexander Graf <agraf@suse.de> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
OpenPOWER on IntegriCloud