Re: ldapd(8) assertion fails on amd64 Dell PowerEdge R710

Stuart Henderson writes: > On 2017/05/26 14:22, Todd C. Miller wrote: >> On Fri, 26 May 2017 14:17:50 -0600, "Theo de Raadt" wrote: >> >> > > diff -u -p -r1.37 btree.c >> > > --- btree.c 2 Dec 2016 05:52:01 - 1.37 >> > > +++ btree.c 26 May 2017 20:11:26

Re: pppoe(4) vs splnet

Hello, > I hope my question does not sound dumb... > > The function pppoe_timeout() grabs NET_LOCK() at line 1059 and then > it goes after splnet() at line 1076, is that intentional? > if so why? do I missing something? I guess the question was dump. your patch deals with NET_LOCK()

Re: ldapd(8) assertion fails on amd64 Dell PowerEdge R710

On 2017/05/26 14:22, Todd C. Miller wrote: > On Fri, 26 May 2017 14:17:50 -0600, "Theo de Raadt" wrote: > > > > diff -u -p -r1.37 btree.c > > > --- btree.c 2 Dec 2016 05:52:01 - 1.37 > > > +++ btree.c 26 May 2017 20:11:26 - > > > @@ -55,6 +55,7 @@ > > > #define

Re: mg backup directory

