profile
viewpoint
Rémy Oudompheng remyoudompheng Paris, France

remyoudompheng/go-misc 116

Miscellaneous Go toys

remyoudompheng/bigfft 44

Big integer multiplication library for Go using Fast Fourier transform

remyoudompheng/go-vectops 26

Vgo is a compiler for vector expressions. It generates SSE2 code for amd64.

remyoudompheng/gigot 21

Gigot is a Go implementation of Git storage layer.

remyoudompheng/go-netlink 15

A go library implementing parts of the Linux netlink protocol

remyoudompheng/go-liblzma 8

Go bindings for XZ Utils/liblzma

remyoudompheng/gdb-ghcrts 7

GDB plugin to display runtime info in GHC-compiled programs

remyoudompheng/go-alpm 6

go bindings to pacman's libalpm

remyoudompheng/go-aurjson 4

Small client for Archlinux's AUR-JSON interface

remyoudompheng/dwm 3

dwm hacks: learning to use XCB

push eventremyoudompheng/android_kernel_motorola_msm8952

Jan Kara

commit sha 790087d5a85193d6eb0cde2e1b1d530d8fab5752

ext4: fix crash during online resizing commit f96c3ac8dfc24b4e38fc4c2eba5fea2107b929d1 upstream. When computing maximum size of filesystem possible with given number of group descriptor blocks, we forget to include s_first_data_block into the number of blocks. Thus for filesystems with non-zero s_first_data_block it can happen that computed maximum filesystem size is actually lower than current filesystem size which confuses the code and eventually leads to a BUG_ON in ext4_alloc_group_tables() hitting on flex_gd->count == 0. The problem can be reproduced like: truncate -s 100g /tmp/image mkfs.ext4 -b 1024 -E resize=262144 /tmp/image 32768 mount -t ext4 -o loop /tmp/image /mnt resize2fs /dev/loop0 262145 resize2fs /dev/loop0 300000 Fix the problem by properly including s_first_data_block into the computed number of filesystem blocks. Fixes: 1c6bd7173d66 "ext4: convert file system to meta_bg if needed..." Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Lukas Czerner

commit sha cc6891edf8dc04cbb72ac68cda60002dc7049a78

ext4: fix data corruption caused by unaligned direct AIO commit 372a03e01853f860560eade508794dd274e9b390 upstream. Ext4 needs to serialize unaligned direct AIO because the zeroing of partial blocks of two competing unaligned AIOs can result in data corruption. However it decides not to serialize if the potentially unaligned aio is past i_size with the rationale that no pending writes are possible past i_size. Unfortunately if the i_size is not block aligned and the second unaligned write lands past i_size, but still into the same block, it has the potential of corrupting the previous unaligned write to the same block. This is (very simplified) reproducer from Frank // 41472 = (10 * 4096) + 512 // 37376 = 41472 - 4096 ftruncate(fd, 41472); io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376); io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472); io_submit(io_ctx, 1, &iocbs[1]); io_submit(io_ctx, 1, &iocbs[2]); io_getevents(io_ctx, 2, 2, events, NULL); Without this patch the 512B range from 40960 up to the start of the second unaligned write (41472) is going to be zeroed overwriting the data written by the first write. This is a data corruption. 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 * 0000a000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 With this patch the data corruption is avoided because we will recognize the unaligned_aio and wait for the unwritten extent conversion. 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 * 0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 * 0000b200 Reported-by: Frank Sorenson <fsorenso@redhat.com> Signed-off-by: Lukas Czerner <lczerner@redhat.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Fixes: e9e3bcecf44c ("ext4: serialize unaligned asynchronous DIO") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Kirill Tkhai

commit sha 4fa61db7566b248da562f04ab105ec79a4bbbf1d

ext4: actually request zeroing of inode table after grow commit 310a997fd74de778b9a4848a64be9cda9f18764a upstream. It is never possible, that number of block groups decreases, since only online grow is supported. But after a growing occured, we have to zero inode tables for just created new block groups. Fixes: 19c5246d2516 ("ext4: add new online resize interface") Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Colin Ian King

commit sha f87be4ee3e434401f0d64da9858eabe6d65fb61a

ext4: set error return correctly when ext4_htree_store_dirent fails commit 7a14826ede1d714f0bb56de8167c0e519041eeda upstream. Currently when the call to ext4_htree_store_dirent fails the error return variable 'ret' is is not being set to the error code and variable count is instead, hence the error code is not being returned. Fix this by assigning ret to the error return code. Addresses-Coverity: ("Unused value") Fixes: 8af0f0822797 ("ext4: fix readdir error in the case of inline_data+dir_index") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Rakesh Pandit

