forked from acpica/acpica
-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Acpica temp #2
Merged
Merged
Acpica temp #2
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
zetalog
pushed a commit
that referenced
this pull request
Feb 22, 2017
I found some ACPI operand cache leaks in ACPI early abort cases. Boot log of ACPI operand cache leak is as follows: >[ 0.174332] ACPI: Added _OSI(Module Device) >[ 0.175504] ACPI: Added _OSI(Processor Device) >[ 0.176010] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.177032] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.178284] ACPI: SCI (IRQ16705) allocation failed >[ 0.179352] ACPI Exception: AE_NOT_ACQUIRED, Unable to install System Control Interrupt handler (20160930/evevent-131) >[ 0.180008] ACPI: Unable to start the ACPI Interpreter >[ 0.181125] ACPI Error: Could not remove SCI handler (20160930/evmisc-281) >[ 0.184068] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.185358] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc3 #2 >[ 0.186820] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 >[ 0.188000] Call Trace: >[ 0.188000] ? dump_stack+0x5c/0x7d >[ 0.188000] ? kmem_cache_destroy+0x224/0x230 >[ 0.188000] ? acpi_sleep_proc_init+0x22/0x22 >[ 0.188000] ? acpi_os_delete_cache+0xa/0xd >[ 0.188000] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.188000] ? acpi_terminate+0x5/0xf >[ 0.188000] ? acpi_init+0x288/0x32e >[ 0.188000] ? __class_create+0x4c/0x80 >[ 0.188000] ? video_setup+0x7a/0x7a >[ 0.188000] ? do_one_initcall+0x4e/0x1b0 >[ 0.188000] ? kernel_init_freeable+0x194/0x21a >[ 0.188000] ? rest_init+0x80/0x80 >[ 0.188000] ? kernel_init+0xa/0x100 >[ 0.188000] ? ret_from_fork+0x25/0x30 When early abort is occurred due to invalid ACPI information, Linux kernel terminates ACPI by calling AcpiTerminate() function. The function calls AcpiNsTerminate() function to delete namespace data and ACPI operand cache (AcpiGbl_ModuleCodeList). But the deletion code in AcpiNsTerminate() function is wrapped in ACPI_EXEC_APP definition, therefore the code is only executed when the definition exists. If the define doesn't exist, ACPI operand cache (AcpiGbl_ModuleCodeList) is leaked, and stack dump is shown in kernel log. This causes a security threat because the old kernel (<= 4.9) shows memory locations of kernel functions in stack dump, therefore kernel ASLR can be neutralized. To fix ACPI operand leak for enhancing security, I made a patch which removes the ACPI_EXEC_APP define in AcpiNsTerminate() function for executing the deletion code unconditionally. Signed-off-by: Seunghun Han <kkamagui@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Apr 14, 2017
This patch converts AcpiInstallMethod() into new OSDT override mechanism. If this is on top of the table sanity check mechanism (link #2), the change in tbinstal.c is not needed. Reported by Zhang Rui, fixed by Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=195325 [#1] Link: acpica#121 Reported-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
May 11, 2017
Windows seems to allow arbitrary table signatures for Load/LoadTable opcodes: ACPI BIOS Error (bug): Table has invalid signature [PRAD] (0x44415250) So this patch removes dynamic load signature checks. However we need to find a way to avoid table loading against tables like MADT. This is not covered by this commit. This Windows behavior has been validated on link #1. An end user bug report can also be found on link #2. This patch also includes simple cleanup for static load signature check code. Reported by Ye Xiaolong, Fixed by Lv Zheng. Link: acpica#121 [#1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=118601 [#2] Reported-by: Ye Xiaolong <xiaolong.ye@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
May 11, 2017
Windows seems to allow arbitrary table signatures for Load/LoadTable opcodes: ACPI BIOS Error (bug): Table has invalid signature [PRAD] (0x44415250) So this patch removes dynamic load signature checks. However we need to find a way to avoid table loading against tables like MADT. This is not covered by this commit. This Windows behavior has been validated on link #1. An end user bug report can also be found on link #2. This patch also includes simple cleanup for static load signature check code. Reported by Ye Xiaolong, Fixed by Lv Zheng. Link: acpica#121 [#1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=118601 [#2] Reported-by: Ye Xiaolong <xiaolong.ye@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jun 9, 2017
Windows seems to allow arbitrary table signatures for Load/LoadTable opcodes: ACPI BIOS Error (bug): Table has invalid signature [PRAD] (0x44415250) So this patch removes dynamic load signature checks. However we need to find a way to avoid table loading against tables like MADT. This is not covered by this commit. This Windows behavior has been validated on link #1. An end user bug report can also be found on link #2. This patch also includes simple cleanup for static load signature check code. Reported by Ye Xiaolong, Fixed by Lv Zheng. Link: acpica#121 [#1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=118601 [#2] Reported-by: Ye Xiaolong <xiaolong.ye@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jun 14, 2017
Windows seems to allow arbitrary table signatures for Load/LoadTable opcodes: ACPI BIOS Error (bug): Table has invalid signature [PRAD] (0x44415250) So this patch removes dynamic load signature checks. However we need to find a way to avoid table loading against tables like MADT. This is not covered by this commit. This Windows behavior has been validated on link #1. An end user bug report can also be found on link #2. This patch also includes simple cleanup for static load signature check code. Reported by Ye Xiaolong, Fixed by Lv Zheng. Link: acpica#121 [#1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=118601 [#2] Reported-by: Ye Xiaolong <xiaolong.ye@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jun 16, 2017
Windows seems to allow arbitrary table signatures for Load/LoadTable opcodes: ACPI BIOS Error (bug): Table has invalid signature [PRAD] (0x44415250) So this patch removes dynamic load signature checks. However we need to find a way to avoid table loading against tables like MADT. This is not covered by this commit. This Windows behavior has been validated on link #1. An end user bug report can also be found on link #2. This patch also includes simple cleanup for static load signature check code. Reported by Ye Xiaolong, Fixed by Lv Zheng. Link: acpica#121 [#1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=118601 [#2] Reported-by: Ye Xiaolong <xiaolong.ye@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jun 16, 2017
Windows seems to allow arbitrary table signatures for Load/LoadTable opcodes: ACPI BIOS Error (bug): Table has invalid signature [PRAD] (0x44415250) So this patch removes dynamic load signature checks. However we need to find a way to avoid table loading against tables like MADT. This is not covered by this commit. This Windows behavior has been validated on link #1. An end user bug report can also be found on link #2. This patch also includes simple cleanup for static load signature check code. Reported by Ye Xiaolong, Fixed by Lv Zheng. Link: acpica#121 [#1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=118601 [#2] Reported-by: Ye Xiaolong <xiaolong.ye@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jun 16, 2017
Windows seems to allow arbitrary table signatures for Load/LoadTable opcodes: ACPI BIOS Error (bug): Table has invalid signature [PRAD] (0x44415250) So this patch removes dynamic load signature checks. However we need to find a way to avoid table loading against tables like MADT. This is not covered by this commit. This Windows behavior has been validated on link #1. An end user bug report can also be found on link #2. This patch also includes simple cleanup for static load signature check code. Reported by Ye Xiaolong, Fixed by Lv Zheng. Link: acpica#121 [#1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=118601 [#2] Reported-by: Ye Xiaolong <xiaolong.ye@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jun 26, 2017
Windows seems to allow arbitrary table signatures for Load/LoadTable opcodes: ACPI BIOS Error (bug): Table has invalid signature [PRAD] (0x44415250) So this patch removes dynamic load signature checks. However we need to find a way to avoid table loading against tables like MADT. This is not covered by this commit. This Windows behavior has been validated on link #1. An end user bug report can also be found on link #2. This patch also includes simple cleanup for static load signature check code. Reported by Ye Xiaolong, Fixed by Lv Zheng. Link: acpica#121 [#1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=118601 [#2] Reported-by: Ye Xiaolong <xiaolong.ye@intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jun 30, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 4, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 5, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 6, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 6, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 7, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 7, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 7, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 7, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 7, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 7, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 7, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 12, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 12, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 12, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 13, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
zetalog
pushed a commit
that referenced
this pull request
Jul 13, 2017
ACPI spec allows to configure different 32-bit/64-bit table addresses for DSDT and FACS. And for FACS, it's meaningful to dump both of them as they are used to support different suspend protocols. While: 1. on Linux, only 1 instance is supported for DSDT/FACS; and 2. on EFI, the code in OslGetTable() is buggy with special table instances, causing endless file dump for such tables (reported by Shao Ming in link #2). This patch adds DSDT/FACS instance support for Linux/EFI but doesn't cover BSD as BSD acpidump needs a full refresh. Fixed by Lv Zheng. Link: https://bugs.acpica.org/show_bug.cgi?id=1407 [#1] Link: acpica#285 [#2] Reported-by: Shao Ming <smbest163@163.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com>
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.
This is a pull request.