[Bug 270798] sysctl(3) missing KERN_PROC_FILEDESC MIB

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270798

Muhammad Moinur Rahman  changed:

   What|Removed |Added

 CC||b...@freebsd.org

--- Comment #3 from Muhammad Moinur Rahman  ---
Submit a git formatted patch. And mainly for src tree it is better to submit a
review in Phabricator(https://reviews.freebsd.org).

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 270798] sysctl(3) missing KERN_PROC_FILEDESC MIB

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270798

--- Comment #4 from Kurt Jaeger  ---
Can you try to provide a unified diff/patch that can be apply with

git apply /tmp/yourpatch

directly to /usr/src ? Please test this before submitting the diff.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 275830] APU2 based router freezes after upgrade to 14.0-RELEASE

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275830

Espen  changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |Unable to Reproduce

--- Comment #8 from Espen  ---
Replaced the board after another freeze. And it has been running stable on 13.2
since 17 days. 

Many thanks to pcengines for sending a replacement board so fast!

Closing the gug-report.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277629] ldd (ld-elf.so.1) uses p_vaddr without checking

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277629

Bug ID: 277629
   Summary: ldd (ld-elf.so.1) uses p_vaddr without checking
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: r...@lcs.mit.edu

Created attachment 249091
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249091&action=edit
corrupt elf file that causes ldd to crash due to its use of p_vaddr

When ldd calls dlopen(..., RTLD_TRACE), ld-elf.so.1's map_object()
sets obj->dynamic from a p_vaddr without checking:

case PT_DYNAMIC:
phdyn = phdr;
...;
obj->dynamic = (const Elf_Dyn *)(obj->relocbase + phdyn->p_vaddr);

and digest_dynamic1() dereferences it:

dynp = obj->dynamic;
...;
for (;  dynp->d_tag != DT_NULL;  dynp++) {

I've attached a corrupt elf file with the relevant p_vaddr set to
0x79699fff. This example happens to cause ldd to crash only on
a riscv machine (not amd64).

# uname -a
FreeBSD  15.0-CURRENT FreeBSD 15.0-CURRENT #270
main-n250982-48b12cb79520-dirty: Sat Mar  9 08:36:40 EST 2024
rtm@zika:/usr/obj/usr/rtm/symbsd/src/riscv.riscv64/sys/RTM riscv
# objdump -x ./ldd7a.exe | grep 0x7fff
 DYNAMIC off0x vaddr 0x79699fff paddr
0x align 2**64
# ldd ./ldd7a.exe 
/ldd7a.exe:
pid 136 (ldd), jid 0, uid 0: exited on signal 11 (core dumped)

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277592] On machines without IPv6, ping uses IPv6

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277592

Dag-Erling Smørgrav  changed:

   What|Removed |Added

 CC||d...@freebsd.org
 Status|New |Open
   Assignee|b...@freebsd.org|d...@freebsd.org

--- Comment #1 from Dag-Erling Smørgrav  ---
What does `sysctl kern.features | grep inet` say?

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277635] ldd (ld-elf.so.1) integer wrap when computing mmap() argument

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277635

Bug ID: 277635
   Summary: ldd (ld-elf.so.1) integer wrap when computing mmap()
argument
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: r...@lcs.mit.edu

Created attachment 249097
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249097&action=edit
elf with huge vaddr that causes ldd / ld.so integer wrap

The attached elf file has a LOAD segment with a p_vaddr big enough
that p_vaddr + p_filesz wraps. This causes rtld-elf's map_object.c to
compute a huge size argument for a call to mmap() to map in the
segment, which causes the segment to be mapped over something
critical. This causes ld-elf.so.1 to crash when called by ldd.

Specifically, data_vaddr ends up larger than data_vlimit in this
map_object() code, so data_vlimit - data_vaddr wraps:

for (i = 0; i <= nsegs; i++) {
/* Overlay the segment onto the proper region. */
data_offset = rtld_trunc_page(segs[i]->p_offset);
data_vaddr = rtld_trunc_page(segs[i]->p_vaddr);
data_vlimit = rtld_round_page(segs[i]->p_vaddr + segs[i]->p_filesz);
data_addr = mapbase + (data_vaddr - base_vaddr);
...;
if (data_vlimit != data_vaddr &&
mmap(data_addr, data_vlimit - data_vaddr, data_prot,
data_flags | MAP_PREFAULT_READ, fd, data_offset) == MAP_FAILED) {

Similarly, clever choices of p_vaddr and p_filesz can cause the later

clear_vaddr = segs[i]->p_vaddr + segs[i]->p_filesz;
clear_addr = mapbase + (clear_vaddr - base_vaddr);
...;
memset(clear_addr, 0, nclear);

to write memory outside of mapbase..(mapbase+mapsize).

The attached elf file demonstrates the first problem, though only on riscv.

# objdump -x ldd1c.exe
..
LOAD off0x0700 vaddr 0xffec5701 paddr
0x1700 align 2**12
 filesz 0x003fb0b2 memsz 0x01b0 flags --x
# ldd ldd1c.exe
ldd1c.exe:
pid 35 (ld-elf.so.1), jid 0, uid 0: exited on signal 11 (core dumped)
/ldd1c.exe: signal 11

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 275063] kernel using 100% CPU in arc_prune

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275063

Maxim Usatov  changed:

   What|Removed |Added

 CC||maxim.usa...@bcsatellite.ne
   ||t

--- Comment #8 from Maxim Usatov  ---
I have kernel{arc_prune} stuck at 100% CPU with system completely unresponsive
on FreeBSD 13.3-RELEASE releng/13.3-n257428-80d2b634ddf0. Can reproduce every
time by doing rsync from internal ZFS NVMe storage to an external UFS SATA
drive attached via USB. Is there a hope of getting this fixed in 13.3 as well?

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277638] Crash when running devinfo on RPI CM4

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277638

