Khadas vims 4.9.y #16

hyphop · 2020-03-23T05:11:33Z

zstd_support
kvim defconfig add zstd and improve squashfs

[ Upstream commit e24c644 ] I compiled with AddressSanitizer and I had these memory leaks while I was using the tep_parse_format function: Direct leak of 28 byte(s) in 4 object(s) allocated from: #0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe) #1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985 #2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140 #3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206 #4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291 #5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299 #6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849 #7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161 #8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207 #9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786 #10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285 #11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369 #12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335 #13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389 #14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431 #15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251 #16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284 #17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593 #18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727 #19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048 #20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127 #21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152 #22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252 #23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347 #24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461 #25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673 #26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) The token variable in the process_dynamic_array_len function is allocated in the read_expect_type function, but is not freed before calling the read_token function. Free the token variable before calling read_token in order to plug the leak. Signed-off-by: Philippe Duplessis-Guindon <pduplessis@efficios.com> Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://lore.kernel.org/linux-trace-devel/20200730150236.5392-1-pduplessis@efficios.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

unload & reload aml_wifi module, below errors occur: [ 19.053599@0] load module: aml_wifi [ 19.053853@0] of_get_named_gpiod_flags: parsed 'interrupt-gpios' property of node '/aml_wifi[0]' - status (0) [ 19.053863@0] of_get_named_gpiod_flags: parsed 'power_on-gpios' property of node '/aml_wifi[0]' - status (0) [ 19.053866@0] wifi: power_on_pin_OD = 0; [ 19.053872@0] aml_wifi aml_wifi: [wifi_dev_probe] no power_on_pin2 [ 19.053876@0] aml_wifi aml_wifi: [wifi_dev_probe] no chip_en_pin [ 19.053879@0] aml_wifi aml_wifi: [wifi_dev_probe] use double channel [ 19.054003@0] aml_wifi aml_wifi: [pwm_double_channel_conf_dt] wifi pwm dt ok [ 19.054009@0] aml_wifi aml_wifi: [pwm_double_channel_conf] wifi pwm conf ok [ 19.054013@0] aml_wifi aml_wifi: [wifi_dev_probe] dhd_static_buf all setup [ 19.054016@0] Wifi: bcmdhd_init_wlan_mem: [dhd] STATIC-MSG) bcmdhd_init_wlan_mem : 101.10.361.10 (wlan=r892223-20210623-1) [ 19.056601@0] Wifi: bcmdhd_init_wlan_mem: [dhd] STATIC-MSG) bcmdhd_init_wlan_mem : prealloc ok: 8162304(7971K) [ 19.056610@0] aml_wifi aml_wifi: [wifi_dev_probe] interrupt_pin=382 [ 19.056614@0] aml_wifi aml_wifi: [wifi_dev_probe] irq_num=0, irq_trigger_type=1 [ 19.056617@0] aml_wifi aml_wifi: [wifi_dev_probe] power_on_pin=381 [ 19.056620@0] aml_wifi aml_wifi: [wifi_dev_probe] clock_32k_pin=0 [ 19.056649@0] sysfs: cannot create duplicate filename '/class/wifi_power' [ 19.056655@0] CPU: 0 PID: 1802 Comm: insmod Not tainted 5.4.125 #16 [ 19.056657@0] Hardware name: Khadas VIM4 (DT) [ 19.056659@0] Call trace: [ 19.056671@0] [ffffffc0202b36c0+ 112][<ffffffc0100953c8>] dump_backtrace+0x0/0x158 [ 19.056675@0] [ffffffc0202b3730+ 32][<ffffffc010095544>] show_stack+0x24/0x30 [ 19.056681@0] [ffffffc0202b3750+ 64][<ffffffc010f18320>] dump_stack+0xb8/0xe0 [ 19.056687@0] [ffffffc0202b3790+ 48][<ffffffc010388968>] sysfs_warn_dup+0x68/0x80 [ 19.056691@0] [ffffffc0202b37c0+ 64][<ffffffc010388af0>] sysfs_create_dir_ns+0xf0/0x108 [ 19.056696@0] [ffffffc0202b3800+ 64][<ffffffc010ed072c>] kobject_add_internal+0xb4/0x308 [ 19.056700@0] [ffffffc0202b3840+ 32][<ffffffc010ed0b4c>] kset_register+0x54/0x80 [ 19.056705@0] [ffffffc0202b3860+ 48][<ffffffc010645294>] __class_register+0xc4/0x170 [ 19.056719@0] [ffffffc0202b3890+ 112][<ffffffc008ff0400>] wifi_dev_probe+0x348/0x888 [aml_wifi] [ 19.056723@0] [ffffffc0202b3900+ 48][<ffffffc010646488>] platform_drv_probe+0x58/0xa8 [ 19.056728@0] [ffffffc0202b3930+ 80][<ffffffc010643898>] really_probe+0xf0/0x3a8 [ 19.056733@0] [ffffffc0202b3980+ 48][<ffffffc010643d3c>] driver_probe_device+0x5c/0xf0 [ 19.056737@0] [ffffffc0202b39b0+ 48][<ffffffc010644004>] device_driver_attach+0x74/0x80 [ 19.056742@0] [ffffffc0202b39e0+ 48][<ffffffc010644074>] __driver_attach+0x64/0xe0 [ 19.056747@0] [ffffffc0202b3a10+ 96][<ffffffc010641408>] bus_for_each_dev+0x80/0xd0 [ 19.056751@0] [ffffffc0202b3a70+ 32][<ffffffc010643160>] driver_attach+0x30/0x40 [ 19.056755@0] [ffffffc0202b3a90+ 64][<ffffffc010642a14>] bus_add_driver+0x14c/0x1f0 [ 19.056760@0] [ffffffc0202b3ad0+ 32][<ffffffc010644dac>] driver_register+0x64/0x110 [ 19.056763@0] [ffffffc0202b3af0+ 32][<ffffffc0106463d4>] __platform_driver_register+0x54/0x60 [ 19.056772@0] [ffffffc0202b3b10+ 16][<ffffffc008ff9028>] wifi_dt_init+0x28/0x1000 [aml_wifi] [ 19.056777@0] [ffffffc0202b3b20+ 144][<ffffffc010085748>] do_one_initcall+0x50/0x2a8 [ 19.056782@0] [ffffffc0202b3bb0+ 48][<ffffffc01017b2dc>] do_init_module+0x5c/0x1f0 [ 19.056786@0] [ffffffc0202b3be0+ 368][<ffffffc01017d730>] load_module+0x2168/0x2770 [ 19.056790@0] [ffffffc0202b3d50+ 256][<ffffffc01017e000>] __do_sys_init_module+0x2c8/0x3a8 [ 19.056793@0] [ffffffc0202b3e50+ 32][<ffffffc01017e104>] __arm64_sys_init_module+0x24/0x30 [ 19.056799@0] [ffffffc0202b3e70+ 48][<ffffffc01009dddc>] el0_svc_common.constprop.0+0x74/0x168 [ 19.056804@0] [ffffffc0202b3ea0+ 336][<ffffffc01009df04>] el0_svc_handler+0x34/0xa0 [ 19.056808@0] [ffffffc0202b3ff0+ 0][<ffffffc010084f08>] el0_svc+0x8/0xc [ 19.056811@0] kobject_add_internal failed for wifi_power with -EEXIST, don't try to register things with the same name in the same directory. [ 19.056918@0] aml_wifi: probe of aml_wifi failed with error -17 Signed-off-by: Nick Xie <nick@khadas.com> Change-Id: I2b8a52a9f2f8707f9c3e450de69856235ca81bdc