commit sha d2e523ba5bbad682430ccca2306d9f0b0d9e383d

ext4: fix warning inside ext4_convert_unwritten_extents_endio commit e3d550c2c4f2f3dba469bc3c4b83d9332b4e99e1 upstream. Really enable warning when CONFIG_EXT4_DEBUG is set and fix missing first argument. This was introduced in commit ff95ec22cd7f ("ext4: add warning to ext4_convert_unwritten_extents_endio") and splitting extents inside endio would trigger it. Fixes: ff95ec22cd7f ("ext4: add warning to ext4_convert_unwritten_extents_endio") Signed-off-by: Rakesh Pandit <rakesh@tuxera.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Ben Hutchings

commit sha 1b05cb3a868a3d43fab9eaceb4bd07f0a144e3fd

ext4: Introduce ext4_clamp_want_extra_isize() Based on commit 7bc04c5c2cc4 "ext4: fix use-after-free race with debug_want_extra_isize". We don't have that bug but this will make it easier to backport commit 4ea99936a163 "ext4: add more paranoia checking in ext4_expand_extra_isize handling". Cc: Barret Rhoden <brho@google.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Theodore Ts'o

commit sha 9b2cb3b9b645c42fe6016325dfde1243632fe4bd

ext4: add more paranoia checking in ext4_expand_extra_isize handling commit 4ea99936a1630f51fc3a2d61a58ec4a1c4b7d55a upstream. It's possible to specify a non-zero s_want_extra_isize via debugging option, and this can cause bad things(tm) to happen when using a file system with an inode size of 128 bytes. Add better checking when the file system is mounted, as well as when we are actually doing the trying to do the inode expansion. Link: https://lore.kernel.org/r/20191110121510.GH23325@mit.edu Reported-by: syzbot+f8d6f8386ceacdbfff57@syzkaller.appspotmail.com Reported-by: syzbot+33d7ea72e47de3bdf4e1@syzkaller.appspotmail.com Reported-by: syzbot+44b6763edfc17144296f@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 3.16: - Use EIO instead of EFSCORRUPTED - Adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Theodore Ts'o

commit sha 0a359b08038dcf29d6c21ebb089ab7f7a5a966db

ext4: work around deleting a file with i_nlink == 0 safely commit c7df4a1ecb8579838ec8c56b2bb6a6716e974f37 upstream. If the file system is corrupted such that a file's i_links_count is too small, then it's possible that when unlinking that file, i_nlink will already be zero. Previously we were working around this kind of corruption by forcing i_nlink to one; but we were doing this before trying to delete the directory entry --- and if the file system is corrupted enough that ext4_delete_entry() fails, then we exit with i_nlink elevated, and this causes the orphan inode list handling to be FUBAR'ed, such that when we unmount the file system, the orphan inode list can get corrupted. A better way to fix this is to simply skip trying to call drop_nlink() if i_nlink is already zero, thus moving the check to the place where it makes the most sense. https://bugzilla.kernel.org/show_bug.cgi?id=205433 Link: https://lore.kernel.org/r/20191112032903.8828-1-tytso@mit.edu Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Andreas Dilger <adilger@dilger.ca> [bwh: Backported to 3.16: Log message and function are different] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Shijie Luo

commit sha 4720ff3b3eb4535f91f2ea1422a59be49f466df0

ext4: add cond_resched() to __ext4_find_entry() commit 9424ef56e13a1f14c57ea161eed3ecfdc7b2770e upstream. We tested a soft lockup problem in linux 4.19 which could also be found in linux 5.x. When dir inode takes up a large number of blocks, and if the directory is growing when we are searching, it's possible the restart branch could be called many times, and the do while loop could hold cpu a long time. Here is the call trace in linux 4.19. [ 473.756186] Call trace: [ 473.756196] dump_backtrace+0x0/0x198 [ 473.756199] show_stack+0x24/0x30 [ 473.756205] dump_stack+0xa4/0xcc [ 473.756210] watchdog_timer_fn+0x300/0x3e8 [ 473.756215] __hrtimer_run_queues+0x114/0x358 [ 473.756217] hrtimer_interrupt+0x104/0x2d8 [ 473.756222] arch_timer_handler_virt+0x38/0x58 [ 473.756226] handle_percpu_devid_irq+0x90/0x248 [ 473.756231] generic_handle_irq+0x34/0x50 [ 473.756234] __handle_domain_irq+0x68/0xc0 [ 473.756236] gic_handle_irq+0x6c/0x150 [ 473.756238] el1_irq+0xb8/0x140 [ 473.756286] ext4_es_lookup_extent+0xdc/0x258 [ext4] [ 473.756310] ext4_map_blocks+0x64/0x5c0 [ext4] [ 473.756333] ext4_getblk+0x6c/0x1d0 [ext4] [ 473.756356] ext4_bread_batch+0x7c/0x1f8 [ext4] [ 473.756379] ext4_find_entry+0x124/0x3f8 [ext4] [ 473.756402] ext4_lookup+0x8c/0x258 [ext4] [ 473.756407] __lookup_hash+0x8c/0xe8 [ 473.756411] filename_create+0xa0/0x170 [ 473.756413] do_mkdirat+0x6c/0x140 [ 473.756415] __arm64_sys_mkdirat+0x28/0x38 [ 473.756419] el0_svc_common+0x78/0x130 [ 473.756421] el0_svc_handler+0x38/0x78 [ 473.756423] el0_svc+0x8/0xc [ 485.755156] watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [tmp:5149] Add cond_resched() to avoid soft lockup and to provide a better system responding. Link: https://lore.kernel.org/r/20200215080206.13293-1-luoshijie1@huawei.com Signed-off-by: Shijie Luo <luoshijie1@huawei.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Jan Kara <jack@suse.cz> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Ethan Wu

