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 the
> 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
> */
>
> #ifdef BUG_WRITEUP //--
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 system call.
> > *
> > * gcc -
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
LUSH,MMX,FXSR,
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
--- BASE/u
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:
> FPU,V86
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 -igncr
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