https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224667
Bug ID: 224667
Summary: The tools reboot and halt are installed with incorrect
permissions
Product: Base System
Version: 11.1-RELEASE
Hardware: i386
O
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #22 from Konstantin Belousov ---
(In reply to Conrad Meyer from comment #20)
Because we do not enforce a policy in the kernel on the possible md(4) usage.
Even assuming that we do, we would need
(a) teach VFS to see through md(
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224498
Bartek Rutkowski changed:
What|Removed |Added
Assignee|freebsd-bugs@FreeBSD.org|ro...@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224498
--- Comment #5 from commit-h...@freebsd.org ---
A commit references this bug:
Author: robak
Date: Thu Dec 28 22:57:35 UTC 2017
New revision: 327317
URL: https://svnweb.freebsd.org/changeset/base/327317
Log:
humanize_number(3): fix math e
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #21 from Wolfram Schneider ---
(In reply to Mark Millard from comment #13)
Hi Mark,
good point about "reboot" <-> "shutdown -r now". The handbook recommends to use
shutdown. My bad.
I tried shutdown -r now on the console and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224426
Mark Linimon changed:
What|Removed |Added
Keywords||patch
--
You are receiving this ma
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222698
Conrad Meyer changed:
What|Removed |Added
Keywords||patch
Version|11.1-STABL
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222698
--- Comment #6 from Conrad Meyer ---
No, hold on, it was broken even before that, in the BSD 4.4-Lite source import:
r1590. Probably broken from the dawn of CSRG.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222698
--- Comment #5 from Conrad Meyer ---
This has apparently been broken since inclusion in 2001 (r76250) of a patch
originally submitted in 1999.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222698
--- Comment #4 from Conrad Meyer ---
This change ought to be sufficient to fix -newer:
--- a/usr.bin/find/function.c
+++ b/usr.bin/find/function.c
@@ -1201,6 +1201,7 @@ c_newer(OPTION *option, char ***argvp)
char *fn_or_tspec;
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222698
--- Comment #3 from Conrad Meyer ---
(In reply to Conrad Meyer from comment #2)
Ah, that is during traversal. For the reference file (the "plan"), find(1) is
incorrectly using fstatat without the NOFOLLOW flag:
fstatat(AT_FDCWD,"lINK-to-f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222698
--- Comment #2 from Conrad Meyer ---
Truss:
open(".",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,01) = 5 (0x5)
fstatfs(5,{ fstypename=ufs,mntonname=/,mntfromname=/dev/gpt/freebsd-root,fsid=
}) = 0 (0x0)
fstat(5,{ mode=drwxr-xr-x ,inode=424554
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222698
Conrad Meyer changed:
What|Removed |Added
CC||c...@freebsd.org
--- Comment #1 fro
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220972
Conrad Meyer changed:
What|Removed |Added
CC||c...@freebsd.org
Assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #20 from Conrad Meyer ---
(In reply to Konstantin Belousov from comment #18)
Re: (1) If the database is owned and operated by the kernel, YES.
Why not swapoff any such vnode backed file before reclaiming the vnode, or at
least
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #19 from Mark Millard ---
(In reply to Konstantin Belousov from comment #18)
It is probably not clear about my notes (other
and shutdown -r now vs. reboot testing directly):
My experience was deadlocks during normal operation
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #18 from Konstantin Belousov ---
(In reply to Andriy Gapon from comment #15)
This is perhaps going too far on the silly fest. Andrey, you do understand
VFS, so I am quite frustrated.
1. If the vnode carriers some database, sho
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #17 from Conrad Meyer ---
(In reply to Andriy Gapon from comment #15)
+1 to all of this. We know what devices/files are used for swap and should be
able to prevent this panic for user-initiated action like umount.
--
You are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224646
Bug ID: 224646
Summary: Attempts to load non-PAE modules into a PAE-kernel
should be rejected
Product: Base System
Version: 11.1-STABLE
Hardware: Any
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #16 from Mark Millard ---
(In reply to Konstantin Belousov from comment #14)
You have written in the past that for file based
(vnode-based) swap files the system is deadlock
prone in a manor not under significant user control.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224532
--- Comment #2 from commit-h...@freebsd.org ---
A commit references this bug:
Author: kib
Date: Thu Dec 28 13:23:13 UTC 2017
New revision: 327286
URL: https://svnweb.freebsd.org/changeset/base/327286
Log:
Reuse kern_proc_vmmap_resident()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #15 from Andriy Gapon ---
(In reply to Konstantin Belousov from comment #14)
On the other hand, if the kernel knows that a vnode is used for swap and the
kernel knows that the force reclaim of that vnode will lead to a panic, th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224479
--- Comment #14 from Konstantin Belousov ---
(In reply to Mark Millard from comment #13)
There is no race, the system behaves as it supposed to. If swap storage is
revoked, the swap in procedure panics. I am not sure that trying to conver
23 matches
Mail list logo