commit sha 01910a5de4f8b9337087e9924733e522cd6591cd

Support exfat capacity more than 2TB - Change the size of num_sectors in memory to 64 bits as it is in on-disk structure. - Use type 'sector_t' for all sector variables. - Fix overflow issue of macro START_SECTOR(x) Reviewed-by: Peter Huang <peterh@synology.com> Signed-off-by: Chung-Chiang Cheng <cccheng@synology.com>

view details

Yuri.Sh

commit sha 16290bc380c25dd89fdf88d1ff5f4437c6b71faa

exfat: Make sure all delayed rcu free inodes are flushed before we destroy cache. This fix was added to all FS drivers in 3.6.0 -rc7 and was missing here. https://github.com/torvalds/linux/commit/8c0a85377048b64c880e76ec7368904fe46d0b94

view details

Peter Huang

commit sha ad58bdaf27d74b62cc56c0bcd9dbd4503cd41a82

exfat: Fix leak for symbolic link in exfat_lookup While exfat_lookup() for symbolic file, we Should not alloc memory to EXFAT_I(inode)->target since the corredspoding exfat inode info is still is in memory and EXFAT_I(inode)->target has not released yet. If we do so, memory leak would happen. Therefore we only alloc it if not null. Reviewed-by: Ethan Wu <ethanwu@synology.com> Signed-off-by: Chung-Chiang Cheng <cccheng@synology.com>

view details

Will Deacon

commit sha ad2575c4b78b41510ffee424e20f31dbfec48c12

ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions commit a469abd0f868c902b75532579bf87553dcf1b360 upstream. CPUs implementing LPAE have atomic ldrd/strd instructions, meaning that userspace software can avoid having to use the exclusive variants of these instructions if they wish. This patch advertises the atomicity of these instructions via the hwcaps, so userspace can detect this CPU feature. Reported-by: Vladimir Danushevsky <vladimir.danushevsky@oracle.com> Signed-off-by: Will Deacon <will.deacon@arm.com>

view details

Ard Biesheuvel

commit sha feb45536603553a27bcc569d0de817b35fce8fbf

ARM: 7981/1: add support for AT_HWCAP2 ELF auxv entry commit b342ea4e4ff970518264c81eefd05f637e3f193a upstream. This enables AT_HWCAP2 for ARM. The generic support for this new ELF auxv entry was added in commit 2171364d1a9 (powerpc: Add HWCAP2 aux entry) Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

view details

Russell King

commit sha ca1326c2021759807f616ded9dc0f5ec5091f032

ARM: make it easier to check the CPU part number correctly commit af040ffc9ba1e079ee4c0748aff64fa3d4716fa5 upstream. Ensure that platform maintainers check the CPU part number in the right manner: the CPU part number is meaningless without also checking the CPU implement(e|o)r (choose your preferred spelling!) Provide an interface which returns both the implementer and part number together, and update the definitions to include the implementer. Mark the old function as being deprecated... indeed, using the old function with the definitions will now always evaluate as false, so people must update their un-merged code to the new function. While this could be avoided by adding new definitions, we'd also have to create new names for them which would be awkward. Acked-by: Nicolas Pitre <nico@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> [backport 3.10: fix context]

view details

Ard Biesheuvel

commit sha a33ac4084b90d67d8b4d6096e07b645ee59c99fc

ARM: 7982/1: introduce HWCAP2 feature bits for ARMv8 Crypto Extensions commit 8258a9895c99cdaacad8edc4748c0a624c710961 upstream. This allocates feature bits 0-4 in HWCAP2 for the crypto and CRC extensions introduced in ARMv8. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

