[pull] master from adam900710:master #2
Conversation
This file contains hidden or 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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
The arguments now match the wrapper, use it. Signed-off-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Use a more descriptive name, the interface is generic so it should use the generic term for file/directory. Signed-off-by: David Sterba <[email protected]>
Feature from sphinx-doc/sphinx#2064 enable navigation to be able to navigate documentation using the arrow keys. Pull-request: kdave#754 Author: Martin <[email protected]> Signed-off-by: David Sterba <[email protected]>
Remove btrfs_qgroup_inherit_add_copy() and the command line interface. This was designed to add a pair of source/destination qgroups into btrfs_qgroup_inherit structure, so that rfer/excl numbers would be copied from the source qgroup into the destination one. This behavior has been intentionally hidden since 2016, as such copy will cause qgroup inconsistent immediately and a rescan would reset whatever numbers copied anyway. Now we're going to reject the copy behavior from kernel, there is no need to keep those hidden (and already disabled for "subvolume create") case. Remove btrfs_qgroup_inherit_add_copy() call, and cleanup the undocumented options. Signed-off-by: Qu Wenruo <[email protected]> Signed-off-by: David Sterba <[email protected]>
…cceeded [BUG] With the latest kernel patch to reject invalid qgroupids in btrfs_qgroup_inherit structure, "btrfs subvolume create" or "btrfs subvolume snapshot" can lead to the following output: # mkfs.btrfs -O quota -f $dev # mount $dev $mnt # btrfs subvolume create -i 2/0 $mnt/subv1 Create subvolume '/mnt/btrfs/subv1' ERROR: cannot create subvolume: No such file or directory The "btrfs subvolume" command output the first line, seemingly to indicate a successful subvolume creation, then followed by an error message. This can be a little confusing on whether if the subvolume is created or not. [FIX] Fix the output by only outputting the regular line if the ioctl succeeded. Signed-off-by: Qu Wenruo <[email protected]> Signed-off-by: David Sterba <[email protected]>
The initial version of libbtrfsutil did not follow a unified naming scheme that's usually used for libraries like those provide by util-linux. Add aliases that are "btrfs_util_" + object + action + suffix. The library version changes to 1.3 but there's no new functionality, only the aliases added. New functions can be added in the future without possible confusion when the same action could apply to different objects. Issue: kdave#574 Signed-off-by: David Sterba <[email protected]>
Copy what's in kernel header, new structures and constants. - raid-stripe-tree - verity - simple quota Deleted: - btrfs_extent_ref_v0 (obsolete, kernel support removed) Signed-off-by: David Sterba <[email protected]>
Sync structures definitions and constants from kernel source. - update btrfs_ioctl_fs_info_args - update btrfs_ioctl_send_args - verity, block-group-tree, raid-stripe-tree, simple quota - ioctl definition updates - copy comments - diff minimization (whitespace changes, moved definitions) Signed-off-by: David Sterba <[email protected]>
There's an error in resource control command name, the argument is IOReadBandwidthMax instead of IOBandwidthReadMax. See https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html [ci skip] Pull-request: kdave#744 Author: Termuellinator <[email protected]> Signed-off-by: David Sterba <[email protected]>
[ci skip] Signed-off-by: David Sterba <[email protected]>
[ci skip] Signed-off-by: David Sterba <[email protected]>
Sync a few more file on the source level with kernel 6.8. - type cleanups - defines and enums - comments - parameter updates - error handling Signed-off-by: David Sterba <[email protected]>
Tree comparators never change parameters, make them all const and also change the rb-tree prototypes. Signed-off-by: David Sterba <[email protected]>
Bit shifts should be done on unsigned type as a matter of good practice to avoid any problems with bit overflowing to the sign bit. Signed-off-by: David Sterba <[email protected]>
Bit shifts should be done on unsigned type as a matter of good practice to avoid any problems with bit overflowing to the sign bit. Signed-off-by: David Sterba <[email protected]>
Bit shifts should be done on unsigned type as a matter of good practice to avoid any problems with bit overflowing to the sign bit. Signed-off-by: David Sterba <[email protected]>
Bit shifts should be done on unsigned type as a matter of good practice to avoid any problems with bit overflowing to the sign bit. Signed-off-by: David Sterba <[email protected]>
Bit shifts should be done on unsigned type as a matter of good practice to avoid any problems with bit overflowing to the sign bit. Signed-off-by: David Sterba <[email protected]>
…ms() Do proper error handling like in the rest of the function. Signed-off-by: David Sterba <[email protected]>
Add new error message template and use it to report invalid range overlaps and do proper error handling. Signed-off-by: David Sterba <[email protected]>
Do proper error handling and use the template error message when setting the label fails. Signed-off-by: David Sterba <[email protected]>
The buffer size check is needed and has already caught problems when adding the raid-stripe-tree, do a better error reporting. Signed-off-by: David Sterba <[email protected]>
Replace BUG_ONs with proper error handling. Signed-off-by: David Sterba <[email protected]>
Add wrappers around v1 and v2 of TREE_SEARCH ioctl so it can be transparently used by code. The structures partially overlap but due to the buffer size the v2 is offset and also needs a filler to expand the flexible buffer. Usage: - define struct btrfs_tree_search_args, all zeros - btrfs_tree_search_sk() reads offset of the search key within the structures - btrfs_tree_search_ioctl() detect support and call the highest supported ioctl version, v2 has been supported since 3.14 but we want to keep backward compatibility - btrfs_tree_search_data() read data from the buffer previously filled by ioctl, a sequence of (search header, data) Signed-off-by: David Sterba <[email protected]>
For unclear reasons using the v2 ioctl leads to an infinite loop in 'btrfs fi usage' in load_chunk_info() when there's only one valid item returned and then it keeps looping. Can be reproduced by mkfs-tests/001. After debugging, from second item in the buffer there's all zeros, while it's returned nr_items=4. Switching the same code to use v1 makes it work again. It's puzzling as it's the same code in kernel. We want to make the switch eventually so only disable the detection so other code can use the new API. Signed-off-by: David Sterba <[email protected]>
Use tree search ioctl wrappers for code that is considered internal, ie. leaving out libbtrfs (legacy), libbtrfsutil (needs own API for that). Conversion is mostly direct of what the API provides. Signed-off-by: David Sterba <[email protected]>
Use a local copy of the search header for proper aligned access instead of the unaligned helpers, move the definitions to the closest scope. Signed-off-by: David Sterba <[email protected]>
The filename sanitization is not recommended as it introduces mismatches between DIR_ITEM and INODE_REF. Even hash collision mode (double "-s" option) is not ensured to always find a hash collision, and when fails to find one, a mismatch happens. And when a mismatch happens, the kernel will not resolve the path correctly since kernel uses the hash from DIR_ITEM to lookup the child inode. So add a warning into the "-s" option of btrfs-image. Signed-off-by: Qu Wenruo <[email protected]>
[BUG]
There is a bug report that image dump taken by "btrfs-image -s" doesn't
really sanitize the filenames:
# truncates -s 1G source.raw
# mkfs.btrfs -f source.raw
# mount source.raw $mnt
# touch $mnt/top_secret_filename
# touch $mnt/secret_filename
# umount $mnt
# btrfs-image -s source.raw dump.img
# string dump.img | grep filename
top_secret_filename
secret_filename
top_secret_filename
secret_filename
top_secret_filename
[CAUSE]
Using above image to store the fs, and we got the following result in fs
tree:
item 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160
generation 3 transid 7 size 68 nbytes 16384
block group 0 mode 40755 links 1 uid 0 gid 0 rdev 0
sequence 2 flags 0x0(none)
item 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12
index 0 namelen 2 name: ..
item 2 key (256 DIR_ITEM 439756795) itemoff 16062 itemsize 49
location key (257 INODE_ITEM 0) type FILE
transid 7 data_len 0 name_len 19
name: top_secret_filename
item 3 key (256 DIR_ITEM 693462946) itemoff 16017 itemsize 45
location key (258 INODE_ITEM 0) type FILE
transid 7 data_len 0 name_len 15
name: secret_filename
item 4 key (256 DIR_INDEX 2) itemoff 15968 itemsize 49
location key (257 INODE_ITEM 0) type FILE
transid 7 data_len 0 name_len 19
name: top_secret_filename
item 5 key (256 DIR_INDEX 3) itemoff 15923 itemsize 45
location key (258 INODE_ITEM 0) type FILE
transid 7 data_len 0 name_len 15
name: secret_filename
item 6 key (257 INODE_ITEM 0) itemoff 15763 itemsize 160
generation 7 transid 7 size 0 nbytes 0
block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
sequence 1 flags 0x0(none)
item 7 key (257 INODE_REF 256) itemoff 15734 itemsize 29
index 2 namelen 19 name: top_secret_filename
item 8 key (258 INODE_ITEM 0) itemoff 15574 itemsize 160
generation 7 transid 7 size 0 nbytes 0
block group 0 mode 100644 links 1 uid 0 gid 0 rdev 0
sequence 1 flags 0x0(none)
item 9 key (258 INODE_REF 256) itemoff 15549 itemsize 25
index 3 namelen 15 name: 1���'�gc*&R
The result shows, only the last INODE_REF got sanitized, all the
remaining are not touched at all.
This is caused by how we sanitize the filenames:
copy_buffer()
|- memcpy(dst, src->data, src->len);
| This means we copy the whole eb into our buffer already.
|
|- zero_items()
|- sanitize_name()
|- eb = alloc_dummy_eb();
|- memcpy(eb->data, src->data, src->len);
| This means we generate a dummy eb with the same contents of
| the source eb.
|
|- sanitize_dir_item();
| We override the dir item of the given item (specified by the
| slot number) inside our dummy eb.
|
|- memcpy(dst, eb->data, eb->lem);
The last one copy the dummy eb into our buffer, with only the slot
corrupted.
But when the whole work flow hits the next slot, we only corrupt the
next slot, but still copy the whole dummy eb back to buffer.
This means the previous slot would be overwritten by the old unsanitized
data.
Resulting only the last slot is corrupted.
[FIX]
Fix the bug by only copying back the corrupted item to the buffer.
So that other slots won't be overwritten by unsanitized data.
Reported-by: Andrea Gelmini <[email protected]>
Signed-off-by: Qu Wenruo <[email protected]>
The new test case does: - Make sure the build has error injection support This is done by checking "btrfs --version" output. - Inject error at the last commit transaction of new data csum generation - Resume the csum conversion and make sure it works Signed-off-by: Qu Wenruo <[email protected]>
This test case checks: - If a regular btrfs-image dump has the unsanitized filenames - If a sanitized btrfs-image dump has filenames properly censored Signed-off-by: Qu Wenruo <[email protected]>
[BUG]
When rolling back a converted btrfs, the filename output is corrupted:
$ btrfs-convert -r ~/test.img
btrfs-convert from btrfs-progs v6.9.2
Open filesystem for rollback:
Label:
UUID: df54baf3-c91e-4956-96f9-99413a857576
Restoring from: ext2_saved0ƨy/image
^^^ Corruption
Rollback succeeded
[CAUSE]
The error is in how we handle the filename. In btrfs all our strings
are not '\0' terminated, but with explicit length.
But in C, most strings are '\0' terminated, so after reading a filename
from btrfs, we need to manually terminate the string.
However the code adding the terminating '\0' looks like this:
/* Get the filename length. */
name_len = btrfs_root_ref_name_len(path.nodes[0], root_ref_item);
/*
* This should not happen, but as an extra handling for possible
* corrupted btrfs.
*/
if (name_len > sizeof(dir_name))
name_len = sizeof(dir_name) - 1;
/* Got the real filename into our buffer. */
read_extent_buffer(path.nodes[0], dir_name, (unsigned long)(root_ref_item + 1), name_len);
/* Terminate the string. */
dir_name[sizeof(dir_name) - 1] = 0;
The problem is, the final termination is totally wrong, it always make
the last buffer char '\0', not using the @name_len we read before.
[FIX]
Use @name_len to terminate the string, as we have already updated it to
handle buffer overflow, it can handle both the regular and corrupted
case.
Fixes: dc29a5c ("btrfs-progs: convert: update default output")
Signed-off-by: Qu Wenruo <[email protected]>
The new new test case is to make sure the rollback output for a fixed content converted fs contains the string "ext2_saved/image". As we have a bug in the past where after the string "ext2_saved", we can have some unterminated garbage. Signed-off-by: Qu Wenruo <[email protected]>
For "btrfstune --csum", currently we do the following operations in just one transaction for each: - Delete old data csums - Change new data csums objectid Both operation can modify up to GiB or even TiB level of metadata, doing them in just one transaction is definitely going to cause problems. This patch adds a leaf number based threshold (32 leaves), after modifying/deleting this many leaves, we commit a transaction to avoid huge amount of dirty leaves piling up. Signed-off-by: Qu Wenruo <[email protected]>
With the new feature description output in "btrfs --version" there is no need to do the config.h hack to determine if we have certain feature. This provides a more reliable way to detect features. Signed-off-by: Qu Wenruo <[email protected]>
Python 3.13, currently in beta, removed the internal _PyObject_LookupSpecial function. The libbtrfsutil Python bindings use it in the path_converter() function because it was based on internal path_converter() function in CPython [1]. This is causing build failures on Fedora Rawhide [2] and Gentoo [3]. Replace path_converter() with a version that only uses public functions based on the one in drgn [4]. 1: https://github.com/python/cpython/blob/d9efa45d7457b0dfea467bb1c2d22c69056ffc73/Modules/posixmodule.c#L1253 2: https://bugzilla.redhat.com/show_bug.cgi?id=2245650 3: kdave#838 4: https://github.com/osandov/drgn/blob/9ad29fd86499eb32847473e928b6540872d3d59a/libdrgn/python/util.c#L81 Issue: kdave#838 Reported-by: Neal Gompa <[email protected]> Reported-by: Sam James <[email protected]> Reviewed-by: Neal Gompa <[email protected]> Signed-off-by: Omar Sandoval <[email protected]> Signed-off-by: David Sterba <[email protected]>
btrfs_insert_dir_item wasn't setting the transid field in btrfs_dir_item. Set it to the current transaction ID rather than writing uninitialized memory to disk. Reviewed-by: Josef Bacik <[email protected]> Reviewed-by: Qu Wenruo <[email protected]> Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: Qu Wenruo <[email protected]>
Currently we already have a kernel-shared/uuid-tree.c, which is mostly shared with kernel. Kernel also has a uuid-tree.h, but we are still using ctree.h for the header. Move all the uuid-tree related definitions to kernel-shared/uuid-tree.h, making future code sync easier. Signed-off-by: Qu Wenruo <[email protected]>
The modification is minimal: - Replace WARN_ON() with UASSERT() - Remove the @trans parameter for btrfs_extend_item() and btrfs_mark_buffer_dirty() As progs version doesn't need a transaction handler. - Remove the btrfs_uuid_tree_add() in mkfs/main.c Signed-off-by: Qu Wenruo <[email protected]>
…onvert Currently mkfs uses its own create_uuid_tree(), but that function is only handling FS_TREE. This means for btrfs-convert we do not generate the uuid tree, nor add the UUID of the image subvolume. This can be a problem if we're going to support multiple subvolumes during mkfs time. To address this, introduce a new helper, btrfs_rebuild_uuid_tree(): - Create a new uuid tree if there is not one - Remove all the existing items from uuid tree - Iterate through all subvolumes * If the subvolume has no valid UUID, regenerate one * Add the uuid entry for the subvolume UUID * If the subvolume has received UUID, also add it to UUID tree By this, this new helper can handle all the uuid tree generation needs for: - Current mkfs Only one uuid entry for FS_TREE - Current btrfs-convert Only FS_TREE and the image subvolume - Future multi-subvolume mkfs As we do the scan for all subvolumes. - Future "btrfs rescue rebuild-uuid-tree" Signed-off-by: Qu Wenruo <[email protected]>
Recent changes to the python code reworked path_converter() so that it does not use fd_converter() anymore. Assuming it may be used in the future again comment it out. Signed-off-by: David Sterba <[email protected]>
mkfs_main() is a main-like function, meaning that return and exit are equivalent. Deduplicate our cleanup code by moving the error label. Signed-off-by: Mark Harmstone <[email protected]> Signed-off-by: David Sterba <[email protected]>
Commit d7492ec ("btrfs-progs: use on-stack buffer in __ino_to_path_fd") was supposed to switch path buffer from dynamic allocation to on-stack but it was done wrong. The btrfs_data_container is a flexible array so it needs to be explicitly allocated to the right size. The conversion turned it to an array. Gcc 13.x started to warn about access to fspath->val[i] being out of bounds. Fortunately overall size was 65536 and used only first 4096 bytes. cmds/inspect.c: In function ‘__ino_to_path_fd’: cmds/inspect.c:86:35: warning: array subscript i is outside array bounds of ‘__u64[]’ {aka ‘long long unsigned int[]’} [-Warray-bounds=] 86 | ptr += fspath->val[i]; | ~~~~~~~~~~~^~~ In file included from ./kernel-shared/accessors.h:11, from cmds/inspect.c:35: ./kernel-shared/uapi/btrfs.h:724:17: note: while referencing ‘val’ 724 | __u64 val[]; /* out */ Add an on-stack buffer and map it over fspath, similar to the previous dynamic array. Signed-off-by: David Sterba <[email protected]>
[BUG]
ASAN test fails at misc/055 with the following leak:
Qgroupid Referenced Exclusive Path
-------- ---------- --------- ----
0/5 16.00KiB 16.00KiB <toplevel>
0/256 16.00KiB 16.00KiB <stale>
====== RUN CHECK /home/runner/work/btrfs-progs/btrfs-progs/btrfs qgroup clear-stale /home/runner/work/btrfs-progs/btrfs-progs/tests/mnt
=================================================================
==102571==ERROR: LeakSanitizer: detected memory leaks
Indirect leak of 4096 byte(s) in 1 object(s) allocated from:
#0 0x7fd1c98fbb37 in malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x55aa2f8953f8 in btrfs_util_subvolume_path_fd libbtrfsutil/subvolume.c:178
kdave#2 0x55aa2f8fa2a6 in get_or_add_qgroup cmds/qgroup.c:837
kdave#3 0x55aa2f8fa7e9 in update_qgroup_info cmds/qgroup.c:883
kdave#4 0x55aa2f8fd912 in __qgroups_search cmds/qgroup.c:1385
kdave#5 0x55aa2f8fe196 in qgroups_search_all cmds/qgroup.c:1453
kdave#6 0x55aa2f902a7c in cmd_qgroup_clear_stale cmds/qgroup.c:2281
kdave#7 0x55aa2f73425b in cmd_execute cmds/commands.h:126
kdave#8 0x55aa2f734bcc in handle_command_group /home/runner/work/btrfs-progs/btrfs-progs/btrfs.c:177
kdave#9 0x55aa2f73425b in cmd_execute cmds/commands.h:126
kdave#10 0x55aa2f735a96 in main /home/runner/work/btrfs-progs/btrfs-progs/btrfs.c:518
kdave#11 0x7fd1c942a1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 08134323d00289185684a4cd177d202f39c2a5f3)
kdave#12 0x7fd1c942a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 08134323d00289185684a4cd177d202f39c2a5f3)
kdave#13 0x55aa2f734144 in _start (/home/runner/work/btrfs-progs/btrfs-progs/btrfs+0x84144) (BuildId: 56f3dd838e1ae189c142c5d27fac025cd46deddb)
Indirect leak of 432 byte(s) in 2 object(s) allocated from:
#0 0x7fd1c98fb4d0 in calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
#1 0x55aa2f8fa1a1 in get_or_add_qgroup cmds/qgroup.c:822
kdave#2 0x55aa2f8fa7e9 in update_qgroup_info cmds/qgroup.c:883
kdave#3 0x55aa2f8fd912 in __qgroups_search cmds/qgroup.c:1385
kdave#4 0x55aa2f8fe196 in qgroups_search_all cmds/qgroup.c:1453
kdave#5 0x55aa2f902a7c in cmd_qgroup_clear_stale cmds/qgroup.c:2281
kdave#6 0x55aa2f73425b in cmd_execute cmds/commands.h:126
kdave#7 0x55aa2f734bcc in handle_command_group /home/runner/work/btrfs-progs/btrfs-progs/btrfs.c:177
kdave#8 0x55aa2f73425b in cmd_execute cmds/commands.h:126
kdave#9 0x55aa2f735a96 in main /home/runner/work/btrfs-progs/btrfs-progs/btrfs.c:518
kdave#10 0x7fd1c942a1c9 (/lib/x86_64-linux-gnu/libc.so.6+0x2a1c9) (BuildId: 08134323d00289185684a4cd177d202f39c2a5f3)
kdave#11 0x7fd1c942a28a in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2a28a) (BuildId: 08134323d00289185684a4cd177d202f39c2a5f3)
kdave#12 0x55aa2f734144 in _start (/home/runner/work/btrfs-progs/btrfs-progs/btrfs+0x84144) (BuildId: 56f3dd838e1ae189c142c5d27fac025cd46deddb)
[CAUSE]
Above leaks are caused by two btrfs_qgroup structures and one path for
toplevel qgroup.
It's caused by the fact that we called qgroups_search_all() but didn't
do any cleanup.
[FIX]
Call __free_all_qgroups() inside cmd_qgroup_clear_stale() to properly
free the qgroups.
Fixes: 701ab15 ("btrfs-progs: qgroup: new command to delete stale qgroups")
Signed-off-by: Qu Wenruo <[email protected]>
The thread sanitizer finds race conditions and in the past did find some bugs. There's not much threaded code, it's namely the progress tracking in btrfs-convert so the coverage is slightly redundant. Add it just in case. Signed-off-by: David Sterba <[email protected]>
It is possible to create swapfile on a multi-device filesystem but it's
not reliable. The check that verifies that in kernel:
10698 } else if (device != map->stripes[0].dev) {
10699 btrfs_warn(fs_info, "swapfile must be on one device");
10700 ret = -EINVAL;
10701 goto out;
10702 }
This does not count devices but rather the actual placement of the
swapfile extents, so multi-device filesystem with single profile can
create it as long as there's enough space and the allocator decides to
place it properly.
[ci skip]
Pull-request: kdave#839
Signed-off-by: David Sterba <[email protected]>
[ci skip] Signed-off-by: David Sterba <[email protected]>
[ci skip] Issue: kdave#768 Signed-off-by: David Sterba <[email protected]>
Make it more visible what the result of snapshotted subvolume is. This partially duplicates the other section. [ci skip] Issue: kdave#644 Signed-off-by: David Sterba <[email protected]>
[ci skip] Signed-off-by: David Sterba <[email protected]>
[ci skip] Signed-off-by: David Sterba <[email protected]>
The sysfs file description is hard to find. Also link to btrfs(5) from administration. [ci skip] Signed-off-by: David Sterba <[email protected]>
The page is not complete but mentions at least NFS, cgroups and fsverity. [ci skip] Signed-off-by: David Sterba <[email protected]>
[ci skip] Issue: kdave#374 Signed-off-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )