Re: Add Diffie-Hellman group negotiation to iked

viq writes: > On 17-06-25 21:44:24, Tim Stewart wrote: >> Hi, >> >> In this message I've tried to encode everything I've done to allow >> strongSwan on Android to connect with iked, including the latest patch. >> I have also verified that it breaks neither initial negotiation

Re: armv7 static vectors

On Mon, Jul 10, 2017 at 04:19:12PM +0300, Artturi Alm wrote: > Hi, > > > this diff does seem bigger than it is, because this does move the exception > handler entrys from arm/exceptions.S to arm/vectors.S, while removing > a round of useless indirection that was needed more before VBAR, which >

[patch] httpd: don't add date header if already set

hello tech@, here is a diff that will cause httpd's fcgi code to not set the HTTP date header if it has already been set. the code i am using for an fcgi server (https://github.com/golang/go/blob/master/src/net/http/fcgi/child.go#L102) unconditionally sets the Date header, so with httpd there

Re: armv7 arm/pmap.h unused defines/variables.

On Sun, Jul 09, 2017 at 12:50:47PM +0300, Artturi Alm wrote: > Hi, > > might have sent this before. at best (or worst, depends how you look at > things), these could help hide a bug that'd be able to bring everything > down in flames, altho. i'm not suggesting so, and have in the past ran >

Re: armv7 sunxi i2c+pmic(=shutdown -p)

On Sun, Jul 16, 2017 at 11:13:35PM +0200, Mark Kettenis wrote: > > Date: Sun, 9 Jul 2017 20:34:29 +0300 > > From: Artturi Alm > > > > Hi, > > > > revived the diff below, i2c tested via pmic's shutdown(), for working > > "shutdown -p now" operation. > > there was only two

Re: log max line length

I like all of these changes. > We have the same limit for syslog lines in libc, kernel, syslogd > now. Do we want a common constant? Is the name LOG_MAXLINE suitable > as a global name? Most constants in sys/syslog.h start with LOG_. > > While there I renamed TBUF_LEN and FMT_LEN to _SIZE as

log max line length

Hi, We have the same limit for syslog lines in libc, kernel, syslogd now. Do we want a common constant? Is the name LOG_MAXLINE suitable as a global name? Most constants in sys/syslog.h start with LOG_. While there I renamed TBUF_LEN and FMT_LEN to _SIZE as they contain a NUL byte. Change

Re: elf.h

Hi, the diff below is generated by CVS. For this I removed include/elf_abi.h and added include/elf.h. I've also merged two _KERNEL sections together and fixed platforms ld.so/*/archdep.h files for inclusion of elf_abi.h. Otherwise the description from previous version still apply. Karel On

Re: /etc/rc: kernel relinking failed

On Tue, Jul 18, 2017 at 11:07:29PM +0200, Hrvoje Popovski wrote: > On 18.7.2017. 22:59, Theo Buehler wrote: > > On Tue, Jul 18, 2017 at 10:55:59PM +0200, Hrvoje Popovski wrote: > >> Hi all, > >> > >> i have checkout cvs tree few minutes ago and i'm seeing this log. > >> > >> Jul 18 22:47:36

Re: /etc/rc: kernel relinking failed

On 18.7.2017. 22:59, Theo Buehler wrote: > On Tue, Jul 18, 2017 at 10:55:59PM +0200, Hrvoje Popovski wrote: >> Hi all, >> >> i have checkout cvs tree few minutes ago and i'm seeing this log. >> >> Jul 18 22:47:36 x3550m4 /etc/rc: kernel relinking failed; see >>

Re: /etc/rc: kernel relinking failed

On Tue, Jul 18, 2017 at 10:55:59PM +0200, Hrvoje Popovski wrote: > Hi all, > > i have checkout cvs tree few minutes ago and i'm seeing this log. > > Jul 18 22:47:36 x3550m4 /etc/rc: kernel relinking failed; see > /usr/share/compile/GENERIC.MP/relink.log Sorry, this is my mistake. I completely

Re: introduction of an additional non-POSIX function in libpthread