view details

Juri Lelli

commit sha e8a3c3eb9b1debea1bceb6cb73e369f65c069422

ARM: 8130/1: cpuidle/cpuidle-big_little: fix reading cpu id part number commit eba1c71819d210f5e0d522571f9b8abce94fe9c5 upstream. Commit af040ffc9ba1 ("ARM: make it easier to check the CPU part number correctly") changed ARM_CPU_PART_X masks, and the way they are returned and checked against. Usage of read_cpuid_part_number() is now deprecated, and calling places updated accordingly. This actually broke cpuidle-big_little initialization, as bl_idle_driver_init() performs a check using an hardcoded mask on cpu_id. Create an interface to perform the check (that is now even easier to read). Define also a proper mask (ARM_CPU_PART_MASK) that makes this kind of checks cleaner and helps preventing bugs in the future. Update usage accordingly. Signed-off-by: Juri Lelli <juri.lelli@arm.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> [bp 3.10: drivers/cpuidle/cpuidle-big_little.c does not exist]

view details

Russell King

commit sha c8b54aec4773145961711d4fca3440e0dd8ab656

ARM: hwcap: disable HWCAP_SWP if the CPU advertises it has exclusives commit 58171bf2af6b547a560b304f6ab2b9edf1c31d5a upstream. When the CPU has support for the byte and word exclusive operations, userspace should use them in preference to the SWP instructions. Detect the presence of these instructions by reading the ISAR CPU ID registers and adjust the ELF HWCAP mask appropriately. Note that ARM1136 < r1p0 has no ISAR4, so this is explicitly detected and the test disabled, leaving the current situation where HWCAP_SWP is set. Tested-by: Tony Lindgren <tony@atomide.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

view details

Ard Biesheuvel

commit sha b06dd8003fc7d2fccb4ae1a0a8fcd213299f216f

ARM: 8318/1: treat CPU feature register fields as signed quantities commit b8c9592b4a6c93211c8163888a97880d608503b5 upstream. The various CPU feature registers consist of 4-bit blocks that represent signed quantities, whose positive values represent incremental features, and whose negative values are reserved. To improve forward compatibility, update the feature detection code to take possible future higher values into account, but ignore negative values. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

view details

Ard Biesheuvel

commit sha afdc02d35ba13a657dc7bca372274df82102bedc

ARM: 8319/1: advertise availability of v8 Crypto instructions commit a092aedb8115c16cb49bc64dd09cb20471ff942b upstream. When running the 32-bit ARM kernel on ARMv8 capable bare metal (e.g., 32-bit Android userland and kernel on a Cortex-A53), or as a KVM guest on a 64-bit host, we should advertise the availability of the Crypto instructions, so that userland libraries such as OpenSSL may use them. (Support for the v8 Crypto instructions in the 32-bit build was added to OpenSSL more than six months ago) This adds the ID feature bit detection, and sets elf_hwcap2 accordingly. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

view details

push time in a month

push eventremyoudompheng/android_kernel_motorola_msm8952

Jan Kara

commit sha 790087d5a85193d6eb0cde2e1b1d530d8fab5752

ext4: fix crash during online resizing commit f96c3ac8dfc24b4e38fc4c2eba5fea2107b929d1 upstream. When computing maximum size of filesystem possible with given number of group descriptor blocks, we forget to include s_first_data_block into the number of blocks. Thus for filesystems with non-zero s_first_data_block it can happen that computed maximum filesystem size is actually lower than current filesystem size which confuses the code and eventually leads to a BUG_ON in ext4_alloc_group_tables() hitting on flex_gd->count == 0. The problem can be reproduced like: truncate -s 100g /tmp/image mkfs.ext4 -b 1024 -E resize=262144 /tmp/image 32768 mount -t ext4 -o loop /tmp/image /mnt resize2fs /dev/loop0 262145 resize2fs /dev/loop0 300000 Fix the problem by properly including s_first_data_block into the computed number of filesystem blocks. Fixes: 1c6bd7173d66 "ext4: convert file system to meta_bg if needed..." Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Lukas Czerner

commit sha cc6891edf8dc04cbb72ac68cda60002dc7049a78

