[Bug 259071] Read reports wrong number of bytes on a network filesystem.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259071 --- Comment #1 from Piotr Robert Konopelko (MooseFS) --- @Alan please could you have a look at this one too? Many thanks -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259024] ext2_search_dirblock() loops forever if e2d_reclen is zero
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259024 --- Comment #1 from Fedor Uporov --- Hi, Robert. Thanks a lot for reports and images for reproduction. I successfully reproduced current issue on amd64 with crash instead of infinity loop: #14 0x810f1927 in trap (frame=0xfe00af5eb7b0) at /usr/src/sys/amd64/amd64/trap.c:443 #15 #16 ext2_search_dirblock (ip=, ip@entry=0xf80004d73900, data=, foundp=foundp@entry=0xfe00af5eb990, name=0xf80004c87805 "a", namelen=1, entryoffsetinblockp=, entryoffsetinblockp@entry=0xfe00af5eb9dc, offp=0xfe00af5eb9e4, prevoffp=0xfe00af5eb9ac, endusefulp=0xfe00af5eb9d4, ssp=0xfe00af5eb978) at /usr/src/sys/fs/ext2fs/ext2_lookup.c:743 #17 0x82746852 in ext2_lookup_ino (vdp=, vpp=0xfe00af5ebc28, cnp=0xfe00af5ebc50, dd_ino=0x0) at /usr/src/sys/fs/ext2fs/ext2_lookup.c:455 #18 0x80cf9f16 in VOP_CACHEDLOOKUP (dvp=0xf800b50d3700, vpp=0xfe00af5ebc28, cnp=0xfe00af5ebc50) at ./vnode_if.h:103 #19 vfs_cache_lookup (ap=) at /usr/src/sys/kern/vfs_cache.c:3068 #20 0x80d0b1e1 in VOP_LOOKUP (dvp=0xf800b50d3700, vpp=0xfe00af5ebc28, cnp=0xfe00af5ebc50) at ./vnode_if.h:69 #21 lookup (ndp=ndp@entry=0xfe00af5ebbd0) at /usr/src/sys/kern/vfs_lookup.c:1128 --Type for more, q to quit, c to continue without paging-- #22 0x80d0a0de in namei (ndp=ndp@entry=0xfe00af5ebbd0) at /usr/src/sys/kern/vfs_lookup.c:658 #23 0x80d29ba2 in kern_statat (td=0xfe0094b47e40, flag=, fd=-100, path=0x8018182f8 , pathseg=pathseg@entry=UIO_USERSPACE, sbp=sbp@entry=0xfe00af5ebd18, hook=0x0) at /usr/src/sys/kern/vfs_syscalls.c:2441 Issues 259105, 259107, 259112 were successfully reproduced too. The problem with these sort of issues, I mean malicious images with bad/corrupted metadata, that it is too difficult to make crosscheck of metadata values read from disk. The only way to avoid it, is to format drive with ext4 metadata_csum (RO_COMPAT_METADATA_CSUM) feature turned on. Need to find a way, how the metadata values, which cause a crashes, could be verified. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259249] [vtnet] [regression]: checksum offloading is suppressing NAT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259249 Bug ID: 259249 Summary: [vtnet] [regression]: checksum offloading is suppressing NAT Product: Base System Version: 13.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: e...@norma.perm.ru Router: FreeBSD 13 Network behind NAT: some Linux hosts Router: --- [root@balancer1:/etc]# ifconfig | grep -A1 vtnet | grep options options=4c079b options=4c079b Host behind NAT, several curl launches: --- [root@back1 server]# curl --output /dev/null https://mirror.yandex.ru/centos/8.4.2105/isos/x86_64/CentOS-8.4.2105-x86_64-dvd1.iso % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 9469M0 527k0 0 150k 0 17:55:26 0:00:03 17:55:23 150k^C [root@back1 server]# curl --output /dev/null https://mirror.yandex.ru/centos/8.4.2105/isos/x86_64/CentOS-8.4.2105-x86_64-dvd1.iso % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 9469M0 671k0 0 188k 0 14:15:29 0:00:03 14:15:26 188k^C [root@back1 server]# curl --output /dev/null https://mirror.yandex.ru/centos/8.4.2105/isos/x86_64/CentOS-8.4.2105-x86_64-dvd1.iso % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 9469M0 1599k0 0 198k 0 13:34:49 0:00:08 13:34:41 214k^C [root@back1 server]# curl --output /dev/null https://mirror.yandex.ru/centos/8.4.2105/isos/x86_64/CentOS-8.4.2105-x86_64-dvd1.iso % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 9469M0 1647k0 0 225k 0 11:56:44 0:00:07 11:56:37 218k^C [root@back1 server]# curl --output /dev/null https://mirror.yandex.ru/centos/8.4.2105/isos/x86_64/CentOS-8.4.2105-x86_64-dvd1.iso % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 9469M0 1247k0 0 134k 0 20:05:17 0:00:09 20:05:08 147k^C [root@back1 server]# curl --output /dev/null https://mirror.yandex.ru/centos/8.4.2105/isos/x86_64/CentOS-8.4.2105-x86_64-dvd1.iso % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 9469M0 383k0 0 185k 0 14:31:44 0:00:02 14:31:42 185k^C Router: -- [root@balancer1:/etc]# ifconfig vtnet0 -rxcsum [root@balancer1:/etc]# ifconfig vtnet1 -rxcsum [root@balancer1:/etc]# ifconfig vtnet1 -txcsum [root@balancer1:/etc]# ifconfig vtnet0 -txcsum Same host behind NAT: -- [root@back1 etc]# curl --output /dev/null https://mirror.yandex.ru/centos/8.4.2105/isos/x86_64/CentOS-8.4.2105-x86_64-dvd1.iso % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 3 9469M3 309M0 0 89.6M 0 0:01:45 0:00:03 0:01:42 89.6M^C [root@back1 etc]# curl --output /dev/null https://mirror.yandex.ru/centos/8.4.2105/isos/x86_64/CentOS-8.4.2105-x86_64-dvd1.iso % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 9469M0 76.9M0 0 85.2M 0 0:01:51 --:--:-- 0:01:51 85.2M^C [root@back1 etc]# curl --output /dev/null https://mirror.yandex.ru/centos/8.4.2105/isos/x86_64/CentOS-8.4.2105-x86_64-dvd1.iso % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 1 9469M1 99.3M0 0 123M 0 0:01:16 --:--:-- 0:01:16 123M^C Guess it's self-explanatory. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259249] [vtnet] [regression]: checksum offloading is suppressing pf NAT
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259249 e...@norma.perm.ru changed: What|Removed |Added Summary|[vtnet] [regression]: |[vtnet] [regression]: |checksum offloading is |checksum offloading is |suppressing NAT |suppressing pf NAT -- You are receiving this mail because: You are the assignee for the bug.
[Bug 237725] Spelling in share/man/man4/bridge.4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237725 Guangyuan Yang changed: What|Removed |Added Assignee|b...@freebsd.org|y...@freebsd.org CC||y...@freebsd.org --- Comment #8 from Guangyuan Yang --- This patch looks good to my eye - I will wait a few days for everyone here to review and respond, and have it committed soon. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259071] Read past EoF in NFS client and fusefs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259071 Alan Somers changed: What|Removed |Added Summary|Read reports wrong number |Read past EoF in NFS client |of bytes on a network |and fusefs |filesystem. | -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259071] Read past EoF in NFS client and fusefs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259071 Alan Somers changed: What|Removed |Added CC||rmack...@freebsd.org --- Comment #2 from Alan Somers --- Rick, have you every seen a bug like this? To summarize: * One thread alternately truncates, extends, and reads a file * Another thread stats the same file After a few seconds, one of the read operations returns more data than the file ought to contain. It usually rounds up to a 64kB boundary, but not always. I can reproduce it with the NFS client, but the OP says it happens in fuse, too. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 133860] [patch] lorder(1) misses symbols defined in read only data section.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133860 Ed Maste changed: What|Removed |Added Status|Open|In Progress -- You are receiving this mail because: You are the assignee for the bug.
[Bug 133860] [patch] lorder(1) misses symbols defined in read only data section.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133860 --- Comment #3 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=e1d6d6f9249d37c10a0df68024c7dacebdc7bf98 commit e1d6d6f9249d37c10a0df68024c7dacebdc7bf98 Author: Ed Maste AuthorDate: 2021-10-18 21:19:53 + Commit: Ed Maste CommitDate: 2021-10-18 21:21:17 + lorder: process read-only data symbols Previously they were skipped. lorder(1) serves no functional purpose today but we might as well address this longstanding bug while it is still in the tree. PR: 133860 MFC after: 1 week Submitted by: John Hein usr.bin/lorder/lorder.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259076] pthread_mutex_init fails with limited AS
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259076 --- Comment #10 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=73dddffc3175581ba99f6ced9a2e508a0e880e59 commit 73dddffc3175581ba99f6ced9a2e508a0e880e59 Author: Konstantin Belousov AuthorDate: 2021-10-15 17:59:37 + Commit: Konstantin Belousov CommitDate: 2021-10-18 22:02:47 + crt_malloc: more accurate handling of mmap(2) failure Reset both pagepool_start and pagepool_end after a mmap(2) failure, to avoid using invalid pagepool either for allocation or munmap(2). PR: 259076 Noted by: Denis Koreshkov Reviewed by:arichardson Sponsored by: The FreeBSD Foundation MFC after: 1 week Differential revision: https://reviews.freebsd.org/D32514 libexec/rtld-elf/rtld_malloc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 259218] Fatal trap 12: page fault while in kernel mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259218
--- Comment #9 from Dennis Clarke ---
Finally I can follow up here.
The kernel ( and buildworld ) were done with another machine and
then I was able to move the hard disk back to the troublesome VIA
Eden Esther motherboard.
After letting the machine boot :
esther#
esther# uname -apKU
FreeBSD esther 14.0-CURRENT FreeBSD 14.0-CURRENT #0 main-n250102-d95c0a12a2d:
Mon Oct 18 05:58:15 GMT 2021
root@esther:/usr/obj/usr/src/i386.i386/sys/GENERIC i386 i386 1400038 1400038
esther#
I left it to sit idle for a good long while and of course we caught
a panic and even a coredump.
esther#
esther# ls -lap /var/crash/
total 109816
drwxr-x--- 2 root wheel512 Oct 18 18:24 ./
drwxr-xr-x 24 root wheel512 Oct 18 19:20 ../
-rw-r--r-- 1 root wheel 2 Oct 18 18:24 bounds
-rw-r--r-- 1 root wheel 84 Oct 18 18:24 core.txt.0
-rw--- 1 root wheel516 Oct 18 18:24 info.0
lrwxr-xr-x 1 root wheel 6 Oct 18 18:24 info.last -> info.0
-rw-r--r-- 1 root wheel 5 Oct 7 21:44 minfree
-rw--- 1 root wheel 121741312 Oct 18 18:24 vmcore.0
lrwxr-xr-x 1 root wheel 8 Oct 18 18:24 vmcore.last -> vmcore.0
esther#
Regardless lets get what you asked for :
esther# cd
esther# setenv TERM 'dumb'
esther# gdb -q /usr/obj/usr/src/i386.i386/sys/GENERIC/kernel.full
Reading symbols from /usr/obj/usr/src/i386.i386/sys/GENERIC/kernel.full...
(gdb) list *random_nehemiah_read+0x60
0x1404240 is in random_nehemiah_read (/usr/src/sys/dev/random/nehemiah.c:69).
64 {
65 uint32_t retval = 0;
66 uint32_t rate = 0;
67
68 #ifdef __GNUCLIKE_ASM
69 __asm __volatile(
70 "movl $0,%%edx\n\t"
71 "xstore"
72 : "=a" (retval), "+d" (rate), "+D" (buf)
73 :
(gdb)
for the sake of looking at more lines :
(gdb) list -
54 .rs_source = RANDOM_PURE_NEHEMIAH,
55 .rs_read = random_nehemiah_read
56 };
57
58 static struct fpu_kern_ctx *fpu_ctx_save;
59
60 /* This H/W source never stores more than 8 bytes in one go */
61 /* ARGSUSED */
62 static __inline size_t
63 VIA_RNG_store(void *buf)
(gdb) list
64 {
65 uint32_t retval = 0;
66 uint32_t rate = 0;
67
68 #ifdef __GNUCLIKE_ASM
69 __asm __volatile(
70 "movl $0,%%edx\n\t"
71 "xstore"
72 : "=a" (retval), "+d" (rate), "+D" (buf)
73 :
(gdb) list
74 : "memory"
75 );
76 #endif
77 if (rate == 0)
78 return (retval&0x1f);
79 return (0);
80 }
81
82 static void
83 random_nehemiah_init(void)
(gdb) quit
esther#
Hope this helps however I can xz compress that coredump and
upload it however I worry that a coredump will contain security
data such as a root password.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 113912] tunefs(8): silent failure setting glabel on boot partition
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=113912 rkober...@gmail.com changed: What|Removed |Added CC||rkober...@gmail.com --- Comment #2 from rkober...@gmail.com --- System is 13-STABLE from August. The title should be updated to "tunefs(8): silent failure change settings on boot partition". Running 13-STABLE and was unable to set TRIM, SUJ, Label. Entered: tunefs -t enable /dev/nvd0p3 It responded with the standard message and no error. "tunefs -p" showed TRIM enabled. Then mounted the volume RW and checked again and TRIM was disabled. Same with SUJ and Label. SWAG, a copy of the superblock is located in memory and that is update by tunefs but is not written to disk since it had been mounted RO. When "mount -u /" is executed, the superblock is read in again. Just a guess, but seems to fit the behavior. Ticket my be updated to "Affects some people". This ticket has been open for over 14 years with no attention. With the increasing use of SSDs that may miss enabling TRIM on the initial installation requiring the use of tunefs to enable it. I know from experience. -- You are receiving this mail because: You are the assignee for the bug.