Sure thing, here an updated diff. Regards. On 18 July 2017 at 16:22, Ted Unangst wrote: > David CARLIER wrote: > > Hi. > > > > I sent a diff originally to a smaller audience but finally decided to > post > > it in the mailing list. > > So it is to introduce the

/etc/rc: kernel relinking failed

Hi all, i have checkout cvs tree few minutes ago and i'm seeing this log. Jul 18 22:47:36 x3550m4 /etc/rc: kernel relinking failed; see /usr/share/compile/GENERIC.MP/relink.log here it is: http://kosjenka.srce.hr/~hrvoje/zaprocvat/relink.log OpenBSD 6.1-current (GENERIC.MP) #8: Tue Jul 18

Fix for clang-provoked relocation errors

The diff below fixes the /usr/bin/ld: /tmp/BC-10602a.o: relocation R_X86_64_PC32 against `xxx' can not be used when making a shared object; recompile with -fPIC errors that we see with some ports when compiled with clang. It is essentially a diff that was carried for a while in upstream

Better ddb support for inteldrm(4)

Because of the locking changes in the inteldrm(4) update, the code that swicthes to the console framebuffer is pretty much broken. The diff below fixes the issue inteldrm(4) by introducing a new enter_ddb() "accessop" for wsdisplay(4). The implementation of this function should bypass as much of

Re: Remove accents from fortunes

> Even though our default xterm(1) configuration is robust enough > that it usually doesn't break anything, I'm not convinced > indiscriminately printing UTF-8 is a good idea. The first part of that sentence contains way too much optimism. xterm and robust probably do not belong in the same

Re: Move {install,upgrade}.site script to the end of installs/upgrades (again)

This will resolve a few subtle issues with syspatch and kernel relinking, among other things. BTW, I would like to take a moment to discourage people from selecting a different kernel image in /etc/boot.conf with the image command. Such a pattern is going to cause increasing problems in the

Move {install,upgrade}.site script to the end of installs/upgrades (again)

Originally, the installer executed the {install,upgrade}.site script at the end of installs and upgrades. Over time, code was after this step and now a list of things happen AFTER this script is executed. - make underlying device nodes for softraid devices - install the boot-block on disk -

Re: [patch] enable calling chroot(2) after calling pledge(2)

> > I would like to be able to call chroot(2) in a program that uses pledge(2). > > You need to postpone the pledge(2) calls until after chroot(2). correct. > Look at any of the pledged privsep daemons to see how this was dealt with in > base. Also check the logs to see the refactorings that

Re: introduction of an additional non-POSIX function in libpthread

David CARLIER wrote: > Hi. > > I sent a diff originally to a smaller audience but finally decided to post > it in the mailing list. > So it is to introduce the pthread_set_name_np's counterpart so > pthread_get_name_np. > Some softwares use it (NSPR for example) and anyway internally in my >

Re: Remove getopt from vipw

> As far as I can tell the only thing gained from using getopt is handling > vipw -- > as vipw takes no flags or arguments, is not intended for non-interactive > use, and is not POSIX, I don't see a reason -- should be handled. If > anyone prefers proper handling of -- perhaps > if (!(

Re: Reduce NET_LOCK() contention part 2

> Date: Tue, 18 Jul 2017 16:08:04 +0200 > From: Martin Pieuchot > > As long as most of the Network Stack run under the NET_LOCK() we want to > avoid grabbing the lock from different contexts. Because when multiple > threads are waiting for the lock, all of them are awaken upon

Reduce NET_LOCK() contention part 2

As long as most of the Network Stack run under the NET_LOCK() we want to avoid grabbing the lock from different contexts. Because when multiple threads are waiting for the lock, all of them are awaken upon rw_exit(). This not only lead to wasted cycles, it also create a userland starvation since

Re: introduction of an additional non-POSIX function in libpthread

Yes that s true NetBSD having a variadic like argument as well ... etc ... I did not have high expectations just wanted to propose ... :-) On 18 July 2017 at 14:55, Landry Breuil wrote: > On Tue, Jul 18, 2017 at 01:43:42PM +0100, David CARLIER wrote: > > Ah I recognise you

Re: introduction of an additional non-POSIX function in libpthread

On Tue, Jul 18, 2017 at 01:43:42PM +0100, David CARLIER wrote: > Ah I recognise you you re Mozilla contributor right ? You re probably right > but that was just an example eventhough I admit it s not extremely widely > used ... Note that you'll have to be careful in your arguments for this

Reducing NET_LOCK() contention

When forwarding a lot of traffic with 10G interfaces contention on the NET_LOCK() is "visible". Each time you type "ifconfig" you can go grab a coffee... The problem has a name: pf_purge_thread(). This thread is created by default and run even if you don't have PF enabled. Every `hz' it wakes