ext4: fix data corruption caused by unaligned direct AIO commit 372a03e01853f860560eade508794dd274e9b390 upstream. Ext4 needs to serialize unaligned direct AIO because the zeroing of partial blocks of two competing unaligned AIOs can result in data corruption. However it decides not to serialize if the potentially unaligned aio is past i_size with the rationale that no pending writes are possible past i_size. Unfortunately if the i_size is not block aligned and the second unaligned write lands past i_size, but still into the same block, it has the potential of corrupting the previous unaligned write to the same block. This is (very simplified) reproducer from Frank // 41472 = (10 * 4096) + 512 // 37376 = 41472 - 4096 ftruncate(fd, 41472); io_prep_pwrite(iocbs[0], fd, buf[0], 4096, 37376); io_prep_pwrite(iocbs[1], fd, buf[1], 4096, 41472); io_submit(io_ctx, 1, &iocbs[1]); io_submit(io_ctx, 1, &iocbs[2]); io_getevents(io_ctx, 2, 2, events, NULL); Without this patch the 512B range from 40960 up to the start of the second unaligned write (41472) is going to be zeroed overwriting the data written by the first write. This is a data corruption. 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 * 0000a000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 With this patch the data corruption is avoided because we will recognize the unaligned_aio and wait for the unwritten extent conversion. 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 * 00009200 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 * 0000a200 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 31 * 0000b200 Reported-by: Frank Sorenson <fsorenso@redhat.com> Signed-off-by: Lukas Czerner <lczerner@redhat.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Fixes: e9e3bcecf44c ("ext4: serialize unaligned asynchronous DIO") Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Kirill Tkhai

commit sha 4fa61db7566b248da562f04ab105ec79a4bbbf1d

ext4: actually request zeroing of inode table after grow commit 310a997fd74de778b9a4848a64be9cda9f18764a upstream. It is never possible, that number of block groups decreases, since only online grow is supported. But after a growing occured, we have to zero inode tables for just created new block groups. Fixes: 19c5246d2516 ("ext4: add new online resize interface") Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Colin Ian King

commit sha f87be4ee3e434401f0d64da9858eabe6d65fb61a

ext4: set error return correctly when ext4_htree_store_dirent fails commit 7a14826ede1d714f0bb56de8167c0e519041eeda upstream. Currently when the call to ext4_htree_store_dirent fails the error return variable 'ret' is is not being set to the error code and variable count is instead, hence the error code is not being returned. Fix this by assigning ret to the error return code. Addresses-Coverity: ("Unused value") Fixes: 8af0f0822797 ("ext4: fix readdir error in the case of inline_data+dir_index") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Rakesh Pandit

commit sha d2e523ba5bbad682430ccca2306d9f0b0d9e383d

ext4: fix warning inside ext4_convert_unwritten_extents_endio commit e3d550c2c4f2f3dba469bc3c4b83d9332b4e99e1 upstream. Really enable warning when CONFIG_EXT4_DEBUG is set and fix missing first argument. This was introduced in commit ff95ec22cd7f ("ext4: add warning to ext4_convert_unwritten_extents_endio") and splitting extents inside endio would trigger it. Fixes: ff95ec22cd7f ("ext4: add warning to ext4_convert_unwritten_extents_endio") Signed-off-by: Rakesh Pandit <rakesh@tuxera.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Ben Hutchings

commit sha 1b05cb3a868a3d43fab9eaceb4bd07f0a144e3fd

ext4: Introduce ext4_clamp_want_extra_isize() Based on commit 7bc04c5c2cc4 "ext4: fix use-after-free race with debug_want_extra_isize". We don't have that bug but this will make it easier to backport commit 4ea99936a163 "ext4: add more paranoia checking in ext4_expand_extra_isize handling". Cc: Barret Rhoden <brho@google.com> Cc: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Theodore Ts'o

commit sha 9b2cb3b9b645c42fe6016325dfde1243632fe4bd

ext4: add more paranoia checking in ext4_expand_extra_isize handling commit 4ea99936a1630f51fc3a2d61a58ec4a1c4b7d55a upstream. It's possible to specify a non-zero s_want_extra_isize via debugging option, and this can cause bad things(tm) to happen when using a file system with an inode size of 128 bytes. Add better checking when the file system is mounted, as well as when we are actually doing the trying to do the inode expansion. Link: https://lore.kernel.org/r/20191110121510.GH23325@mit.edu Reported-by: syzbot+f8d6f8386ceacdbfff57@syzkaller.appspotmail.com Reported-by: syzbot+33d7ea72e47de3bdf4e1@syzkaller.appspotmail.com Reported-by: syzbot+44b6763edfc17144296f@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 3.16: - Use EIO instead of EFSCORRUPTED - Adjust context] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Theodore Ts'o

commit sha 0a359b08038dcf29d6c21ebb089ab7f7a5a966db

