[Bug 224479] kernel panic in reboot+swapoff sys call
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 convert this situation into SIGSEGV to the affected process is useful, because kernel stacks can be also swapped out, and the kernel has no other way out except panicing. You complain about swap over file being enabled by default does not make sense either. The configuration requires explicit user involvement, and it is allowed by combination of the components that were designed to fit. The consequences of doing so is up to the user, we cannot and must not hold user' hands. Taking your line of reasoning, shall we disallow for installing the system on unreliable media like sdcard 'by default', because wearing makes the system fail fast ? -- 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 224479] kernel panic in reboot+swapoff sys call
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, then why should the kernel allow that? I see several possibilities, but not sure if any of them makes sense from the FreeBSD architecture and design point of view. 1. When vgone-ing the swap vnode somehow perform an equivalent of swap off on it. 2. Do not allow even the force unmount of a filesystem if there is a vnode used for swap. 3. "Orphan" the swap vnode such that it is removed from its mount list, the name cache, etc, but it is still alive and is owned by the swap pager. I feel that this is impossible to do, however. Also, I am not sure about any "race", but it seems that during a shutdown we should first turn off all the file-backed swap and only then start unmounting filesystems. From comment #0 it seems that we do not follow this order. -- 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 224532] Remove resident count from procfs map
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() for procfs_map resident count. The existing algorithm in procfs_map() to calculate count of resident pages in an entry is too primitive, resulting in too long run time for large sparse mapping entries. Re-use the kern_proc_vmmap_resident() from kern_proc.c which only looks at the existing pages in the iterations. Also, this makes procfs to honor kern.proc_vmmap_skip_resident_count, if user does not need this information. Reported by: Glenn Weinberg PR: 224532 No objections from: des (procfs maintainer) Sponsored by: The FreeBSD Foundation MFC after:1 week Differential revision:https://reviews.freebsd.org/D13595 Changes: head/sys/fs/procfs/procfs_map.c -- 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 224479] kernel panic in reboot+swapoff sys call
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. >From what I've seen lots of folks set up the file based swap spaces without having a clue that such is the status. I was one of them at one time, following http://www.wonkity.com/~wblock/docs/html/ssd.html#_filesystems_and_trim material for SSDs that gave no hint of the issues involved. If the instructions had told me that I needed to enable the mode of use because of deadlock issues that do not happen with partition based swap spaces, I never would have tied it. I had swap space based deadlocks vastly faster than any sdcard wear out would have occurred: the configuration was simply unreliable over fairly short time frames. Also, the deadlocks are not examples of wear-and-tear. (You might want a better analogy for your point in that respect.) I view FreeBSD as designed to automatically avoid deadlocks for swapping only for partition-based swap spaces. Lesser points but more tied to this report: I was expecting that "shutdown -r now" might stop some processes before initiating the v-node removal, making such processes no longer sources of swap-in activity for later stages. (I was not thinking of any general fix to the deadlocking issues.) reboot, by contrast, I was expecting leaves more processes around that might try to swap-in in an untimely manor. I freely admit my expectations might be garbage-in/garbage-out. I was not expecting the sending of SIGSEGV or other signals to a process that is trying to swap-in after there is effectively nothing available to swap-in from. Does some involved kernel stack need to be in a swapped out state to have the problem that has been described? Or can it be a problem when no kernel stacks are swapped out? -- 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 224646] Attempts to load non-PAE modules into a PAE-kernel should be rejected
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 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: m...@freebsd.org When a module is built outside of the normal "make kernel" process, it may not have the PAE defined. There may also be a problem in the other direction. I was recently bitten by this as documented in Bug #224616 -- vboxguest.ko installed by the emulators/virtualbox-ose-additions would load, but fail to initialize itself with an incomprehensible -- and easy to miss -- error-message. The port-maintainer(s) may fix the problem with the port, but the kldload and/or kernel need to detect such miscompilations and reject attempts to load the module -- with an easy to understand error. -- 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 224479] kernel panic in reboot+swapoff sys call
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 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 224479] kernel panic in reboot+swapoff sys call
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, should kernel stop the database on the basis that otherwise user data might be corrupted ? Should kernel print (Abort, Retry, Ignore ?) 2.If force unmount is not allowed because there is the swap on a file, would the next request be to add really-force option which causes unmount to proceed even in this case. 3. You agree on your own that io to reclaimed vnode is not possible. May be we should not reclaim such vnode, but then add VOP_RECLAIMFORREAL. It is very clear situation, system was directed to change its configuration in a way which makes the continuation of the operations sometimes problematic, sometimes not. Why people consider it is reasonable to either deny the reconfiguration or to deny and have kernel to spit the whole man page on the console as the additional punishment, is beyond me. -- 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 224479] kernel panic in reboot+swapoff sys call
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 when I used a swapfile, not during shutdown. The specifics of just this submittal do not by itself drive why I wrote what I wrote. As such, I'll stop making such notes here. Sorry for the noise. -- 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 224479] kernel panic in reboot+swapoff sys call
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 before umounting the backing filesystem? -- 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 220972] stable/11: panic in scsi_pass.c/passsendccb: page not present
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220972 Conrad Meyer changed: What|Removed |Added CC||c...@freebsd.org Assignee|freebsd-bugs@FreeBSD.org|freebsd-s...@freebsd.org -- 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 222698] find(1)'s -newer expression doesn't work with symbolic links if '-P' (the default) is requested.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222698 Conrad Meyer changed: What|Removed |Added CC||c...@freebsd.org --- Comment #1 from Conrad Meyer --- Here the behavior is described in the POSIX 2008, 2016 edition standard: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html Harald is correct that the default behavior (and for -H, traversed paths) should use the metadata for the link itself, rather than that of the referenced file. -- 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 222698] find(1)'s -newer expression doesn't work with symbolic links if '-P' (the default) is requested.
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=42455429,size=512,blksize=32768 }) = 0 (0x0)
fchdir(0x5) = 0 (0x0)
getdirentries(5,"\M^E\M-Q\M^G\^B\0\0\0\0\0\0\0\0"...,4096,{ 0x0 }) = 168 (0xa8)
fstatat(AT_FDCWD,"lINK-to-fILE",{ mode=lrwxr-xr-x
,inode=42459218,size=4,blksize=32768 },AT_SYMLINK_NOFOLLOW) = 0 (0x0)
fstatat(AT_FDCWD,"fILE2",{ mode=-rw-r--r--
,inode=42459473,size=27,blksize=32768 },AT_SYMLINK_NOFOLLOW) = 0 (0x0)
fstatat(AT_FDCWD,"fILE",{ mode=-rw-r--r-- ,inode=42459474,size=19,blksize=32768
},AT_SYMLINK_NOFOLLOW) = 0 (0x0)
getdirentries(5,0x8006a8000,4096,{ 0x200 }) = 0 (0x0)
close(5) = 0 (0x0)
So we see that find(1) is correctly using AT_SYMLINK_NOFOLLOW to obtain stat
information for the symlink, as well as the other files. So either the kernel
is broken, or the comparison is somehow broken.
--
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 222698] find(1)'s -newer expression doesn't work with symbolic links if '-P' (the default) is requested.
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-fILE",{ mode=-rw-r--r--
,inode=42459474,size=19,blksize=32768 },0x0) = 0 (0x0)
--
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 222698] find(1)'s -newer expression doesn't work with symbolic links if '-P' (the default) is requested.
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;
PLAN *new;
struct stat sb;
+ int error;
fn_or_tspec = nextarg(option, argvp);
ftsoptions &= ~FTS_NOSTAT;
@@ -1214,7 +1215,11 @@ c_newer(OPTION *option, char ***argvp)
/* Use the seconds only in the comparison. */
new->t_data.tv_nsec = 9;
} else {
- if (stat(fn_or_tspec, &sb))
+ if (ftsoptions & FTS_PHYSICAL)
+ error = lstat(fn_or_tspec, &sb);
+ else
+ error = stat(fn_or_tspec, &sb);
+ if (error != 0)
err(1, "%s", fn_or_tspec);
if (option->flags & F_TIME2_C)
new->t_data = sb.st_ctim;
However, -samefile is similarly broken. Here's a patch for that part:
--- a/usr.bin/find/function.c
+++ b/usr.bin/find/function.c
@@ -1066,12 +1066,17 @@ c_samefile(OPTION *option, char ***argvp)
char *fn;
PLAN *new;
struct stat sb;
+ int error;
fn = nextarg(option, argvp);
ftsoptions &= ~FTS_NOSTAT;
new = palloc(option);
- if (stat(fn, &sb))
+ if (ftsoptions & FTS_PHYSICAL)
+ error = lstat(fn, &sb);
+ else
+ error = stat(fn, &sb);
+ if (error != 0)
err(1, "%s", fn);
new->i_data = sb.st_ino;
return new;
--
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 222698] find(1)'s -newer expression doesn't work with symbolic links if '-P' (the default) is requested.
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. ___ 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 222698] find(1)'s -newer expression doesn't work with symbolic links if '-P' (the default) is requested.
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. ___ 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 222698] [patch] find(1)'s -newer expression doesn't work with symbolic links if '-P' (the default) is requested.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222698 Conrad Meyer changed: What|Removed |Added Keywords||patch Version|11.1-STABLE |CURRENT Summary|find(1)'s -newer expression |[patch] find(1)'s -newer |doesn't work with symbolic |expression doesn't work |links if '-P' (the default) |with symbolic links if '-P' |is requested. |(the default) is requested. Assignee|freebsd-bugs@FreeBSD.org|freebsd-standards@FreeBSD.o ||rg -- 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 224426] fetch -i runs in an endless loop
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224426 Mark Linimon changed: What|Removed |Added Keywords||patch -- 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 224479] kernel panic in reboot+swapoff sys call
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 it works fine, not kernel panic. Good. I will try to setup a test script which checks if "shutdown -r now" will always work (untils it fails). -- 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 224498] ls -lh does not display properly around 1MB, 1GB, ...
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224498 Bartek Rutkowski changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|ro...@freebsd.org CC||ro...@freebsd.org -- 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 224498] ls -lh does not display properly around 1MB, 1GB, ...
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 edge case in rounding large numbers Fix for remainder overflow, when in rare cases adding remainder to divider exceeded 1 and turned the total to 1000 in final formatting, taking up the space for the unit character. The fix continues the division of the original number if the above case happens -- added the appropriate check to the for loop performing the division. This lowers the value shown, to make it fit into the buffer space provided (1.0M for 4+1 character buffer, as used by ls). Add test case for the reported bug and extend test program to support providing buffer length (ls -lh uses 5, tests hard-coded 4). PR: 224498 Submitted by: Pawel Biernacki Reported by: Masachika Ishizuka Reviewed by: cem, kib Approved by: cem, kib MFC after:1 week Sponsored by: Mysterious Code Ltd. Differential Revision:D13578 Changes: head/lib/libutil/humanize_number.3 head/lib/libutil/humanize_number.c head/lib/libutil/tests/humanize_number_test.c -- 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 224479] kernel panic in reboot+swapoff sys call
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(4) to understand the usages for the files (b) call swap_pager_swapoff() while VFS flushes vnodes. Both are intolerable layering violations, see the reference to 'policy' above. -- 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 224667] The tools reboot and halt are installed with incorrect permissions
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 OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: dr2867.busin...@pacbell.net The programs halt and reboot in /sbin do not seem to be installed with correct group and permissions. strata:/home/dr2867 1032 $$$ ->cd /sbin strata:/sbin 1033 $$$ ->ls -l reboot halt poweroff shutdown -r-xr-xr-x 4 root wheel 7680 Dec 22 23:58 halt -r-sr-xr-- 2 root operator 11508 Dec 22 23:58 poweroff -r-xr-xr-x 4 root wheel 7680 Dec 22 23:58 reboot -r-sr-xr-- 2 root operator 11508 Dec 22 23:58 shutdown strata:/sbin 1034 $$$ -> I do not know if they were installed this way originally, but I noticed this just now after trying to reboot the system as a normal user. I can do it through shutdown -r now though. I have performed a make buildworld and make installworld to include security fixes for 11.1 release. -- 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"
