[Bug 271344] page fault during assigning/removing IPv6 addresses simultaneously

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271344

Bug ID: 271344
   Summary: page fault during assigning/removing IPv6 addresses
simultaneously
   Product: Base System
   Version: 13.2-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: pku...@freebsd.org

Created attachment 242098
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=242098&action=edit
panic

Reproduced on powerpc64 with bge and on amd64 with ice and bge.
Run the following command repeatedly:
for i in {1..20}; do ifconfig ice0 inet6 fec0::2:930/112 & ifconfig ice0 inet6
fec0::2:930 delete & done

It may take a few attempts, but will result in the attached panic (on amd64
with ice).

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

[Bug 271344] page fault during assigning/removing IPv6 addresses simultaneously

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271344

Piotr Kubaj  changed:

   What|Removed |Added

   Assignee|b...@freebsd.org|n...@freebsd.org

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

[Bug 271350] ftp(1) does not process file:// uris correctly

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271350

Bug ID: 271350
   Summary: ftp(1) does not process file:// uris correctly
   Product: Base System
   Version: 13.2-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: m...@online.fr

ftp(1) will enter an infinite loop when used in non-interactive mode with a
`file://' uri as argument.

This is caused by the `bufsize` local variable of `fetch_url()` in
`contrib/tnftp/src/fetch.c` being only set to a non-zero value when sockets are
created to fetch files from the network. Because of this, the
loop-until-all-the-contents-are-read starting on line 1215 always computes a
value of 0 for `bufrem`, does not perform any I/O, and basically spins hogging
the cpu.

How to reproduce:
$ cd /tmp && ftp file:///etc/passwd

Expected result:
copy of /etc/passwd in /tmp

Observed result:
progress bar at 0%, no ETA, one cpu spinning

Workaround:
Use fetch(1).

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

[Bug 271333] kernel panic 13.2-RELEASE

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271333

--- Comment #4 from Mark Johnston  ---
(In reply to Greg Balfour from comment #3)
Hmm, I don't *think* the patch is likely to help with that.  If the bug fixed
by the patch is triggered, I'd expect to see a kernel panic.

I'm not sure how to begin tracking down the cause of GPU driver hangs.

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

[Bug 271351] fsck_ffs can crash if fs_size < fs_ncg*fs_fpg

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271351

Bug ID: 271351
   Summary: fsck_ffs can crash if fs_size < fs_ncg*fs_fpg
   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 242107
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=242107&action=edit
broken image that causes fsck_ffs to crash due to fs_size < fs_ncg*fs_fpg

These two checks in ffs_subr.c's validate_sblock():

FCHK(fs->fs_size, <=, ((int64_t)fs->fs_ncg - 1) * fs->fs_fpg,
%jd);

and 

FCHK(fs->fs_size, <=, ((int64_t)fs->fs_ncg - 1) * fs->fs_fpg, %jd);

allow fs_size to be smaller than fs_ncg*fs_fpg. For example, if fs_ncg
is 1, then the test only requires fs_size to be > 0.

validate_sblock() checks fs_csaddr against fs_ncg*fs_fpg, and thus
fs_csaddr can point beyond fs_size.

As a result, a too-large value of fs_csaddr can cause this code in
fsck_ffs's pass1() to write beyond the end of blockmap, whose size is
determined by fs_size:

i = sblock.fs_csaddr;
cgd = i + howmany(sblock.fs_cssize, sblock.fs_fsize);
for (; i < cgd; i++)
setbmap(i);

I've attached a file system image that causes fsck_ffs -y to either
dump core or fail valgrind.

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

[Bug 271352] "live" dump -- with a snapshot -- broken by recent upgrade

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271352

Bug ID: 271352
   Summary: "live" dump -- with a snapshot -- broken by recent
upgrade
   Product: Base System
   Version: Unspecified
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: m...@aldan.algebra.com

For years now the nightly dumps of /home were running here from cron:

exec lockf -t 0 /tmp/home-dump-lock dump 0uaCLf 16 - /home | .

After upgrading to the 13-stable as of May 5th (after 265 days of uptime), that
job started failing with:

  DUMP: Date of this level 0 dump: Wed May 10 10:58:00 2023
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping snapshot of /dev/ada0h (/home) to standard output
dump: Cannot find file system superblock: No such file or directory

(Note, that the file system is happily mounted and in use.)

Rerunning the same command without the "L" switch works (with a warning):

  DUMP: WARNING: should use -L when dumping live read-write filesystems!
  DUMP: Date of this level 0 dump: Wed May 10 10:58:07 2023
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/ada0h (/home) to standard output
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 57211585 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
...

Seems like something is broken about the snapshot-creation. The /home/.snap
exists -- and is empty... The machine has 32Gb of RAM, and /home is only about
13% full at present:

root@symbion:~ # df -m /home
Filesystem 1M-blocks  Used  Avail Capacity  Mounted on
/dev/ada0h458392 56009 36571113%/home
root@symbion:~ # tunefs -p /dev/ada0h
tunefs: POSIX.1e ACLs: (-a)disabled
tunefs: NFSv4 ACLs: (-N)   disabled
tunefs: MAC multilabel: (-l)   disabled
tunefs: soft updates: (-n) enabled
tunefs: soft update journaling: (-j)   disabled
tunefs: gjournal: (-J) disabled
tunefs: trim: (-t) enabled
tunefs: maximum blocks per file in a cylinder group: (-e)  4096
tunefs: average file size: (-f)16384
tunefs: average number of files in a directory: (-s)   64
tunefs: minimum percentage of free space: (-m) 8%
tunefs: space to hold for metadata blocks: (-k)2600
tunefs: optimization preference: (-o)  time
tunefs: volume label: (-L) home

I recall it being formatted as UFS1 -- but don't know, how to ascertain that.

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

[Bug 271352] "live" dump -- with a snapshot -- broken by recent upgrade

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271352

Mikhail T.  changed:

   What|Removed |Added

Version|Unspecified |13.2-STABLE

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

[Bug 271354] reachable directory with zero link count can cause fsck to deref NULL

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271354

Bug ID: 271354
   Summary: reachable directory with zero link count can cause
fsck to deref NULL
   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 242111
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=242111&action=edit
ffs image with reachable directory with zero link count causes fsck to deref
NULL

If a directory inode's link count is zero, then pass1.c's checkinode()
doesn't call cacheino() to enter it into inphash[]:

 if (mode == IFDIR) {
if (DIP(dp, di_size) == 0) {
inoinfo(inumber)->ino_state = DCLEAR;
} else if (DIP(dp, di_nlink) <= 0) {
inoinfo(inumber)->ino_state = DZLINK;
} else {
inoinfo(inumber)->ino_state = DSTATE;  
cacheino(dp, inumber);

Then in pass2check(), if the directory is reachable, the fall-through
path from DZLINK calls getinoinfo(), which returns NULL, causing
inp->i_parent to crash:

case DZLINK:
if (inoinfo(idesc->id_number)->ino_state == DFOUND)
inoinfo(dirp->d_ino)->ino_state = DFOUND;
/* FALLTHROUGH */

case DFOUND:
inp = getinoinfo(dirp->d_ino);
if (idesc->id_entryno > 2) {
if (inp->i_parent == 0) {

I've attached a file system image in which i-node 3 (/.snap) has a 0
link count, and which yields this fsck_ffs backtrace:

Program received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
0x0021f412 in pass2check (idesc=0x7fffe7b8) at pass2.c:554
554 if (inp->i_parent == 0) {
(gdb) where
#0  0x0021f412 in pass2check (idesc=0x7fffe7b8) at pass2.c:554
#1  0x002093e7 in dirscan (idesc=0x7fffe7b8) at dir.c:211
#2  0x0021318b in ckinode (dp=0x7fffe6b8, idesc=0x7fffe7b8)
at inode.c:126
#3  0x0021e130 in pass2 () at pass2.c:202
#4  0x00219a7d in checkfilesys (filesys=0x7fffed71 "junk")
at main.c:468
#5  0x00218f42 in main (argc=1, argv=0x7fffea20) at main.c:210

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

[Bug 261349] Modernise hier(7)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=261349

--- Comment #13 from Graham Perrin  ---


> hier(7): drop list of /usr/include subdirectories



> hier(7): drop list of /usr/share/doc subdirectories



> hier(7): document /home/ and /usr/home/

– all MFC after one week.

Thanks mhorne@

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

[Bug 271352] "live" dump -- with a snapshot -- broken by recent upgrade

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271352

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #1 from Ed Maste  ---
file(1) should report the fs type, for example

# file -s /dev/md0 
/dev/md0: Unix Fast File system [v2] (little-endian)...

or

/dev/md0: Unix Fast File system [v1] (little-endian)...

Do you have the git references available for the previously-working and
now-broken cases?

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

[Bug 270536] By default ntpd does not work on IPv6-only hosts

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270536

Mallory  changed:

   What|Removed |Added

 CC||mallo...@fastmail.com

--- Comment #8 from Mallory  ---
*** Bug 264088 has been marked as a duplicate of this bug. ***

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

[Bug 271246] Kernel wired memory leak with repeated netstat

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271246

--- Comment #23 from Dave Hayes  ---
After 48 hours here is the top of the file containing output of the script:

Total wired change: 37450 pages
(vmstat -z)  vm pgcache (18) grew 43426 units of whatever the
'used' field is in inside that time period
(vmstat -z)  RADIX NODE (41) grew 601 units of whatever the
'used' field is in inside that time period
(vmstat -z)  vm pgcache (19) grew 565 units of whatever the
'used' field is in inside that time period
(vmstat -z) UMA Slabs 0 (25) grew 277 units of whatever the
'used' field is in inside that time period
(vmstat -z)mbuf_cluster (94) grew 252 units of whatever the
'used' field is in inside that time period
(vmstat -z)  pf state keys (158) grew 228 units of whatever the
'used' field is in inside that time period
(vmstat -z)  pf states (157) grew 197 units of whatever the
'used' field is in inside that time period

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

[Bug 271352] "live" dump -- with a snapshot -- broken by recent upgrade

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271352

--- Comment #2 from Mikhail T.  ---
> file(1) should report the fs type, for example

Awesome, thanks! Here it is:

root@symbion:~ # file -s /dev/ada0h
/dev/ada0h: Unix Fast File system [v1] (little-endian), last mounted on /home,
last written at Thu May 11 03:57:49 2023, clean flag 0, number of blocks
119241301, number of data blocks 117348597, number of cylinder groups 1834,
block size 32768, fragment size 4096, minimum percentage of free blocks 8,
rotational delay 0ms, disk rotational speed 60rps, TIME optimization

> Do you have the git references available for the previously-working and 
> now-broken cases?

The current version is  stable/13-8ba9384727. The kernel.old/kernel has this
string: FreeBSD 13.1-STABLE #3 stable/13-c9f9dc96d9.

Hope, this helps.

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

[Bug 142434] [patch] Add cpuset(1) support to rc.subr(8)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=142434

Enji Cooper  changed:

   What|Removed |Added

 CC||n...@freebsd.org

--- Comment #11 from Enji Cooper  ---
Other variables exist in rc.subr:
```
 775 #   ${name}_env n   Environment variables to run ${command}
