-
Notifications
You must be signed in to change notification settings - Fork 1.3k
stable v2.39.3 #2599
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
stable v2.39.3 #2599
Conversation
Fixes util-linux#2462 Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Fixes util-linux#2461 Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Fixes: util-linux#2460 Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Using sys/stat.h and linux/stat is too tricky.h together. It seems better to rely on libc and use sys/stat.h only. Users affected by old libc must update to use recent util-linux. Fixes: util-linux#2448 Signed-off-by: Karel Zak <kzak@redhat.com>
Let's make statx() support visible in "mount -V" output. Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Signed-off-by: Karel Zak <kzak@redhat.com>
Some lines in /proc/cpuinfo can be large e.g. flags and can then truncate them in displaying them BUFSIZ can vary quite a bit e.g. glibc/linux systems its 8192 but on musl/linux and OSX its 1024, on mingW it is 256, some tests e.g. x86_64-64cpu-linux6.2.tar.gz has added really long line for cpu flags line which is greater than 1024 characters and hence this test fails on musl because lscpu -s reports truncated string Fixes x86_64-64cpu-linux6.2 tests Signed-off-by: Khem Raj <raj.khem@gmail.com> s
Reported-by: Samuel Thibault <samuel.thibault@aquilenet.fr> Signed-off-by: Karel Zak <kzak@redhat.com>
In 0b4d75f the variable "timeout" has been moved from global to local scope, but its comment was not. Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Since child_pid keeps track of a PID, it should be of type pid_t and not of type int. Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
The realloc() needs to happen before that memory is used. Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
read_all_alloc() returns a negative error on failure. When casting this to an unsigned type the failure check "< 1" will not work. Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
If stat() fails the realloc loop would always try to allocate zero bytes. Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Instead use _exit(). Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
fputs(NULL) is not allowed. Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
The NTFS prober reads data based off an offset of the sector size. If the sector size is unaligned and the read data is cached then other probers can read unaligned values. Sector sizes for NTFS actually only make sense as power-of-two so validate that and as a sideeffect avoid the unaligned reads. Also add the reproducer from OSS-Fuzz that found this issue. Fixes util-linux#2509 Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
The "get" functions already do this and some callers rely on it also for "add" ones. For completeness also handle it in free_idcache(). Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
GitHub has dropped support for the git:// protocol: https://github.blog/changelog/2022-03-15-removed-unencrypted-git-protocol-and-certain-ssh-keys/
err_exclusive_options needs to be passed the long options array, otherwise it will crash. Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
Signed-off-by: Karel Zak <kzak@redhat.com>
The function utilizes the struct libmnt_itr to iterate through the mountinfo file but neglects the direction specified by the iterator. This a bug. The application must manage the direction, as, for instance, umount(8) requires the children of the mountpoint in reverse order. Fixes: util-linux#2552 Signed-off-by: Karel Zak <kzak@redhat.com>
... to fix: write: effective gid does not match group of /dev/pts/3
... for proper permissions.
Signed-off-by: Karel Zak <kzak@redhat.com>
Define cs_min through a define and not a const int to avoid the following build failure with -O0 raised since version 2.39 and util-linux@2fa4168: libuuid/src/gen_uuid.c: In function 'uuid_generate_time_generic': libuuid/src/gen_uuid.c:536:33: error: initializer element is not constant THREAD_LOCAL int cache_size = cs_min; ^~~~~~ For consistency, also use define for cs_max and cs_factor Fixes: - http://autobuild.buildroot.org/results/2f80a5cdb523cc3c8c0f3693607a1be036b2ae98 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Instead of explicitly truncating clocks.txt file, pad with whitespaces in the end of file. This is done to improve performance of libuuid on xfs filesystems. Instead of truncating the file, pad it with whitespaces. This is anyways used as a failsafe method in case truncate fails. The reason why this regression was introduced was because of: 869ae85dae64 ("xfs: flush new eof page on truncate to avoid post-eof corruption") An attempt to move the clocks.txt to /run (tmpfs) has been attempted before [1] and with commit ab2e7dd ("libuuid: move clock state file from /var/lib to /var/run"). The latter was reverted. [1] https://www.spinics.net/lists/util-linux-ng/msg17331.html Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Note: When cherry-picking commits to maintenance branches it's useful to use |
Thanks, I didn't know about -x. Frankly, I don't like the way I'm adding things to the stable branch. It would be better to do always when we merge bugfix to master and then push it to stable too. |
Ack |
The version superblock field has been split into a major and minor version part in the upstream code. Adapt libblkid to it. Link: https://lore.kernel.org/linux-bcachefs/20230709171551.2349961-11-kent.overstreet@linux.dev/ Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de> (cherry picked from commit 8beea16)
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de> (cherry picked from commit da91337)
I guess this needs d53284b for the test failures |
Also #2528 would be good to be fixed in 2.39.3 IMO. |
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de> (cherry picked from commit d53284b)
I have doubts we can in any simple way fix the overlay remount issue in v2.39.3. Maybe the best solution would be to fall back to classic mount(2) if fstype is overlay on remount. |
BTW, for overlay, there is a regression with a comma in options, see: It seems the best would be to support escape for comma, "bar=foo," should be used as "bar=foo", this is something we can try to support for v2.39.3. |
…/util-linux into PR/stable-v2.39.3 * 'stable-2.39/bcachefs-fixes' of https://github.com/t-8ch/util-linux: tests: skip broken tests on docker libblkid: (bcachefs) add support for sub-device labels libblkid: (bcachefs) adapt to major.minor version
FUSE is also affected. (See #2576). |
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de> (cherry picked from commit 023e77d)
The libmount library can accept any characters as an option value when the value is quoted (e.g., foo="b,a,r"). However, overlayfs users have been using '\' as an escape character (e.g., lowerdir=foo\,bar). Although this escaping mechanism was never officially supported by libmount/mount, it worked for the old mount(2) API because it kept the options string unparsed for the mount(2) syscall. The introduction of the new mount API, which utilizes fsconfig(2) per option, has brought attention to this issue. This patch addresses the problem by introducing official support for '\' as an escape character for options separator. Suggested-by: Miklos Szeredi <miklos@szeredi.hu> References: https://lore.kernel.org/all/CAOQ4uxhgUSPkYAV8SJu-SFszkJcVO3-M4DXf46nJUtXODrPk2g@mail.gmail.com/T/#ma8e6cfc1ce7229abc089e03eed99b23b90d701e5 Signed-off-by: Karel Zak <kzak@redhat.com> (cherry picked from commit f6c29ef)
fix:util-linux#2486 (cherry picked from commit b36a792)
Signed-off-by: zuoqian <zuoqian2023@gmail.com> (cherry picked from commit c5d9cc4)
Signed-off-by: Masatake YAMATO <yamato@redhat.com> (cherry picked from commit d0fe6e4)
Passing a pointer to a different datatype to tfind() then were inserted evokes undefines behavior. This triggers UBSAN as shown below. Instead pass the proper structs. ``` ../misc-utils/lsfd.c:513:27: runtime error: member access within misaligned address 0x7ffe9ee6495c for type 'struct proc', which requires 8 byte alignment 0x7ffe9ee6495c: note: pointer points here 1a 1a 1a 1a 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d0 49 e6 9e fe 7f 00 00 ^ #0 0x56159cfa4a3b in proc_tree_compare ../misc-utils/lsfd.c:513 #1 0x7f9dd4d2d743 in __tfind (/usr/lib/libc.so.6+0x10f743) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658) #2 0x56159cfa4ac3 in get_proc ../misc-utils/lsfd.c:518 #3 0x56159cfe217b in anon_pidfd_get_name ../misc-utils/lsfd-unkn.c:203 util-linux#4 0x56159cfe1040 in unkn_fill_column ../misc-utils/lsfd-unkn.c:93 util-linux#5 0x56159cfaaa37 in fill_column ../misc-utils/lsfd.c:1178 util-linux#6 0x56159cfaaac5 in convert_file ../misc-utils/lsfd.c:1193 util-linux#7 0x56159cfaac4f in convert ../misc-utils/lsfd.c:1212 util-linux#8 0x56159cfb2b54 in main ../misc-utils/lsfd.c:2317 util-linux#9 0x7f9dd4c45ccf (/usr/lib/libc.so.6+0x27ccf) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658) util-linux#10 0x7f9dd4c45d89 in __libc_start_main (/usr/lib/libc.so.6+0x27d89) (BuildId: 8bfe03f6bf9b6a6e2591babd0bbc266837d8f658) util-linux#11 0x56159cfa3c34 in _start (util-linux/build-meson/lsfd+0x41c34) (BuildId: 35fece1a205f96a2dbfe7a0e93b658530de675c4) ``` Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de> (cherry picked from commit 816109f)
Signed-off-by: Karel Zak <kzak@redhat.com> (cherry picked from commit 53bcec4)
This is stuff for the next stable 2.39.3 release. Do we need something more (less)?
Don't ask for the way how the patches were selected :-) It's mostly about my feeling ... the change should be trivial, or relatively independent of the rest of the code, or important enough, etc."