ext4: work around deleting a file with i_nlink == 0 safely commit c7df4a1ecb8579838ec8c56b2bb6a6716e974f37 upstream. If the file system is corrupted such that a file's i_links_count is too small, then it's possible that when unlinking that file, i_nlink will already be zero. Previously we were working around this kind of corruption by forcing i_nlink to one; but we were doing this before trying to delete the directory entry --- and if the file system is corrupted enough that ext4_delete_entry() fails, then we exit with i_nlink elevated, and this causes the orphan inode list handling to be FUBAR'ed, such that when we unmount the file system, the orphan inode list can get corrupted. A better way to fix this is to simply skip trying to call drop_nlink() if i_nlink is already zero, thus moving the check to the place where it makes the most sense. https://bugzilla.kernel.org/show_bug.cgi?id=205433 Link: https://lore.kernel.org/r/20191112032903.8828-1-tytso@mit.edu Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Andreas Dilger <adilger@dilger.ca> [bwh: Backported to 3.16: Log message and function are different] Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

view details

Shijie Luo

commit sha 4720ff3b3eb4535f91f2ea1422a59be49f466df0

ext4: add cond_resched() to __ext4_find_entry() commit 9424ef56e13a1f14c57ea161eed3ecfdc7b2770e upstream. We tested a soft lockup problem in linux 4.19 which could also be found in linux 5.x. When dir inode takes up a large number of blocks, and if the directory is growing when we are searching, it's possible the restart branch could be called many times, and the do while loop could hold cpu a long time. Here is the call trace in linux 4.19. [ 473.756186] Call trace: [ 473.756196] dump_backtrace+0x0/0x198 [ 473.756199] show_stack+0x24/0x30 [ 473.756205] dump_stack+0xa4/0xcc [ 473.756210] watchdog_timer_fn+0x300/0x3e8 [ 473.756215] __hrtimer_run_queues+0x114/0x358 [ 473.756217] hrtimer_interrupt+0x104/0x2d8 [ 473.756222] arch_timer_handler_virt+0x38/0x58 [ 473.756226] handle_percpu_devid_irq+0x90/0x248 [ 473.756231] generic_handle_irq+0x34/0x50 [ 473.756234] __handle_domain_irq+0x68/0xc0 [ 473.756236] gic_handle_irq+0x6c/0x150 [ 473.756238] el1_irq+0xb8/0x140 [ 473.756286] ext4_es_lookup_extent+0xdc/0x258 [ext4] [ 473.756310] ext4_map_blocks+0x64/0x5c0 [ext4] [ 473.756333] ext4_getblk+0x6c/0x1d0 [ext4] [ 473.756356] ext4_bread_batch+0x7c/0x1f8 [ext4] [ 473.756379] ext4_find_entry+0x124/0x3f8 [ext4] [ 473.756402] ext4_lookup+0x8c/0x258 [ext4] [ 473.756407] __lookup_hash+0x8c/0xe8 [ 473.756411] filename_create+0xa0/0x170 [ 473.756413] do_mkdirat+0x6c/0x140 [ 473.756415] __arm64_sys_mkdirat+0x28/0x38 [ 473.756419] el0_svc_common+0x78/0x130 [ 473.756421] el0_svc_handler+0x38/0x78 [ 473.756423] el0_svc+0x8/0xc [ 485.755156] watchdog: BUG: soft lockup - CPU#2 stuck for 22s! [tmp:5149] Add cond_resched() to avoid soft lockup and to provide a better system responding. Link: https://lore.kernel.org/r/20200215080206.13293-1-luoshijie1@huawei.com Signed-off-by: Shijie Luo <luoshijie1@huawei.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Jan Kara <jack@suse.cz> Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

view details

Ethan Wu

commit sha 01910a5de4f8b9337087e9924733e522cd6591cd

Support exfat capacity more than 2TB - Change the size of num_sectors in memory to 64 bits as it is in on-disk structure. - Use type 'sector_t' for all sector variables. - Fix overflow issue of macro START_SECTOR(x) Reviewed-by: Peter Huang <peterh@synology.com> Signed-off-by: Chung-Chiang Cheng <cccheng@synology.com>

view details

Yuri.Sh

commit sha 16290bc380c25dd89fdf88d1ff5f4437c6b71faa

exfat: Make sure all delayed rcu free inodes are flushed before we destroy cache. This fix was added to all FS drivers in 3.6.0 -rc7 and was missing here. https://github.com/torvalds/linux/commit/8c0a85377048b64c880e76ec7368904fe46d0b94

view details

Peter Huang

commit sha ad58bdaf27d74b62cc56c0bcd9dbd4503cd41a82

exfat: Fix leak for symbolic link in exfat_lookup While exfat_lookup() for symbolic file, we Should not alloc memory to EXFAT_I(inode)->target since the corredspoding exfat inode info is still is in memory and EXFAT_I(inode)->target has not released yet. If we do so, memory leak would happen. Therefore we only alloc it if not null. Reviewed-by: Ethan Wu <ethanwu@synology.com> Signed-off-by: Chung-Chiang Cheng <cccheng@synology.com>

