- 09 Jun, 2015 29 commits
-
-
Lv Zheng authored
[ Upstream commit 6d3fd3cc ] ACPICA commit 154f6d074dd38d6ebc0467ad454454e6c5c9ecdf There are code pieces converting pointers using "(acpi_physical_address) x" or "ACPI_CAST_PTR (t, x)" formats, this patch cleans up them. Known issues: 1. Cleanup of "(ACPI_PHYSICAL_ADDRRESS) x" for a table field For the conversions around the table fields, it is better to fix it with alignment also fixed. So this patch doesn't modify such code. There should be no functional problem by leaving them unchanged. Link: https://github.com/acpica/acpica/commit/154f6d07Signed-off-by:
Lv Zheng <lv.zheng@intel.com> Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Lv Zheng authored
[ Upstream commit f254e3c5 ] ACPICA commit 7d9fd64397d7c38899d3dc497525f6e6b044e0e3 OSPMs like Linux expect an acpi_physical_address returning value from acpi_find_root_pointer(). This triggers warnings if sizeof (acpi_size) doesn't equal to sizeof (acpi_physical_address): drivers/acpi/osl.c:275:3: warning: passing argument 1 of 'acpi_find_root_pointer' from incompatible pointer type [enabled by default] In file included from include/acpi/acpi.h:64:0, from include/linux/acpi.h:36, from drivers/acpi/osl.c:41: include/acpi/acpixf.h:433:1: note: expected 'acpi_size *' but argument is of type 'acpi_physical_address *' This patch corrects acpi_find_root_pointer(). Link: https://github.com/acpica/acpica/commit/7d9fd643Signed-off-by:
-
Al Viro authored
[ Upstream commit 86cc0584 ] Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Alexey Khoroshilov authored
[ Upstream commit bc26d4d0 ] A deadlock can be initiated by userspace via ioctl(SNDCTL_SEQ_OUTOFBAND) on /dev/sequencer with TMR_ECHO midi event. In this case the control flow is: sound_ioctl() -> case SND_DEV_SEQ: case SND_DEV_SEQ2: sequencer_ioctl() -> case SNDCTL_SEQ_OUTOFBAND: spin_lock_irqsave(&lock,flags); play_event(); -> case EV_TIMING: seq_timing_event() -> case TMR_ECHO: seq_copy_to_input() -> spin_lock_irqsave(&lock,flags); It seems that spin_lock_irqsave() around play_event() is not necessary, because the only other call location in seq_startplay() makes the call without acquiring spinlock. So, the patch just removes spinlocks around play_event(). By the way, it removes unreachable code in seq_timing_event(), since (seq_mode == SEQ_2) case is handled in the beginning. Compile tested only. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Mark Rutland authored
[ Upstream commit c0978773 ] arm64 builds with GCC 5 have caused the __asmeq assertions in the PSCI calling code to fire, so move the ARM PSCI calls out of line into their own assembly file for consistency and to safeguard against the same issue occuring with the 32-bit toolchain. [will: brought into line with arm64 implementation] Reported-by:
Andy Whitcroft <apw@canonical.com> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Takeshi Kihara authored
[ Upstream commit bad4371d ] f9fd54f2 ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout") changed the timeout value from 1000 jiffies to 1s. In the case where HZ is 1000 the values are the same. However, for smaller HZ values the timeout is now smaller, 1s instead of 10s in the case of HZ=100. Since the timeout occurs in spite of a normal data transfer a timeout of 10s seems more appropriate. This restores the previous timeout in the case where HZ=100 and results in an increase over the previous timeout for larger values of HZ. Fixes: f9fd54f2 ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout") Signed-off-by:
Takeshi Kihara <takeshi.kihara.df@renesas.com> [horms: rewrote changelog to refer to HZ] Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
Yoshihiro Kaneko <ykaneko0929@gmail.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Grygorii Strashko authored
[ Upstream commit 184af16b ] The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(), as result mmc_rescan() could be scheduled and executed at late hibernation restore stages when MMC device is suspended already - which, in turn, will lead to system crash on TI dra7-evm board: WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify(). Fixes: 4c2ef25f (mmc: fix all hangs related to mmc/sd card...) Signed-off-by:
Grygorii Strashko <Grygorii.Strashko@linaro.org> Signed-off-by:
-
Chuanxiao Dong authored
[ Upstream commit 4e93b9a6 ] During kernel boot, it will try to read some logical sectors of each block device node for the possible partition table. But since RPMB partition is special and can not be accessed by normal eMMC read / write CMDs, it will cause below error messages during kernel boot: ... mmc0: Got data interrupt 0x00000002 even though no data operation was in progress. mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00 mmcblk0rpmb: retrying using single block read mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900 end_request: I/O error, dev mmcblk0rpmb, sector 0 Buffer I/O error on device mmcblk0rpmb, logical block 0 end_request: I/O error, dev mmcblk0rpmb, sector 8 Buffer I/O error on device mmcblk0rpmb, logical block 1 end_request: I/O error, dev mmcblk0rpmb, sector 16 Buffer I/O error on device mmcblk0rpmb, logical block 2 end_request: I/O error, dev mmcblk0rpmb, sector 24 Buffer I/O error on device mmcblk0rpmb, logical block 3 ... This patch will discard the access request in eMMC queue if it is RPMB partition access request. By this way, it avoids trigger above error messages. Fixes: 090d25fe ("mmc: core: Expose access to RPMB partition") Signed-off-by:
Yunpeng Gao <yunpeng.gao@intel.com> Signed-off-by:
Chuanxiao Dong <chuanxiao.dong@intel.com> Tested-by:
Michael Shigorin <mike@altlinux.org> Signed-off-by:
-
Doug Anderson authored
[ Upstream commit c5272a28 ] Way back, when the world was a simpler place and there was no war, no evil, and no kernel bugs, there was just a single pinctrl lock. That was how the world was when (57291ce2 pinctrl: core device tree mapping table parsing support) was written. In that case, there were instances where the pinctrl mutex was already held when pinctrl_register_map() was called, hence a "locked" parameter was passed to the function to indicate that the mutex was already locked (so we shouldn't lock it again). A few years ago in (42fed7ba pinctrl: move subsystem mutex to pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex. ...but (oops) we forgot to re-think about the whole "locked" parameter for pinctrl_register_map(). Basically the "locked" parameter appears to still refer to whether the bigger pinctrl_dev mutex is locked, but we're using it to skip locks of our (now separate) pinctrl_maps_mutex. That's kind of a bad thing(TM). Probably nobody noticed because most of the calls to pinctrl_register_map happen at boot time and we've got synchronous device probing. ...and even cases where we're asynchronous don't end up actually hitting the race too often. ...but after banging my head against the wall for a bug that reproduced 1 out of 1000 reboots and lots of looking through kgdb, I finally noticed this. Anyway, we can now safely remove the "locked" parameter and go back to a war-free, evil-free, and kernel-bug-free world. Fixes: 42fed7ba ("pinctrl: move subsystem mutex to pinctrl_dev struct") Signed-off-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Christian König authored
[ Upstream commit d52cdfa4 ] MPEG 2/4 are only supported since UVD3. Signed-off-by:
Christian König <christian.koenig@amd.com> CC: stable@vger.kernel.org Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Christian König authored
[ Upstream commit a1b403da ] Invalid messages can crash the hw otherwise. Signed-off-by:
-
Christian König authored
[ Upstream commit 29c63fe2 ] Invalid handles can crash the hw. Signed-off-by:
-
monk.liu authored
[ Upstream commit db12973c ] Fixing a memory leak with userptrs. v2: clean up the loop, use an iterator instead v3: remove unused variable Signed-off-by:
monk.liu <monk.liu@amd.com> Signed-off-by:
-
Christian König authored
[ Upstream commit 013ead48 ] Hardware doesn't seem to work correctly, just block userspace in this case. v2: add missing defines Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=85320Signed-off-by:
-
Jani Nikula authored
[ Upstream commit 9fcb1704 ] The eDP port A register on PCH split platforms has a slightly different register layout from the other ports, with bit 6 being either alternate scrambler reset or reserved, depending on the generation. Our misinterpretation of the bit as audio has lead to warning. Fix this by not enabling audio on port A, since none of our platforms support audio on port A anyway. v2: DDI doesn't have audio on port A either (Sivakumar Thulasimani) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89958Reported-and-tested-by:
Chris Bainbridge <chris.bainbridge@gmail.com> Cc: stable@vger.kernel.org Reviewed-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Lukas Wunner authored
[ Upstream commit 3916e3fd ] Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz) as a BTO option, both versions used dual channel LVDS even though the smaller one would have fit into a single channel. Notes: Bug report showing that the MacBookPro8,2 with 1440x900 uses dual channel LVDS (this lead to it being hardcoded in intel_lvds.c by Daniel Vetter with commit 618563e3): https://bugzilla.kernel.org/show_bug.cgi?id=42842 If i915.lvds_channel_mode=2 is missing even though the machine needs it, every other vertical line is white and consequently, only the left half of the screen is visible (verified by myself on a MacBookPro9,1). Forum posting concerning a MacBookPro6,2 with 1440x900, author is using i915.lvds_channel_mode=2 on the kernel command line, proving that the machine uses dual channels: https://bbs.archlinux.org/viewtopic.php?id=185770 Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all MacBook Pro "A1286" models, and that model number encompasses the MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's driven with dual channel LVDS: http://www.ebay.com/itm/-/400690878560 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286 http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones with i915 graphics and dual channel LVDS, so that list should be complete. And the 8,2 is already in intel_lvds.c. Possible motivation to use dual channel LVDS even on the 1440x900 models: Reduce the number of different parts, i.e. use identical logic boards and display cabling on both versions and the only differing component is the panel. Signed-off-by:
Lukas Wunner <lukas@wunner.de> Acked-by:
-
Mario Kleiner authored
[ Upstream commit fdb68e09 ] Since commit 844b03f2 we make sure that after vblank irq off, we return the last valid (vblank count, vblank timestamp) pair to clients, e.g., during modesets, which is good. An overlooked side effect of that commit for kms drivers without support for precise vblank timestamping is that at vblank irq enable, when we update the vblank counter from the hw counter, we can't update the corresponding vblank timestamp, so now we have a totally mismatched timestamp for the new count to confuse clients. Restore old client visible behaviour from before Linux 3.17, but zero out the timestamp at vblank counter update (instead of disable as in original implementation) if we can't generate a meaningful timestamp immediately for the new vblank counter. This will fix this regression, so callers know they need to retry again later if they need a valid timestamp, but at the same time preserves the improvements made in the commit mentioned above. Signed-off-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Cc: <stable@vger.kernel.org> #v3.17+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Ulf Hansson authored
[ Upstream commit 11133db7 ] Fixes: c94a4ab7 ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by:
Bjorn Andersson <bjorn.andersson@sonymobile.com> Signed-off-by:
-
Ulf Hansson authored
[ Upstream commit f9a8c391 ] Fixes: c94a4ab7 ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by:
-
Ulf Hansson authored
[ Upstream commit 53d26698 ] The GPIO regulator for the SD-card isn't a ux500 SOC configuration, but instead it's specific to the board. Move the definition of it, into the board DTSs. Fixes: c94a4ab7 ("ARM: ux500: Disable the MMCI gpio-regulator by default") Signed-off-by:
-
Nicolas Schichan authored
[ Upstream commit 19fc99d0 ] In that case, emit_udiv() will be called with rn == ARM_R0 (r_scratch) and loading rm first into ARM_R0 will result in jit_udiv() function being called the same dividend and divisor. Fix that by loading rn first into ARM_R1 and then rm into ARM_R0. Signed-off-by:
Nicolas Schichan <nschichan@freebox.fr> Cc: <stable@vger.kernel.org> # v3.13+ Fixes: aee636c4 (bpf: do not use reciprocal divide) Acked-by:
Mircea Gherzan <mgherzan@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Tony Lindgren authored
[ Upstream commit 102bcb6e ] If we use a combination of VMODE and I2C4 for retention modes, eventually the off idle power consumption will creep up by about 23mW, even during off mode with I2C4 always staying enabled. Turns out this is because of erratum i531 "Extra Power Consumed When Repeated Start Operation Mode Is Enabled on I2C Interface Dedicated for Smart Reflex (I2C4)" as pointed out by Nishanth Menon <nm@ti.com>. Let's fix the issue by adding i2c_cfg_clear_mask for the bits to clear when initializing the I2C4 adapter so we can clear SREN bit that drives the I2C4 lines low otherwise when there is no traffic. Fixes: 3b8c4ebb ("ARM: OMAP3: Fix idle mode signaling for Cc: stable@vger.kernel.org # v3.16+ sys_clkreq and sys_off_mode") Cc: Kevin Hilman <khilman@kernel.org> Cc: Tero Kristo <t-kristo@ti.com> Reviewed-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Gregory CLEMENT authored
[ Upstream commit 750e30d4 ] There is no crystal connected to the internal RTC on the Open Block AX3. So let's disable it in order to prevent the kernel probing the driver uselessly. Eventually this patches removes the following warning message from the boot log: "rtc-mv d0010300.rtc: internal RTC not ticking" Acked-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Cc: <stable@vger.kernel.org> # v3.8 + Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit cfe8c597 ] On imx23-olinuxino the LED turns on when level logic high is aplied to GPIO2_1. Fix the gpios property accordingly. Fixes: b34aa185 ("ARM: dts: imx23-olinuxino: Remove unneeded "default-on"") Reported-by:
Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Tested-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Stefan Wahren authored
[ Upstream commit 0fdebe1a ] The dr_mode of usb0 on imx233-olinuxino is left to default "otg". Since the green LED (GPIO2_1) on imx233-olinuxino is connected to the same pin as USB_OTG_ID it's possible to disable USB host by LED toggling: echo 0 > /sys/class/leds/green/brightness [ 1068.890000] ci_hdrc ci_hdrc.0: remove, state 1 [ 1068.890000] usb usb1: USB disconnect, device number 1 [ 1068.920000] usb 1-1: USB disconnect, device number 2 [ 1068.920000] usb 1-1.1: USB disconnect, device number 3 [ 1069.070000] usb 1-1.2: USB disconnect, device number 4 [ 1069.450000] ci_hdrc ci_hdrc.0: USB bus 1 deregistered [ 1074.460000] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in 11 This patch fixes the issue by setting dr_mode to "host" in the dts file. Reported-by:
Harald Geyer <harald@ccbib.org> Signed-off-by:
Marek Vasut <marex@denx.de> Acked-by:
Peter Chen <peter.chen@freescale.com> Fixes: b4931294 ("ARM: dts: imx23-olinuxino: Add USB host support") Cc: stable@vger.kernel.org Signed-off-by:
-
Marek Vasut authored
[ Upstream commit 4ada77e3 ] Fix a typo in the TX DMA interrupt name for AUART4. This patch makes AUART4 operational again. Signed-off-by:
-
Philipp Zabel authored
[ Upstream commit 7f8d49dc ] The fixed-regulator bindings require a separate property enable-active-high, the standard gpio phandle property polarity setting is ignored. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Fixes: 4fe69a93 ("ARM: dts: Add Phytec pfla02 with i.MX6 DualLite/Solo") Cc: stable@vger.kernel.org Signed-off-by:
-
Markus Pargmann authored
[ Upstream commit f90d3f0d ] The property '#pwm-cells' is currently missing. It is not possible to use pwm4 without this property. Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Fixes: 5658a68f ("ARM i.MX25: Add devicetree") Cc: <stable@vger.kernel.org> Reviewed-by:
-
Pavel Machek authored
[ Upstream commit 1819e303 ] N900 audio recording needs that codec provides bias voltage for integrated digital microphone and headset microphone depending which one is used. Digital microphone uses 2 V bias and it comes from the codec A part. Codec B part drives the headset microphone bias and that is set to 2.5 V. Cc: stable@vger.kernel.org # v3.16+ Signed-off-by:
Pavel Machek <pavel@ucw.cz> [Jarkko: Headset mic bias changed to 2 (2.5 V) as it was before commit e2e8bfdf ("ASoC: tlv320aic3x: Convert mic bias to a supply widget")] Signed-off-by:
Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by:
-
- 23 May, 2015 11 commits
-
-
Rabin Vincent authored
[ Upstream commit c0403ec0 ] This reverts Linux 4.1-rc1 commit 0618764c. The problem which that commit attempts to fix actually lies in the Freescale CAAM crypto driver not dm-crypt. dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto driver should internally backlog requests which arrive when the queue is full and process them later. Until the crypto hw's queue becomes full, the driver returns -EINPROGRESS. When the crypto hw's queue if full, the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is expected to backlog the request and process it when the hardware has queue space. At the point when the driver takes the request from the backlog and starts processing it, it calls the completion function with a status of -EINPROGRESS. The completion function is called (for a second time, in the case of backlogged requests) with a status/err of 0 when a request is done. Crypto drivers for hardware without hardware queueing use the helpers, crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request() and crypto_get_backlog() helpers to implement this behaviour correctly, while others implement this behaviour without these helpers (ccp, for example). dm-crypt (before the patch that needs reverting) uses this API correctly. It queues up as many requests as the hw queues will allow (i.e. as long as it gets back -EINPROGRESS from the request function). Then, when it sees at least one backlogged request (gets -EBUSY), it waits till that backlogged request is handled (completion gets called with -EINPROGRESS), and then continues. The references to af_alg_wait_for_completion() and af_alg_complete() in that commit's commit message are irrelevant because those functions only handle one request at a time, unlink dm-crypt. The problem is that the Freescale CAAM driver, which that commit describes as having being tested with, fails to implement the backlogging behaviour correctly. In cam_jr_enqueue(), if the hardware queue is full, it simply returns -EBUSY without backlogging the request. What the observed deadlock was is not described in the commit message but it is obviously the wait_for_completion() in crypto_convert() where dm-crypto would wait for the completion being called with -EINPROGRESS in the case of backlogged requests. This completion will never be completed due to the bug in the CAAM driver. Commit 0618764c incorrectly made dm-crypt wait for every request, even when the driver/hardware queues are not full, which means that dm-crypt will never see -EBUSY. This means that that commit will cause a performance regression on all crypto drivers which implement the API correctly. Revert it. Correct backlog handling should be implemented in the CAAM driver instead. Cc'ing stable purely because commit 0618764c did. If for some reason a stable@ kernel did pick up commit 0618764c it should get reverted. Signed-off-by:
Rabin Vincent <rabin.vincent@axis.com> Reviewed-by:
Horia Geanta <horia.geanta@freescale.com> Cc: stable@vger.kernel.org Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Ben Hutchings authored
[ Upstream commit 8014bcc8 ] The variable for the 'permissive' module parameter used to be static but was recently changed to be extern. This puts it in the kernel global namespace if the driver is built-in, so its name should begin with a prefix identifying the driver. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Fixes: af6fc858 ("xen-pciback: limit guest control of command register") Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
-
Boris Ostrovsky authored
[ Upstream commit 16e6bd59 ] .. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to 'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu(). Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Tested-by:
Annie Li <annie.li@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Boris Ostrovsky authored
[ Upstream commit b9d934f2 ] After a resume the hypervisor/tools may change console event channel number. We should re-query it. Signed-off-by:
-
Boris Ostrovsky authored
[ Upstream commit 16f1cf3b ] After a resume the hypervisor/tools may change xenbus event channel number. We should re-query it. Signed-off-by:
-
Boris Ostrovsky authored
[ Upstream commit 5cec9883 ] When a guest is resumed, the hypervisor may change event channel assignments. If this happens and the guest uses 2-level events it is possible for the interrupt to be claimed by wrong VCPU since cpu_evtchn_mask bits may be stale. This can happen even though evtchn_2l_bind_to_cpu() attempts to clear old bits: irq_info that is passed in is not necessarily the original one (from pre-migration times) but instead is freshly allocated during resume and so any information about which CPU the channel was bound to is lost. Thus we should clear the mask during resume. We also need to make sure that bits for xenstore and console channels are set when these two subsystems are resumed. While rebind_evtchn_irq() (which is invoked for both of them on a resume) calls irq_set_affinity(), the latter will in fact postpone setting affinity until handling the interrupt. But because cpu_evtchn_mask will have bits for these two cleared we won't be able to take the interrupt. With that in mind, we need to bind those two channels explicitly in rebind_evtchn_irq(). We will keep irq_set_affinity() so that we have a pass through generic irq affinity code later, in case something needs to be updated there as well. (Also replace cpumask_of(0) with cpumask_of(info->cpu) in rebind_evtchn_irq(): it should be set to zero in preceding xen_irq_info_evtchn_setup().) Signed-off-by:
-
Naoya Horiguchi authored
[ Upstream commit 602498f9 ] If multiple soft offline events hit one free page/hugepage concurrently, soft_offline_page() can handle the free page/hugepage multiple times, which makes num_poisoned_pages counter increased more than once. This patch fixes this wrong counting by checking TestSetPageHWPoison for normal papes and by checking the return value of dequeue_hwpoisoned_huge_page() for hugepages. Signed-off-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Acked-by:
Dean Nelson <dnelson@redhat.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: <stable@vger.kernel.org> [3.14+] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Tejun Heo authored
[ Upstream commit 464d1387 ] mm/page-writeback.c has several places where 1 is added to the divisor to prevent division by zero exceptions; however, if the original divisor is equivalent to -1, adding 1 leads to division by zero. There are three places where +1 is used for this purpose - one in pos_ratio_polynom() and two in bdi_position_ratio(). The second one in bdi_position_ratio() actually triggered div-by-zero oops on a machine running a 3.10 kernel. The divisor is x_intercept - bdi_setpoint + 1 == span + 1 span is confirmed to be (u32)-1. It isn't clear how it ended up that but it could be from write bandwidth calculation underflow fixed by c72efb65 ("writeback: fix possible underflow in write bandwidth calculation"). At any rate, +1 isn't a proper protection against div-by-zero. This patch converts all +1 protections to |1. Note that bdi_update_dirty_ratelimit() was already using |1 before this patch. Signed-off-by:
Tejun Heo <tj@kernel.org> Cc: stable@vger.kernel.org Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Al Viro authored
[ Upstream commit f15133df ] path_openat() jumps to the wrong place after do_tmpfile() - it has already done path_cleanup() (as part of path_lookupat() called by do_tmpfile()), so doing that again can lead to double fput(). Cc: stable@vger.kernel.org # v3.11+ Signed-off-by:
-
Naoya Horiguchi authored
[ Upstream commit 09789e5d ] Currently memory_failure() calls shake_page() to sweep pages out from pcplists only when the victim page is 4kB LRU page or thp head page. But we should do this for a thp tail page too. Consider that a memory error hits a thp tail page whose head page is on a pcplist when memory_failure() runs. Then, the current kernel skips shake_pages() part, so hwpoison_user_mappings() returns without calling split_huge_page() nor try_to_unmap() because PageLRU of the thp head is still cleared due to the skip of shake_page(). As a result, me_huge_page() runs for the thp, which is broken behavior. One effect is a leak of the thp. And another is to fail to isolate the memory error, so later access to the error address causes another MCE, which kills the processes which used the thp. This patch fixes this problem by calling shake_page() for thp tail case. Fixes: 385de357 ("thp: allow a hwpoisoned head page to be put back to LRU") Signed-off-by:
Andi Kleen <ak@linux.intel.com> Acked-by:
-
Eric W. Biederman authored
[ Upstream commit 7e96c1b0 ] This fixes a dumb bug in fs_fully_visible that allows proc or sys to be mounted if there is a bind mount of part of /proc/ or /sys/ visible. Cc: stable@vger.kernel.org Reported-by:
Eric Windisch <ewindisch@docker.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
