Re: dhclient/bpf.c

2016-07-22 Thread Holger Mikolon
I played with different bpf filters and came up with the below patch. It compares the interface's LLADDR with the the respective address in the bootp structure instead of the ether header. I don't know if this is the right way to fix my regression and at the same time retain the original intent of

stty pledge abort

2016-07-22 Thread Alexander Bluhm
Hi, stty(1) can trigger a pledge violation. $ stty -a clocal speed 38400 baud; 24 rows; 80 columns; lflags: icanon isig iexten echo echoe echok echoke -echonl echoctl -echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo -extproc -xcase iflags: -istrip icrnl -inlcr

Re: Hyper-V protection fault trap on i386 with 5.9

2016-07-22 Thread Mike Larkin
On Fri, Jul 22, 2016 at 03:26:01PM +0200, Franco Fichtner wrote: > Hi, > > With a client we're running into the following boot panic > since upgrading from 5.7 to 5.9 on a specific Hyper-V guest: > > cpu0: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz ("GenuineIntel" 686-class) 1.65 GHz > cpu0: >

Alternative control socket location in ripd

2016-07-22 Thread Nima GHOTBI
Hi everyone In one of our projects we had to run multiple instances of ripd on different rdomains so I made a patch to add "-s" argument to ripd and ripctl to let the user change control socket path from /var/run/ripd.sock diff -Naur BASE/usr.sbin/ripd/control.c usr.sbin/ripd/control.c ---

Hyper-V protection fault trap on i386 with 5.9

2016-07-22 Thread Franco Fichtner
Hi, With a client we're running into the following boot panic since upgrading from 5.7 to 5.9 on a specific Hyper-V guest: cpu0: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz ("GenuineIntel" 686-class) 1.65 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CF

Re: [Bug 63] Any user can panic the kernel with the sysctl call.

2016-07-22 Thread Claudio Jeker
On Fri, Jul 22, 2016 at 11:26:57AM +0200, Mark Kettenis wrote: > > From: Tim Newsham > > Date: Fri, 22 Jul 2016 08:32:04 + > > > > Here's a new one we just found: > > > > /* > > * sysctl_tmpfs_panic.c > > *Demonstrate a panic in UFS through the getdents

Re: [Bug 63] Any user can panic the kernel with the sysctl call.

2016-07-22 Thread Mark Kettenis
> From: Tim Newsham > Date: Fri, 22 Jul 2016 08:32:04 + > > Here's a new one we just found: > > /* > * sysctl_tmpfs_panic.c > *Demonstrate a panic in UFS through the getdents system call. > * > * gcc -g sysctl_tmpfs_panic.c -o sysctl_tmpfs_panic > */ >

[Bug 63] Any user can panic the kernel with the sysctl call.

2016-07-22 Thread Tim Newsham
Here's a new one we just found: /* * sysctl_tmpfs_panic.c *Demonstrate a panic in UFS through the getdents system call. * * gcc -g sysctl_tmpfs_panic.c -o sysctl_tmpfs_panic */ #ifdef BUG_WRITEUP //--- Any user can panic the kernel with