Bug ID: 277638
   Summary: Crash when running devinfo on RPI CM4
   Product: Base System
   Version: 15.0-CURRENT
  Hardware: arm64
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: h...@tmm.cx

Note: This was also tested on 14.0-RELEASE with the same results.

To boot the CM4 it is necessary to set devmatch_enable="NO". This papers over
the same crash it seems as gets triggered when running "devinfo" with it
enabled.

Doing this results in the following backtrace (obtained using kgdb)

#0  0x0042b1c8 in doadump (textdump=0, textdump@entry=3234298464) at
/usr/src/sys/kern/kern_shutdown.c:403
#1  0x000efaa4 in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at
/usr/src/sys/ddb/db_command.c:590
#2  0x000ef880 in db_command (last_cmdp=,
cmd_table=, dopager=true) at /usr/src/sys/ddb/db_commandc:503
#3  0x000ef568 in db_command_loop () at
/usr/src/sys/ddb/db_command.c:550
#4  0x000f3050 in db_trap (type=, code=)
at /usr/src/sys/ddb/db_main.c:267
#5  0x0047a94c in kdb_trap (type=60, code=0, tf=) at
/usr/src/sys/kern/subr_kdb.c:790
#6  
#7  kdb_enter (why=, msg=) at
/usr/src/sys/kern/subr_kdb.c:556
#8  0x0042b480 in vpanic (fmt=, ap=...) at
/usr/src/sys/kern/kern_shutdown.c:961
#9  0x0042b29c in panic (fmt=0x12 ) at /usr/src/sys/kern/kern_shutdown.c:889
#10 0x0077e964 in data_abort (td=0xc3a86c80,
frame=0xc0c783b0, esr=2516582404, far=, lower=0) at
/usr/src/sys/arm64/arm64/trap.c:398
#11 
#12 strlcpy (dst=dst@entry=0xc0c78570 "", src=0xdeadc0dedeadc0de
,
dsize=dsize@entry=32) at /usr/src/sys/libkern/strlcpy.c:36
#13 0x00486c4c in sysctl_rman (oidp=, arg1=, arg2=, req=0xc0c786d0) at
/usr/src/sys/kern/subr_rman.c:998
#14 0x0043d3e4 in sysctl_root_handler_locked
(oid=oid@entry=0x00a3aa60 ,
arg1=arg1@entry=0xc0c787ac, arg2=arg2@entry=3,
req=req@entry=0xc0c786d0, 
tracker=tracker@entry=0xc0c78658) at
/usr/src/sys/kern/kern_sysctl.c:199
#15 0x0043c754 in sysctl_root (oidp=,
arg1=0xc0c787ac, arg1@entry=0xc0c787a0, arg2=3, arg2@entry=6,
req=req@entry=0xc0c786d0) at /usr/src/sys/kern/kern_sysctl.c:2407
#16 0x0043cdec in userland_sysctl (td=td@entry=0xc3a86c80,
name=name@entry=0xc0c787a0, namelen=, old=0x1e0e686d760,
oldlenp=, inkernel=, inkernel@entry=-1060665472, 
new=, newlen=, retval=0xc0c78798,
flags=0) at /usr/src/sys/kern/kern_sysctl.c:2564
#17 0x0043cc68 in sys___sysctl (td=0xc3a86c80,
uap=0xc3a87080) at /usr/src/sys/kern/kern_sysctl.c:2437
#18 0x0077df4c in syscallenter (td=0xc3a86c80) at
/usr/src/sys/arm64/arm64/../../kern/subr_syscall.c:186
#19 svc_handler (td=0xc3a86c80, frame=) at
/usr/src/sys/arm64/arm64/trap.c:198
#20 do_el0_sync (td=0xc3a86c80, frame=) at
/usr/src/sys/arm64/arm64/trap.c:640
#21 
#22 0x01e0e9df9944 in ?? ()
#23 0x01e0e9d7e888 in ?? ()

After looking at the code a bit it seems that the "rm" entry is invalid at that
point. I don't really know how to continue debugging this.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277638] Crash when running devinfo on RPI CM4

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277638

Mark Linimon  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|freebsd-...@freebsd.org
   Keywords||crash

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 274519] panic with x11/nvidia-driver-470: sleepq_add: td … to sleep on wchan … with sleeping prohibited

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=274519

