- 04 Jul, 2015 27 commits
-
-
Subbaraya Sundeep Bhatta authored
[ Upstream commit 76e838c9 ] We need to return error to caller if command is not sent to controller succesfully. Signed-off-by:
Subbaraya Sundeep Bhatta <sbhatta@xilinx.com> Fixes: 72246da4 (usb: Introduce DesignWare USB3 DRD Driver) Cc: <stable@vger.kernel.org> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
Subbaraya Sundeep Bhatta authored
[ Upstream commit 891b1dc0 ] We need to return error to caller if command is not sent to controller succesfully. Signed-off-by:
-
Alex Deucher authored
[ Upstream commit 39fa10f7 ] Since we are messing with state in the worker. v2: drop the changes in the mst worker Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Vincent Fann authored
[ Upstream commit 1277fa2a ] Several of these drivers have there TX randomly blocked for 3~5 seconds while measuring tx throughput (iperf). The root couse happens in rtl_pci_flush(). The function uses a while-loop to wait for TX queue length to decrease to 0. The TX queue length counts the number of packets that are queued in the driver. The driver relys on the TX OK interrupt to return skb and reduce TX queue length. The interrupt subroutine disables interupts, reads the interrupt registers, and then clears the registers in the beginning of _rtl_pci_interrupt(). After all interupts process are finished, the driver invokes enable_interrupt() to enable interupts. This behavior is normal for an interrupt subroutine. But enable_interrupt() invokes clear_interrupt() again. This unexpected interrupt clearing may cleari me fresh TX OK interrupts. These missing interrupts cause TX queue length to never reduce to 0i, which causes rtl_pci_flush() to be stuck in unterminated while-loop. This patch removes clear_interrupt() in enable_interrupt() to avoid this behavior. Signed-off-by:
Vincent Fann <vincent_fann@realtek.com> Signed-off-by:
Shao Fu <shaofu@realtek.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> [3.18+] Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Gregory CLEMENT authored
[ Upstream commit ce2f6ea1 ] The commit df59fa7f "spi: orion: support armada extended baud rates" was too optimistic for the maximum baud rate that the Armada SoCs can support. According to the hardware datasheet the maximum frequency supported by the Armada 370 SoC is tclk/4. But for the Armada XP, Armada 38x and Armada 39x SoCs the limitation is 50MHz and for the Armada 375 it is tclk/15. Currently the armada-370-spi compatible is only used by the Armada 370 and the Armada XP device tree. On Armada 370, tclk cannot be higher than 200MHz. In order to be able to handle both SoCs, we can take the minimum of 50MHz and tclk/4. A proper solution is adding a compatible string for each SoC, but it can't be done as a fix for compatibility reason (we can't modify device tree that have been already released) and it will be part of a separate patch. Fixes: df59fa7f (spi: orion: support armada extended baud rates) Reported-by:
Kostya Porotchkin <kostap@marvell.com> Signed-off-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by:
-
David Fries authored
[ Upstream commit f7134eea ] A temperature conversion can take 750 ms and when possible the w1_therm slave driver drops the bus_mutex to allow other bus operations, but that includes operations such as a periodic slave search, which can remove this slave when it is no longer detected. If that happens the sl->family_data will be freed and set to NULL causing w1_slave_show to crash when it wakes up. Signed-off-by:
David Fries <David@Fries.net> Reported-By:
Thorsten Bschorr <thorsten@bschorr.de> Tested-by:
Evgeniy Polyakov <zbr@ioremap.net> Cc: stable <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Tomas Winkler authored
[ Upstream commit fe292283 ] HW has to be in known state before the initialisation sequence is started. The polling step for settling aliveness was set to 200ms while in practise this can be done in up to 30msecs. Cc: <stable@vger.kernel.org> #3.18+ Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Barak Yoresh <barak.yoresh@intel.com> Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 08249651 ] Refine the mechanism introduced by commit f244d8b6 ("ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug") to propagate the ignore_hotplug setting of the device to its parent bridge in case hotplug notifications related to the graphics adapter switching are given for the bridge rather than for the device itself (they need to be ignored in both cases). Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891 Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927 Fixes: b440bde7 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device") Reported-and-tested-by:
tiagdtd-lava <tiagdtd-lava@yahoo.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> CC: stable@vger.kernel.org # v3.17+ Signed-off-by:
-
Christoffer Dall authored
[ Upstream commit bde1b294 ] Clearly specify that "Cc: stable@vger.kernel.org" is strongly preferred so that developers understand that the other options should only be used when absolutely required. Also specify how upstream commit ids should be referenced in patches submitted directly to stable (I gathered this from looking at the stable archives), and specify that any modified patches for stable should be clearly documented in the patch description. Signed-off-by:
Christoffer Dall <christoffer.dall@linaro.org> Signed-off-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
-
Mimi Zohar authored
[ Upstream commit f2b3dee4 ] The call to asymmetric_key_hex_to_key_id() from ca_keys_setup() silently fails with -ENOMEM. Instead of dynamically allocating memory from a __setup function, this patch defines a variable and calls __asymmetric_key_hex_to_key_id(), a new helper function, directly. This bug was introduced by 'commit 46963b77 ("KEYS: Overhaul key identification when searching for asymmetric keys")'. Changelog: - for clarification, rename hexlen to asciihexlen in asymmetric_key_hex_to_key_id() - add size argument to __asymmetric_key_hex_to_key_id() - David Howells - inline __asymmetric_key_hex_to_key_id() - David Howells - remove duplicate strlen() calls Acked-by:
David Howells <dhowells@redhat.com> Signed-off-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: stable@vger.kernel.org # 3.18 Signed-off-by:
-
Paolo Bonzini authored
[ Upstream commit 69a12200 ] The argument to KVM_GET_DIRTY_LOG is a memslot id; it may not match the position in the memslots array, which is sorted by gfn. Cc: stable@vger.kernel.org Reviewed-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Bart Van Assche authored
[ Upstream commit be34c62d ] Introduce the helper function srp_wait_for_queuecommand(). Move the definition of scsi_request_fn_active(). Add a comment above srp_wait_for_queuecommand() that support for scsi-mq needs to be added. This patch does not change any functionality. A second call to srp_wait_for_queuecommand() will be introduced in the next patch. Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Cc: James Bottomley <JBottomley@Odin.com> Cc: Sagi Grimberg <sagig@mellanox.com> Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com> Cc: <stable@vger.kernel.org> #v3.13 Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Zhichang Yuan authored
[ Upstream commit 5dbb4c61 ] 41f8bba7 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") added support for systems with several I/O ranges described by OF bindings. It modified pci_address_to_pio() look up the io_range for a given CPU physical address, but the conversion was wrong. Fix the conversion of address to I/O port. [bhelgaas: changelog] Fixes: 41f8bba7 ("of/pci: Add pci_register_io_range() and pci_pio_to_address()") Signed-off-by:
Zhichang Yuan <yuanzhichang@hisilicon.com> Signed-off-by:
Liviu Dudau <Liviu.Dudau@arm.com> CC: stable@vger.kernel.org # v3.18+ Signed-off-by:
-
Axel Lin authored
[ Upstream commit 12c35005 ] WM8955_K_8_0_MASK bits is controlled by WM8955_PLL_CONTROL_3 rather than WM8955_PLL_CONTROL_2. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Acked-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
-
Thomas Reitmayr authored
[ Upstream commit e989a73e ] Fix an oops during device initialization by correctly setting size_of_priv instead of leaving it 0. The regression was introduced by 8abe4a0a ("[media] dib7000: export just one symbol") and only fixed for one type of dib0700 based devices in 9e334c75 ("[media] Fix regression in some dib0700 based devices"). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=92301 Fixes: 8abe4a0a ("[media] dib7000: export just one symbol") Cc: stable@vger.kernel.org # for version 3.17+ Signed-off-by:
Thomas Reitmayr <treitmayr@devbase.at> Signed-off-by:
Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by:
-
Axel Lin authored
[ Upstream commit ebb6ad73 ] VMID Control 0 BIT[2:1] is VMID Divider Enable and Select 00 = VMID disabled (for OFF mode) 01 = 2 x 50kΩ divider (for normal operation) 10 = 2 x 250kΩ divider (for low power standby) 11 = 2 x 5kΩ divider (for fast start-up) So WM8903_VMID_RES_250K should be 2 << 1, which is 4. Signed-off-by:
-
Axel Lin authored
[ Upstream commit 14ba3ec1 ] According to the datasheet: R10 (0Ah) VMID Impedance Control BIT 3:2 VMIDSEL DEFAULT 00 DESCRIPTION: VMID impedance selection control 00: 75kΩ output 01: 300kΩ output 10: 2.5kΩ output WM8737_VMIDSEL_MASK is 0xC (VMIDSEL - [3:2]), so it needs to left shift WM8737_VMIDSEL_SHIFT bits for setting these bits. Signed-off-by:
-
Axel Lin authored
[ Upstream commit 63781394 ] request_any_context_irq() returns a negative value on failure. It returns either IRQC_IS_HARDIRQ or IRQC_IS_NESTED on success. So fix testing return value of request_any_context_irq(). Also fixup the return value of devm_request_any_context_irq() to make it consistent with request_any_context_irq(). Fixes: 0668d306 ("genirq: Add devm_request_any_context_irq()") Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/1431334978.17783.4.camel@ingics.comSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Horia Geant? authored
[ Upstream commit 69d9cd8c ] This reverts commit 7291a932. The conversion to be16_add_cpu() is incorrect in case cryptlen is negative due to premature (i.e. before addition / subtraction) implicit conversion of cryptlen (int -> u16) leading to sign loss. Cc: <stable@vger.kernel.org> # 3.10+ Cc: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
Horia Geanta <horia.geanta@freescale.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Horia Geant? authored
[ Upstream commit 5fa7dadc ] Cc: <stable@vger.kernel.org> # 3.2+ Fixes: 1d11911a ("crypto: talitos - fix warning: 'alg' may be used uninitialized in this function") Signed-off-by:
-
Grygorii Strashko authored
[ Upstream commit 084609bf ] Setting a dev_pm_ops suspend/resume pair of callbacks but not a set of hibernation callbacks means those pm functions will not be called upon hibernation - that leads to system crash on ARM during freezing if gpio-led is used in combination with CPU led trigger. It may happen after freeze_noirq stage (GPIO is suspended) and before syscore_suspend stage (CPU led trigger is suspended) - usually when disable_nonboot_cpus() is called. Log: PM: noirq freeze of devices complete after 1.425 msecs Disabling non-boot CPUs ... ^ system may crash or stuck here with message (TI AM572x) WARNING: CPU: 0 PID: 3100 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x22c/0x370() 44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in Supervisor mode during Functional access CPU1: shutdown ^ or here Fix this by using SIMPLE_DEV_PM_OPS, which appropriately assigns the suspend and hibernation callbacks and move led_suspend/led_resume under CONFIG_PM_SLEEP to avoid build warnings. Fixes: 73e1ab41 (leds: Convert led class driver from legacy pm ops to dev_pm_ops) Signed-off-by:
Grygorii Strashko <Grygorii.Strashko@linaro.org> Acked-by:
Jacek Anaszewski <j.anaszewski@samsung.com> Cc: 3.11+ <stable@vger.kernel.org> # 3.11+ Signed-off-by:
-
Joe Konno authored
[ Upstream commit 0dd23f94 ] Commit 007bea09 (intel_pstate: Add setting voltage value for baytrail P states.) introduced byt_set_pstate() with the assumption that it would always be run by the CPU whose MSR is to be written by it. It turns out, however, that is not always the case in practice, so modify byt_set_pstate() to enforce the MSR write done by it to always happen on the right CPU. Fixes: 007bea09 (intel_pstate: Add setting voltage value for baytrail P states.) Signed-off-by:
Joe Konno <joe.konno@intel.com> Acked-by:
Kristen Carlson Accardi <kristen@linux.intel.com> Cc: 3.14+ <stable@vger.kernel.org> # 3.14+ Signed-off-by:
-
David Härdeman authored
[ Upstream commit 4d298b85 ] commit af3a4a9b ("[media] dib0700: NEC scancode cleanup") cleaned up the NEC scancode logic but overlooked the RC5 case. This patch brings the RC5 case in line with the NEC code and makes the struct self-documenting. Signed-off-by:
David Härdeman <david@hardeman.nu> Reported-by:
David Cimbůrek <david.cimburek@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Brian Norris authored
[ Upstream commit 073db4a5 ] On A MIPS 32-cores machine a BUG_ON was triggered because some acesses to mtd->usecount were done without taking mtd_table_mutex. kernel: Call Trace: kernel: [<ffffffff80401818>] __put_mtd_device+0x20/0x50 kernel: [<ffffffff804086f4>] blktrans_release+0x8c/0xd8 kernel: [<ffffffff802577e0>] __blkdev_put+0x1a8/0x200 kernel: [<ffffffff802579a4>] blkdev_close+0x1c/0x30 kernel: [<ffffffff8022006c>] __fput+0xac/0x250 kernel: [<ffffffff80171208>] task_work_run+0xd8/0x120 kernel: [<ffffffff8012c23c>] work_notifysig+0x10/0x18 kernel: kernel: Code: 2442ffff ac8202d8 000217fe <00020336> dc820128 10400003 00000000 0040f809 00000000 kernel: ---[ end trace 080fbb4579b47a73 ]--- Fixed by taking the mutex in blktrans_open and blktrans_release. Note that this locking is already suggested in include/linux/mtd/blktrans.h: struct mtd_blktrans_ops { ... /* Called with mtd_table_mutex held; no race with add/remove */ int (*open)(struct mtd_blktrans_dev *dev); void (*release)(struct mtd_blktrans_dev *dev); ... }; But we weren't following it. Originally reported by (and patched by) Zhang and Giuseppe, independently. Improved and rewritten. Cc: stable@vger.kernel.org Reported-by:
Zhang Xingcai <zhangxingcai@huawei.com> Reported-by:
Giuseppe Cantavenera <giuseppe.cantavenera.ext@nokia.com> Tested-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Martin Sperl authored
[ Upstream commit 8e76ef88 ] Fix a race (with some kernel configurations) where a queued master->pump_messages runs and frees dummy_tx/rx before spi_unmap_msg is running (or is finished). This results in the following messages: BUG: Bad page state in process page:db7ba030 count:0 mapcount:0 mapping: (null) index:0x0 flags: 0x200(arch_1) page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set ... Reported-by:
Noralf Trønnes <noralf@tronnes.org> Suggested-by:
Martin Sperl <kernel@martin.sperl.org> Signed-off-by:
-
Dmitry Osipenko authored
[ Upstream commit 4d48edb3 ] Commit 7232398a ("ARM: tegra: Convert PMC to a driver") changed tegra_resume() location storing from late to early and, as a result, broke suspend on Tegra20. PMC scratch register 41 is used by tegra LP1 resume code for retrieving stored physical memory address of common resume function and in the same time used by tegra20_cpu_shutdown() (shared by Tegra20 cpuidle driver and platform SMP code), which is storing CPU1 "resettable" status. It implies strict order of scratch register usage, otherwise resume function address is lost on Tegra20 after disabling non-boot CPU's on suspend. Fix it by storing "resettable" status in IRAM instead of PMC scratch register. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Fixes: 7232398a (ARM: tegra: Convert PMC to a driver) Cc: <stable@vger.kernel.org> # v3.17+ Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Pawel Moll authored
[ Upstream commit a18f8e97 ] Events defined as watchpoints on nodes must have their config values converted so that they apply to the respective node's XP. The function setting new values was using wrong mask for the "port" field, resulting in corrupted value. Fixed now. Cc: stable@vger.kernel.org # 3.17+ Signed-off-by:
Pawel Moll <pawel.moll@arm.com> Signed-off-by:
-
- 03 Jul, 2015 13 commits
-
-
Mauro Carvalho Chehab authored
[ Upstream commit 82e3b88b ] The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up much more values: drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23 Cc: stable@vger.kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
[ Upstream commit d7b76c91 ] If userspace sends an invalid bandwidth, it should either return EINVAL or switch to auto mode. This driver will go past an array and program the hardware on a wrong way if this happens. Cc: stable@vger.kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
[ Upstream commit 1fa2337a ] The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up much more values: drivers/media/dvb-frontends/cx24116.c:983 cx24116_send_diseqc_msg() error: buffer overflow 'd->msg' 6 <= 23 Cc: stable@vger.kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
[ Upstream commit 12f4543f ] The maximum size for a DiSEqC command is 6, according to the userspace API. However, the code allows to write up to 7 values: drivers/media/dvb-frontends/s5h1420.c:193 s5h1420_send_master_cmd() error: buffer overflow 'cmd->msg' 6 <= 7 Cc: stable@vger.kernel.org Signed-off-by:
-
Sagi Grimberg authored
[ Upstream commit 2f1b6b7d ] When receiving a new iser connect request we serialize the pending requests by adding the newly created iser connection to the np accept list and let the login thread process the connect request one by one (np_accept_wait). In case we received a disconnect request before the iser_conn has begun processing (still linked in np_accept_list) we should detach it from the list and clean it up and not have the login thread process a stale connection. We do it only when the connection state is not already terminating (initiator driven disconnect) as this might lead us to access np_accept_mutex after the np was released in live shutdown scenarios. Signed-off-by:
Sagi Grimberg <sagig@mellanox.com> Signed-off-by:
Jenny Falkovich <jennyf@mellanox.com> Cc: stable@vger.kernel.org # 3.10+ Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
Alex Deucher authored
[ Upstream commit ebb9bf18 ] This reverts commit 7fe04d6f. Fixes some systems at the expense of others. Need to properly fix the pll divider selection. bug: https://bugzilla.kernel.org/show_bug.cgi?id=99651 Cc: stable@vger.kernel.org Signed-off-by:
-
Alex Deucher authored
[ Upstream commit 6fb3c025 ] This reverts commit a10f0df0. Fixes some systems at the expense of others. Need to properly fix the pll divider selection. bug: https://bugzilla.kernel.org/show_bug.cgi?id=99651 Cc: stable@vger.kernel.org Signed-off-by:
-
Jérôme Glisse authored
[ Upstream commit 6dfd1972 ] Laptop with Turks/Thames GPU will freeze if dpm is enabled. It seems the SMC engine is relying on some state inside the CP engine. CP needs to chew at least one packet for it to get in good state for dynamic power management. This patch simply disabled and re-enable DPM after the ring test which is enough to avoid the freeze. Signed-off-by:
Jérôme Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Jurgen Kramer authored
[ Upstream commit 3b7e5c7e ] This patch adds native DSD support for the XMOS based JLsounds I2SoverUSB board Signed-off-by:
Jurgen Kramer <gtmkramer@xs4all.nl> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Axel Lin authored
[ Upstream commit febe0696 ] Fixes: 6058bb36 'ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller' Signed-off-by:
-
Nadav Haklai authored
[ Upstream commit e96998fc ] According to the Armada 38x datasheet, the window base address registers value is set in bits [31:4] of the register and corresponds to the transaction address bits [47:20]. Therefore, the 32bit base address value should be shifted right by 20bits and left by 4bits, resulting in 16 bit shift right. The bug as not been noticed yet because if the memory available on the platform is less than 2GB, then the base address is zero. [gregory.clement@free-electrons.com: add extra-explanation] Fixes: a3464ed2 (ata: ahci_mvebu: new driver for Marvell Armada 380 AHCI interfaces) Signed-off-by:
Nadav Haklai <nadavh@marvell.com> Reviewed-by:
Omri Itach <omrii@marvell.com> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Johannes Berg authored
[ Upstream commit 9c5a18a3 ] Until recently, mac80211 overwrote all the statistics it could provide when getting called, but it now relies on the struct having been zeroed by the caller. This was always the case in nl80211, but wext used a static struct which could even cause values from one device leak to another. Using a static struct is OK (as even documented in a comment) since the whole usage of this function and its return value is always locked under RTNL. Not clearing the struct for calling the driver has always been wrong though, since drivers were free to only fill values they could report, so calling this for one device and then for another would always have leaked values from one to the other. Fix this by initializing the structure in question before the driver method call. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=99691 Cc: stable@vger.kernel.org Reported-by:
Gerrit Renker <gerrit@erg.abdn.ac.uk> Reported-by:
Alexander Kaltsas <alexkaltsas@gmail.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Gu Zheng authored
[ Upstream commit 85bd8399 ] Izumi found the following oops when hot re-adding a node: BUG: unable to handle kernel paging request at ffffc90008963690 IP: __wake_up_bit+0x20/0x70 Oops: 0000 [#1] SMP CPU: 68 PID: 1237 Comm: rs:main Q:Reg Not tainted 4.1.0-rc5 #80 Hardware name: FUJITSU PRIMEQUEST2800E/SB, BIOS PRIMEQUEST 2000 Series BIOS Version 1.87 04/28/2015 task: ffff880838df8000 ti: ffff880017b94000 task.ti: ffff880017b94000 RIP: 0010:[<ffffffff810dff80>] [<ffffffff810dff80>] __wake_up_bit+0x20/0x70 RSP: 0018:ffff880017b97be8 EFLAGS: 00010246 RAX: ffffc90008963690 RBX: 00000000003c0000 RCX: 000000000000a4c9 RDX: 0000000000000000 RSI: ffffea101bffd500 RDI: ffffc90008963648 RBP: ffff880017b97c08 R08: 0000000002000020 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a0797c73800 R13: ffffea101bffd500 R14: 0000000000000001 R15: 00000000003c0000 FS: 00007fcc7ffff700(0000) GS:ffff880874800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90008963690 CR3: 0000000836761000 CR4: 00000000001407e0 Call Trace: unlock_page+0x6d/0x70 generic_write_end+0x53/0xb0 xfs_vm_write_end+0x29/0x80 [xfs] generic_perform_write+0x10a/0x1e0 xfs_file_buffered_aio_write+0x14d/0x3e0 [xfs] xfs_file_write_iter+0x79/0x120 [xfs] __vfs_write+0xd4/0x110 vfs_write+0xac/0x1c0 SyS_write+0x58/0xd0 system_call_fastpath+0x12/0x76 Code: 5d c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 48 83 ec 20 65 48 8b 04 25 28 00 00 00 48 89 45 f8 31 c0 48 8d 47 48 <48> 39 47 48 48 c7 45 e8 00 00 00 00 48 c7 45 f0 00 00 00 00 48 RIP [<ffffffff810dff80>] __wake_up_bit+0x20/0x70 RSP <ffff880017b97be8> CR2: ffffc90008963690 Reproduce method (re-add a node):: Hot-add nodeA --> remove nodeA --> hot-add nodeA (panic) This seems an use-after-free problem, and the root cause is zone->wait_table was not set to *NULL* after free it in try_offline_node. When hot re-add a node, we will reuse the pgdat of it, so does the zone struct, and when add pages to the target zone, it will init the zone first (including the wait_table) if the zone is not initialized. The judgement of zone initialized is based on zone->wait_table: static inline bool zone_is_initialized(struct zone *zone) { return !!zone->wait_table; } so if we do not set the zone->wait_table to *NULL* after free it, the memory hotplug routine will skip the init of new zone when hot re-add the node, and the wait_table still points to the freed memory, then we will access the invalid address when trying to wake up the waiting people after the i/o operation with the page is done, such as mentioned above. Signed-off-by:
Gu Zheng <guz.fnst@cn.fujitsu.com> Reported-by:
Taku Izumi <izumi.taku@jp.fujitsu.com> Reviewed by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Tang Chen <tangchen@cn.fujitsu.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
