On Tue, Jul 12, 2016 at 11:46:43AM +0200, Martin Pieuchot wrote:
> 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 ::1
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 ou
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.
>We're
>> not sure what the
> 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 help).
>
> OK?
Makes sense to
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
==
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 the
... 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 -
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 constructe
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
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 w
>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 still
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
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 directory
>
> - todd
>
>
> 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 as
Do you know what other systems return EISDIR for read(2) of a
directory?
- todd
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 ret
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
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 -g
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) flag
> to remember tha
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 that piece of shi
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". However since 1996 this
>> 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.
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
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
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 "stronge
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
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 update
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 tls_config_set_
28 matches
Mail list logo