--- Comment #11 from Graham Perrin  ---
(In reply to Graham Perrin from comment #10)

Instead (again, work in progress):

…

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 276985] Crash in scheduler __curthread

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985

--- Comment #1 from f...@fehcom.de ---
I've got serveral crashes how. I all cases it points to the same problem:


Fatal trap 12: page fault while in kernel mode
cpuid = 5; apic id = 05
fault virtual address   = 0xf802c1e8c110
fault code  = supervisor read instruction, protection violation
instruction pointer = 0x20:0xf802c1e8c110
stack pointer   = 0x28:0xfe00c0721e18
frame pointer   = 0x28:0xfe00c0721e40
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (linuxkpi_irq_wq)
rdi: f802c1e8c110 rsi: f803d6652400 rdx: 0028
rcx: fe00dc462c10  r8: 003e  r9: fe001aa01c18
rax: f802c1e8c110 rbx: fe00c0721e28 rbp: fe00c0721e40
r10: f803d6652200 r11: f803d6652600 r12: f80001971a58
r13:  r14: 81a10d48 r15: 0004
trap number = 12

=> linuxkpi_irq_wq

As a reminder: https://wiki.freebsd.org/LinuxKPI

Not very satisfying. Any hints, which programs produce this behavior? How can I
tell, which programs require the Linux compat layer?

--eh.

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 276985] Crash in scheduler __curthread

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985

--- Comment #2 from f...@fehcom.de ---
Created attachment 249103
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249103&action=edit
Current crash

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 275063] kernel using 100% CPU in arc_prune

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275063

--- Comment #9 from Trev  ---
I still have arc_prune stuck at 100% for days despite having recently compiled
a 13-STABLE (stable/13-8b84d2da9: Fri Mar  8 15:06:13 AEDT 2024).

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 276985] crash in LinuxKPI/drm

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276985

Gleb Smirnoff  changed:

   What|Removed |Added

Summary|Crash in scheduler  |crash in LinuxKPI/drm
   |__curthread |

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277646] patch no longer work for simple diff

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277646

Bug ID: 277646
   Summary: patch no longer work for simple diff
   Product: Base System
   Version: 13.3-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: jguo...@gmail.com

%mkdir a b
%echo aaa > a/txt
%echo bbb > b/txt

# 13.3-R /usr/bin/patch failing case for normal simple diff, no matter if -p#
is used
# patch at earlier versions of FreeBSD releases do not have this issue.

%diff -r a b > ab.dif
patch < ab.dif
Hmm...  Looks like a normal diff to me...
The text leading up to this was:
--
|diff -r a/txt b/txt
--
File to patch: ^C

# works well for context based and unified diff
diff -ur a b > ab.dif
patch < ab.dif
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|diff -ur a/txt b/txt
|--- a/txt  2024-03-11 21:21:19.328439000 -0700
|+++ b/txt  2024-03-11 21:22:49.232518000 -0700
--
Patching file a/txt using Plan A...
Hunk #1 succeeded at 1.
done

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277649] clang version 17.0.6 compiles va_list to both integer and structure pointer

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277649

Bug ID: 277649
   Summary: clang version 17.0.6 compiles va_list to both integer
and structure pointer
   Product: Base System
   Version: 13.3-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: jguo...@gmail.com

new clang release 17.0.6 in 13.3-R generates a weird error on using va_list:

/usr/bin/cc compiled va_list at line 8 as 'unsigned int', where at line 14, cc
compiles va_list as 'struct __va_list_tag *'.
No other C compiler has a such issue.

  1 /*  ParseARGUment . C
  2 #
  3 */
  4
  5 #include 
  6
  7 struct  a_build_ctrl_t  {
  8 va_list ap; /* why it is uint ???   */
  9 int last_arg_t,
 10 List_In;
 11 };
 12
 13 void*
 14 build_arg_fmt_list(void* fmt, va_list ap)   // here is a structure
pointer
 15 {
 16 int tBE, na=1, Nv;
 17 register intn, ne;
 18  char   *cp, *cpr, *fmtp;
 19 struct a_build_ctrl_t   abc = {ap, 0};
 20 #define nv  ne
 21 // ...
 22 }

cc: warning: -Wl,--allow-shlib-undefined: 'linker' input unused
[-Wunused-command-line-argument]
parsargu.c:20:30: error: incompatible pointer to integer conversion
initializing 'unsigned int' with an expression of type 'struct __va_list_tag *'
[-Wint-conversion]
   20 | struct a_build_ctrl_t   abc = {ap, 0};
  |^~
1 error generated.
*** Error code 1

-- 
You are receiving this mail because:
You are the assignee for the bug.


[Bug 277649] clang version 17.0.6 compiles va_list to both integer and structure pointer

2024-03-11 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277649

Jin Guojun  changed:

   What|Removed |Added

   Severity|Affects Only Me |Affects Many People

-- 
You are receiving this mail because:
You are the assignee for the bug.