Re: MP-safe TX for cnmac(4)

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

Re: anti-ROP mechanism in libc

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 || > > +

Re: anti-ROP mechanism in libc

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

acpi: add HPET and EC to skip_hids

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

Re: Clearing environ

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 >

Re: Clearing environ

"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 >

Re: match RTS522A in rtsx(4)

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 >

Re: anti-ROP mechanism in libc

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

Re: anti-ROP mechanism in libc

> 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.

Re: anti-ROP mechanism in libc

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

Re: anti-ROP mechanism in libc

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

Re: anti-ROP mechanism in libc

> 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

Re: anti-ROP mechanism in libc

>> 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

Re: anti-ROP mechanism in libc

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

Re: dc patch

Edgar Pettijohn [ed...@pettijohn-web.com] wrote: > nevermind just found the elusive "q" > There's always the universal ^D

Re: numerous statfs bugs

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

Re: anti-ROP mechanism in libc

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 && > >

Clearing environ

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

more systrace mop up 2/2: man8.${ARCH}/MAKEDEV.8

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

more systrace mop up 1/2: distrib/sets/lists

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

Re: match RTS522A in rtsx(4)

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

Re: more systrace mop up 2/2: man8.${ARCH}/MAKEDEV.8

Theo Buehler wrote: > Index: share/man/man8//man8.alpha/MAKEDEV.8 please note the comment at the top of these files. they are autogenerated.

Re: Clearing environ

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

Re: Clearing environ

"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

Re: Clearing environ

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

Re: Clearing environ

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

Re: Clearing environ

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 *)); > >

Re: pledge: remove unneeded check in sys_pledge()

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. > >

Re: pledge: remove unneeded check in sys_pledge()

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

Re: MP-safe TX for cnmac(4)

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 >

Re: Duplicate route lookups

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

Re: ifa_ifwithroute() fix

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

anti-ROP mechanism in libc

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

doas: adjust yyerror() output

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

Re: match RTS522A in rtsx(4)

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.

Re: more systrace mop up 2/2: man8.${ARCH}/MAKEDEV.8

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

Re: doas: adjust yyerror() output

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

failure to send a udp packet is not a fatal error

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

Re: MP-safe TX for cnmac(4)

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

Re: Moving away from softnet interrupts

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

Single route lookup when forwarding an IPv4 packet

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

Re: MP-safe TX for cnmac(4)

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.

pledge: serialize (v2 - reordering version)

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