Rpi 4.4.y #1244
Closed
Rpi 4.4.y #1244
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…onversion" Commit 25642e1 ("powerpc/opal-irqchip: Fix double endian conversion") fixed an endian bug by calling opal_handle_events() in opal_event_unmask(). However this introduced a deadlock if we find an event is active during unmasking and call opal_handle_events() again. The bad call sequence is: opal_interrupt() -> opal_handle_events() -> generic_handle_irq() -> handle_level_irq() -> raw_spin_lock(&desc->lock) handle_irq_event(desc) unmask_irq(desc) -> opal_event_unmask() -> opal_handle_events() -> generic_handle_irq() -> handle_level_irq() -> raw_spin_lock(&desc->lock) (BOOM) When generating multiple opal events in quick succession this would lead to the following stall warnings: EEH: Fenced PHB#0 detected, location: U78C9.001.WZS09XA-P1-C32 INFO: rcu_sched detected stalls on CPUs/tasks: 12-...: (1 GPs behind) idle=68f/140000000000001/0 softirq=860/861 fqs=2065 15-...: (1 GPs behind) idle=be5/140000000000001/0 softirq=1142/1143 fqs=2065 (detected by 13, t=2102 jiffies, g=1325, c=1324, q=602) NMI watchdog: BUG: soft lockup - CPU#18 stuck for 22s! [irqbalance:2696] INFO: rcu_sched detected stalls on CPUs/tasks: 12-...: (1 GPs behind) idle=68f/140000000000001/0 softirq=860/861 fqs=8371 15-...: (1 GPs behind) idle=be5/140000000000001/0 softirq=1142/1143 fqs=8371 (detected by 20, t=8407 jiffies, g=1325, c=1324, q=1290) This patch corrects the problem by queuing the work if an event is active during unmasking, which is similar to the pre-endian fix behaviour. Fixes: 25642e1 ("powerpc/opal-irqchip: Fix double endian conversion") Signed-off-by: Alistair Popple <[email protected]> Reported-by: Andrew Donnellan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
The print_insn() function returns strings like "lghi %r1,0". To escape the '%' character in sprintf() a second '%' is used. For example "lghi %%r1,0" is converted into "lghi %r1,0". After print_insn() the output string is passed to printk(). Because format specifiers like "%r" or "%f" are ignored by printk() this works by chance most of the time. But for instructions with control registers like "lctl %c6,%c6,780" this fails because printk() interprets "%c" as character format specifier. Fix this problem and escape the '%' characters twice. For example "lctl %%%%c6,%%%%c6,780" is then converted by sprintf() into "lctl %%c6,%%c6,780" and by printk() into "lctl %c6,%c6,780". Signed-off-by: Michael Holzheu <[email protected]> Cc: [email protected] Signed-off-by: Martin Schwidefsky <[email protected]>
Using RING_GET_REQUEST() on a shared ring is easy to use incorrectly (i.e., by not considering that the other end may alter the data in the shared ring while it is being inspected). Safe usage of a request generally requires taking a local copy. Provide a RING_COPY_REQUEST() macro to use instead of RING_GET_REQUEST() and an open-coded memcpy(). This takes care of ensuring that the copy is done correctly regardless of any possible compiler optimizations. Use a volatile source to prevent the compiler from reordering or omitting the copy. This is part of XSA155. CC: [email protected] Signed-off-by: David Vrabel <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
The last from guest transmitted request gives no indication about the minimum amount of credit that the guest might need to send a packet since the last packet might have been a small one. Instead allow for the worst case 128 KiB packet. This is part of XSA155. CC: [email protected] Reviewed-by: Wei Liu <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Instead of open-coding memcpy()s and directly accessing Tx and Rx requests, use the new RING_COPY_REQUEST() that ensures the local copy is correct. This is more than is strictly necessary for guest Rx requests since only the id and gref fields are used and it is harmless if the frontend modifies these. This is part of XSA155. CC: [email protected] Reviewed-by: Wei Liu <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
A compiler may load a switch statement value multiple times, which could be bad when the value is in memory shared with the frontend. When converting a non-native request to a native one, ensure that src->operation is only loaded once by using READ_ONCE(). This is part of XSA155. CC: [email protected] Signed-off-by: Roger Pau Monné <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Since indirect descriptors are in memory shared with the frontend, the frontend could alter the first_sect and last_sect values after they have been validated but before they are recorded in the request. This may result in I/O requests that overflow the foreign page, possibly overwriting local pages when the I/O request is executed. When parsing indirect descriptors, only read first_sect and last_sect once. This is part of XSA155. CC: [email protected] Signed-off-by: Roger Pau Monné <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
The copy of the ring request was lacking a following barrier(), potentially allowing the compiler to optimize the copy away. Use RING_COPY_REQUEST() to ensure the request is copied to local memory. This is part of XSA155. CC: [email protected] Reviewed-by: Juergen Gross <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Double fetch vulnerabilities that happen when a variable is fetched twice from shared memory but a security check is only performed the first time. The xen_pcibk_do_op function performs a switch statements on the op->cmd value which is stored in shared memory. Interestingly this can result in a double fetch vulnerability depending on the performed compiler optimization. This patch fixes it by saving the xen_pci_op command before processing it. We also use 'barrier' to make sure that the compiler does not perform any optimization. This is part of XSA155. CC: [email protected] Reviewed-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: Jan Beulich <[email protected]> Signed-off-by: David Vrabel <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
…I or MSI-X enabled The guest sequence of: a) XEN_PCI_OP_enable_msi b) XEN_PCI_OP_enable_msi c) XEN_PCI_OP_disable_msi results in hitting an BUG_ON condition in the msi.c code. The MSI code uses an dev->msi_list to which it adds MSI entries. Under the above conditions an BUG_ON() can be hit. The device passed in the guest MUST have MSI capability. The a) adds the entry to the dev->msi_list and sets msi_enabled. The b) adds a second entry but adding in to SysFS fails (duplicate entry) and deletes all of the entries from msi_list and returns (with msi_enabled is still set). c) pci_disable_msi passes the msi_enabled checks and hits: BUG_ON(list_empty(dev_to_msi_list(&dev->dev))); and blows up. The patch adds a simple check in the XEN_PCI_OP_enable_msi to guard against that. The check for msix_enabled is not stricly neccessary. This is part of XSA-157. CC: [email protected] Reviewed-by: David Vrabel <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
…SI or MSI-X enabled The guest sequence of: a) XEN_PCI_OP_enable_msix b) XEN_PCI_OP_enable_msix results in hitting an NULL pointer due to using freed pointers. The device passed in the guest MUST have MSI-X capability. The a) constructs and SysFS representation of MSI and MSI groups. The b) adds a second set of them but adding in to SysFS fails (duplicate entry). 'populate_msi_sysfs' frees the newly allocated msi_irq_groups (note that in a) pdev->msi_irq_groups is still set) and also free's ALL of the MSI-X entries of the device (the ones allocated in step a) and b)). The unwind code: 'free_msi_irqs' deletes all the entries and tries to delete the pdev->msi_irq_groups (which hasn't been set to NULL). However the pointers in the SysFS are already freed and we hit an NULL pointer further on when 'strlen' is attempted on a freed pointer. The patch adds a simple check in the XEN_PCI_OP_enable_msix to guard against that. The check for msi_enabled is not stricly neccessary. This is part of XSA-157 CC: [email protected] Reviewed-by: David Vrabel <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
Otherwise an guest can subvert the generic MSI code to trigger
an BUG_ON condition during MSI interrupt freeing:
for (i = 0; i < entry->nvec_used; i++)
BUG_ON(irq_has_action(entry->irq + i));
Xen PCI backed installs an IRQ handler (request_irq) for
the dev->irq whenever the guest writes PCI_COMMAND_MEMORY
(or PCI_COMMAND_IO) to the PCI_COMMAND register. This is
done in case the device has legacy interrupts the GSI line
is shared by the backend devices.
To subvert the backend the guest needs to make the backend
to change the dev->irq from the GSI to the MSI interrupt line,
make the backend allocate an interrupt handler, and then command
the backend to free the MSI interrupt and hit the BUG_ON.
Since the backend only calls 'request_irq' when the guest
writes to the PCI_COMMAND register the guest needs to call
XEN_PCI_OP_enable_msi before any other operation. This will
cause the generic MSI code to setup an MSI entry and
populate dev->irq with the new PIRQ value.
Then the guest can write to PCI_COMMAND PCI_COMMAND_MEMORY
and cause the backend to setup an IRQ handler for dev->irq
(which instead of the GSI value has the MSI pirq). See
'xen_pcibk_control_isr'.
Then the guest disables the MSI: XEN_PCI_OP_disable_msi
which ends up triggering the BUG_ON condition in 'free_msi_irqs'
as there is an IRQ handler for the entry->irq (dev->irq).
Note that this cannot be done using MSI-X as the generic
code does not over-write dev->irq with the MSI-X PIRQ values.
The patch inhibits setting up the IRQ handler if MSI or
MSI-X (for symmetry reasons) code had been called successfully.
P.S.
Xen PCIBack when it sets up the device for the guest consumption
ends up writting 0 to the PCI_COMMAND (see xen_pcibk_reset_device).
XSA-120 addendum patch removed that - however when upstreaming said
addendum we found that it caused issues with qemu upstream. That
has now been fixed in qemu upstream.
This is part of XSA-157
CC: [email protected]
Reviewed-by: David Vrabel <[email protected]>
Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
…s MSI(X) enabled. Otherwise just continue on, returning the same values as previously (return of 0, and op->result has the PIRQ value). This does not change the behavior of XEN_PCI_OP_disable_msi[|x]. The pci_disable_msi or pci_disable_msix have the checks for msi_enabled or msix_enabled so they will error out immediately. However the guest can still call these operations and cause us to disable the 'ack_intr'. That means the backend IRQ handler for the legacy interrupt will not respond to interrupts anymore. This will lead to (if the device is causing an interrupt storm) for the Linux generic code to disable the interrupt line. Naturally this will only happen if the device in question is plugged in on the motherboard on shared level interrupt GSI. This is part of XSA-157 CC: [email protected] Reviewed-by: David Vrabel <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
commit f598282 ("PCI: Fix the NIU MSI-X problem in a better way") teaches us that dealing with MSI-X can be troublesome. Further checks in the MSI-X architecture shows that if the PCI_COMMAND_MEMORY bit is turned of in the PCI_COMMAND we may not be able to access the BAR (since they are memory regions). Since the MSI-X tables are located in there.. that can lead to us causing PCIe errors. Inhibit us performing any operation on the MSI-X unless the MEMORY bit is set. Note that Xen hypervisor with: "x86/MSI-X: access MSI-X table only after having enabled MSI-X" will return: xen_pciback: 0000:0a:00.1: error -6 enabling MSI-X for guest 3! When the generic MSI code tries to setup the PIRQ without MEMORY bit set. Which means with later versions of Xen (4.6) this patch is not neccessary. This is part of XSA-157 CC: [email protected] Reviewed-by: Jan Beulich <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
After several open/close sai test with ctrl+c, there will be I/O error. The SAI can't work anymore, can't recover. There will be no frame clock. With adding the software reset in trigger stop, the issue can be fixed. This is a hardware bug/errata and reset is the only option. According to the reference manual, the software reset doesn't reset any control register but only internal hardware logics such as bit clock generator, status flags, and FIFO pointers. (Our purpose is just to reset the clock generator while the software reset is the only way to do that.) Since slave mode doesn't use the clock generator, only apply the reset procedure to the master mode. For asynchronous mode, TX will not be reset when RX is still running. In this case, i can't reproduce this issue. Signed-off-by: Zidan Wang <[email protected]> Acked-by: Nicolin Chen <[email protected]> Signed-off-by: Mark Brown <[email protected]>
If CONFIG_BITREVERSE is not built-in, the sht15 driver fails to link: drivers/built-in.o: In function `sht15_crc8': drivers/hwmon/sht15.c:195: undefined reference to `byte_rev_table' This adds a Kconfig 'select' statement, like all other users of bitrev.h have it. Signed-off-by: Arnd Bergmann <[email protected]> Fixes: 33836ee ("hwmon:change sht15_reverse()") Signed-off-by: Guenter Roeck <[email protected]>
When allocating a pciback device fails, clear the private field. This could lead to an use-after free, however the 'really_probe' takes care of setting dev_set_drvdata(dev, NULL) in its failure path (which we would exercise if the ->probe function failed), so we we are OK. However lets be defensive as the code can change. Going forward we should clean up the pci_set_drvdata(dev, NULL) in the various code-base. That will be for another day. Reviewed-by: Boris Ostrovsky <[email protected]> Reported-by: Jonathan Creekmore <[email protected]> Signed-off-by: Doug Goldstein <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>
…el/git/kishon/linux-phy into usb-linus Kishon writes: phy: for 4.4 -rc *) Add missing of_node_put in a bunch of PHY drivers *) Add get_device in devm_of_phy_get_by_index() *) Fix randconfig build error in sun9i usb driver
This patch broke ivtv logic, as reported at https://bugzilla.redhat.com/show_bug.cgi?id=1278942 This reverts commit 09290cc. Cc: [email protected] # for v4.1 and upper Signed-off-by: Mauro Carvalho Chehab <[email protected]>
drivers/media/usb/hackrf/hackrf.c:1533 hackrf_probe() error: we previously assumed 'dev' could be null (see line 1366) Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Antti Palosaari <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Used Avago MGA-81563 RF amplifier could be destroyed pretty easily with too strong signal or transmitting to bad antenna. Add module parameter 'enable_rf_gain_ctrl' which allows enabling RF gain control - otherwise, default without the module parameter, RF gain control is set to 'grabbed' state which prevents setting value to the control. Signed-off-by: Antti Palosaari <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Driver requested device firmware version string during probe using only 24 byte long buffer. That buffer is too small for newer firmware versions, which causes device firmware hang - device stops responding to any commands after that. Increase buffer size to 128 which should be enough for any current and future version strings. Link: airspy/airspyone_host#27 Cc: <[email protected]> # 3.17+ Reported-by: Benjamin Vernoux <[email protected]> Signed-off-by: Antti Palosaari <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]>
The code expects the loop to end with "retries" set to zero but, because it is a post-op, it will end set to -1. I have fixed this by moving the decrement inside the loop. Fixes: 014aa2a ('USB: ipaq: minor ipaq_open() cleanup.') Signed-off-by: Dan Carpenter <[email protected]> Cc: stable <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Commit 8520f38 ("USB: change hub initialization sleeps to delayed_work") changed the hub_activate() routine to make part of it run in a workqueue. However, the commit failed to take a reference to the usb_hub structure or to lock the hub interface while doing so. As a result, if a hub is plugged in and quickly unplugged before the work routine can run, the routine will try to access memory that has been deallocated. Or, if the hub is unplugged while the routine is running, the memory may be deallocated while it is in active use. This patch fixes the problem by taking a reference to the usb_hub at the start of hub_activate() and releasing it at the end (when the work is finished), and by locking the hub interface while the work routine is running. It also adds a check at the start of the routine to see if the hub has already been disconnected, in which nothing should be done. Signed-off-by: Alan Stern <[email protected]> Reported-by: Alexandru Cornea <[email protected]> Tested-by: Alexandru Cornea <[email protected]> Fixes: 8520f38 ("USB: change hub initialization sleeps to delayed_work") CC: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…x/kernel/git/kvmarm/kvmarm into HEAD KVM/ARM fixes for v4.4-rc6 - Fix for the active interrupt detection code, affecting the timer interrupt injection.
Pull MTD fixes from Brian Norris:
"I was holding out on this pull request for a bit, since there are a
few other small issues being discussed that look like 4.4-rc
regressions. Hopefully I can get those stabilized soon, but these are
ready at any rate:
- A little bit of a last-minute change for the device tree "fixed
partition" binding. This is needed because we might want to reuse
the 'partitions' subnode for other sorts of partitioning
descriptions -- e.g., for describing which on-flash partition
format(s) might be used on the system.
- Also tone down a warning message, since it is probably going to
show up on a lot of systems where it should just be ignored"
* tag 'for-linus-20151217' of git://git.infradead.org/linux-mtd:
doc: dt: mtd: partitions: add compatible property to "partitions" node
mtd: ofpart: don't complain about missing 'partitions' node too loudly
…l/git/tiwai/sound Pull sound fixes from Takashi Iwai: "As usual in rc6, this update contains only a few HD-audio and USB-audio device-specific quirks: yet another Thinkpad noise fixes, Dell headphone mic fixes, and AudioQuest DragonFly fixes" * tag 'sound-4.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: ALSA: hda - Add a fixup for Thinkpad X1 Carbon 2nd ALSA: hda - Set codec to D3 at reboot/shutdown on Thinkpads ALSA: hda - Apply click noise workaround for Thinkpads generically ALSA: hda - Fix headphone mic input on a few Dell ALC293 machines ALSA: usb-audio: Add sample rate inquiry quirk for AudioQuest DragonFly ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly
…ux/kernel/git/vgupta/arc Pull ARC architecture fixes from Vineet Gupta: "Fixes for: - perf interrupts on SMP: Not enabled (at boot) and disabled (at runtime) - stack unwinder regression (for modules, ignoring dwarf3) - nsim hosed for non default kernel link base builds" * tag 'arc-fixes-for-4.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc: ARC: smp: Rename platform hook @init_cpu_smp -> @init_per_cpu ARC: rename smp operation init_irq_cpu() to init_per_cpu() ARC: dw2 unwind: Ignore CIE version !=1 gracefully instead of bailing ARC: dw2 unwind: Reinstante unwinding out of modules ARC: [plat-sim] unbork non default CONFIG_LINUX_LINK_BASE ARC: intc: Document arc_request_percpu_irq() better ARCv2: perf: Ensure perf intr gets enabled on all cores ARC: intc: No need to clear IRQ_NOAUTOEN ARCv2: intc: Fix random perf irq disabling in SMP setup ARC: [axs10x] cap ethernet phy to 100 Mbit/sec
…ux/kernel/git/xen/tip Pull xen bug fixes from David Vrabel: - XSA-155 security fixes to backend drivers. - XSA-157 security fixes to pciback. * tag 'for-linus-4.4-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: xen-pciback: fix up cleanup path when alloc fails xen/pciback: Don't allow MSI-X ops if PCI_COMMAND_MEMORY is not set. xen/pciback: For XEN_PCI_OP_disable_msi[|x] only disable if device has MSI(X) enabled. xen/pciback: Do not install an IRQ handler for MSI interrupts. xen/pciback: Return error on XEN_PCI_OP_enable_msix when device has MSI or MSI-X enabled xen/pciback: Return error on XEN_PCI_OP_enable_msi when device has MSI or MSI-X enabled xen/pciback: Save xen_pci_op commands before processing it xen-scsiback: safely copy requests xen-blkback: read from indirect descriptors only once xen-blkback: only read request operation from shared ring once xen-netback: use RING_COPY_REQUEST() throughout xen-netback: don't use last request to determine minimum Tx credit xen: Add RING_COPY_REQUEST() xen/x86/pvh: Use HVM's flush_tlb_others op xen: Resume PMU from non-atomic context xen/events/fifo: Consume unprocessed events when a CPU dies
…x/kernel/git/joro/iommu Pull IOMMU fixes from Joerg Roedel: "Two similar fixes for the Intel and AMD IOMMU drivers to add proper access checks before calling handle_mm_fault" * tag 'iommu-fixes-v4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/vt-d: Do access checks before calling handle_mm_fault() iommu/amd: Do proper access checking before calling handle_mm_fault()
The HiFiBerry DAC+ and DAC+ Pro products both use the existing bcm sound driver with the DAC+ Pro having a special clock device driver representing the two high precision oscillators. An addition bug fix is included for the PCM512x codec where by the physical size of the sample frame is used in the calculation of the LRCK divisor as it was found to be wrong when using 24-bit depth sample contained in a little endian 4-byte sample frame.
Add an overlay to support the Atmel AT86RF233 WPAN transceiver on spi0.0. See: #1151
See commit dae803e -- the warning is expected sometimes when using CMA. However, that commit still spams my kernel log with these warnings. Signed-off-by: Eric Anholt <[email protected]>
This allows a driver to derive from the CMA object without copying all of the code. Signed-off-by: Eric Anholt <[email protected]>
This can be parsed with vc4-gpu-tools tools for trying to figure out what was going on. Signed-off-by: Eric Anholt <[email protected]>
This gets almost everything matching, except for the MSAA support and using generic PM domains. Signed-off-by: Eric Anholt <[email protected]>
VC4 wraps the CMA objects in its own structures, so it needs to do its own teardown (waiting for GPU to finish, updating bo_stats tracking). The other CMA drivers are using drm_gem_cma_free_object as their gem_free_object, so this should be a no-op for them. Signed-off-by: Eric Anholt <[email protected]>
For MSAA, you set a bit in the binner that halves the size of tiles in each direction, so you can pack 4 samples per pixel in the tile buffer. During rendering, you can load and store raw tile buffer contents (to save the per-sample MSAA contents), or you can load/store resolved tile buffer contents (loads spam the pixel value to all 4 samples, and stores either average the 4 color samples, or store the first sample for Z/S). Signed-off-by: Eric Anholt <[email protected]>
At this point all that's left is the force-enable of HDMI connector, and using direct firmware calls to turn on V3D instead of the generic power domain support. Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
If CONFIG_MMC_BCM2835 was not set the compiling of the kernel failed since mmc_debug was not defined but used in drivers/mmc/core/quirks.c. This patch add a ifdef-check for CONFIG_MMC_BCM2835 to the change of commit 64d3954
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.