Re: Unmounting with MNT_DOOMED flag can lead to a kernel panic

On Tue, Jul 12, 2016 at 12:55:50PM -0600, Todd C. Miller wrote: > On Tue, 12 Jul 2016 07:22:57 -1000, Tim Newsham wrote: > > > Here's another root-only (unless kern.usermount is set) panic issue. We > > exercise it through tmpfs but it might be more general than that. We're > > not sure what

always reset mt state in wsmouse_mt_init

It seems that if an MT device is disabled and reenabled, remnants of the previous MT state can lead to problems. wsmouse_mt_init should always reset that state completely (thanks to jcs@ for help). OK? Index: dev/wscons/wsmouse.c

Re: always reset mt state in wsmouse_mt_init

> From: Ulf Brosziewski > Date: Tue, 12 Jul 2016 23:17:34 +0200 > > It seems that if an MT device is disabled and reenabled, > remnants of the previous MT state can lead to problems. > wsmouse_mt_init should always reset that state completely > (thanks to jcs@ for

Auto tunnel - RFC4213

By default we have a route to reject compatible addresses: ::/96 ::1UGRS 0 0 32768 8 lo0 But the corresponding check in ip6_input() is still commented because it is "stronger than RFC1933". However since 1996 this RFC has been obsoleted twice and

Race in ARP

dlg@ could reproduce a panic by running dhclient in a loop on one of his machines. Turns out that there's a race between arplookup() and arpcache() inside in_arpinput(). If another CPU removes the ARP entry from the table, via RTM_DELETE, it will free the ARP storage. That means we cannot

Re: client certificate support in syslogd

On 12/07/16 02:28, Alexander Bluhm wrote: > On Mon, Jun 27, 2016 at 05:10:14PM +0300, Kapetanakis Giannis wrote: >> new version with all changes > > I have polished the diff a bit and would like to commit it. > > ok? > > bluhm Nice, One question. Since you've already changed to

Re: Auto tunnel - RFC4213

On 12/07/16(Tue) 11:33, Claudio Jeker wrote: > On Tue, Jul 12, 2016 at 11:28:47AM +0200, Martin Pieuchot wrote: > > By default we have a route to reject compatible addresses: > > > > ::/96 ::1UGRS 0 0 32768 8 lo0 > > > > But the corresponding check in

Introduce M_ACAST

Turning the IPv6 forwarding path MP-safe implies, in a first step, to defer local delivery to a context serialized by the KERNEL_LOCK(). This is the same design as for IPv4. In order to keep discarding TCP-over-Anycast I'm using an mbuf(9) flag to remember that a packet has been received on such

Re: Auto tunnel - RFC4213

On Tue, Jul 12, 2016 at 11:28:47AM +0200, Martin Pieuchot wrote: > By default we have a route to reject compatible addresses: > > ::/96 ::1UGRS 0 0 32768 8 lo0 > > But the corresponding check in ip6_input() is still commented because it > is

Re: Unmounting with MNT_DOOMED flag can lead to a kernel panic

On July 12, 2016 8:55:50 PM GMT+02:00, "Todd C. Miller" wrote: >On Tue, 12 Jul 2016 07:22:57 -1000, Tim Newsham wrote: > >> Here's another root-only (unless kern.usermount is set) panic issue. >We >> exercise it through tmpfs but it might be more general than that.

Re: Unmounting with MNT_DOOMED flag can lead to a kernel panic

On Wed, 13 Jul 2016 03:26:34 +0200, Alexander Hall wrote: > Then wouldn't EINVAL be a reasonable response? Am I missing something? We typically ignore flags that don't make sense. For example, chmod(2) doesn't return an error if you pass in a mode with the directory bit set, it just masks it

Re: libcrypto: explicitly initialize constant

>> Noted by VS2013, const values should be initialized (though I think >> the 'static' should also implicitly zero). > > this sounds like the compiler doesn't know C? He is talking about Visual Studio. The C part of that piece of shit pretending to be a compiler only supports a subset of C89.

Re: libcrypto: explicitly initialize constant

On Tue, Jul 12, 2016 at 6:41 AM, Miod Vallat wrote: > >> Noted by VS2013, const values should be initialized (though I think > >> the 'static' should also implicitly zero). > > > > this sounds like the compiler doesn't know C? > > He is talking about Visual Studio. The C part of

Re: Auto tunnel - RFC4213

Martin Pieuchot writes: > By default we have a route to reject compatible addresses: > > ::/96 ::1UGRS 0 0 32768 8 lo0 > > But the corresponding check in ip6_input() is still commented because it > is "stronger than RFC1933".

Re: Introduce M_ACAST

Martin Pieuchot writes: > Turning the IPv6 forwarding path MP-safe implies, in a first step, to > defer local delivery to a context serialized by the KERNEL_LOCK(). This > is the same design as for IPv4. > > In order to keep discarding TCP-over-Anycast I'm using an mbuf(9)

Unmounting with MNT_DOOMED flag can lead to a kernel panic

Here's another root-only (unless kern.usermount is set) panic issue. We exercise it through tmpfs but it might be more general than that. We're not sure what the proper remediation should be here. /* * unmount_panic.c *Demonstrate a panic through the unmount system call. * * gcc

read(2) on directories

Sending this now to get opinions, but I do not plan any change for 6.0. Since I started to use OpenBSD I've always found confusing that cat /directory/ doesn't error out. I initially assumed that it was historical behavior, but, as hinted by Theo, in rev. 1.1 the behavior was actually to

Re: read(2) on directories

> From: j...@wxcvbn.org (Jeremie Courreges-Anglas) > Date: Tue, 12 Jul 2016 21:10:37 +0200 > > Sending this now to get opinions, but I do not plan any change for 6.0. > > Since I started to use OpenBSD I've always found confusing that > > cat /directory/ > > doesn't error out. I initially

Re: read(2) on directories

On Tue, Jul 12, 2016 at 9:19 AM, Todd C. Miller wrote: > Do you know what other systems return EISDIR for read(2) of a > directory? > Linux: >>> os.open("/", 0) 3 >>> os.read(3, 1024) Traceback (most recent call last): File "", line 1, in OSError: [Errno 21] Is a

Re: Unmounting with MNT_DOOMED flag can lead to a kernel panic

On Tue, 12 Jul 2016 07:22:57 -1000, Tim Newsham wrote: > Here's another root-only (unless kern.usermount is set) panic issue. We > exercise it through tmpfs but it might be more general than that. We're > not sure what the proper remediation should be here. The only valid flag for umount(2) is

Re: read(2) on directories

Do you know what other systems return EISDIR for read(2) of a directory? - todd

Re: read(2) on directories

On Tue, 12 Jul 2016 21:23:51 +0200, Mark Kettenis wrote: > What do other BSDs (including Mac OS X) do? Mac OS X returns EISDIR. - todd

Re: read(2) on directories

Todd C. Miller [todd.mil...@courtesan.com] wrote: > On Tue, 12 Jul 2016 12:47:46 -0700, Chris Cappuccio wrote: > > > I've personally always liked being able to cat / read() a directory > > since it gives you a peek behind the curtain and reflects the > > reality of how the filesystem is

Unsigned variables can't be < 0

... and size_t is unsigned. Index: sys/dev/wscons/wsmouse.c === RCS file: /home/OpenBSD/cvs/src/sys/dev/wscons/wsmouse.c,v retrieving revision 1.31 diff -u -p -U8 -r1.31 wsmouse.c --- sys/dev/wscons/wsmouse.c5 Jul 2016 19:33:14

Re: read(2) on directories

Todd C. Miller [todd.mil...@courtesan.com] wrote: > >From source inspection, Net and Free appear to allow read(2) of > dirs to succeed. However, since Linux, Mac OS X and Solaris have > the EISDIR behavior I think it is probably safe from a portability > standpoint. > > We're long past the days

Re: read(2) on directories

On Tue, 12 Jul 2016 12:47:46 -0700, Chris Cappuccio wrote: > I've personally always liked being able to cat / read() a directory > since it gives you a peek behind the curtain and reflects the > reality of how the filesystem is constructed. You haven't been able to do that on OpenBSD for a very

Re: read(2) on directories

>From source inspection, Net and Free appear to allow read(2) of dirs to succeed. However, since Linux, Mac OS X and Solaris have the EISDIR behavior I think it is probably safe from a portability standpoint. We're long past the days when opendir(3)/readdir(3) used read(2)... HP-UX and AIX