Re: connect(2), KERNEL_LOCK() vs socket lock

On Tue, Jul 18, 2017 at 09:03:00AM +0200, Martin Pieuchot wrote: > Diff below extends the scope of the socket lock. It has been previously > introduced in sys_connect(), first as NET_LOCK() then renamed, where old > splsofnet() were used. But we now need to "move the line up" in order to >

Re: [PATCH] ure improvement

On 2017/07/18 09:12, Martin Pieuchot wrote: > On 17/07/17(Mon) 15:24, sc dying wrote: >> On 2017/07/17 08:24, Martin Pieuchot wrote: >>> On 15/07/17(Sat) 21:16, sc dying wrote: - Call usbd_set_config before configuring endpoints in ure_init to fix an error when re-opening pipes. I

Re: filt_soread() & socket lock

On Tue, Jul 18, 2017 at 08:25:38AM +0200, Martin Pieuchot wrote: > The socket checks in filt_soread() should be atomic. As found in the > past week it is not possible to call solock() there because we're not > allowed to sleep. However I'd like to prepare the function for future > locking in

Re: Extend the scope of socket lock in soo_stat()

On Tue, Jul 18, 2017 at 08:42:51AM +0200, Martin Pieuchot wrote: > `so_state' and `so_rcv' need to be checked atomically, so extend the > scope of the lock. > > ok? OK claudio@ > Index: kern/sys_socket.c > === > RCS file:

Re: introduction of an additional non-POSIX function in libpthread

Oups mistake of mine. good catch On 18 July 2017 at 14:08, Karel Gardas wrote: > Why your patch defines MALLOC_STATS? > > -/* #define MALLOC_STATS */ > +#define MALLOC_STATS > > On Tue, Jul 18, 2017 at 2:43 PM, David CARLIER wrote: > > Ah I recognise you

Re: introduction of an additional non-POSIX function in libpthread

Why your patch defines MALLOC_STATS? -/* #define MALLOC_STATS */ +#define MALLOC_STATS On Tue, Jul 18, 2017 at 2:43 PM, David CARLIER wrote: > Ah I recognise you you re Mozilla contributor right ? You re probably right > but that was just an example eventhough I admit it s

Re: introduction of an additional non-POSIX function in libpthread

Ah I recognise you you re Mozilla contributor right ? You re probably right but that was just an example eventhough I admit it s not extremely widely used ... On 18 July 2017 at 13:36, Landry Breuil wrote: > On Tue, Jul 18, 2017 at 01:24:21PM +0100, David CARLIER wrote: > >

Re: intel.4: Typofix

On Mon, Jul 17, 2017 at 10:38:22PM -0400, Bryan Steele wrote: > This is an upstream Xorg manual. > > https://lists.x.org/mailman/listinfo/xorg-devel Reported upstream, thanks.

Re: introduction of an additional non-POSIX function in libpthread

On Tue, Jul 18, 2017 at 01:24:21PM +0100, David CARLIER wrote: > Hi. > > I sent a diff originally to a smaller audience but finally decided to post > it in the mailing list. > So it is to introduce the pthread_set_name_np's counterpart so > pthread_get_name_np. > Some softwares use it (NSPR for

Re: SIGBUS short mmap object

> From: Theo de Raadt > Date: Mon, 17 Jul 2017 16:06:05 -0600 (MDT) > > Sorry I disagree. SIGSEGV is the right answer. It was not mapped. > That is segmentation. Actually it is mapped in the sense that uvm has created mapping entries for it. The mapping just isn't backed

