{"push_id":1125291257,"size":68,"distinct_size":68,"ref":"refs/heads/linux-4.1.y","head":"e429f243df2823451c92227317e5fce5f310b674","before":"648d744eff1aedea4ffe49dfca07aa465669e1f4","commits":[{"sha":"f94e3630d7cf37e59d9c8772e38d4d73fa59e59e","author":{"email":"4645f7897fd33786a2ee1264d590b3c400559d85@linuxfoundation.org","name":"Greg Kroah-Hartman"},"message":"Revert \"usb: hub: do not clear BOS field during reset device\"\n\nThis reverts commit 522dc09ca0451d118795e8a05c7b3717f3d1ad8b..\n\nTony writes:\n\nThis upstream commit is causing an oops:\nd8f00cd685f5 (\"usb: hub: do not clear BOS field during reset device\")\n\nThis patch has already been included in several -stable kernels.  Here\nare the affected kernels:\n4.5.0-rc4 (current git)\n4.4.2\n4.3.6 (currently in review)\n4.1.18\n3.18.27\n3.14.61\n\nHow to reproduce the problem:\nBoot kernel with slub debugging enabled (otherwise memory corruption\nwill cause random oopses later instead of immediately)\nPlug in USB 3.0 disk to xhci USB 3.0 port\ndd if=/dev/sdc of=/dev/null bs=65536\n(where /dev/sdc is the USB 3.0 disk)\nUnplug USB cable while dd is still going\nOops is immediate:\n\nReported-by: Tony Battersby <tonyb@cybernetics.com>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/f94e3630d7cf37e59d9c8772e38d4d73fa59e59e"},{"sha":"686b2f5895f1ae7b5891e5cba3ad78e6f3346e64","author":{"email":"e642b69ed2fc111e09ffdc37feb733a52253340d@oracle.com","name":"Sasha Levin"},"message":"stable: remove artifact created on backport\n\nI have erroneously created a copy of said file when backporting\na commit back to the tree, and have ended up commiting it.\n\nRemove it from the tree.\n\nReported-by: Jens Rottmann <Jens.Rottmann@adlinktech.com>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/686b2f5895f1ae7b5891e5cba3ad78e6f3346e64"},{"sha":"81aa039171d2efee11a93714385d8d35c5ce7665","author":{"email":"e642b69ed2fc111e09ffdc37feb733a52253340d@oracle.com","name":"Sasha Levin"},"message":"iwlwifi: pcie: lower the debug level for RSA semaphore access\n\n[ Upstream commit 9fc515bc9e735c10cd327f05c20f5ef69474188d ]\n\nIWL_INFO is not an error but still printed by default.\n\"can't access the RSA semaphore it is write protected\" seems\nworrisome but it is not really a problem.\n\nCC: <stable@vger.kernel.org> [4.1+]\nSigned-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/81aa039171d2efee11a93714385d8d35c5ce7665"},{"sha":"35d3478878eae689a9934dda6fc6f1cd55262bfd","author":{"email":"796c82e218db295aebae52e44a32471577d15e1c@rock-chips.com","name":"Sugar Zhang"},"message":"ASoC: rt5640: Correct the digital interface data select\n\n[ Upstream commit 653aa4645244042826f105aab1be3d01b3d493ca ]\n\nthis patch corrects the interface adc/dac control register definition\naccording to datasheet.\n\nSigned-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nCc: stable@vger.kernel.org\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/35d3478878eae689a9934dda6fc6f1cd55262bfd"},{"sha":"e1bab7565919a5eb4765ba26f927a17898177c04","author":{"email":"1a8531307367602b8284517edb33d53d54e5ce8e@samsung.com","name":"Krzysztof Kozlowski"},"message":"regulator: s2mps11: Fix invalid selector mask and voltages for buck9\n\n[ Upstream commit 3b672623079bb3e5685b8549e514f2dfaa564406 ]\n\nThe buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff\ninstead of 0x1f) thus reading entire register as buck9's voltage. This\neffectively caused regulator core to interpret values as higher voltages\nthan they were and then to set real voltage much lower than intended.\n\nThe buck9 provides power to other regulators, including LDO13\nand LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower\nvoltage caused SD card detection errors on Odroid XU3/XU4:\n\tmmc1: card never left busy state\n\tmmc1: error -110 whilst initialising SD card\n\nDuring driver probe the regulator core was checking whether initial\nvoltage matches the constraints. With incorrect vsel_mask of 0xff and\ndefault value of 0x50, the core interpreted this as 5 V which is outside\nof constraints (3-3.775 V). Then the regulator core was adjusting the\nvoltage to match the constraints. With incorrect vsel_mask this new\nvoltage mapped to a vere low voltage in the driver.\n\nSigned-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>\nReviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>\nTested-by: Javier Martinez Canillas <javier@osg.samsung.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/e1bab7565919a5eb4765ba26f927a17898177c04"},{"sha":"a5d2af4cf04bd0d1a6c1cb178d4673d9ca32a298","author":{"email":"e9a3fcd7365f8e6a430ada3b68b984cb4aaf0c3e@linaro.org","name":"Srinivas Kandagatla"},"message":"libahci: save port map for forced port map\n\n[ Upstream commit 2fd0f46cb1b82587c7ae4a616d69057fb9bd0af7 ]\n\nIn usecases where force_port_map is used saved_port_map is never set,\nresulting in not programming the PORTS_IMPL register as part of initial\nconfig. This patch fixes this by setting it to port_map even in case\nwhere force_port_map is used, making it more inline with other parts of\nthe code.\n\nFixes: 566d1827df2e (\"libata: disable forced PORTS_IMPL for >= AHCI 1.3\")\nCc: stable@vger.kernel.org # v4.5+\nSigned-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>\nAcked-by: Tejun Heo <tj@kernel.org>\nReviewed-by: Andy Gross <andy.gross@linaro.org>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/a5d2af4cf04bd0d1a6c1cb178d4673d9ca32a298"},{"sha":"eab51598c1b3a48f320ea66fe1e0d58b61fa6c70","author":{"email":"e9a3fcd7365f8e6a430ada3b68b984cb4aaf0c3e@linaro.org","name":"Srinivas Kandagatla"},"message":"ata: ahci-platform: Add ports-implemented DT bindings.\n\n[ Upstream commit 17dcc37e3e847bc0e67a5b1ec52471fcc6c18682 ]\n\nOn some SOCs PORTS_IMPL register value is never programmed by the\nfirmware and left at zero value. Which means that no sata ports are\navailable for software. AHCI driver used to cope up with this by\nfabricating the port_map if the PORTS_IMPL register is read zero,\nbut recent patch broke this workaround as zero value was valid for\nNVMe disks.\n\nThis patch adds ports-implemented DT bindings as workaround for this issue\nin a way that DT can can override the PORTS_IMPL register in cases where\nthe firmware did not program it already.\n\nFixes: 566d1827df2e (\"libata: disable forced PORTS_IMPL for >= AHCI 1.3\")\nCc: stable@vger.kernel.org # v4.5+\nSigned-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>\nAcked-by: Tejun Heo <tj@kernel.org>\nReviewed-by: Andy Gross <andy.gross@linaro.org>\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/eab51598c1b3a48f320ea66fe1e0d58b61fa6c70"},{"sha":"24a50739c3e4e9947f4f4a28a023c348d7bea042","author":{"email":"cbd79eb9617449d4bb49d0087b0eb70c6cf062b0@codeaurora.org","name":"Jack Pham"},"message":"regmap: spmi: Fix regmap_spmi_ext_read in multi-byte case\n\n[ Upstream commit dec8e8f6e6504aa3496c0f7cc10c756bb0e10f44 ]\n\nSpecifically for the case of reads that use the Extended Register\nRead Long command, a multi-byte read operation is broken up into\n8-byte chunks.  However the call to spmi_ext_register_readl() is\nincorrectly passing 'val_size', which if greater than 8 will\nalways fail.  The argument should instead be 'len'.\n\nFixes: c9afbb05a9ff (\"regmap: spmi: support base and extended register spaces\")\nSigned-off-by: Jack Pham <jackp@codeaurora.org>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nCc: stable@vger.kernel.org\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/24a50739c3e4e9947f4f4a28a023c348d7bea042"},{"sha":"e7e16bb686861933ff351e945432bd607fc9fa02","author":{"email":"1a8531307367602b8284517edb33d53d54e5ce8e@samsung.com","name":"Krzysztof Kozlowski"},"message":"iio: ak8975: Fix NULL pointer exception on early interrupt\n\n[ Upstream commit 07d2390e36ee5b3265e9cc8305f2a106c8721e16 ]\n\nIn certain probe conditions the interrupt came right after registering\nthe handler causing a NULL pointer exception because of uninitialized\nwaitqueue:\n\n$ udevadm trigger\ni2c-gpio i2c-gpio-1: using pins 143 (SDA) and 144 (SCL)\ni2c-gpio i2c-gpio-3: using pins 53 (SDA) and 52 (SCL)\nUnable to handle kernel NULL pointer dereference at virtual address 00000000\npgd = e8b38000\n[00000000] *pgd=00000000\nInternal error: Oops: 5 [#1] SMP ARM\nModules linked in: snd_soc_i2s(+) i2c_gpio(+) snd_soc_idma snd_soc_s3c_dma snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore ac97_bus spi_s3c64xx pwm_samsung dwc2 exynos_adc phy_exynos_usb2 exynosdrm exynos_rng rng_core rtc_s3c\nCPU: 0 PID: 717 Comm: data-provider-m Not tainted 4.6.0-rc1-next-20160401-00011-g1b8d87473b9e-dirty #101\nHardware name: SAMSUNG EXYNOS (Flattened Device Tree)\n(...)\n(__wake_up_common) from [<c0379624>] (__wake_up+0x38/0x4c)\n(__wake_up) from [<c0a41d30>] (ak8975_irq_handler+0x28/0x30)\n(ak8975_irq_handler) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140)\n(handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68)\n(handle_irq_event) from [<c0389c40>] (handle_edge_irq+0xf0/0x19c)\n(handle_edge_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34)\n(generic_handle_irq) from [<c05ee360>] (exynos_eint_gpio_irq+0x50/0x68)\n(exynos_eint_gpio_irq) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140)\n(handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68)\n(handle_irq_event) from [<c0389a70>] (handle_fasteoi_irq+0xb4/0x194)\n(handle_fasteoi_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34)\n(generic_handle_irq) from [<c03860b4>] (__handle_domain_irq+0x5c/0xb4)\n(__handle_domain_irq) from [<c0301774>] (gic_handle_irq+0x54/0x94)\n(gic_handle_irq) from [<c030c910>] (__irq_usr+0x50/0x80)\n\nThe bug was reproduced on exynos4412-trats2 (with a max77693 device also\nusing i2c-gpio) after building max77693 as a module.\n\nCc: <stable@vger.kernel.org>\nFixes: 94a6d5cf7caa (\"iio:ak8975 Implement data ready interrupt handling\")\nSigned-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>\nTested-by: Gregor Boirie <gregor.boirie@parrot.com>\nSigned-off-by: Jonathan Cameron <jic23@kernel.org>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/e7e16bb686861933ff351e945432bd607fc9fa02"},{"sha":"83619523130164cb525e35b6001755cd185055fb","author":{"email":"7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com","name":"Laszlo Ersek"},"message":"efi: Fix out-of-bounds read in variable_matches()\n\n[ Upstream commit 630ba0cc7a6dbafbdee43795617c872b35cde1b4 ]\n\nThe variable_matches() function can currently read \"var_name[len]\", for\nexample when:\n\n - var_name[0] == 'a',\n - len == 1\n - match_name points to the NUL-terminated string \"ab\".\n\nThis function is supposed to accept \"var_name\" inputs that are not\nNUL-terminated (hence the \"len\" parameter\"). Document the function, and\naccess \"var_name[*match]\" only if \"*match\" is smaller than \"len\".\n\nReported-by: Chris Wilson <chris@chris-wilson.co.uk>\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>\nCc: Peter Jones <pjones@redhat.com>\nCc: Matthew Garrett <mjg59@coreos.com>\nCc: Jason Andryuk <jandryuk@gmail.com>\nCc: Jani Nikula <jani.nikula@linux.intel.com>\nCc: <stable@vger.kernel.org> # v3.10+\nLink: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/86906\nSigned-off-by: Matt Fleming <matt@codeblueprint.co.uk>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/83619523130164cb525e35b6001755cd185055fb"},{"sha":"35f45c8a07dbc749e3b0602f1d6def24ee8cc657","author":{"email":"17b9e1c64588c7fa6419b4d29dc1f4426279ba01@bsch.com.au","name":"Mike Manning"},"message":"USB: serial: cp210x: add ID for Link ECU\n\n[ Upstream commit 1d377f4d690637a0121eac8701f84a0aa1e69a69 ]\n\nThe Link ECU is an aftermarket ECU computer for vehicles that provides\nfull tuning abilities as well as datalogging and displaying capabilities\nvia the USB to Serial adapter built into the device.\n\nSigned-off-by: Mike Manning <michael@bsch.com.au>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Johan Hovold <johan@kernel.org>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/35f45c8a07dbc749e3b0602f1d6def24ee8cc657"},{"sha":"b4782b68dbabd15982bb417d1e75bdd36c4eefc6","author":{"email":"20afd2fb0e02429b9001da5878965a4ca5c8c7af@ikarustech.com","name":"Jasem Mutlaq"},"message":"USB: serial: cp210x: add Straizona Focusers device ids\n\n[ Upstream commit 613ac23a46e10d4d4339febdd534fafadd68e059 ]\n\nAdding VID:PID for Straizona Focusers to cp210x driver.\n\nSigned-off-by: Jasem Mutlaq <mutlaqja@ikarustech.com>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Johan Hovold <johan@kernel.org>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/b4782b68dbabd15982bb417d1e75bdd36c4eefc6"},{"sha":"4f1948989e9af00623bb23d321cae7bd4792002e","author":{"email":"f625be9dbdcbbd12a043857af148e8fb895d9a1d@xs4all.nl","name":"Hans Verkuil"},"message":"[media] v4l2-dv-timings.h: fix polarity for 4k formats\n\n[ Upstream commit 3020ca711871fdaf0c15c8bab677a6bc302e28fe ]\n\nThe VSync polarity was negative instead of positive for the 4k CEA formats.\nI probably copy-and-pasted these from the DMT 4k format, which does have a\nnegative VSync polarity.\n\nSigned-off-by: Hans Verkuil <hans.verkuil@cisco.com>\nReported-by: Martin Bugge <marbugge@cisco.com>\nCc: <stable@vger.kernel.org>      # for v4.1 and up\nSigned-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/4f1948989e9af00623bb23d321cae7bd4792002e"},{"sha":"cdfac06ee2d5aabbe89724c6a4a3fbb1148fcc7a","author":{"email":"c0c0c8857ed6ec93282de3ee9d47e224acf995af@fb.com","name":"Shaohua Li"},"message":"MD: make bio mergeable\n\n[ Upstream commit 9c573de3283af007ea11c17bde1e4568d9417328 ]\n\nblk_queue_split marks bio unmergeable, which makes sense for normal bio.\nBut if dispatching the bio to underlayer disk, the blk_queue_split\nchecks are invalid, hence it's possible the bio becomes mergeable.\n\nIn the reported bug, this bug causes trim against raid0 performance slash\nhttps://bugzilla.kernel.org/show_bug.cgi?id=117051\n\nReported-and-tested-by: Park Ju Hyung <qkrwngud825@gmail.com>\nFixes: 6ac45aeb6bca(block: avoid to merge splitted bio)\nCc: stable@vger.kernel.org (v4.3+)\nCc: Ming Lei <ming.lei@canonical.com>\nCc: Neil Brown <neilb@suse.de>\nReviewed-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: Shaohua Li <shli@fb.com>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/cdfac06ee2d5aabbe89724c6a4a3fbb1148fcc7a"},{"sha":"2519c9fc644c0fc14c54518bab9440765e0ea99a","author":{"email":"1442a6c14b8a3ca4f3871460b6fe539768980294@bl4ckb0x.de","name":"Conrad Kostecki"},"message":"ALSA: hda - Add dock support for ThinkPad X260\n\n[ Upstream commit 037e119738120c1cdc460c6ae33871c3000531f3 ]\n\nFixes audio output on a ThinkPad X260, when using Lenovo CES 2013\ndocking station series (basic, pro, ultra).\n\nSigned-off-by: Conrad Kostecki <ck+linuxkernel@bl4ckb0x.de>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/2519c9fc644c0fc14c54518bab9440765e0ea99a"},{"sha":"14794cfb6c9bcca151dbe940f3d7b9f9f818499f","author":{"email":"dbfa0240d5f642b4c1caf29a6c9a7befb57d96a6@profitbricks.com","name":"Roman Pen"},"message":"workqueue: fix ghost PENDING flag while doing MQ IO\n\n[ Upstream commit 346c09f80459a3ad97df1816d6d606169a51001a ]\n\nThe bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list\nwith the following backtrace:\n\n[  601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds.\n[  601.347574]       Tainted: G           O    4.4.5-1-storage+ #6\n[  601.347651] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[  601.348142] kworker/u129:5  D ffff880803077988     0  1636      2 0x00000000\n[  601.348519] Workqueue: ibnbd_server_fileio_wq ibnbd_dev_file_submit_io_worker [ibnbd_server]\n[  601.348999]  ffff880803077988 ffff88080466b900 ffff8808033f9c80 ffff880803078000\n[  601.349662]  ffff880807c95000 7fffffffffffffff ffffffff815b0920 ffff880803077ad0\n[  601.350333]  ffff8808030779a0 ffffffff815b01d5 0000000000000000 ffff880803077a38\n[  601.350965] Call Trace:\n[  601.351203]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60\n[  601.351444]  [<ffffffff815b01d5>] schedule+0x35/0x80\n[  601.351709]  [<ffffffff815b2dd2>] schedule_timeout+0x192/0x230\n[  601.351958]  [<ffffffff812d43f7>] ? blk_flush_plug_list+0xc7/0x220\n[  601.352208]  [<ffffffff810bd737>] ? ktime_get+0x37/0xa0\n[  601.352446]  [<ffffffff815b0920>] ? bit_wait+0x60/0x60\n[  601.352688]  [<ffffffff815af784>] io_schedule_timeout+0xa4/0x110\n[  601.352951]  [<ffffffff815b3a4e>] ? _raw_spin_unlock_irqrestore+0xe/0x10\n[  601.353196]  [<ffffffff815b093b>] bit_wait_io+0x1b/0x70\n[  601.353440]  [<ffffffff815b056d>] __wait_on_bit+0x5d/0x90\n[  601.353689]  [<ffffffff81127bd0>] wait_on_page_bit+0xc0/0xd0\n[  601.353958]  [<ffffffff81096db0>] ? autoremove_wake_function+0x40/0x40\n[  601.354200]  [<ffffffff81127cc4>] __filemap_fdatawait_range+0xe4/0x140\n[  601.354441]  [<ffffffff81127d34>] filemap_fdatawait_range+0x14/0x30\n[  601.354688]  [<ffffffff81129a9f>] filemap_write_and_wait_range+0x3f/0x70\n[  601.354932]  [<ffffffff811ced3b>] blkdev_fsync+0x1b/0x50\n[  601.355193]  [<ffffffff811c82d9>] vfs_fsync_range+0x49/0xa0\n[  601.355432]  [<ffffffff811cf45a>] blkdev_write_iter+0xca/0x100\n[  601.355679]  [<ffffffff81197b1a>] __vfs_write+0xaa/0xe0\n[  601.355925]  [<ffffffff81198379>] vfs_write+0xa9/0x1a0\n[  601.356164]  [<ffffffff811c59d8>] kernel_write+0x38/0x50\n\nThe underlying device is a null_blk, with default parameters:\n\n  queue_mode    = MQ\n  submit_queues = 1\n\nVerification that nullb0 has something inflight:\n\nroot@pserver8:~# cat /sys/block/nullb0/inflight\n       0        1\nroot@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec cat {} \\;\n...\n/sys/block/nullb0/mq/0/cpu2/rq_list\nCTX pending:\n        ffff8838038e2400\n...\n\nDuring debug it became clear that stalled request is always inserted in\nthe rq_list from the following path:\n\n   save_stack_trace_tsk + 34\n   blk_mq_insert_requests + 231\n   blk_mq_flush_plug_list + 281\n   blk_flush_plug_list + 199\n   wait_on_page_bit + 192\n   __filemap_fdatawait_range + 228\n   filemap_fdatawait_range + 20\n   filemap_write_and_wait_range + 63\n   blkdev_fsync + 27\n   vfs_fsync_range + 73\n   blkdev_write_iter + 202\n   __vfs_write + 170\n   vfs_write + 169\n   kernel_write + 56\n\nSo blk_flush_plug_list() was called with from_schedule == true.\n\nIf from_schedule is true, that means that finally blk_mq_insert_requests()\noffloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue,\ni.e. it calls kblockd_schedule_delayed_work_on().\n\nThat means, that we race with another CPU, which is about to execute\n__blk_mq_run_hw_queue() work.\n\nFurther debugging shows the following traces from different CPUs:\n\n  CPU#0                                  CPU#1\n  ----------------------------------     -------------------------------\n  reqeust A inserted\n  STORE hctx->ctx_map[0] bit marked\n  kblockd_schedule...() returns 1\n  <schedule to kblockd workqueue>\n                                         request B inserted\n                                         STORE hctx->ctx_map[1] bit marked\n                                         kblockd_schedule...() returns 0\n  *** WORK PENDING bit is cleared ***\n  flush_busy_ctxs() is executed, but\n  bit 1, set by CPU#1, is not observed\n\nAs a result request B pended forever.\n\nThis behaviour can be explained by speculative LOAD of hctx->ctx_map on\nCPU#0, which is reordered with clear of PENDING bit and executed _before_\nactual STORE of bit 1 on CPU#1.\n\nThe proper fix is an explicit full barrier <mfence>, which guarantees\nthat clear of PENDING bit is to be executed before all possible\nspeculative LOADS or STORES inside actual work function.\n\nSigned-off-by: Roman Pen <roman.penyaev@profitbricks.com>\nCc: Gioh Kim <gi-oh.kim@profitbricks.com>\nCc: Michael Wang <yun.wang@profitbricks.com>\nCc: Tejun Heo <tj@kernel.org>\nCc: Jens Axboe <axboe@kernel.dk>\nCc: linux-block@vger.kernel.org\nCc: linux-kernel@vger.kernel.org\nCc: stable@vger.kernel.org\nSigned-off-by: Tejun Heo <tj@kernel.org>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/14794cfb6c9bcca151dbe940f3d7b9f9f818499f"},{"sha":"85489830a875eee4c5357b2ffa217f06676c1211","author":{"email":"e85aef63a1a9803b668741313e484162be52f7bd@redhat.com","name":"cpaul@redhat.com"},"message":"drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1()\n\n[ Upstream commit 263efde31f97c498e1ebad30e4d2906609d7ad6b ]\n\nWe can thank KASAN for finding this, otherwise I probably would have spent\nhours on it. This fixes a somewhat harder to trigger kernel panic, occuring\nwhile enabling MST where the port we were currently updating the payload on\nwould have all of it's refs dropped before we finished what we were doing:\n\n==================================================================\nBUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018\nRead of size 4 by task Xorg/973\n=============================================================================\nBUG kmalloc-2048 (Tainted: G    B   W      ): kasan: bad access detected\n-----------------------------------------------------------------------------\n\nINFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175\n\t___slab_alloc+0x472/0x490\n\t__slab_alloc+0x20/0x40\n\tkmem_cache_alloc_trace+0x151/0x190\n\tdrm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper]\n\tdrm_dp_send_link_address+0x526/0x960 [drm_kms_helper]\n\tdrm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper]\n\tdrm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper]\n\tprocess_one_work+0x562/0x1350\n\tworker_thread+0xd9/0x1390\n\tkthread+0x1c5/0x260\n\tret_from_fork+0x22/0x40\nINFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175\n\t__slab_free+0x17f/0x2d0\n\tkfree+0x169/0x180\n\tdrm_dp_free_mst_port+0x50/0x60 [drm_kms_helper]\n\tdrm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper]\n\tprocess_one_work+0x562/0x1350\n\tworker_thread+0xd9/0x1390\n\tkthread+0x1c5/0x260\n\tret_from_fork+0x22/0x40\n\nwhich on this T460s, would eventually lead to kernel panics in somewhat\nrandom places later in intel_mst_enable_dp() if we got lucky enough.\n\nSigned-off-by: Lyude <cpaul@redhat.com>\nCc: stable@vger.kernel.org\nSigned-off-by: Dave Airlie <airlied@redhat.com>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/85489830a875eee4c5357b2ffa217f06676c1211"},{"sha":"b61a5d5456479618426d25bec4175c011bcc9726","author":{"email":"e85aef63a1a9803b668741313e484162be52f7bd@redhat.com","name":"Lyude"},"message":"drm/dp/mst: Restore primary hub guid on resume\n\n[ Upstream commit 9dc0487d96a0396367a1451b31873482080b527f ]\n\nSome hubs are forgetful, and end up forgetting whatever GUID we set\npreviously after we do a suspend/resume cycle. This can lead to\nhotplugging breaking (along with probably other things) since the hub\nwill start sending connection notifications with the wrong GUID. As\nsuch, we need to check on resume whether or not the GUID the hub is\ngiving us is valid.\n\nSigned-off-by: Lyude <cpaul@redhat.com>\nReviewed-by: Harry Wentland <harry.wentland@amd.com>\nSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>\nLink: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com\nCc: stable@vger.kernel.org\nSigned-off-by: Dave Airlie <airlied@redhat.com>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/b61a5d5456479618426d25bec4175c011bcc9726"},{"sha":"86128809b5bf37d75b6bee83d0e83a32f9a80673","author":{"email":"7b0ab45a730e48a69239010b5b8fe5fa4e8eaac6@neuling.org","name":"Michael Neuling"},"message":"cxl: Keep IRQ mappings on context teardown\n\n[ Upstream commit d6776bba44d9752f6cdf640046070e71ee4bba7b ]\n\nKeep IRQ mappings on context teardown.  This won't leak IRQs as if we\nallocate the mapping again, the generic code will give the same\nmapping used last time.\n\nDoing this works around a race in the generic code. Masking the\ninterrupt introduces a race which can crash the kernel or result in\nIRQ that is never EOIed. The lost of EOI results in all subsequent\nmappings to the same HW IRQ never receiving an interrupt.\n\nWe've seen this race with cxl test cases which are doing heavy context\nstartup and teardown at the same time as heavy interrupt load.\n\nA fix to the generic code is being investigated also.\n\nSigned-off-by: Michael Neuling <mikey@neuling.org>\nCc: stable@vger.kernel.org # 3.8\nTested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>\nAcked-by: Ian Munsie <imunsie@au1.ibm.com>\nTested-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>\nSigned-off-by: Michael Ellerman <mpe@ellerman.id.au>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/86128809b5bf37d75b6bee83d0e83a32f9a80673"},{"sha":"39161f8ab357bc5e13eca3a04828cb7aecab0f9d","author":{"email":"fbd5edba1988036c8923f0cca0cce6ac4811db29@intel.com","name":"Imre Deak"},"message":"drm/i915/ddi: Fix eDP VDD handling during booting and suspend/resume\n\n[ Upstream commit 5eaa60c7109b40f17ac81090bc8b90482da76cd1 ]\n\nThe driver's VDD on/off logic assumes that whenever the VDD is on we\nalso hold an AUX power domain reference. Since BIOS can leave the VDD on\nduring booting and resuming and on DDI platforms we won't take a\ncorresponding power reference, the above assumption won't hold on those\nplatforms and an eventual delayed VDD off work will do an extraneous AUX\npower domain put resulting in a refcount underflow. Fix this the same\nway we did this for non-DDI DP encoders:\n\ncommit 6d93c0c41760c0 (\"drm/i915: fix VDD state tracking after system\nresume\")\n\nAt the same time call the DP encoder suspend handler the same way as the\nnon-DDI DP encoders do to flush any pending VDD off work. Leaving the\nwork running may cause a HW access where we don't expect this (at a point\nwhere power domains are suspended already).\n\nWhile at it remove an unnecessary function call indirection.\n\nThis fixed for me AUX refcount underflow problems on BXT during\nsuspend/resume.\n\nCC: Ville Syrjälä <ville.syrjala@linux.intel.com>\nCC: stable@vger.kernel.org\nSigned-off-by: Imre Deak <imre.deak@intel.com>\nReviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>\nLink: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-4-git-send-email-imre.deak@intel.com\n(cherry picked from commit bf93ba67e9c05882f05b7ca2d773cfc8bf462c2a)\nSigned-off-by: Jani Nikula <jani.nikula@intel.com>\nSigned-off-by: Sasha Levin <sasha.levin@oracle.com>","distinct":true,"url":"https://api.github.com/repos/Noltari/linux/commits/39161f8ab357bc5e13eca3a04828cb7aecab0f9d"}]}
{"actor":{"display_login":"Noltari"}}