view details

push time in a month

issue commentremyoudompheng/bigfft

Support s390x?

Done. Please let me know in case of issues.

xhit

comment created time in 2 months

push eventremyoudompheng/bigfft

Rémy Oudompheng

commit sha eec4a21b6bb01e5c1260ca5e04d0c58e11e20f30

Add stub file for S/390 arithmetic routines. Fixes #9

view details

push time in 2 months

issue closedremyoudompheng/bigfft

Support s390x?

closed time in 2 months

xhit

push eventremyoudompheng/android_external_exfat

relan

commit sha b9552ca2f9d746a72063165c7d461f3e58e039a5

Use DIV_ROUND_UP macro.

view details

relan

commit sha 449b965b88d5f9b85435ba6d742b37177c508404

Respect daylight saving time.

view details

relan

commit sha bc5c231dc66a4ed4cfeb416c42c42da7829316d9

Fix memory leak on error path when directory read fails.

view details

relan

commit sha e10d9d0b4176f7cfcff9c336309efd22de1ed6d4

Remove unused field of struct iterator.

view details

Daniel Drake

commit sha 1b38628dfde2ae1f71cfdecb9eb23c4d34a8b938

dumpexfat: add option to show file fragments. Add an option to show a list of fragments that a given file is composed of. This is useful for if you want to have low-level access to a file without going through the file system layers.

view details

Daniel Drake

commit sha c80517b50d9271abf2b832063a0ca129b564a5fa

dumpexfat: print version number only when requested. If the version number is printed only when the -V arg is given, it's easier to use the output of this tool in external scripts.

view details

relan

commit sha 1a2f610852cd0e045b79dddff0e24a851e5a790b

Improve error messages in opendir().

view details

relan

commit sha 74ab25d6e5994adda78c342b949a8eda35b27b39

Run all checks in check_node(). Do not stop node validation on the first error.

view details

relan

commit sha 575ba4bca69096d5c795f466f2fdd4600a36fd4f

Add node start cluster checks.

view details

relan

commit sha b7bac38b16acf6bc6d84d3ad8906fcf0d3c538b0

Move meta2 fields checking into check_node(). There we know node name and print it if an error is detected.

view details

relan

commit sha 0a11f088786d24e067a9222148c14a477a523c5d

Bump version to 1.2.5 and update changelog.

view details

relan

commit sha a061c5c65a3e3ddb646200966cf7ba5f51ef09ca

Fix max file name length. In exFAT file name limit is 255 16-bit code units, not 256. That's because name length field size is 1 byte.

view details

relan

commit sha 386a87abe72cbacc68c0bac82384a8db4940c2a9

Refactor file entry checksum calculation. Move actual algorithm implementation into add_checksum_byte() function. Avoid utf16_length() call: we already have valid file name length. Avoid extra data copying: take it from the name buffer instead of making a temporary file name entry.

view details

relan

commit sha 615b0cae5dd1bdaca7a719347627beea421a0b92

Avoid name length calculation in exfat_calc_name_hash(). We always know it when exfat_calc_name_hash() is called, so pass file name length as an argument.

view details

relan

commit sha e62b9699508e26f3865918bb75bef199cb5627df

Remove buffer size argument for exfat_get_name(). The output buffer is always UTF8_BYTES(EXFAT_NAME_MAX)+1 characters. No need to repeat this every time.

view details

relan

commit sha 758e96d2be3b4ca302a3169454e39028edac58a0

Change output buffer size semantics for UTF functions. Make them consistent with other string functions: now output buffer size includes potential null terminator, i.e. this is total size. This change also means that if output buffer isn't large enough it can be left unterminated (indicated by the -ENAMETOOLONG return value).

view details

relan

commit sha 088ea8a362ab77d93699b7da72d9b1abf164b59c

Reduce the sizes of name buffers. EXFAT_NAME_MAX is the number of 16-bit code units, not Unicode characters. When converting to UTF-8, 3 bytes are enough to keep any Unicode character encoded by a 16-bit code unit.

view details

relan

commit sha ca112f07b115a419250b6526e71345dcd29e4d67

Propagate ENOSPC on write. Return -errno from exfat_generic_pread()/exfat_generic_pwrite() functions to distinguish between I/O error and out-of-space error.

view details

relan

commit sha 6f8123064cab7a46c3d81ba6fef1190262534d28

Use ROUND_UP() macro instead of DIV_ROUND_UP().

view details

relan

commit sha 7157501b8b2202f0c8fcc204cb2b82de9596a8e6

