On Tue, Apr 26, 2016 at 01:43:31PM +1000, David Gwynne wrote:
> the tftp proxy on the firewall is dying these days. i managed to
> track the failure down to an error sending the udp packet on.
>
> rather than err, i think it more appropriate to warn and let the
> client retry in this situation.
>
On Mon, Apr 25, 2016 at 04:06:08PM +0200, Martin Pieuchot wrote:
> On 25/04/16(Mon) 11:35, Visa Hankala wrote:
> > On Mon, Apr 25, 2016 at 10:20:32AM +0200, Martin Pieuchot wrote:
> > > On 24/04/16(Sun) 16:13, Visa Hankala wrote:
> > > > This adds MP-safe TX for cnmac(4). OK?
> > >
> > > Would it
Gleydson Soares wrote:
>
> I just stumbled over this...
>
> % doas abc
> syntax error at line 1
> %
>
> I took some secs trying to figure out what was wrong with abc's command
> syntax that I typed out.
> But bingo, It was happenned due my doas.conf has a syntax error...
> Seems that yyerr
the tftp proxy on the firewall is dying these days. i managed to
track the failure down to an error sending the udp packet on.
rather than err, i think it more appropriate to warn and let the
client retry in this situation.
ok?
Index: tftp-proxy.c
I just stumbled over this...
% doas abc
syntax error at line 1
%
I took some secs trying to figure out what was wrong with abc's command syntax
that I typed out.
But bingo, It was happenned due my doas.conf has a syntax error...
Seems that yyerror() doesn't print out the progname's string,
On Tue, Apr 26, 2016 at 09:55:38AM +1000, Jonathan Gray wrote:
> We normally only add usb devices to usbdevs if they are used in drivers
> and sometimes if the device doesn't provide a string of it's own.
>
> I'd be surprised if a string is not supplied by the device in this case.
You're right. I
On Mon, Apr 25, 2016 at 09:11:35PM -0400, Ted Unangst wrote:
> Theo Buehler wrote:
> > Index: share/man/man8//man8.alpha/MAKEDEV.8
>
> please note the comment at the top of these files. they are autogenerated.
:(
and now i see that i simply missed the update in that part of the
tree... sorry for
Theo Buehler wrote:
> Index: share/man/man8//man8.alpha/MAKEDEV.8
please note the comment at the top of these files. they are autogenerated.
Index: share/man/man8//man8.alpha/MAKEDEV.8
===
RCS file: /var/cvs/src/share/man/man8/man8.alpha/MAKEDEV.8,v
retrieving revision 1.70
diff -u -p -r1.70 MAKEDEV.8
--- share/man/man8//man8.alpha/MAKEDEV.812 Mar 2016 18:02:18 -000
after the this patch and the next, the following files contain the last
appearances of systrace in /usr/src
regress/lib/libc/glob/files
regress/lib/libc/glob/globtest.in
regress/usr.bin/sdiff/file1
regress/usr.bin/sdiff/file2
regress/usr.bin/sdiff/tabs1
regress/usr.bin/sdiff/tabs2
usr.bin/ssh/sand
On Mon, Apr 25, 2016 at 03:20:05PM -0700, Bryan Vyhmeister wrote:
> On Sun, Apr 24, 2016 at 05:01:41PM +1000, Jonathan Gray wrote:
> > Device id appears on the latest generation of thinkpads.
> > It looks like it should be compatible with the others?
> >
> > This requires the pcidevs changes I jus
On Sun, Apr 24, 2016 at 05:01:41PM +1000, Jonathan Gray wrote:
> Device id appears on the latest generation of thinkpads.
> It looks like it should be compatible with the others?
>
> This requires the pcidevs changes I just committed.
>
> Index: sys/dev/pci/rtsx_pci.c
> ==
"Todd C. Miller" writes:
> On Mon, 25 Apr 2016 16:56:47 -0400, "Ted Unangst" wrote:
>
>> compilers will, however, "miscompile" such code. we should avoid it.
>
> Fair enough.
ok jca@
> - todd
>
> Index: lib/libc/stdlib/setenv.c
>
On Mon, 25 Apr 2016 16:56:47 -0400, "Ted Unangst" wrote:
> compilers will, however, "miscompile" such code. we should avoid it.
Fair enough.
- todd
Index: lib/libc/stdlib/setenv.c
===
RCS file: /cvs/src/lib/libc/stdlib/setenv.c,v
Todd C. Miller wrote:
> On Mon, 25 Apr 2016 22:39:48 +0200, Jeremie Courreges-Anglas wrote:
>
> > Agreed, I also had this in mind. But then, should the memset call with
> > a zero size be avoided?
> >
> > if (lastenv != environ)
> > memcpy(P, environ, cnt * sizeof(char *));
>
>
"Todd C. Miller" writes:
> It is already safe to call getenv() and unsetenv() when environ is
> NULL so I think it makes sense for setenv() and putenv() to also
> support this. However, I'd prefer that we just wrap the loop that
> counts the length of environ in an if (environ != NULL) check rat
On Mon, 25 Apr 2016 22:39:48 +0200, Jeremie Courreges-Anglas wrote:
> Agreed, I also had this in mind. But then, should the memset call with
> a zero size be avoided?
>
> if (lastenv != environ)
> memcpy(P, environ, cnt * sizeof(char *));
I thought about that too. Strictly
It is already safe to call getenv() and unsetenv() when environ is
NULL so I think it makes sense for setenv() and putenv() to also
support this. However, I'd prefer that we just wrap the loop that
counts the length of environ in an if (environ != NULL) check rather
than needlessly check for NULL
Jeremie Courreges-Anglas wrote:
>
> A few ports make use of clearenv(3), a GNU extension. This function was
> rejected by POSIX, so what's left?
> I think ports should probably use calloc here if we want to push those
> patches upstream. But supporting the "environ = NULL" method looks
> cheap.
A few ports make use of clearenv(3), a GNU extension. This function was
rejected by POSIX, so what's left?
If all you want to do is clear the environment before exec(), you can
construct a new environment and use execve, which is specified by POSIX.
Now if a port is not using execve, but cleare
On Mon, Apr 25, 2016 at 03:23:47PM +, Robert Peichaer wrote:
> On Mon, Apr 25, 2016 at 10:57:37AM -0400, Ted Unangst wrote:
> > Theo de Raadt wrote:
> > > + cp -p /usr/lib/$_lib /usr/lib/$_tmplib
> > > + install -o root -g bin -m 0444 $_lib /usr/lib/$_lib &&
> >
On Sun, Apr 24, 2016 at 01:48:04PM +0200, Stefan Kempf wrote:
>
> Diff reads good to me. Any reason why you changed setting f_mntfromname
> from "fusefs" to "fuse"?
No, it's a typo; updated diff below. Thanks!
natano
Index: isofs/cd9660/cd9660_vfsops.c
Edgar Pettijohn [ed...@pettijohn-web.com] wrote:
> nevermind just found the elusive "q"
>
There's always the universal ^D
>> Wait! Does that mean there is a moment where there is not a valid
>> libc.so installed? That would be wrong wouldn't it?
>>
>> Doesn't the install command guarantee atomicity?
>
> Well, this is the same procedure we use during every make build,
> and it works.
It had been fixed to use insta
On Mon, 25 Apr 2016 10:18:56 -0600, "Todd C. Miller" wrote:
> On Mon, 25 Apr 2016 18:04:58 +0200, Mark Kettenis wrote:
>
> > Wait! Does that mean there is a moment where there is not a valid
> > libc.so installed? That would be wrong wouldn't it?
> >
> > Doesn't the install command guarantee a
> On Mon, Apr 25, 2016 at 8:23 AM, Robert Peichaer wrote:
> > If the install fails, the original library file is restored.
> >
> > The "install .. && rm .. || mv ..." is identical to if-then-else and could
> > be written like this too.
> >
> > if install -o root -g bin -m 0444 $_lib /usr/l
Robert Peichaer wrote:
> On Mon, Apr 25, 2016 at 10:57:37AM -0400, Ted Unangst wrote:
> > Theo de Raadt wrote:
> > > + cp -p /usr/lib/$_lib /usr/lib/$_tmplib
> > > + install -o root -g bin -m 0444 $_lib /usr/lib/$_lib &&
> > > + rm -f /usr/lib
On Mon, Apr 25, 2016 at 8:23 AM, Robert Peichaer wrote:
> If the install fails, the original library file is restored.
>
> The "install .. && rm .. || mv ..." is identical to if-then-else and could
> be written like this too.
>
> if install -o root -g bin -m 0444 $_lib /usr/lib/$_lib; then
> Wait! Does that mean there is a moment where there is not a valid
> libc.so installed? That would be wrong wouldn't it?
>
> Doesn't the install command guarantee atomicity?
Well, this is the same procedure we use during every make build,
and it works.
On Mon, 25 Apr 2016 18:04:58 +0200, Mark Kettenis wrote:
> Wait! Does that mean there is a moment where there is not a valid
> libc.so installed? That would be wrong wouldn't it?
>
> Doesn't the install command guarantee atomicity?
Seems like it would be safer to just install as /usr/lib/$_tmp
> Date: Mon, 25 Apr 2016 15:23:47 +
> From: Robert Peichaer
>
> On Mon, Apr 25, 2016 at 10:57:37AM -0400, Ted Unangst wrote:
> > Theo de Raadt wrote:
> > > + cp -p /usr/lib/$_lib /usr/lib/$_tmplib
> > > + install -o root -g bin -m 0444 $_lib /usr/lib/$_lib &&
>
> Date: Mon, 25 Apr 2016 17:53:54 +0300
> From: Paul Irofti
>
> We attach acpihpet(4) and acpiec(4) without using the HID, so do not
> report it in the dmesg. Okay?
Sure. At some point I thought acpiec(4) relied on acpi_foundhid() to
attach if an ECDT table wasn't present. But I now see acpi_f
On Mon, Apr 25, 2016 at 10:57:37AM -0400, Ted Unangst wrote:
> Theo de Raadt wrote:
> > + cp -p /usr/lib/$_lib /usr/lib/$_tmplib
> > + install -o root -g bin -m 0444 $_lib /usr/lib/$_lib &&
> > + rm -f /usr/lib/$_tmplib ||
> > +
Theo de Raadt wrote:
> + cp -p /usr/lib/$_lib /usr/lib/$_tmplib
> + install -o root -g bin -m 0444 $_lib /usr/lib/$_lib &&
> + rm -f /usr/lib/$_tmplib ||
> + mv /usr/lib/$_tmplib /usr/lib/$_lib
I'm a li
We attach acpihpet(4) and acpiec(4) without using the HID, so do not
report it in the dmesg. Okay?
Index: acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.309
diff -u -p -u -p -r1.309 acpi.c
--- acpi.c 2
On 25/04/16(Mon) 11:35, Visa Hankala wrote:
> On Mon, Apr 25, 2016 at 10:20:32AM +0200, Martin Pieuchot wrote:
> > On 24/04/16(Sun) 16:13, Visa Hankala wrote:
> > > This adds MP-safe TX for cnmac(4). OK?
> >
> > Would it be possible to do that without mutex? Having the same pattern
> > across mos
This change randomizes the order of symbols in libc.so at boot time.
This is done by saving all the independent .so sub-files into an ar
archive, and then relinking them into a new libc.so in random order,
at each boot. The cost is less than a second on the systems I am
using.
For now, this is o
Diff below makes ip_forward() use the route entry fetched in in_ouraddr().
As you can imagine a proper caching could be done for forwarding using
PF statekey.
This diff has been tested by Hrvoje Popovski who confirmed that the
benchmark performances are similar to the ones using a single cache
en
Hi,
sys_pledge() has races when concurrent threads calling it in parallel.
for now, the race isn't really triggerable, but when wlpaths will be
enabled it could be more simple, and will result in leaking memory
(malloc without associated free).
This diff is an attempt to reordering operations in
On Mon, Apr 25, 2016 at 10:20:32AM +0200, Martin Pieuchot wrote:
> On 24/04/16(Sun) 16:13, Visa Hankala wrote:
> > This adds MP-safe TX for cnmac(4). OK?
>
> Would it be possible to do that without mutex? Having the same pattern
> across most of our drivers would reduce the maintenance effort.
T
Sebastien Marie writes:
> On Sun, Apr 10, 2016 at 01:54:33PM +0200, Sebastien Marie wrote:
>> Hi,
>>
>> The following diff removes an unneeded check on flags. It was used
>> historically, when tame(2) promises were passed as bitflags, in order to
>> avoid userland to be able to set flags normall
On Sun, Apr 10, 2016 at 01:54:33PM +0200, Sebastien Marie wrote:
> Hi,
>
> The following diff removes an unneeded check on flags. It was used
> historically, when tame(2) promises were passed as bitflags, in order to
> avoid userland to be able to set flags normally managed by kernel.
>
> Nowaday
On Sun, Apr 10, 2016 at 03:09:44PM +0200, Sebastien Marie wrote:
> Hi,
>
> The following diff simplifies the check for allowing only promises
> reductions.
ping ?
> Please review it carefully: it implies several bitwise operations.
>
> I will try also to explain the diff step-by-step because ev
On 19/04/16(Tue) 10:43, Martin Pieuchot wrote:
> Mart Tõnso reported [0] a weird case related to the use of ifa_ifwithnet().
>
> The problem is that ifa_ifwithroute() does not always use route entries but
> the poor's man routing table: ifa_ifwithnet(). This is misleading because
> one cannot und
On 24/04/16(Sun) 16:13, Visa Hankala wrote:
> This adds MP-safe TX for cnmac(4). OK?
Would it be possible to do that without mutex? Having the same pattern
across most of our drivers would reduce the maintenance effort.
>
> Index: arch/octeon/dev/if_cnmac.c
> ===
On 19/04/16(Tue) 11:18, Martin Pieuchot wrote:
> These two chunks are equivalent so let's keep one.
>
> ok?
Nobody?
>
> Index: netinet6/ip6_forward.c
> ===
> RCS file: /cvs/src/sys/netinet6/ip6_forward.c,v
> retrieving revision 1.8
On 20/04/16(Wed) 09:33, Dimitris Papastamos wrote:
> On Mon, Apr 18, 2016 at 10:50:46AM +0200, Martin Pieuchot wrote:
> > The current goal of the Network SMP effort is to have a single CPU
> > process the IP forwarding path in a process context without holding
> > the KERNEL_LOCK(). To achieve thi
47 matches
Mail list logo