[Bug 254937] build(7) refers to svn(1) and svnlite(1)

2021-04-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254937

Bug ID: 254937
   Summary: build(7) refers to svn(1) and svnlite(1)
   Product: Documentation
   Version: Latest
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: Manual Pages
  Assignee: b...@freebsd.org
  Reporter: m.bue...@berlin.de
CC: d...@freebsd.org

build(7) mentions svn(1) and svnlite(1) in the top DESCRIPTION (and in SEE
ALSO), but makes no mention of git.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 254939] zfsprops(8) refers to zpool(8) where it should be zpoolconcepts(8)

2021-04-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254939

Bug ID: 254939
   Summary: zfsprops(8) refers to zpool(8) where it should be
zpoolconcepts(8)
   Product: Documentation
   Version: Latest
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: Manual Pages
  Assignee: b...@freebsd.org
  Reporter: m.bue...@berlin.de
CC: b...@freebsd.org, d...@freebsd.org

Where it explains the "special_small_blocks=size" property, zfsprops(8) says:
"See zpool(8) for more details on the special allocation class."

However, the relevant explanation is not found in zpool(8), but rather in
zpoolconcepts(8).

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 254911] lib/msun/ctrig_test fails if compiled with AVX (-mavx) or any CPUSET enabling AVX

2021-04-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254911

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

URL:
https://cgit.FreeBSD.org/src/commit/?id=3b00222f156dca5700c839d73e36daf479fa640c

commit 3b00222f156dca5700c839d73e36daf479fa640c
Author: Dimitry Andric 
AuthorDate: 2021-04-09 23:07:54 +
Commit: Dimitry Andric 
CommitDate: 2021-04-10 11:59:57 +

Avoid raising unexpected floating point exceptions in libm

When using clang with x86_64 CPUs that support AVX, some floating point
transformations may raise exceptions that would not have been raised by
the original code. To avoid this, use the -fp-exception-behavior=maytrap
flag, introduced in clang 10.0.0.

In particular, this fixes a number of test failures with ctanhf(3) and
ctanf(3), when libm is compiled with -mavx. An unexpected FE_INVALID
exception is then raised, because clang emits vdivps instructions to
perform certain divides. (The vdivps instruction operates on multiple
single-precision float operands simultaneously, but the exceptions may
be influenced by unused parts of the XMM registers. In this particular
case, it was calculating 0 / 0, which results in FE_INVALID.)

If -fp-exception-behavior=maytrap is specified however, clang uses
vdivss instructions instead, which work on one operand, and should not
raise unexpected exceptions.

Reported by:olivier
Reviewed by:arichardson
PR: 254911
MFC after:  1 week
Differential Revision: https://reviews.freebsd.org/D29686

 lib/msun/Makefile | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 254911] lib/msun/ctrig_test fails if compiled with AVX (-mavx) or any CPUSET enabling AVX

2021-04-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254911

Dimitry Andric  changed:

   What|Removed |Added

  Flags||mfc-stable13+,
   ||mfc-stable12+,
   ||mfc-stable11+
 Status|New |In Progress

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 254911] lib/msun/ctrig_test fails if compiled with AVX (-mavx) or any CPUSET enabling AVX

2021-04-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254911

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

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

commit bae9fd0b33462e9506c3ac3400089c6dbc4aee8f
Author: Dimitry Andric 
AuthorDate: 2021-04-10 14:02:49 +
Commit: Dimitry Andric 
CommitDate: 2021-04-10 14:02:58 +

Only use -fp-exception-behavior=maytrap on x86, for now

After 3b00222f156d, it turns out that clang only supports strict
floating point semantics for SystemZ and x86 at the moment, while for
other architectures it is still experimental.

Therefore, only use -fp-exception-behavior=maytrap on x86 for now,
otherwise this option results in "error: overriding currently
unsupported use of floating point exceptions on this target
[-Werror,-Wunsupported-floating-point-opt]" on other architectures.

Fixes:  3b00222f156d
PR: 254911
MFC after:  1 week

 lib/msun/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 254723] [patch] systat -swap to display per-process swap space usage ordered by highest

2021-04-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254723

--- Comment #1 from o...@j.email.ne.jp ---
Created https://reviews.freebsd.org/D29695.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 254955] name man page says the tunable for nda is called "verbose_cmd_dump"

2021-04-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254955

Bug ID: 254955
   Summary: name man page says the tunable for nda is called
"verbose_cmd_dump"
   Product: Documentation
   Version: Latest
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: Manual Pages
  Assignee: b...@freebsd.org
  Reporter: p...@twisted.org.uk