Rename write_entry() to commit_entry(). This function doesn't just write an entry, it also constructs a new node and adds it into the tree.

view details

push time in 2 months

push eventremyoudompheng/android_packages_inputmethods_LatinIME

Rémy Oudompheng

commit sha 86a478a39dc3c77d02a2b41dce2586df9abb6c57

Fix hair style modifiers and update reference to Emoji 12.1

view details

push time in 2 months

push eventremyoudompheng/gdb-ghcrts

Rémy Oudompheng

commit sha fa618da45f50a19c54237272c0545f340ac8f272

Attempt to pretty-print frames for anonymous closures

view details

push time in 3 months

push eventremyoudompheng/gdb-ghcrts

Rémy Oudompheng

commit sha 6ea05faf01688aab555994fbc83a233fd78fc3db

First version.

view details

push time in 3 months

create barnchremyoudompheng/gdb-ghcrts

branch : master

created branch time in 3 months

created repositoryremyoudompheng/gdb-ghcrts

GDB plugin to display runtime info in GHC-compiled programs

created time in 3 months

issue commentgolang/go

math/big: panic in big.ParseFloat (off by one access)

I switched to strings for the test case so that a single test case can be used for 32-bit and 64-bit platforms (the stringified version also fails with GOARCH=386 and go1.14).

catenacyber

comment created time in 3 months

issue commentgolang/go

math/big: panic in big.ParseFloat (off by one access)

I understand @griesemer comment now, indeed, the precondition of divBasic is not violated here (but it's incorrectly documented: the true precondition is "q is large enough to hold the quotient of u / v") and is properly ensured here.

The change introduced in divBasic, was to remove the assumption that u always had an extra word at the top. But I didn't expect that the code would require it. It happens every time the 1st word quotient is inaccurate on the first loop iteration, which happens when the top words are very close to each other. The example given by @griesemer can be minified further like this :

func TestNatDivBasic(t *testing.T) {                              
      q := nat(nil).make(4)                                       
                                                                  
      u := nat{16376284702921012097, 13094865702141265827,        
            4177168489727452539, 7329502793467785323,             
            6638869193213356561, 3128937800410202751}             
      v := nat{7329502793467785324,                               
            6638869193213356561, 3128937800410202751}             
      q.divBasic(u, v)                                            
      t.Logf("%v", q)                                             
}

The D3 of divBasic computes an approximate first word by looking at the first word, but it may still be off by one. In step D4

            c := subVV(u[j:j+qhl], u[j:], qhatv)
            if c != 0 {
                  c := addVV(u[j:j+n], u[j:], v)
                  u[j+n] += c
                  qhat--
            }

in case we are off-by-one, subVV will create a "negative" number, to be offset by re-adding v. So it is normal to have a carry here, the subtlely is that the second c should offset the first c, and thus not be added to u[j+n] (in the previous code, u[j+n] would be -1). It was not an issue in the previous code because qhatv was always larger than v.

I believe the appropriate patch is this one:

diff --git a/src/math/big/nat.go b/src/math/big/nat.go
index 1b771ca7c6..aab49a1416 100644
--- a/src/math/big/nat.go
+++ b/src/math/big/nat.go
@@ -740,7 +740,8 @@ func (z nat) divLarge(u, uIn, vIn nat) (q, r nat) {
 // The remainder overwrites input u.
 //
 // Precondition:
-// - len(q) >= len(u)-len(v)
+// - q is large enough to hold the quotient u / v
+//   which has length len(u)-len(v) or len(u)-len(v)+1
 func (q nat) divBasic(u, v nat) {
        n := len(v)
        m := len(u) - n
@@ -779,6 +780,8 @@ func (q nat) divBasic(u, v nat) {
                }
 
                // D4.
+               // Compute the remainder u - W^j q̂ v,
+               // the substraction may overflow if q̂ estimate was off by one.
                qhatv[n] = mulAddVWW(qhatv[0:n], v, qhat, 0)
                qhl := len(qhatv)
                if j+qhl > len(u) && qhatv[n] == 0 {
@@ -787,7 +790,11 @@ func (q nat) divBasic(u, v nat) {
                c := subVV(u[j:j+qhl], u[j:], qhatv)
                if c != 0 {
                        c := addVV(u[j:j+n], u[j:], v)
-                       u[j+n] += c
+                       if n < qhl {
+                               // If n == qhl, the previous carry was ignored
+                               // and offsets this one.
+                               u[j+n] += c
+                       }
                        qhat--
                }
 

i will format it as a proper review later today.

catenacyber

comment created time in 3 months

issue commentgolang/go

math/big: panic in big.ParseFloat (off by one access)

I am going to look at this by tomorrow.

catenacyber

comment created time in 3 months

more