[Bug 204813] suggeted improvement for crontab(1)'s newly created files
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204813 --- Comment #4 from commit-h...@freebsd.org --- A commit references this bug: Author: jilles Date: Tue Jan 5 16:21:21 UTC 2016 New revision: 293204 URL: https://svnweb.freebsd.org/changeset/base/293204 Log: Add sbin and /usr/local directories to _PATH_DEFPATH. Set _PATH_DEFPATH to /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin. This is the path in the default class in the default /etc/login.conf, excluding ~/bin which would not be expanded properly in a string constant. For normal logins, _PATH_DEFPATH is overridden by /etc/login.conf, ~/.login_conf or shell startup files. _PATH_DEFPATH is still used as a default by execlp(), execvp(), posix_spawnp() and sh if PATH is not set, and by cron. Especially the latter is a common trap (most recently in PR 204813). PR: 204813 Reviewed by: secteam (delphij), alfred Changes: head/include/paths.h head/lib/libc/gen/exec.3 head/lib/libc/gen/posix_spawn.3 head/usr.sbin/cron/crontab/crontab.5 -- 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 205855] ICH7R identified as ICH9R, doesn't work in RAID mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205855 John Baldwin changed: What|Removed |Added CC||j...@freebsd.org --- Comment #3 from John Baldwin --- Can you get pciconf -lv output from a working 10.1 kernel with the mode set to RAID? I believe the devices use different device IDs depending on the BIOS setting, so the pciconf -lv output will differ for different BIOS settings. -- 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 205855] ICH7R identified as ICH9R, doesn't work in RAID mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205855 John Baldwin changed: What|Removed |Added Status|New |Open CC||m...@freebsd.org --- Comment #4 from John Baldwin --- Actually, I suspect that this change may be the issue: https://svnweb.freebsd.org/base?view=revision&revision=287016 IIRC, there might be some Intel parts that support AHCI but don't advertise it via the progif config register. In that case, we need to keep the old "force AHCI" bits in ata-intel.c instead. -- 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 205855] ICH7R identified as ICH9R, doesn't work in RAID mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205855 --- Comment #5 from John Baldwin --- And to be clear, having the pciconf -lv output from the older kernel with RAID mode enabled is still needed to determine if my theory is correct. -- 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 205926] jail(8): fails to parse ifconfig parameters in ip4.addr and ip6.addr after /netmask
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205926 Bug ID: 205926 Summary: jail(8): fails to parse ifconfig parameters in ip4.addr and ip6.addr after /netmask Product: Base System Version: 10.2-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: mark.marti...@ijs.si The jail(8) man page states that additional ifconfig parameters may be supplied after ip-address/netmask in ip4.addr and ip6.addr (which is needed for example to specify a CARPed IP address): The manpage states: ip4.addr In addition to the IP addresses that are passed to the kernel, an interface, netmask and additional paramters (as supported by ifconfig(8)) may also be specified, in the form “interface|ip-address/netmask param ...”. As it turns out this does not work, unless /netmask is omitted. Seems like the check_intparams() in /usr/src/usr.sbin/jail/config.c assumes that everything after a slash is a netmask or a mask-length (or IPv6 prefix length), so any parameter following a /netmask is treated as a netmask syntax error. Example: # jail -c ip4.addr='igb0|10.0.0.246/24 vhid 23 advskew 100' \ ip6.addr='igb0|2001:db8::246/64 vhid 23 advskew 100' [...] jail: ip4.addr: bad netmask "/24 vhid 23 advskew 100" jail: ip6.addr: bad prefixlen "/64 vhid 23 advskew 100" Omitting the /24 (and /64) works as intended, but the implied mask length is /32 (and /128). An attempted workaround like: ip4.addr='igb0|10.0.0.246 netmask 255.255.255.0 vhid 23 advskew 100' produces a double netmask option to ifconfig, which may be ambiguous (or a potential syntax error) - as reported by jail -v : run command: /sbin/ifconfig igb0 inet 10.0.0.246 \ netmask 255.255.255.255 netmask 255.255.255.0 vhid 23 advskew 100 alias ( Btw, why does the jail(8) bother to convert a mask length into a netmask, where the ifconfig is perfectly happy with a CIDR notation? ) -- 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 205926] jail(8): fails to parse ifconfig parameters in ip4.addr and ip6.addr after /netmask
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205926 --- Comment #1 from mark.marti...@ijs.si --- > Btw, why does the jail(8) bother to convert a mask length [...] It doesn't - please disregard this last comment. -- 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 205663] clang++ 3.7.1 gets Bus Errors during compilation on arm that has SCTLR bit[1]==1 (alignment required)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205663 --- Comment #6 from Mark Millard --- llvm.org's Bugzilla reports that clang trunk has been fixed and clang 3.8 will contain the fixes: James Molloy changed bug 25958 WhatRemoved Added Status NEW RESOLVED Resolution --- FIXED Comment # 8 on bug 25958 from James Molloy Hi Mark, Thanks for your detailed investigation. I can confirm that this is fixed on trunk and therefore will be fixed for LLVM 3.8. The fixes were done for SPARC, which requires strict accesses much as ARM does with SCTLR=1. There was a sequence of commits by James Knight that fixed these, but an example is http://reviews.llvm.org/rL242554 . The fixes were in a similar vein to yours, but required changes in fewer places and there were a few more sticky issues to solve too. I'll CC James here in case he wants to comment on the current state of the clang codebase for self-hosting in a strict alignment environment. Cheers, James -- 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 205928] Ipfw segmentation fault with nat command
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205928
Bug ID: 205928
Summary: Ipfw segmentation fault with nat command
Product: Base System
Version: 10.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs@FreeBSD.org
Reporter: m...@steepath.eu
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org
I was testing nat with ipfw, and during my test (reading example file), a
segmentation fault was found after executing one example command.
Here the bug:
--
$ ipfw add nat
Segmentation fault
$ echo $?
139
--
Here a small investigation:
--
# cd /usr/src/sbin/ipfw
# make DEBUG_FLAGS=-g
$ gdb ./ipfw
(gdb) run add nat
Program received signal SIGSEGV, Segmentation fault.
0x000800b85fbb in strlen () from /lib/libc.so.7
(gdb) i r
rax0x1b 27
rbx0x6183f0 6390768
rcx0x0 0
rdx0x0 0
rsi0x0 0
rdi0x0 0
rbp0x7fffd2e0 0x7fffd2e0
rsp0x7fffd2e0 0x7fffd2e0
r8 0xf80235122920 -8786612704992
r9 0x0 0
r100x0 0
r110x246582
r120x801406050 34380734544
r130x801406058 34380734552
r140x0 0
r150x3 3
rip0x800b85fbb 0x800b85fbb
eflags 0x10246 66118
cs 0x43 67
ss 0x3b 59
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb) bt
#0 0x000800b85fbb in strlen () from /lib/libc.so.7
#1 0x00405c43 in ipfw_add (av=0x801406058) at ipfw2.c:527
#2 0x00410182 in ipfw_main (oldac=,
oldav=)
at main.c:407
#3 0x0040f55b in main (ac=3, av=0x7fffe688) at
main.c:620
--
after adding some c code into main.c:
--
$ svnlite diff ipfw2.c
Index: ipfw2.c
===
--- ipfw2.c (revision 291749)
+++ ipfw2.c (working copy)
@@ -522,6 +522,7 @@
int
_substrcmp(const char *str1, const char* str2)
{
+ printf("str1: %s, str2: %s\n", str1, str2);
if (strncmp(str1, str2, strlen(str1)) != 0)
return 1;
@@ -2865,6 +2866,7 @@
* Some things that need to go out of order (prob, action etc.)
* go into actbuf[].
*/
+ printf("in\n");
static uint32_t rulebuf[255], actbuf[255], cmdbuf[255];
int rblen, ablen, cblen;
--
This code return this:
--
str1: add, str2: queue
str1: add, str2: flowset
str1: add, str2: sched
str1: add, str2: add
before:
in
str1: (null), str2: global
Segmentation fault
--
So, ipfw try to compare a null-pointer to a const char* in strncmp() function.
I don't know if this segmentation fault is due to this last function, or linked
to another issue.
If you have any idea. ;)
--
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 178396] [kernel] [patch] Add jid to kernel log when a process has been forced closed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178396 te...@elde.net changed: What|Removed |Added CC||te...@elde.net --- Comment #2 from te...@elde.net --- This looks like a good idea to me, and people are in need of it as well: https://twitter.com/tykling/status/684359369102868480 -- 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 205930] -funroll-loop options is undocument
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205930 Bug ID: 205930 Summary: -funroll-loop options is undocument Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: ka...@freebsd.org cc accepts the undocumented option -funroll-loops. As it is undocumented, one has no idea what it does. If cc does unrolling, there appears to be no way to control the level of unrolling. Please fix. -- 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 205930] -funroll-loop options is undocument
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205930 NGie Cooper changed: What|Removed |Added CC||n...@freebsd.org --- Comment #1 from NGie Cooper --- A lot of options are unfortunately undocumented with clang :(... see this thread for more details: http://clang-developers.42468.n3.nabble.com/clang-1-3-4-manpage-documentation-is-sparse-need-help-figuring-out-available-options-in-compiler-td4042738.html (tl;dr: submit a patch to our project and we'll accept it :/...). -- 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 205930] clang(1) doesn't document all flags and options
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205930 NGie Cooper changed: What|Removed |Added Summary|-funroll-loop options is|clang(1) doesn't document |undocument |all flags and options -- 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 205932] [panic] Kernel panic when copying from ext2fs partition to UFS partition
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205932 Bug ID: 205932 Summary: [panic] Kernel panic when copying from ext2fs partition to UFS partition Product: Base System Version: 10.2-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Some People Priority: --- Component: misc Assignee: freebsd-bugs@FreeBSD.org Reporter: will_brokenbou...@yahoo.com CC: freebsd-am...@freebsd.org CC: freebsd-am...@freebsd.org Created attachment 165117 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=165117&action=edit Verbose kernel panic textual information When copying files from an ext4 partition on device ada1 mounted read-only to a user's home directory on the FreeBSD root (UFS) partition on device ada0, a kernel panic occurs after around 100 files are copied. It appears at least one other person has experienced this recently: http://freebsd.1045724.n5.nabble.com/Ext4-Kernel-Panic-td6025605.html This kernel panic happens after a fresh install with NO packages or ports installed yet and both before AND after performing system update with freebsd-update. COMMANDS ISSUED (under root account): - - - # mount -t ext2fs -o ro /dev/ada1p4 /mnt/adisk # cd /mnt/adisk # ls lost+found will # cp -Rnv will /home/will (KP happens after about 100 files copied) - - - CRASH INFO: - - - Dump header from device /dev/ada0p3 Architecture: amd64 Architecture Version: 2 Dump Length: 714723328B (681 MB) Blocksize: 512 Dumptime: Tue Jan 5 10:51:56 2016 Hostname: will-freebsd Magic: FreeBSD Kernel Dump Version String: FreeBSD 10.2-RELEASE #0 r28: Wed Aug 12 15:26:37 UTC 2015 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC Panic String: __lockmgr_args: recursing on non recursive lockmgr getblk @ (null):0 Dump Parity: 3650188378 Bounds: 1 Dump Status: good - - - The more verbose crash text is attached. -- 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 205933] [boot] Loader hangs when connecting serial console
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205933 Bug ID: 205933 Summary: [boot] Loader hangs when connecting serial console Product: Base System Version: 10.2-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: ara...@mgk.ro $ freebsd-version ; uname -a 10.2-RELEASE-p8 FreeBSD z800.mgk.ro 10.2-RELEASE-p7 FreeBSD 10.2-RELEASE-p7 #0: Mon Nov 2 14:19:39 UTC 2015 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 $ $ cat /boot/loader.conf loader_color="NO" loader_logo="beastiebw" boot_multicons="YES" boot_serial="YES" comconsole_speed="115200" console="comconsole,vidconsole" kern.geom.label.gptid.enable="0" zfs_load="YES" $ $ grep -v '^#' /etc/ttys console noneunknown off secure ttyv0 "/usr/libexec/getty Pc" xterm on secure ttyv1 "/usr/libexec/getty Pc" xterm on secure ttyv2 "/usr/libexec/getty Pc" xterm on secure ttyv3 "/usr/libexec/getty Pc" xterm on secure ttyv4 "/usr/libexec/getty Pc" xterm on secure ttyv5 "/usr/libexec/getty Pc" xterm on secure ttyv6 "/usr/libexec/getty Pc" xterm on secure ttyv7 "/usr/libexec/getty Pc" xterm on secure ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure ttyu0 "/usr/libexec/getty std.115200" vt100 onifconsole secure ttyu1 "/usr/libexec/getty std.9600" dialup off secure ttyu2 "/usr/libexec/getty std.9600" dialup off secure ttyu3 "/usr/libexec/getty std.9600" dialup off secure dcons "/usr/libexec/getty std.9600" vt100 off secure When I boot without a serial console attached, boot proceeds fine (the loader autoboots after an interval). However, when I attach a serial console, the loader hangs as if I had pressed a key to stop the boot. The boot proceeds normally after I press Enter. This seems to be correlated with whether I have a remote terminal emulator on that serial line or not. If there's nobody listening, so to speak, the boot proceeds fine, but if I connect with screen, cu, or minicom, the boot pauses and waits for input. Not sure if this matters or not, but the remote machine connects to the serial console through an USB adapter. This seems to be related, or perhaps the same problem as the one described in this mailing list post: https://lists.freebsd.org/pipermail/freebsd-stable/2014-April/078378.html. -- 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 205934] clang crashes in configure test with #pragma weak
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205934
Bug ID: 205934
Summary: clang crashes in configure test with #pragma weak
Product: Base System
Version: 10.2-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: freebsd-bugs@FreeBSD.org
Reporter: f...@fuz.su
The following very short C program triggers a bug in /usr/bin/cc (Clang 3.4.1)
on amd64 FreeBSD 10.2-RELEASE:
extern int test2();
#pragma weak test2 = test1
int test1() {return 0;}
int main() {
return test2();
; return 0; }
This program is used as a configure test in the Schily utilities, it's supposed
to test if the compiler correctly supports SysV #pragma weak, though it's not
supposed to induce a compiler crash. The output of /usr/bin/cc is:
Stack dump:
0. Program arguments: /usr/bin/cc -cc1 -triple x86_64-unknown-freebsd10.2
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
clang-bug.c -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -coverage-file
/tmp/clang-bug.o -resource-dir /usr/bin/../lib/clang/3.4.1
-fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 0 -mstackrealign
-fobjc-runtime=gnustep -fdiagnostics-show-option -vectorize-slp -o clang-bug.o
-x c clang-bug.c
1. clang-bug.c:5:14: current parser token ')'
2. clang-bug.c:4:12: parsing function body 'main'
3. clang-bug.c:4:12: in compound statement ('{}')
cc: error: unable to execute command: Segmentation fault (core dumped)
cc: error: clang frontend command failed due to signal (use -v to see
invocation)
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.2
Thread model: posix
cc: note: diagnostic msg: PLEASE submit a bug report to
https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed
source, and associated run script.
cc: note: diagnostic msg:
PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
cc: note: diagnostic msg: /tmp/clang-bug-60a5bb.c
cc: note: diagnostic msg: /tmp/clang-bug-60a5bb.sh
cc: note: diagnostic msg:
--
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 205930] clang(1) doesn't document all flags and options
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205930 --- Comment #2 from Steve Kargl --- Oh yuck. Long lines and new sentences starting in the middle of a line. diff -u cc.1.orig cc.1 --- cc.1.orig 2016-01-05 11:57:16.699107000 -0800 +++ cc.12016-01-05 12:12:47.718444000 -0800 @@ -251,8 +251,15 @@ through Clang compiled stack frames. This is on by default in x86-64. .It Sy -ftrapv Generate code to catch integer overflow errors. Signed integer overflow is -undefined in C, with this flag, extra code is generated to detect this and abort -when it happens. +undefined in C, with this flag, extra code is generated to detect this and +abort when it happens. +.It Sy -funroll-loops +This option is accepted by the compiler, but testing with simply +loops suggests that apparently does nothing. +Surprisingly, +.Nm +does not issue a warning about the omission of what can only be characterized +as a basic optimization. .It Sy -fvisibility This flag sets the default visibility level. .It Sy -fcommon -- 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 205855] ICH7R identified as ICH9R, doesn't work in RAID mode
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205855 --- Comment #6 from arca...@ivanovy.net --- Will do. -- 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 198062] FreeBSD 10.1-RELEASE kernel freezes on 'pci0: on pcib0'
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198062 --- Comment #18 from John Baldwin --- (In reply to Joseph King from comment #16) Install a version that works. Then build a test kernel with the patch and boot it. One method of building a test kernel: # Checkout a tree % mkdir pr_198062 % cd pr_198062 % svn co svn://svn.freebsd.org/base/stable/10 . # Apply the patch % fetch -o foo.patch https://github.com/bsdjhb/freebsd/compare/stable/10...bsdjhb:pr_198062.diff % patch -p1 < foo.patch % find . -name '*.rej' # This last command should generate no output # Build a toolchain % make kernel-toolchain # Build a test kernel and install it to /boot/test % make buildkernel % make installkernel INSTKERNNAME=test # Reboot with the test kernel % nextboot -k test % reboot If I update the patch with additional changes you can do this: % cd pr_198062 % svn revert -R . And then apply the new patch same fetch / patch / find commands from above followed by building the kernel, installing it, and rebooting. You can avoid the manual patch, etc. steps if you install git and do this instead: % mkdir pr_198062 % git clone https://github.com/bsdjhb/freebsd.git % cd freebsd % git checkout pr_198062 Can then build a kernel toolchain and kernel using same steps as before. After I update the patch you can do this: % git pull Followed by building the kernel, installing it, and rebooting. -- 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 205938] [ext2fs][patch][panic] EXT4: reading mmaped file causes panic because struct buf leaks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205938 Bug ID: 205938 Summary: [ext2fs][patch][panic] EXT4: reading mmaped file causes panic because struct buf leaks Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: crash, patch Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: damjan@gmail.com CC: freebsd...@freebsd.org Created attachment 165127 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=165127&action=edit Fix a kernel panic when reading mmaped files from EXT4 Calling mmap() on any sizeable file on an EXT4 filesystem, and then attempting to read that memory (can be easily tested using the "cmp file file" tool), causes a reproducible kernel panic: userret: returning with the following locks held: exclusive lockmgr bufwait (bufwait) r = 0 (0xfe001d90c220) locked @ /usr/src/sys/kern/vfs_bio.c:1454 panic: witness_warn cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace-self_wrapper+0x2b/frame 0xfe002b7e67f0 vpanic() at vpanic+0x182/frame 0xfe002b7e6870 kassert_panic() at kassert_panic+0x126/frame 0xfe002b7e68e0 witness_warn() at witness_warn+0x3c6/frame 0xfe002b7e69b0 userret() at userret+0x98/frame 0xfe002b7e69e0 trap() at trap+0x3f4/frame 0xfe002b7e6bf0 calltrap() at calltrap+0x8/frame 0xfe002b7e6bf0 --- trap 0xc, rip = 0x4019c0, rsp = 0x7fffe940, rbp = 0x7eea30 --- KDB: enter: panic [ thread pid 909 tid 100082 ] Stopped at kdb_enter+0x3b: movq$0,kdb_why The problem comes from ext4_bmapext() in sys/fs/ext2fs/ext2_bmap.c never calling brelse(), meaning the "struct buf" returned in path.ep_bp from ext4_ext_find_extent() is never released/unlocked, something userret() catches later and panics from. The attached patch always calls brelse(path.ep_bp), fixing reading EXT4 files using mmap(). This affects all versions of FreeBSD. -- 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 178396] [kernel] [patch] Add jid to kernel log when a process has been forced closed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178396 tho...@gibfest.dk changed: What|Removed |Added CC||tho...@gibfest.dk --- Comment #3 from tho...@gibfest.dk --- Created attachment 165129 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=165129&action=edit updated patch against stable/10 r293209 The original attachment in this bug no longer works since it doesn't use the newish jailed() to check if the process is jailed. The attachment I'm adding is a patch against stable/10 base r293209 which fixes the jailed detection, and also adds jail hostname to the log entry (when a jail hostname is available). For this patch to work on HEAD the exit1() call needs to be changed, no other changes needed I think. This patch could be a few lines shorter by only having one log() call, which includes a empty string for nonjailed processes and something like ", jid: xxx (example.com)" for jailed processes. The current is arguably more readable though. Testing with this patch applied: - [tykling@test /usr/src]$ sudo jail -c path=/ command=/bin/sh # perl -e 'dump' Abort trap (core dumped) # ^Djail: /bin/sh: failed [tykling@test /usr/src]$ sudo jail -c path=/ host.hostname=example.com command=/bin/sh # perl -e 'dump' Abort trap (core dumped) # ^Djail: /bin/sh: failed [tykling@test /usr/src]$ perl -e 'dump' Abort trap [tykling@test /usr/src]$ dmesg | tail -3 pid 847 (perl), uid 0, jid 3: exited on signal 6 (core dumped) pid 853 (perl), uid 0, jid 4 (example.com): exited on signal 6 (core dumped) pid 857 (perl), uid 1001: exited on signal 6 [tykling@test /usr/src]$ - I am not good with C so please feel free to comment on style and other problems. Thanks :) -- 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 205932] [panic] Kernel panic when copying from ext2fs partition to UFS partition
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205932 --- Comment #1 from Will B --- Testing the same ext4->UFS copy with FreeBSD 10.2 amd64 in VirtualBox also yields the same kernel panic with the same panic type, so it appears to rule out hardware. I also tried adding 'sync' to the mount options in /etc/fstab but this made no difference...the kernel panic still happens. -- 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 205871] install(1) in endless loop for orphaned symlinks
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205871 Mateusz Guzik changed: What|Removed |Added Status|New |In Progress CC||m...@freebsd.org Assignee|freebsd-bugs@FreeBSD.org|m...@freebsd.org --- Comment #1 from Mateusz Guzik --- Bugreport looks legitimate. However, it is unclear what to do here - do an lstat or stat + lstat combo? I'll have to look around. -- 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 178396] [kernel] [patch] Add jid to kernel log when a process has been forced closed
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178396
Mateusz Guzik changed:
What|Removed |Added
CC||m...@freebsd.org
--- Comment #4 from Mateusz Guzik ---
The feature is definitely desirable.
I would argue the complete solution would just support jail-aware dmesgs and
print jail-specific stuff specific stuff with appropriate prefix to the 'main'
dmesg. This would require some effort and may be off the table for now.
Regardless, it would be good if the new message here got the format one would
expect to see in the more advanced case.
There is further issue with increased infoleaks - now not only you learn what
segfaulting programs are being used by other jails, you get their (host)names.
Either way, the patch is wrong:
+ if (jailed(p->p_ucred)) {
+ char buf[MAXHOSTNAMELEN + 3];
+ if (strcmp(p->p_ucred->cr_prison->pr_hostname,
"") != 0) {
+ sprintf(buf, " (%s)",
p->p_ucred->cr_prison->pr_hostname);
+ } else {
+ *buf = '\0';
+ }
This should have used getcredhostname, assuming hostname is desirable. I would
argue hostname is not the field you are interested in - after all, jail can
change it. Instead, you should obtain jail name.
Also, this patch does not handle hierarchical jails.
+ log(LOG_INFO,
+ "pid %d (%s), uid %d, jid %d%s: exited on
signal %d%s\n",
+ p->p_pid, p->p_comm,
+ td->td_ucred->cr_uid,
+ p->p_ucred->cr_prison->pr_id,
+ buf,
+ sig &~ WCOREFLAG,
+ sig & WCOREFLAG ? " (core dumped)" : "");
+ } else {
+ log(LOG_INFO,
+ "pid %d (%s), uid %d: exited on signal
%d%s\n",
+ p->p_pid, p->p_comm,
+ td->td_ucred ? td->td_ucred->cr_uid : -1,
+ sig &~ WCOREFLAG,
+ sig & WCOREFLAG ? " (core dumped)" : "");
+ }
As a nit, just should have been handled with one log() call. Missing optional
jail bit could be provided with a pointer to "".
That said, I would be in favor of messages like this one:
[$jailname] $msg
That is:
pid 857 (perl), uid 1001: exited on signal 6
is turned into:
[foo] pid 857 (perl), uid 1001: exited on signal 6
Assuming jail name is 'foo'. For hierarchical jails this would be [foo.bar].
--
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"
