- 20 Oct, 2016 6 commits
-
-
Konstantin Khlebnikov authored
BugLink: http://bugs.launchpad.net/bugs/1627730 commit adb7ef60 upstream. This might be unexpected but pages allocated for sbi->s_buddy_cache are charged to current memory cgroup. So, GFP_NOFS allocation could fail if current task has been killed by OOM or if current memory cgroup has no free memory left. Block allocator cannot handle such failures here yet. Signed-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: Jan Kara <jack@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com>
-
Li Zhong authored
BugLink: http://bugs.launchpad.net/bugs/1613295 walk.iv is not assigned a value in blkcipher_walk_init. It makes iv uninitialized. It is possibly a null value(as shown below), which is then used by aes_p8_encrypt. This patch moves iv = walk.iv after blkcipher_walk_virt, in which walk.iv is set. [17856.268050] Unable to handle kernel paging request for data at address 0x00000000 [17856.268212] Faulting instruction address: 0xd000000002ff04bc 7:mon> t [link register ] d000000002ff47b8 p8_aes_xts_crypt+0x168/0x2a0 [vmx_crypto] (938) [c000000013b77960] d000000002ff4794 p8_aes_xts_crypt+0x144/0x2a0 [vmx_crypto] (unreliable) [c000000013b77a70] c000000000544d64 skcipher_decrypt_blkcipher+0x64/0x80 [c000000013b77ac0] d000000003c0175c crypt_convert+0x53c/0x620 [dm_crypt] [c000000013b77ba0] d000000003c043fc kcryptd_crypt+0x3cc/0x440 [dm_crypt] [c000000013b77c50] c0000000000f3070 process_one_work+0x1e0/0x590 [c000000013b77ce0] c0000000000f34c8 worker_thread+0xa8/0x660 [c000000013b77d80] c0000000000fc0b0 kthread+0x110/0x130 [c000000013b77e30] c0000000000098f0 ret_from_kernel_thread+0x5c/0x6c Signed-off-by:
Li Zhong <zhong@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> (cherry picked from commit 901d3d4f) Signed-off-by:
Chris J Arges <chris.j.arges@canonical.com> Acked-by:
Colin King <colin.king@canonical.com>
-
Tushar Dave authored
BugLink: http://bugs.launchpad.net/bugs/1626782 On systems with 128 CPUs, turning off TSO results in errors, i40e 0000:03:00.0: failed to get tracking for 1 vectors for VSI 400, err=-12 i40e 0000:03:00.0: Couldn't create FDir VSI i40e 0000:03:00.0: i40e_ptp_init: PTP not supported on eth0 i40e 0000:03:00.0: couldn't add VEB, err I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_ENOENT i40e 0000:03:00.0: rebuild of switch failed: -1, will try to set up simple PF connection i40e 0000:03:00.0 eth0: adding 00:10:e0:8a:24:b6 vid=0 Enabling FD_SB without checking availability of MSI-X vector is the root cause. This change adds necessary check. Signed-off-by:
Tushar Dave <tushar.n.dave@oracle.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit a70e407f) Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Wei Yongjun authored
BugLink: http://bugs.launchpad.net/bugs/1626222 Since we will remove items off the list using list_del() we need to use a safe version of the list_for_each() macro aptly named list_for_each_safe(). Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 96183182) Signed-off-by:
-
Tyrel Datwyler authored
BugLink: http://bugs.launchpad.net/bugs/1625986 The underlying slot hotplug registration code assumed multiple slots, but the actual implementation is broken for multiple slots. This went unnoticed for years do to the fact that PowerVM seems to only ever provide a single hotplug slot per PHB. Under qemu/kvm the hotplug slot model aligns more with x86 where multiple slots are presented under a single PHB. As seen in the following each additional slot after the first fails to register due to each slot always being compared against the first child node of the PHB in the device tree. rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 rpaphp: Slot [Slot 0] registered rpaphp: pci_hp_register failed with error -16 rpaphp: pci_hp_register failed with error -16 rpaphp: pci_hp_register failed with error -16 rpaphp: pci_hp_register failed with error -16 The registration logic is fixed so that each slot is compared against the existing child devices of the PHB in the device tree to determine present slots vs empty slots. rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1 rpaphp: Slot [C0] registered rpaphp: Slot [C1] registered rpaphp: Slot [C2] registered rpaphp: Slot [C3] registered rpaphp: Slot [C4] registered Signed-off-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Reviewed-by:
Nathan Fontenot <nfont@linux.vnet.ibm.com> [mpe: Massage changelog] Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit e2413a7d) Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1628520 Commit 5706aca74fe4 ("NVMe: Don't unmap controller registers on reset"), which backported b00a726a to the 4.4.y kernel introduced a regression in which it didn't call pci_disable_device in the error path of nvme_pci_enable. Reported-by:
Jiri Slaby <jslaby@suse.cz> Embarassed-developer: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Signed-off-by:
-
- 19 Oct, 2016 4 commits
-
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1611078 This reverts commit 63f6655e, which is superseded by later patches. Signed-off-by:
-
Seth Forshee authored
Ignore: yes Signed-off-by: -
Stefan Bader authored
Signed-off-by: -
John Johansen authored
path_put() call dput() which might sleep on some paths. When it does sleep from these code paths, the per cpu work buffer may get reused overwriting the data that was just placed in the buffer. This causes the following mediation to fail as the work buffer no longer has valid data for the current operation. BugLink: http://bugs.launchpad.net/bugs/1634753Signed-off-by:
John Johansen <john.johansen@canonical.com> Acked-by:
Andy Whitcroft <andy.whitcroft@canonical.com> Signed-off-by:
-
- 18 Oct, 2016 1 commit
-
-
Linus Torvalds authored
This is an ancient bug that was actually attrempted to be fixed once (badly) by me eleven years ago in commit 4ceb5db9 ("Fix get_user_pages() race for write access") but that was then undone due to problems on s390 by commit f33ea7f4 ("fix get_user_pages bug"). In the meantime, the s390 situation has long been fixed, and we can once more try to fix it by checking the pte_dirty() bit properly (and do it better). Also, the VM has become more scalable, and what was a purely theoretical race back then has become easier to trigger. To fix it, we introduce a new internal FOLL_COW flag to mark the "yes, we already did a COW" rather than play racy games with FOLL_WRITE that is very fundamental, and then use the pte dirty flag to validate that the FOLL_COW flag is still valid. Reported-and-tested-by:
Phil "not Paul" Oester <kernel@linuxace.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Andy Lutomirski <luto@kernel.org> Cc: Kees Cook <keescook@chromium.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Willy Tarreau <w@1wt.eu> Acked-by:
Hugh Dickins <hughd@google.com> Cc: Nick Piggin <npiggin@gmail.com> Cc: Greg Thelen <gthelen@google.com> Cc: stable@vger.kernel.org Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> CVE-2016-5195 [ saf: Adjust context for missing FOLL_REMOTE ] Signed-off-by:
-
- 17 Oct, 2016 1 commit
-
-
Stefan Bader authored
Ignore: yes Signed-off-by:
-
- 12 Oct, 2016 2 commits
-
-
Seth Forshee authored
Signed-off-by: -
Gavin Guo authored
BugLink: http://bugs.launchpad.net/bugs/1518457 On an AWS t2.micro instance (Xeon E5-2670, 991MiB of memory). Occasionally (about once a day), kswapd0 falls into a busy loop and spins on 100% CPU usage indefinitely. Reject to do the zone balance when the memory is too small. Signed-off-by:
Dan Streetman <dan.streetman@canonical.com> Signed-off-by:
Gavin Guo <gavin.guo@canonical.com> Tested-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Acked-by:
Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
- 11 Oct, 2016 1 commit
-
-
Seth Forshee authored
Ignore: yes Signed-off-by:
-
- 07 Oct, 2016 4 commits
-
-
Seth Forshee authored
Signed-off-by: -
Sabrina Dubroca authored
BugLink: http://bugs.launchpad.net/bugs/1631287 Currently, GRO can do unlimited recursion through the gro_receive handlers. This was fixed for tunneling protocols by limiting tunnel GRO to one level with encap_mark, but both VLAN and TEB still have this problem. Thus, the kernel is vulnerable to a stack overflow, if we receive a packet composed entirely of VLAN headers. This patch adds a recursion counter to the GRO layer to prevent stack overflow. When a gro_receive function hits the recursion limit, GRO is aborted for this skb and it is processed normally. Fixes: 9b174d88 ("net: Add Transparent Ethernet Bridging GRO support.") Fixes: 66e5133f ("vlan: Add GRO support for non hardware accelerated vlan") Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Reviewed-by:
Jiri Benc <jbenc@redhat.com> Acked-by:
Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
Steve Beattie <steve.beattie@canonical.com> [ saf: backported to xenial - Fix up gro_receive callback invocation in udb_gro_receive() - Adjust context ] CVE-2016-7039 Acked-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1631287 This patch should fix the issues seen with a recent fix to prevent tunnel-in-tunnel frames from being generated with GRO. The fix itself is correct for now as long as we do not add any devices that support NETIF_F_GSO_GRE_CSUM. When such a device is added it could have the potential to mess things up due to the fact that the outer transport header points to the outer UDP header and not the GRE header as would be expected. Fixes: fac8e0f5 ("tunnels: Don't apply GRO to multiple layers of encapsulation.") Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Signed-off-by:
-
Jesse Gross authored
BugLink: http://bugs.launchpad.net/bugs/1631287 When drivers express support for TSO of encapsulated packets, they only mean that they can do it for one layer of encapsulation. Supporting additional levels would mean updating, at a minimum, more IP length fields and they are unaware of this. No encapsulation device expresses support for handling offloaded encapsulated packets, so we won't generate these types of frames in the transmit path. However, GRO doesn't have a check for multiple levels of encapsulation and will attempt to build them. UDP tunnel GRO actually does prevent this situation but it only handles multiple UDP tunnels stacked on top of each other. This generalizes that solution to prevent any kind of tunnel stacking that would cause problems. Fixes: bf5a755f ("net-gre-gro: Add GRE support to the GRO stack") Signed-off-by:
Jesse Gross <jesse@kernel.org> Signed-off-by:
-
- 28 Sep, 2016 1 commit
-
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 27 Sep, 2016 2 commits
-
-
Kamal Mostafa authored
Signed-off-by: -
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1626894 Commit b00a726a upstream. Fix nvme_pci_enable missing initializer accidentally omitted from Xenial backport of 30d6592f "NVMe: Don't unmap controller registers on reset" (and homogenize comment lines with the 4.4.y-stable tree). Signed-off-by:
-
- 26 Sep, 2016 1 commit
-
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 23 Sep, 2016 4 commits
-
-
Kamal Mostafa authored
Signed-off-by: -
Sachin Prabhu authored
BugLink: http://bugs.launchpad.net/bugs/1626112 Patch a6b5058f results in -EREMOTE returned by is_path_accessible() in cifs_mount() to be ignored which breaks DFS mounting. Signed-off-by:
Sachin Prabhu <sprabhu@redhat.com> Reviewed-by:
Aurelien Aptel <aaptel@suse.com> CC: Stable <stable@vger.kernel.org> Signed-off-by:
Steve French <smfrench@gmail.com> (cherry picked from commit de5233745cd59cf5853d963ad216067788a87594 git://git.samba.org/sfrench/cifs-2.6.git) Signed-off-by:
-
Sachin Prabhu authored
BugLink: http://bugs.launchpad.net/bugs/1626112 The patch fs/cifs: make share unaccessible at root level mountable makes use of prepaths when any component of the underlying path is inaccessible. When mounting 2 separate shares having different prepaths but are other wise similar in other respects, we end up sharing superblocks when we shouldn't be doing so. Signed-off-by:
-
Sachin Prabhu authored
BugLink: http://bugs.launchpad.net/bugs/1626112 Fix memory leaks introduced by the patch fs/cifs: make share unaccessible at root level mountable Also move allocation of cifs_sb->prepath to cifs_setup_cifs_sb(). Signed-off-by:
-
- 22 Sep, 2016 3 commits
-
-
Shawn Lee authored
UBUNTU: SAUCE: i915_bpo: drm/i915/backlight: setup backlight pwm alternate increment on backlight enable BugLink: http://bugs.launchpad.net/bugs/1625932 Backlight enable is supposed to do a full setup of the backlight. We were missing the PWM alternate increment bit in the south chicken registers on lpt+ pch. This potentially caused a PWM frequency change when the chicken register value was lost e.g. on suspend. v2 by Jani, rebase on the patch caching alt increment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 References: https://bugs.freedesktop.org/show_bug.cgi?id=67454 Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Wei Shun Chen <wei.shun.chang@intel.com> Cc: Gary C Wang <gary.c.wang@intel.com> Cc: stable@vger.kernel.org # v4.4+ 32b421e7 drm/i915/backlight: setup and cache... Cc: stable@vger.kernel.org # v4.4+ Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Shawn Lee <shawn.c.lee@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/8265f5935bd31c039ddfc82819d26c2ca1ae9cba.1474281249.git.jani.nikula@intel.com (cherry-picked from drm-intel-next-queued commit e29aff05) Signed-off-by:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
Jani Nikula authored
BugLink: http://bugs.launchpad.net/bugs/1625932 This will also be needed later on when setting up the alternate increment in backlight enable. Cc: Shawn Lee <shawn.c.lee@intel.com> Reviewed-by:
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 20 Sep, 2016 1 commit
-
-
Joseph Salisbury authored
Signed-off-by:Joseph Salisbury <joseph.salisbury@canonical.com>
-
- 19 Sep, 2016 9 commits
-
-
Sunil Goutham authored
BugLink: http://bugs.launchpad.net/bugs/1624569 On ThunderX 88xx pass 2.x chips when TSO is offloaded to HW, HW posts a CQE for every TSO segment transmitted. Current code does handles this, but is prone to issues when segment sizes are small resulting in SW processing too many CQEs and also at times frees a SKB which is not yet transmitted. This patch handles the errata in a different way and eliminates issues with earlier approach, TSO packet is submitted to HW with post_cqe=0, so that no CQE is posted upon completion of transmission of TSO packet but a additional HDR + IMMEDIATE descriptors are added to SQ due to which a CQE is posted and will have required info to be used while cleanup in napi. This way only one CQE is posted for a TSO packet. Signed-off-by:
Sunil Goutham <sgoutham@cavium.com> Signed-off-by:
dann frazier <dann.frazier@canonical.com> Acked-by:
-
Sunil Goutham authored
BugLink: http://bugs.launchpad.net/bugs/1623627 There is a issue in HW where-in while sending GSO sized pkts as part of TSO, if pkt len falls below configured min packet size i.e 60, NIC will zero PAD packet and also updates IP total length. Hence set this value to lessthan min pkt size of MAC + IP + TCP headers, BGX will anyway do the padding to transmit 64 byte pkt including FCS. Signed-off-by:
-
Eric Dumazet authored
When tcp_sendmsg() allocates a fresh and empty skb, it puts it at the tail of the write queue using tcp_add_write_queue_tail() Then it attempts to copy user data into this fresh skb. If the copy fails, we undo the work and remove the fresh skb. Unfortunately, this undo lacks the change done to tp->highest_sack and we can leave a dangling pointer (to a freed skb) Later, tcp_xmit_retransmit_queue() can dereference this pointer and access freed memory. For regular kernels where memory is not unmapped, this might cause SACK bugs because tcp_highest_sack_seq() is buggy, returning garbage instead of tp->snd_nxt, but with various debug features like CONFIG_DEBUG_PAGEALLOC, this can crash the kernel. This bug was found by Marco Grassi thanks to syzkaller. Fixes: 6859d494 ("[TCP]: Abstract tp->highest_sack accessing & point to next skb") Reported-by:
Marco Grassi <marco.gra@gmail.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Cc: Yuchung Cheng <ycheng@google.com> Cc: Neal Cardwell <ncardwell@google.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Reviewed-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com> Acked-by:
-
David Britton authored
BugLink: http://bugs.launchpad.net/bugs/1622763 This USB headset doesn't seem to support sample rate polling, similar to this issue: https://bugzilla.kernel.org/show_bug.cgi?id=95961 Every time something goes to interact with the device (playing a sound file, opening the sound panel, opening web audio/video), a 10 second pause is encountered, where dmesg prints out two messages: usb 2-1.2: 2:1: cannot get freq at ep 0x83 usb 2-1.2: 2:1: cannot get freq at ep 0x83 Once the sound is playing, everything is fine. These sample rate polls don't seem to keep happening. After waiting for maybe 30 seconds after sound is playing, future interactions will again trigger the pause. This 10 second pause can introduce other subtle problems. For instance, google hangouts will sometimes timeout waiting for the sound device to respond, and the browser tab will crash or not fully load as a result. The sound panel often also will not display the device in the list of choices, and you will have to close it out. Sometimes restart pulse audio to get it to recognize the headset again. Signed-off-by:
-
Jason Baron authored
BugLink: http://bugs.launchpad.net/bugs/1619766 Skylake adjusts some register locations, but otherwise follows the existing model quite closely. I was able to verify that the 'ce_count' increments when 'bad dimms' are used. The accounting of 'ce_count' and 'ue_count' is the primary functionality of interest for us. Tested on Intel(R) Xeon(R) CPU E3-1260L v5 @ 2.90GHz. Signed-off-by:
Jason Baron <jbaron@akamai.com> Acked-by:
Tony Luck <tony.luck@intel.com> Cc: linux-edac <linux-edac@vger.kernel.org> Link: http://lkml.kernel.org/r/1462547927-22679-1-git-send-email-jbaron@akamai.comSigned-off-by:
Borislav Petkov <bp@suse.de> (cherry picked from commit 953dee9b) Signed-off-by:
-
Gabriel Krisman Bertazi authored
Pending 4.8-rc merge. BugLink: http://bugs.launchpad.net/bugs/1602724 This fixes a regression in my previous commit c21377f8 ("nvme: Suspend all queues before deletion"), which provoked an Oops in the removal path when removing a device that became IO incapable very early at probe (i.e. after a failed EEH recovery). Turns out, if the error occurred very early at the probe path, before even configuring the admin queue, we might try to suspend the uninitialized admin queue, accessing bad memory. Fixes: c21377f8 ("nvme: Suspend all queues before deletion") Signed-off-by:
Jay Freyensee <james_p_freyensee@linux.intel.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Jens Axboe authored
BugLink: http://bugs.launchpad.net/bugs/1620317 We do this in a few places, if the CPU is offline. This isn't allowed, though, since on multi queue hardware, we can't just move a request from one software queue to another, if they map to different hardware queues. The request and tag isn't valid on another hardware queue. This can happen if plugging races with CPU offlining. But it does no harm, since it can only happen in the window where we are currently busy freezing the queue and flushing IO, in preparation for redoing the software <-> hardware queue mappings. Signed-off-by:
-
Jens Axboe authored
BugLink: http://bugs.launchpad.net/bugs/1620317 __blk_mq_run_hw_queue() currently warns if we are running the queue on a CPU that isn't set in its mask. However, this can happen if a CPU is being offlined, and the workqueue handling will place the work on CPU0 instead. Improve the warning so that it only triggers if the batch cpu in the hardware queue is currently online. If it triggers for that case, then it's indicative of a flow problem in blk-mq, so we want to retain it for that case. Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1620317 In case a submitted request gets stuck for some reason, the block layer can prevent the request starvation by starting the scheduled timeout work. If this stuck request occurs at the same time another thread has started a queue freeze, the blk_mq_timeout_work will not be able to acquire the queue reference and will return silently, thus not issuing the timeout. But since the request is already holding a q_usage_counter reference and is unable to complete, it will never release its reference, preventing the queue from completing the freeze started by first thread. This puts the request_queue in a hung state, forever waiting for the freeze completion. This was observed while running IO to a NVMe device at the same time we toggled the CPU hotplug code. Eventually, once a request got stuck requiring a timeout during a queue freeze, we saw the CPU Hotplug notification code get stuck inside blk_mq_freeze_queue_wait, as shown in the trace below. [c000000deaf13690] [c000000deaf13738] 0xc000000deaf13738 (unreliable) [c000000deaf13860] [c000000000015ce8] __switch_to+0x1f8/0x350 [c000000deaf138b0] [c000000000ade0e4] __schedule+0x314/0x990 [c000000deaf13940] [c000000000ade7a8] schedule+0x48/0xc0 [c000000deaf13970] [c0000000005492a4] blk_mq_freeze_queue_wait+0x74/0x110 [c000000deaf139e0] [c00000000054b6a8] blk_mq_queue_reinit_notify+0x1a8/0x2e0 [c000000deaf13a40] [c0000000000e7878] notifier_call_chain+0x98/0x100 [c000000deaf13a90] [c0000000000b8e08] cpu_notify_nofail+0x48/0xa0 [c000000deaf13ac0] [c0000000000b92f0] _cpu_down+0x2a0/0x400 [c000000deaf13b90] [c0000000000b94a8] cpu_down+0x58/0xa0 [c000000deaf13bc0] [c0000000006d5dcc] cpu_subsys_offline+0x2c/0x50 [c000000deaf13bf0] [c0000000006cd244] device_offline+0x104/0x140 [c000000deaf13c30] [c0000000006cd40c] online_store+0x6c/0xc0 [c000000deaf13c80] [c0000000006c8c78] dev_attr_store+0x68/0xa0 [c000000deaf13cc0] [c0000000003974d0] sysfs_kf_write+0x80/0xb0 [c000000deaf13d00] [c0000000003963e8] kernfs_fop_write+0x188/0x200 [c000000deaf13d50] [c0000000002e0f6c] __vfs_write+0x6c/0xe0 [c000000deaf13d90] [c0000000002e1ca0] vfs_write+0xc0/0x230 [c000000deaf13de0] [c0000000002e2cdc] SyS_write+0x6c/0x110 [c000000deaf13e30] [c000000000009204] system_call+0x38/0xb4 The fix is to allow the timeout work to execute in the window between dropping the initial refcount reference and the release of the last reference, which actually marks the freeze completion. This can be achieved with percpu_refcount_tryget, which does not require the counter to be alive. This way the timeout work can do it's job and terminate a stuck request even during a freeze, returning its reference and avoiding the deadlock. Allowing the timeout to run is just a part of the fix, since for some devices, we might get stuck again inside the device driver's timeout handler, should it attempt to allocate a new request in that path - which is a quite common action for Abort commands, which need to be sent after a timeout. In NVMe, for instance, we call blk_mq_alloc_request from inside the timeout handler, which will fail during a freeze, since it also tries to acquire a queue reference. I considered a similar change to blk_mq_alloc_request as a generic solution for further device driver hangs, but we can't do that, since it would allow new requests to disturb the freeze process. I thought about creating a new function in the block layer to support unfreezable requests for these occasions, but after working on it for a while, I feel like this should be handled in a per-driver basis. I'm now experimenting with changes to the NVMe timeout path, but I'm open to suggestions of ways to make this generic. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