On 26/05/17 12:38, Florian Obser wrote: On Fri, May 19, 2017 at 02:11:22PM -0300, Lucas Gabriel Vuotto wrote: Previous patch shall be ignored, as it was an ugly hack. Below is a patch that is simpler and fixes expandtilde instead, so it fixes the problem in other situations (writing files to

Re: pppoe(4) vs splnet

Hello, I hope my question does not sound dumb... The function pppoe_timeout() grabs NET_LOCK() at line 1059 and then it goes after splnet() at line 1076, is that intentional? if so why? do I missing something? 1059 NET_LOCK(s);

Re: [bgpd] RFC 7607 Codification of AS 0 Processing

On Fri, May 26, 2017 at 10:15:37PM +0200, Sebastian Benoit wrote: > Peter Hessler(phess...@openbsd.org) on 2017.05.26 21:40:49 +0200: > > On 2017 May 26 (Fri) at 20:01:00 +0200 (+0200), Peter Hessler wrote: > > :Apropos of "I found it", I implemented support for RFC 7607. It's a > > :super short

Re: ldapd(8) assertion fails on amd64 Dell PowerEdge R710

On 2017/05/26 14:22, Todd C. Miller wrote: > On Fri, 26 May 2017 14:17:50 -0600, "Theo de Raadt" wrote: > > > > diff -u -p -r1.37 btree.c > > > --- btree.c 2 Dec 2016 05:52:01 - 1.37 > > > +++ btree.c 26 May 2017 20:11:26 - > > > @@ -55,6 +55,7 @@ > > > #define

Re: ldapd(8) assertion fails on amd64 Dell PowerEdge R710

> > > diff -u -p -r1.37 btree.c > > > --- btree.c 2 Dec 2016 05:52:01 - 1.37 > > > +++ btree.c 26 May 2017 20:11:26 - > > > @@ -55,6 +55,7 @@ > > > #define P_INVALID 0x > > > > > > #define F_ISSET(w, f) (((w) & (f)) == (f)) > > > +#define min(a,b)

Re: refactor m_makespace() to use MCLGETI

On Fri, May 26, 2017 at 05:38:07PM +0200, Claudio Jeker wrote: > m_makespace() is using an old way to build up the mbuf chain. By using > MCLGETI() a lot of the code can be simplified and results at least in my > opinion in better readable code. In some cases this may reduce the number Yes, the

Re: [bgpd] RFC 7607 Codification of AS 0 Processing

On 2017 May 26 (Fri) at 22:15:37 +0200 (+0200), Sebastian Benoit wrote: :diff is ok, but please consider this: : :i think we should limit the list to the features we support so :that users can check if a certain something should work or not. : :this is not a feature, this is a protocol

Re: ldapd(8) assertion fails on amd64 Dell PowerEdge R710

On Fri, 26 May 2017 14:17:50 -0600, "Theo de Raadt" wrote: > > diff -u -p -r1.37 btree.c > > --- btree.c 2 Dec 2016 05:52:01 - 1.37 > > +++ btree.c 26 May 2017 20:11:26 - > > @@ -55,6 +55,7 @@ > > #define P_INVALID 0x > > > > #define F_ISSET(w, f) (((w) & (f)) ==

Re: ldapd(8) assertion fails on amd64 Dell PowerEdge R710

> Index: btree.c > === > RCS file: /cvs/src/usr.sbin/ldapd/btree.c,v > retrieving revision 1.37 > diff -u -p -r1.37 btree.c > --- btree.c 2 Dec 2016 05:52:01 - 1.37 > +++ btree.c 26 May 2017 20:11:26 - > @@ -55,6

Re: ldapd(8) assertion fails on amd64 Dell PowerEdge R710

On Fri, 26 May 2017 21:13:05 +0100, Stuart Henderson wrote: > It's part of the on-disk format, so changing it to a 32-bit value > breaks it for existing users. Following an idea from deraadt@: OK millert@ - todd

Re: [bgpd] RFC 7607 Codification of AS 0 Processing

Peter Hessler(phess...@openbsd.org) on 2017.05.26 21:40:49 +0200: > On 2017 May 26 (Fri) at 20:01:00 +0200 (+0200), Peter Hessler wrote: > :Apropos of "I found it", I implemented support for RFC 7607. It's a > :super short RFC, but basically it forbids use of AS 0 anywhere. > : > :OK? > : > : >

Re: ldapd(8) assertion fails on amd64 Dell PowerEdge R710

On 2017/05/26 11:42, Allan Streib wrote: > "Todd C. Miller" writes: > > > I can explain that. The page size is being set based on the file > > system block size. > > Yes, I just discovered exactly this. > > I was looking at the btree.c code and saw: > > if

Re: Shrink and give example for sets question

> Vadim Zhukov wrote: > > Let's make it more informative and smaller size at the same time? > > I think the example should be games instead of encouraging people to install > without X, which only causes trouble later. '-g*' is fine, version free and > still shows wildcards. Please use the

Re: Shrink and give example for sets question

Vadim Zhukov wrote: > Let's make it more informative and smaller size at the same time? I think the example should be games instead of encouraging people to install without X, which only causes trouble later. '-g*' is fine, version free and still shows wildcards. > > Index: install.sub >

Re: pfsync(4) vs splnet()

On Fri, May 26, 2017 at 04:10:25PM +0200, Martin Pieuchot wrote: > pfsyncioctl already runs under the NET_LOCK() and pfsync(4) doesn't > touch any hardware so these splnet() are useless. > > ok? looks good to me. OK sashan@

Re: [bgpd] RFC 7607 Codification of AS 0 Processing

On 2017 May 26 (Fri) at 20:01:00 +0200 (+0200), Peter Hessler wrote: :Apropos of "I found it", I implemented support for RFC 7607. It's a :super short RFC, but basically it forbids use of AS 0 anywhere. : :OK? : : Fixed some denglish in an error message, mention the RFC in the man page, and

Throttle bgpd's RDE if the client is slow

Both bgpctl and bgp neighbors are often not fast enough to keep up with the RDE. The result is quite a bit of memory bloat or some ugly workarounds for bgpctl which can result in starving other bgpctl calls to death. This implements a simple XON / XOFF protocol for peers and control sessions and

Re: [bgpd] RFC 7607 Codification of AS 0 Processing

On Fri, May 26, 2017 at 07:24:06PM BST, Claudio Jeker wrote: > On Fri, May 26, 2017 at 08:01:00PM +0200, Peter Hessler wrote: > > Apropos of "I found it", I implemented support for RFC 7607. It's a > > super short RFC, but basically it forbids use of AS 0 anywhere. > > > > OK? > > > > > >

Re: tun/tap vs splnet()

On Fri, 26 May 2017 18:05:30 +0200 Martin Pieuchot wrote: > On 26/05/17(Fri) 17:43, Alexander Bluhm wrote: >> > @@ -569,8 +554,6 @@ tun_output(struct ifnet *ifp, struct mbu >> >af = mtod(m0, u_int32_t *); >> >*af = htonl(dst->sa_family); >> > >> > - s = splnet(); >> >

Re: [bgpd] RFC 7607 Codification of AS 0 Processing

On Fri, May 26, 2017 at 08:01:00PM +0200, Peter Hessler wrote: > Apropos of "I found it", I implemented support for RFC 7607. It's a > super short RFC, but basically it forbids use of AS 0 anywhere. > > OK? > hi. you probably want to add the rfc to the list in STANDARDS too, after 7606. jmc

Re: [bgpd] RFC 7607 Codification of AS 0 Processing

On Fri, May 26, 2017 at 08:01:00PM +0200, Peter Hessler wrote: > Apropos of "I found it", I implemented support for RFC 7607. It's a > super short RFC, but basically it forbids use of AS 0 anywhere. > > OK? > > > Index: parse.y >

[bgpd] RFC 7607 Codification of AS 0 Processing

Apropos of "I found it", I implemented support for RFC 7607. It's a super short RFC, but basically it forbids use of AS 0 anywhere. OK? Index: parse.y === RCS file: /cvs/openbsd/src/usr.sbin/bgpd/parse.y,v retrieving revision

Re: sync identd et al style loggers severity to log.c

On Fri, May 26, 2017 at 04:22:11PM +, Florian Obser wrote: > Sync the severity of the syslog_* functions shared between identd, > slowcgi, tftp-proxy and tftpd to the severity used in log.c style > loggers. > This also fixes an issue where syslog_err and syslog_errx logged with > different

Re: tun/tap vs splnet()

On Fri, May 26, 2017 at 06:05:30PM +0200, Martin Pieuchot wrote: > Thanks for your review, it was a bad diff. Updated version below. OK bluhm@ > > Index: net/if_tun.c > === > RCS file: /cvs/src/sys/net/if_tun.c,v > retrieving

Re: Suspend/Resume for nvme

On Fri, May 26, 2017 at 01:54:26PM +0200, Stefan Fritsch wrote: > Hi, > > the following diff adds the missing bits to make suspend/resuem work with > nvme. It was done by ehrhardt@ and tested against nvme.c 1.50, but seems > to apply cleanly. > > Unfortunately, I don't have any nvme hardware

Re: wsconsctl.8: mention the display.font variable in EXAMPLES

On Fri, May 26, 2017 at 06:05:55PM +0200, Frederic Cambus wrote: > Hi tech@, > > As mentioned by miod@ here [1], wsconsctl(8) has a currently > undocumented 'display.font' variable allowing to change the > current font on framebuffer consoles. > > [1]

sync identd et al style loggers severity to log.c

Sync the severity of the syslog_* functions shared between identd, slowcgi, tftp-proxy and tftpd to the severity used in log.c style loggers. This also fixes an issue where syslog_err and syslog_errx logged with different severities. OK? diff --git identd/identd.c identd/identd.c index

dhclient: request interface-mtu by default?

Hi, does anyone know a specific reason why we should not request interface-mtu by default? It may be set by the DHCP server enable jumbo frames or to work around PMTU discovery breakage. Cheers, Stefan --- a/sbin/dhclient/clparse.c +++ b/sbin/dhclient/clparse.c @@ -118,6 +118,8 @@

wsconsctl.8: mention the display.font variable in EXAMPLES

Hi tech@, As mentioned by miod@ here [1], wsconsctl(8) has a currently undocumented 'display.font' variable allowing to change the current font on framebuffer consoles. [1] http://undeadly.org/cgi?action=article=20131023125815 Comments? OK? Index: sbin/wsconsctl/wsconsctl.8

Re: tun/tap vs splnet()

On 26/05/17(Fri) 17:43, Alexander Bluhm wrote: > On Fri, May 26, 2017 at 04:06:43PM +0200, Martin Pieuchot wrote: > > @@ -362,7 +355,6 @@ int > > tun_dev_open(struct tun_softc *tp, int flag, int mode, struct proc *p) > > { > > struct ifnet *ifp; > > - int s; > > > > if (tp->tun_flags

Shrink and give example for sets question

Let's make it more informative and smaller size at the same time? Index: install.sub === RCS file: /cvs/src/distrib/miniroot/install.sub,v retrieving revision 1.958 diff -u -p -r1.958 install.sub --- install.sub 24 Jan 2017 10:14:14

Re: tun/tap vs splnet()

On Fri, May 26, 2017 at 04:06:43PM +0200, Martin Pieuchot wrote: > @@ -362,7 +355,6 @@ int > tun_dev_open(struct tun_softc *tp, int flag, int mode, struct proc *p) > { > struct ifnet *ifp; > - int s; > > if (tp->tun_flags & TUN_OPEN) > return (EBUSY); I wonder

Re: mg backup directory

On Fri, May 19, 2017 at 02:11:22PM -0300, Lucas Gabriel Vuotto wrote: > Previous patch shall be ignored, as it was an ugly hack. Below is a patch > that is simpler and fixes expandtilde instead, so it fixes the problem in > other situations (writing files to ~, for example). The only thing that

refactor m_makespace() to use MCLGETI

m_makespace() is using an old way to build up the mbuf chain. By using MCLGETI() a lot of the code can be simplified and results at least in my opinion in better readable code. In some cases this may reduce the number of MGET and MCLGET calls so it may be a bit quicker... OK? -- :wq Claudio

simplify pfkeyv2 attachement

There is only v2 of the pfkey protocol and this will not change anytime soon. So simplify the code that currently does some dirty tricks to allow multiple pfkey protocols. Remove the magic and hardcode the code directly use the v2 version. This removes the code where the protosw struct is

enc(4) vs splnet

The global array of interfaces is accessed in the input path and need the NET_LOCK(). Ok? Index: net/if_enc.c === RCS file: /cvs/src/sys/net/if_enc.c,v retrieving revision 1.67 diff -u -p -r1.67 if_enc.c --- net/if_enc.c23

Re: git patches

On Fri, 26 May 2017 06:55:34 -0400, "Ted Unangst" wrote: > what if we special case these special diffs? they are easily detectable, and > patch can fix them on the fly. of course, only do this when no -p option is > used to preserve patch's smarts about auto detecting directories. Seems

Re: dig(1) doesn't play well with rebound(8)

On Fri, 26 May 2017 08:08:08 -0400, "Ted Unangst" wrote: > Edgar Pettijohn wrote: > > This may not be the best way to handle this, but it was the first fix to > > come to mind. Not sure where to put this in the manual or if its even > > worth documenting. Thoughts? > > I think this is a

trunk(4) vs splnet

The global list of softc is *not* accessed in the input path, so it doesn't need splnet(). ioctl(2) handlers are already executed with the NET_LOCK() held, so splnet() is superfluous. ok? Index: net/if_trunk.c === RCS file:

ppp vs splnet()

The global list of softc is used in the input path and need to be protected by the NET_LOCK(). ok? Index: net/if_ppp.c === RCS file: /cvs/src/sys/net/if_ppp.c,v retrieving revision 1.106 diff -u -p -r1.106 if_ppp.c --- net/if_ppp.c

pfsync(4) vs splnet()

pfsyncioctl already runs under the NET_LOCK() and pfsync(4) doesn't touch any hardware so these splnet() are useless. ok? Index: net/if_pfsync.c === RCS file: /cvs/src/sys/net/if_pfsync.c,v retrieving revision 1.251 diff -u -p

pppoe(4) vs splnet

pppoe_softc_list is accessed in the input path, so it needs to be protected by the NET_LOCK(). While here if_down() and if_up() don't need splnet() the need the NET_LOCK() which the ioctl(2) path already provides. ok? Index: net/if_pppoe.c

tun/tap vs splnet()

tun(4) and tap(4) are pseudo-drivers, they don't need splnet(). The global lists of interfaces are only used inside the driver in code path protected by the KERNEL_LOCK(). ok? Index: net/if_tun.c === RCS file:

Re: dig(1) doesn't play well with rebound(8)

Sounds good to me. Just started using rebound and thought it would be good to use dig to prepopulate the cache. Also noticed host(1) has the same problem but was waiting for a response to dig first. Edgar ⁣Sent from BlueMail ​ On May 26, 2017, 7:34 AM, at 7:34 AM, Ted Unangst

Re: git patches

On Fri, May 26, 2017 at 02:07:00PM +0100, Stuart Henderson wrote: > On 2017/05/26 14:26, Paul Irofti wrote: > > On Fri, May 26, 2017 at 06:55:34AM -0400, Ted Unangst wrote: > > > let's say, hypothetically, you're working with a blasphemer who mails you > > > a > > > git diff which looks a little

Test wanted: IPv4 forwarding w/o KERNEL_LOCK()

This diff get rids of the ipintrq for forwarding. The queue is now used for packets delivered locally which still need the KERNEL_LOCK(). Since ipv4_input()/ip_forward() no longer need the KERNEL_LOCK() they are called directly from the 'unlocked' task. That's why the task is now grabbing the

[PATCH] netcat throttling

Hi, The following patch for netcat, adds the capability to limit the data transfer bandwidth with the flag '-B'. For instance, the following command limits ssh traffic to 40KB/s: ssh -oProxyCommand='./nc -B 40 %h %p' localhost cat /bsd >/dev/null ? nc Index: nc.1

Re: git patches

On Fri, May 26, 2017 at 06:55:34AM -0400, Ted Unangst wrote: > what if we special case these special diffs? they are easily detectable, and > patch can fix them on the fly. of course, only do this when no -p option is > used to preserve patch's smarts about auto detecting directories. Fine with

Re: git patches

Paul Irofti(p...@irofti.net) on 2017.05.26 14:26:46 +0300: > On Fri, May 26, 2017 at 06:55:34AM -0400, Ted Unangst wrote: > > let's say, hypothetically, you're working with a blasphemer who mails you a > > git diff which looks a little like this: > > > > diff --git a/d2/bar.c b/d2/bar.c > > index

Re: dig(1) doesn't play well with rebound(8)

Edgar Pettijohn wrote: > This may not be the best way to handle this, but it was the first fix to > come to mind. Not sure where to put this in the manual or if its even > worth documenting. Thoughts? I think this is a better fix. the user shouldn't worry about such things. at least until a

Suspend/Resume for nvme

Hi, the following diff adds the missing bits to make suspend/resuem work with nvme. It was done by ehrhardt@ and tested against nvme.c 1.50, but seems to apply cleanly. Unfortunately, I don't have any nvme hardware at the moment in order to test it. Is there anyone who could test it? Cheers,

Re: [patch] mg: fix overflow on vteeol()

On Fri, May 12, 2017 at 12:01:52PM +0200, Hiltjo Posthuma wrote: > On Sun, May 07, 2017 at 05:31:26PM +0200, Hiltjo Posthuma wrote: > > Hey, > > > > mg crashes with certain (unicode) characters and moving the cursor to the > > end of the line. > > > > The characters are printed to the screen as

Re: git patches

On Fri, May 26, 2017 at 02:26:46PM +0300, Paul Irofti wrote: > On Fri, May 26, 2017 at 06:55:34AM -0400, Ted Unangst wrote: > > let's say, hypothetically, you're working with a blasphemer who mails you a > > git diff which looks a little like this: > > > > diff --git a/d2/bar.c b/d2/bar.c > >

Re: git patches

On Fri, May 26, 2017 at 06:55:34AM -0400, Ted Unangst wrote: > let's say, hypothetically, you're working with a blasphemer who mails you a > git diff which looks a little like this: > > diff --git a/d2/bar.c b/d2/bar.c > index 496ef02..51a910f 100644 > --- a/d2/bar.c > +++ b/d2/bar.c This is a

git patches

let's say, hypothetically, you're working with a blasphemer who mails you a git diff which looks a little like this: diff --git a/d2/bar.c b/d2/bar.c index 496ef02..51a910f 100644 --- a/d2/bar.c +++ b/d2/bar.c the problem is obvious, no? there's these janky a/ and b/ marring the file names. if

Re: OpenBGPd: expand rib list (updated for r1.295)

Also looks good to me, OK On 2017 Jan 20 (Fri) at 21:19:22 +0100 (+0100), Denis Fondras wrote: :Hello, : :Here is a patch to expand RIB names in rules. When playing with multi-RIBs, it :allows to simplify ruleset. : : Ex : :# cat /etc/bgpd.conf :[...] :peer_ribs = "{ m1, m2, m3 }" :deny rib m2

Re: [patch/openbgpd] make man example works

looks good to me, OK On 2017 May 21 (Sun) at 19:36:36 +0200 (+0200), Denis Fondras wrote: :Hi, : :bgpd.conf manual has an example with : : :good="{ 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }" :bad="{ 224.0.0.0/4 prefixlen >= 4, 240.0.0.0/4 prefixlen >= 4 }" :ugly="{ 127.0.0.1/8, 169.254.0.0/16

[patch] acpithinkpad(4) unknown event 0x6005

Hello, when I press 'Fn' key on on thinkpad e530 I see aforesaid message on console log. Can someone review inlined patch? Index: dev/acpi/acpithinkpad.c === RCS file: /home/misha/work/cvs/src/sys/dev/acpi/acpithinkpad.c,v