with.
 776 #
 777 #   ${name}_env_file n  File to source variables to run ${command}
with.
 778 #
 779 #   ${name}_fib n   Routing table number to run ${command}
with.
 780 #
 781 #   ${name}_nicen   Nice level to run ${command} at.
 782 #
 783 #   ${name}_oomprotect nDon't kill ${command} when swap space is
exhausted.
```
This seems like a straightforward ask. I'll check with kylev and see what I can
do.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 142434] [patch] Add cpuset(1) support to rc.subr(8)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=142434

--- Comment #12 from Kyle Evans  ---
(In reply to Enji Cooper from comment #11)

Sorry, forgot about this. Looking at the patch again and previous responses, I
think I'm happy to land this as-is, I'm just going to remove the comment about
"fix for background-fsck problem" -- probably replace it with "Loose validation
of the configured cpu set"

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 142434] [patch] Add cpuset(1) support to rc.subr(8)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=142434

--- Comment #13 from commit-h...@freebsd.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=0661f93892a2564a64c5650a3d73417172a9

commit 0661f93892a2564a64c5650a3d73417172a9
Author: Miroslav Lachman <000.fbsd_quip.cz>
AuthorDate: 2023-05-11 04:38:23 +
Commit: Kyle Evans 
CommitDate: 2023-05-11 04:40:18 +

rc: add support for cpuset(1)

If ${name}_cpuset is specified (and /usr is mounted), cpuset(1) will be
run to limit the service to the configured cpuset.

PR: 142434
Reviewed by:kevans

 libexec/rc/rc.subr | 32 ++--
 1 file changed, 30 insertions(+), 2 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 142434] [patch] Add cpuset(1) support to rc.subr(8)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=142434

Kyle Evans  changed:

   What|Removed |Added

  Flags||mfc-stable13?,
   ||mfc-stable12-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

help

[Michel Le Cocq]