We have been seeing crashes on duplicate keys in btrfs_set_item_key_safe(): BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:2620! invalid opcode: 0000 [khadas#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 khadas#6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs] With the following stack trace: #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4) khadas#1 btrfs_drop_extents (fs/btrfs/file.c:411:4) khadas#2 log_one_extent (fs/btrfs/tree-log.c:4732:9) khadas#3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9) khadas#4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9) khadas#5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8) khadas#6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8) khadas#7 btrfs_sync_file (fs/btrfs/file.c:1933:8) khadas#8 vfs_fsync_range (fs/sync.c:188:9) khadas#9 vfs_fsync (fs/sync.c:202:9) khadas#10 do_fsync (fs/sync.c:212:9) khadas#11 __do_sys_fdatasync (fs/sync.c:225:9) khadas#12 __se_sys_fdatasync (fs/sync.c:223:1) khadas#13 __x64_sys_fdatasync (fs/sync.c:223:1) khadas#14 do_syscall_x64 (arch/x86/entry/common.c:52:14) khadas#15 do_syscall_64 (arch/x86/entry/common.c:83:7) khadas#16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121) So we're logging a changed extent from fsync, which is splitting an extent in the log tree. But this split part already exists in the tree, triggering the BUG(). This is the state of the log tree at the time of the crash, dumped with drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py) to get more details than btrfs_print_leaf() gives us: >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"]) leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610 leaf 33439744 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160 generation 7 transid 9 size 8192 nbytes 8473563889606862198 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 204 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-22 15:41:44) otime 17592186044416.000000000 (559444-03-08 01:40:16) item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13 index 195 namelen 3 name: 193 item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 4096 ram 12288 extent compression 0 (none) item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 4096 nr 8192 item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 ... So the real problem happened earlier: notice that items 4 (4k-12k) and 5 (8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and item 5 starts at i_size. Here is the state of the filesystem tree at the time of the crash: >>> root = prog.crashed_thread().stack_trace()[2]["inode"].root >>> ret, nodes, slots = btrfs_search_slot(root, BtrfsKey(450, 0, 0)) >>> print_extent_buffer(nodes[0]) leaf 30425088 level 0 items 184 generation 9 owner 5 leaf 30425088 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da ... item 179 key (450 INODE_ITEM 0) itemoff 4907 itemsize 160 generation 7 transid 7 size 4096 nbytes 12288 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 6 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417703.220000000 (2024-05-22 15:41:43) mtime 1716417703.220000000 (2024-05-22 15:41:43) otime 1716417703.220000000 (2024-05-22 15:41:43) item 180 key (450 INODE_REF 256) itemoff 4894 itemsize 13 index 195 namelen 3 name: 193 item 181 key (450 XATTR_ITEM 1640047104) itemoff 4857 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 182 key (450 EXTENT_DATA 0) itemoff 4804 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 8192 ram 12288 extent compression 0 (none) item 183 key (450 EXTENT_DATA 8192) itemoff 4751 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 Item 5 in the log tree corresponds to item 183 in the filesystem tree, but nothing matches item 4. Furthermore, item 183 is the last item in the leaf. btrfs_log_prealloc_extents() is responsible for logging prealloc extents beyond i_size. It first truncates any previously logged prealloc extents that start beyond i_size. Then, it walks the filesystem tree and copies the prealloc extent items to the log tree. If it hits the end of a leaf, then it calls btrfs_next_leaf(), which unlocks the tree and does another search. However, while the filesystem tree is unlocked, an ordered extent completion may modify the tree. In particular, it may insert an extent item that overlaps with an extent item that was already copied to the log tree. This may manifest in several ways depending on the exact scenario, including an EEXIST error that is silently translated to a full sync, overlapping items in the log tree, or this crash. This particular crash is triggered by the following sequence of events: - Initially, the file has i_size=4k, a regular extent from 0-4k, and a prealloc extent beyond i_size from 4k-12k. The prealloc extent item is the last item in its B-tree leaf. - The file is fsync'd, which copies its inode item and both extent items to the log tree. - An xattr is set on the file, which sets the BTRFS_INODE_COPY_EVERYTHING flag. - The range 4k-8k in the file is written using direct I/O. i_size is extended to 8k, but the ordered extent is still in flight. - The file is fsync'd. Since BTRFS_INODE_COPY_EVERYTHING is set, this calls copy_inode_items_to_log(), which calls btrfs_log_prealloc_extents(). - btrfs_log_prealloc_extents() finds the 4k-12k prealloc extent in the filesystem tree. Since it starts before i_size, it skips it. Since it is the last item in its B-tree leaf, it calls btrfs_next_leaf(). - btrfs_next_leaf() unlocks the path. - The ordered extent completion runs, which converts the 4k-8k part of the prealloc extent to written and inserts the remaining prealloc part from 8k-12k. - btrfs_next_leaf() does a search and finds the new prealloc extent 8k-12k. - btrfs_log_prealloc_extents() copies the 8k-12k prealloc extent into the log tree. Note that it overlaps with the 4k-12k prealloc extent that was copied to the log tree by the first fsync. - fsync calls btrfs_log_changed_extents(), which tries to log the 4k-8k extent that was written. - This tries to drop the range 4k-8k in the log tree, which requires adjusting the start of the 4k-12k prealloc extent in the log tree to 8k. - btrfs_set_item_key_safe() sees that there is already an extent starting at 8k in the log tree and calls BUG(). Fix this by detecting when we're about to insert an overlapping file extent item in the log tree and truncating the part that would overlap. CC: stable@vger.kernel.org # 6.1+ Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Omar Sandoval <osandov@fb.com> Signed-off-by: David Sterba <dsterba@suse.com>

hyphop added 2 commits March 23, 2020 14:09

zstd_support

147b608

defconfig_change_zstd_improve_squashfs

e712d99

numbqq merged commit 5f42d8e into khadas:khadas-vims-4.9.y Mar 23, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Khadas vims 4.9.y #16

Khadas vims 4.9.y #16

hyphop commented Mar 23, 2020

Khadas vims 4.9.y #16

Khadas vims 4.9.y #16

Conversation

hyphop commented Mar 23, 2020