introduction of an additional non-POSIX function in libpthread

Hi. I sent a diff originally to a smaller audience but finally decided to post it in the mailing list. So it is to introduce the pthread_set_name_np's counterpart so pthread_get_name_np. Some softwares use it (NSPR for example) and anyway internally in my workplace we have multiplatform needing

Re: Extend the scope of socket lock in soo_stat()

On Tue, Jul 18, 2017 at 08:42:51AM +0200, Martin Pieuchot wrote: > `so_state' and `so_rcv' need to be checked atomically, so extend the > scope of the lock. > > ok? OK bluhm@ > > Index: kern/sys_socket.c > === > RCS file:

Re: soo_ioctl() & socket lock

On Tue, Jul 18, 2017 at 08:38:56AM +0200, Martin Pieuchot wrote: > Where soo_ioctl() modifies `so_state', `so_rcv' or `so_snd' it needs the > socket lock. > > More fields might need the lock in the future but for the moment I'm > concentrating on fields accessed in the TCP input path. > > ok?

Re: urndis issues

On Thu, Jul 13, 2017 at 14:04 +0200, Mike Belopuhov wrote: > On Wed, Jul 12, 2017 at 21:04 +, Jonathan Armani wrote: > > Hi, > > > > Thanks I was cooking the same diff. > > > > Ok armani@ > > > > Hi, thanks! I want to get rid of printfs though and > return errors (or unhandled status

Re: filt_soread() & socket lock

On Tue, Jul 18, 2017 at 08:25:38AM +0200, Martin Pieuchot wrote: > #ifdef SOCKET_SPLICE > if (isspliced(so)) > - return (0); > + rv = 0; > + else > #endif /* SOCKET_SPLICE */ You could use braces "if {...} else" here to be consistent with the other if else.

Re: SIGBUS short mmap object

On Mon, Jul 17, 2017 at 04:06:05PM -0600, Theo de Raadt wrote: > Finally, the diff here only touches 2 architectures. Yes, I know. But why work on the others if the change is not accepted anyway. > Where is this coming from? Is it just to satisfy a regress test? My concern is only the regress

Re: [PATCH] ure improvement

On 17/07/17(Mon) 15:24, sc dying wrote: > On 2017/07/17 08:24, Martin Pieuchot wrote: > > On 15/07/17(Sat) 21:16, sc dying wrote: > >> This patch does: > >> > >> - Enable RX aggregation. > > > > Does it work on all chips? > > I don't have all, but it works with mine that have RTL8152 (ver 4c10) >

Re: [patch] enable calling chroot(2) after calling pledge(2)

On Tue, Jul 18, 2017 at 02:44:12AM +, Matt Miller wrote: > I would like to be able to call chroot(2) in a program that uses pledge(2). You need to postpone the pledge(2) calls until after chroot(2). Look at any of the pledged privsep daemons to see how this was dealt with in base. Also check

connect(2), KERNEL_LOCK() vs socket lock

sys_connect() currently relies on the KERNEL_LOCK() to be sure `so_state' isn't changing while it manipulates the socket. Since we want to remove the KERNEL_LOCK() from the Network Stack, we need a way to guaranty this atomicity. Diff below extends the scope of the socket lock. It has been

Extend the scope of socket lock in soo_stat()

`so_state' and `so_rcv' need to be checked atomically, so extend the scope of the lock. ok? Index: kern/sys_socket.c === RCS file: /cvs/src/sys/kern/sys_socket.c,v retrieving revision 1.30 diff -u -p -r1.30 sys_socket.c ---

soo_ioctl() & socket lock

Where soo_ioctl() modifies `so_state', `so_rcv' or `so_snd' it needs the socket lock. More fields might need the lock in the future but for the moment I'm concentrating on fields accessed in the TCP input path. ok? Index: kern/sys_socket.c

filt_soread() & socket lock

The socket checks in filt_soread() should be atomic. As found in the past week it is not possible to call solock() there because we're not allowed to sleep. However I'd like to prepare the function for future locking in order to keep the locking diff minimal. ok? Index: kern/uipc_socket.c