CC: d...@freebsd.org

man page says this:

"To select the nda(4) driver, set the following tunable value in
loader.conf(5):

   hw.nvme.verbose_cmd_dump=1"

but actually its "hw.nvme.use_nvd=0"

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 254964] Integer overflow in ffs_setextattr() could lead to a kernel heap overflow

2021-04-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254964

Bug ID: 254964
   Summary: Integer overflow in ffs_setextattr() could lead to a
kernel heap overflow
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: b...@freebsd.org
  Reporter: cutesmilee.resea...@protonmail.com

ffs_setextattr() is used to set a named attribute to an ffs vfs.
the problem is that it takes some user controlled data, the interesting ones
are: ap->a_name (arbitrary user string, not checked), and ip->i_ea_len
(unsigned int), which also isn't checked.
the function uses ip->i_ea_len + ealength (which is 7 + strlen(ap->a_name)) for
allocating a buffer, after that user-controlled data are copied to the buffer
using ip->i_ea_len.
providing an INT_MAX ip->i_ea_len + 2^32 + 2 long string will cause an integer
overflow, and the buffer in the heap will be 1 byte, but the bcopy will copy
2^32 bytes to the buffer.
this should be reachable from an unprivileged user (since extattr_check_cred()
doesn't require root if the attrnamespace is set to EXTATTR_NAMESPACE_USER),
but seems to be difficult to exploit, since you'd need 4GBs of ram (for the
long string) just to perform the 2^32 heap overflow, an exploitable overflow
will probably take even more memory.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 254965] re0 ethernet connection fails with thousands of "phy read failed" errors in system message

2021-04-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254965

Bug ID: 254965
   Summary: re0 ethernet connection fails with thousands of "phy
read failed" errors in system message
   Product: Base System
   Version: Unspecified
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: misc
  Assignee: b...@freebsd.org
  Reporter: doctorwho...@gmail.com

I have a Toshiba Satellite L875D-S7210 with a Realtek 10/100 ethernet adapter.
It uses the re(4) driver. I'm running FreeBSD 13-RC5. My ethernet connection
may work for a few hours just fine, but it will randomly drop the connection.
ifconfig will report "no carrier", and dmesg and /var/log/messages will contain
thousands of "re0: PHY read failed" errors. Restarting the netif service won't
bring the connection back up. using ifconfig to bring the device down and back
up won't work. Even a warm reboot won't bring the ethernet connection back up.
I have to completely power down the system then turn it back on to get the
ethernet working again. On a warm reboot, FreeBSD won't even recognize that the
ethernet adapter is there after a failure. I Googled the error, and there are
reports of similar behavior with the re driver going back to 2008, so this may
be a longstanding issue.

Also, my wifi connection will intermittently go out. But with the wifi,
restarting the netif service brings the connection back up. It was actually the
wifi issue that made me start using ethernet so I could try to keep a stable
connection. I mention the wifi dropping for two reasons: 1) I had Manjaro Linux
on this same laptop for months before putting FreeBSD on it, and I never had
any problems with the wifi connection, and 2) if my laptop is connected to wifi
and ethernet at the same time, when the connection drops, it simultaneously
drops the wifi and the ethernet connection. So there seems to be some
relationship between the two where a failure in one causes the other to fail.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 254966] geli setkey not working with detached provider

2021-04-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254966

Bug ID: 254966
   Summary: geli setkey not working with detached provider
   Product: Base System
   Version: 12.2-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: bin
  Assignee: b...@freebsd.org
  Reporter: spam...@bitbert.com

trying to run "geli setkey -n 1 gpt/hd01" on a detached geli provider asks me
for the master password, and after entering the right password just prints
"Note, that the master key encrypted with old keys and/or passphrase may still
exists in a metadata backup file." - so it does not ask me for the userpassword
I want to set to slot 1 (as one woud expect). So either the man page should be
changed to inform the user that setkey only works with attached providers or
the program should be adapted so that after entering the right master password
the user is asked for the user password. (IIRC this has already worked the last
time - quite some time ago - when I used it)

"geli setkey -n 1 gpt/hd01" works when the provider is already attached - the
dialogue:

Enter new passphrase: 
Reenter new passphrase: 
Note, that the master key encrypted with old keys and/or passphrase may still
exists in a metadata backup file.

System: FreeBSD mach2020 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 GENERIC  amd64

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"


[Bug 254966] geli setkey not working with detached provider

2021-04-10 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254966

--- Comment #1 from rob2g2  ---
same behaviour on 13.0-RC5

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"