Re: execve -1 errno 12 Cannot allocate memory
Otto Moerbeek wrote: > On Mon, Feb 01, 2021 at 10:24:31PM -0500, Philippe Meunier wrote: > > > Anyone? > > Fixing a particluar issue is fine, but more important is an assessment > it does not break other things. In particular, does this limit the VM > for data available to any program (which is already quite limited on > i386)? Good of you to point that out of otto. I am concerned about the impact this might have on binaries and shared libraries fitting, because of the i386 line-in-the-sand code and data seperation model for pre-NX W^X, binaries and libraries are intended to fit into 512MB seperation, and if they cannot, then the X line ends up being very high. Of course we all have NX systems now, so that should not matter, but we should still see if the layout actually works. We never investigated these edge conditions.
Re: execve -1 errno 12 Cannot allocate memory
On Mon, Feb 01, 2021 at 10:24:31PM -0500, Philippe Meunier wrote: > Anyone? Fixing a particluar issue is fine, but more important is an assessment it does not break other things. In particular, does this limit the VM for data available to any program (which is already quite limited on i386)? -Otto > > Philippe > > > Philippe Meunier wrote: > >Jonathan Gray wrote: > >>MAXTSIZ is 128 MB on i386 > >>see sys/arch/i386/include/vmparam.h > > > >Mark Kettenis wrote: > >>sys/arch/i386/include/vmparam.h has: > >>#define MAXTSIZ (128*1024*1024) /* max text size */ > > > >Thanks to both of you for the pointer! > > > >So what about the patch below? I've checked with a new kernel that it > >fixes the problem with chrome (even when using the default limits in > >/etc/login.conf). > > > >Philippe > > > > > >Index: sys/arch/i386/include/vmparam.h > >=== > >RCS file: /cvs/src/sys/arch/i386/include/vmparam.h,v > >retrieving revision 1.56 > >diff -u -r1.56 vmparam.h > >--- sys/arch/i386/include/vmparam.h 17 Apr 2018 15:50:05 - 1.56 > >+++ sys/arch/i386/include/vmparam.h 31 Jan 2021 09:41:00 - > >@@ -46,7 +46,7 @@ > > /* > > * Virtual memory related constants, all in bytes > > */ > >-#define MAXTSIZ (128*1024*1024) /* max text size */ > >+#define MAXTSIZ (256*1024*1024) /* max text size */ > > #ifndef DFLDSIZ > > #define DFLDSIZ (64*1024*1024) /* initial data size > > limit */ > > #endif > > > > >
Re: pf route-to: only run pf_test when packets enter and leave the stack
On Tue, Feb 02, 2021 at 02:52:52PM +1000, David Gwynne wrote:
> this is part of a high level discussion about when pf runs against a
> packet. the options are:
>
> 1. pf runs when a packet goes over an interface
> or
> 2. pf runs when a packet enters or leaves the network stack.
>
> for normal packet handling there isn't a difference between these
> options. in the routing case a packet comes in on an interface, pf tests
> it, then the stack processes it and decides to send it out another
> interface, pf tests it again on the way out, the packet goes on the
> wire. for packets handled by the local system, a packet comes in on an
> interface, pf tests it, the stack processes it locally, something
> generates a reply, the stack decides to route that out an interface, pf
> tests it on the way out, the reply packet ends up on the wire.
>
> in both situations, you get the same sequence of events if you think
> that pf runs when a packet goes over an interface or wether pf runs when
> a packet enters or leaves the stack.
>
> however, there is a difference if route-to gets involved. if route-to is
> applied on an outbound rule/state, it could change which interface the
> packet should be going over.
>
> currently the code implements option 1. this means that if route-to
> changes the interface, it reruns pf test for the packet going over the
> new interface. i would like to change it to option 2.
>
> the main reason i want to change it is that option 1 creates confusion
> for the state table. by default, pf states are floating, meaning that
> packets are matched to states regardless of which interface they're
> going over. if a packet leaving on em0 is rerouted out em1, both
> traversals will end up using the same state, which at best will make the
> accounting look weird, or at worst fail some checks in the state and get
> dropped.
>
> another reason i want to change this is to make it consistent with
> other changes that are made to packet. eg, when nat is applied to
> a packet, we don't run pf_test again with the new addresses.
>
> the downside to this change is that the pf_test rerun may have been used
> to do things like push a packet out another interface with the first run
> through pf, and pick up a broad "nat all packets leaving this interface"
> rule on the second one.
>
> however, like most things relating to route-to/reply-to/dup-to, im
> pretty sure at this point it's not used a lot, so the impact is minimal.
> a lot of changes in this space have already been made, so adding another
> simplification is justifiable. if this does remove functionality that
> people need, i believe sashan@ has agreed to help me implement route-to
> on match rules to give more flexibility and composability of rules.
>
> i've canvassed a few people, and their responses have varied from "i
> don't care, route-to is the worst" to "i thought we did option 2
> anyway". anyone else want to chime in?
>
> this keeps the behaviour where route-to on a packet coming into the
> stack is pushed past it and immediately forwarded to the output
> interface. the condition for that is greatly simplified now though.
>
> ok?
For me pf(4) should behave like 2. That was the initial design (pf_test in
ip_input and in ip_output) and with this a forwarded packet is tested when
received and when sent. route-to, reply-to, dup-to where added later and
the change of behaviour using these special shortcuts was never fully
considered. (I'm not even sure if you could use route-to on out rules in
old versions of pf). The state matching was built on the behaviour in 2
and retesting the same packet again results in a lot of state confusion.
The result is erratic behaviour and this is why I think that you're right
and route-to, reply-to should avoid rerunning pf_test() for the same
direction.
So in my opinion this diff is OK.
> Index: pf.c
> ===
> RCS file: /cvs/src/sys/net/pf.c,v
> retrieving revision 1.1106
> diff -u -p -r1.1106 pf.c
> --- pf.c 1 Feb 2021 00:31:05 - 1.1106
> +++ pf.c 2 Feb 2021 03:44:51 -
> @@ -6033,7 +6033,7 @@ pf_route(struct pf_pdesc *pd, struct pf_
> (ifp->if_flags & IFF_LOOPBACK) == 0)
> ip->ip_src = ifatoia(rt->rt_ifa)->ia_addr.sin_addr;
>
> - if (s->rt != PF_DUPTO && pd->kif->pfik_ifp != ifp) {
> + if (s->rt != PF_DUPTO && pd->dir == PF_IN) {
> if (pf_test(AF_INET, PF_OUT, ifp, ) != PF_PASS)
> goto bad;
> else if (m0 == NULL)
> @@ -6178,7 +6178,7 @@ pf_route6(struct pf_pdesc *pd, struct pf
> (ifp->if_flags & IFF_LOOPBACK) == 0)
> ip6->ip6_src = ifatoia6(rt->rt_ifa)->ia_addr.sin6_addr;
>
> - if (s->rt != PF_DUPTO && pd->kif->pfik_ifp != ifp) {
> + if (s->rt != PF_DUPTO && pd->dir == PF_IN) {
> if (pf_test(AF_INET6, PF_OUT, ifp, ) != PF_PASS)
> goto bad;
> else if
Re: ypxfr: ypxfr.8: small grammar fix
On Tue, Feb 02, 2021 at 06:29:17PM +1100, Eddie Youseph wrote: > Hi, > > A small grammar fix for ypxfr.8 > fixed, thanks. if you have any more small diffs like these, consider bundling them so we can fix them in a single pass. jmc > RCS file: /cvs/src/usr.sbin/ypserv/ypxfr/ypxfr.8,v > retrieving revision 1.22 > diff -u -p -u -p -r1.22 ypxfr.8 > --- usr.sbin/ypserv/ypxfr/ypxfr.8 21 Nov 2015 19:43:50 - 1.22 > +++ usr.sbin/ypserv/ypxfr/ypxfr.8 2 Feb 2021 07:26:18 - > @@ -45,7 +45,7 @@ > .Nm ypxfr > is the utility in YP that transfers maps to the local host. > .Pp > -Since the YP master transfers a map when it has changed, an YP slave should > +Since the YP master transfers a map when it has changed, a YP slave should > check for missed maps regularly. > This can be done via an entry in > .Xr crontab 5 . >
Re: tmux: tmux.1: small grammar fix
On Tue, Feb 02, 2021 at 06:19:40PM +1100, Eddie Youseph wrote: > Hi, > > A small grammar fix for the tmux manpage. > fixed, thanks. jmc > Index: usr.bin/tmux/tmux.1 > === > RCS file: /cvs/src/usr.bin/tmux/tmux.1,v > retrieving revision 1.814 > diff -u -p -u -p -r1.814 tmux.1 > --- usr.bin/tmux/tmux.1 29 Jan 2021 09:48:43 - 1.814 > +++ usr.bin/tmux/tmux.1 2 Feb 2021 06:51:15 - > @@ -1362,7 +1362,7 @@ a pane ID such as > .Ql %0 ; > .Ql %* > for all panes in the attached session; > -an window ID such as > +a window ID such as > .Ql @0 ; > or > .Ql @* >
Re: libmenu: menu_driver.3, menu_post.3: small grammar fixes
On Tue, Feb 02, 2021 at 06:16:33PM +1100, Eddie Youseph wrote: > Hi, > > Couple of grammar fixes for libmenu menu_driver.3 and menu_post.3 > curses too, so same applies as my libform comments. jmc > Index: lib/libmenu/menu_driver.3 > === > RCS file: /cvs/src/lib/libmenu/menu_driver.3,v > retrieving revision 1.7 > diff -u -p -u -p -r1.7 menu_driver.3 > --- lib/libmenu/menu_driver.3 12 Jan 2010 23:22:08 - 1.7 > +++ lib/libmenu/menu_driver.3 2 Feb 2021 06:51:08 - > @@ -52,7 +52,7 @@ Printable characters (which must be posi > checked according to the program's locale settings. > .TP 3 > - > -The input is the KEY_MOUSE special key associated with an mouse event. > +The input is the KEY_MOUSE special key associated with a mouse event. > .PP > The menu driver requests are as follows: > .TP 5 > Index: lib/libmenu/menu_post.3 > === > RCS file: /cvs/src/lib/libmenu/menu_post.3,v > retrieving revision 1.8 > diff -u -p -u -p -r1.8 menu_post.3 > --- lib/libmenu/menu_post.3 15 Nov 2015 22:10:16 - 1.8 > +++ lib/libmenu/menu_post.3 2 Feb 2021 06:51:08 - > @@ -44,7 +44,7 @@ int unpost_menu(MENU *menu); > .SH DESCRIPTION > The function \fBpost_menu\fR displays a menu to its associated subwindow. To > trigger physical display of the subwindow, use \fBrefresh\fR or some > equivalent > -\fBcurses\fR routine (the implicit \fBdoupdate\fR triggered by an > \fBcurses\fR > +\fBcurses\fR routine (the implicit \fBdoupdate\fR triggered by a \fBcurses\fR > input request will do). \fBpost_menu\fR resets the selection status > of all items. > .PP > The function \fBunpost_menu\fR erases menu from its associated subwindow. >
Re: libform: form_driver.3, form_fieldtype.3: Small grammar fixes
On Tue, Feb 02, 2021 at 06:14:01PM +1100, Eddie Youseph wrote: > Hi, > > Some grammar fixes for libform. > these ones come from curses. you should check whether their latest sources still need fixing and mail them direct. jmc > Index: lib/libform/form_driver.3 > === > RCS file: /cvs/src/lib/libform/form_driver.3,v > retrieving revision 1.8 > diff -u -p -u -p -r1.8 form_driver.3 > --- lib/libform/form_driver.3 12 Jan 2010 23:22:07 - 1.8 > +++ lib/libform/form_driver.3 2 Feb 2021 06:51:08 - > @@ -52,7 +52,7 @@ Printable characters (which must be posi > checked according to the program's locale settings. > .TP 3 > - > -The input is the KEY_MOUSE special key associated with an mouse event. > +The input is the KEY_MOUSE special key associated with a mouse event. > .PP > The form driver requests are as follows: > .TP 5 > @@ -263,7 +263,7 @@ a REQ_NEXT_PAGE is generated for a doubl > a REQ_LAST_FIELD is generated for a triple-click. > .RE > .PP > -If you click at an field inside the display area of the form: > +If you click at a field inside the display area of the form: > .RS > .TP 3 > - > @@ -274,7 +274,7 @@ If you double-click a field, > the form cursor is positioned to that field > and \fBE_UNKNOWN_COMMAND\fR is returned. > This return value makes sense, > -because a double click usually means that an field-specific action should > +because a double click usually means that a field-specific action should > be returned. > It is exactly the purpose of this return value to signal that an > application specific command should be executed. > Index: lib/libform/form_fieldtype.3 > === > RCS file: /cvs/src/lib/libform/form_fieldtype.3,v > retrieving revision 1.12 > diff -u -p -u -p -r1.12 form_fieldtype.3 > --- lib/libform/form_fieldtype.314 Nov 2015 01:35:38 - 1.12 > +++ lib/libform/form_fieldtype.32 Feb 2021 06:51:08 - > @@ -89,7 +89,7 @@ argument into a single scalar value. > .PP > The function \fBlink_fieldtype\fR creates > a new field type from the two given types. > -They are connected by an logical 'OR'. > +They are connected by a logical 'OR'. > .PP > The form driver requests \fBREQ_NEXT_CHOICE\fR and \fBREQ_PREV_CHOICE\fR > assume > that the possible values of a field form an ordered set, and provide the > forms >
Re: libc: cgetent.3, ungetwc.3: small grammar fixes
On Tue, Feb 02, 2021 at 06:08:19PM +1100, Eddie Youseph wrote: > Hi, > > A couple of small grammar fixes for cgetent.3 and ungetwc.3 > fixed, thanks. jmc > Index: lib/libc/gen/cgetent.3 > === > RCS file: /cvs/src/lib/libc/gen/cgetent.3,v > retrieving revision 1.1 > diff -u -p -u -p -r1.1 cgetent.3 > --- lib/libc/gen/cgetent.3 2 Sep 2019 21:18:41 - 1.1 > +++ lib/libc/gen/cgetent.3 2 Feb 2021 06:51:08 - > @@ -244,7 +244,7 @@ Upon completion of the database 0 is ret > return of a record with possibly more remaining (the end of the database has > not been reached yet); 2 is returned if the record contains an unresolved > .Ic tc > -expansion; \-1 is returned if an system error occurred; and \-2 > +expansion; \-1 is returned if a system error occurred; and \-2 > is returned if a potential reference loop is detected (see > .Ic tc= > comments below). > > Index: lib/libc/stdio/ungetwc.3 > === > RCS file: /cvs/src/lib/libc/stdio/ungetwc.3,v > retrieving revision 1.5 > diff -u -p -u -p -r1.5 ungetwc.3 > --- lib/libc/stdio/ungetwc.31 Dec 2017 11:18:40 - 1.5 > +++ lib/libc/stdio/ungetwc.32 Feb 2021 06:51:08 - > @@ -51,7 +51,7 @@ The > .Fn ungetwc > function pushes the wide character > .Fa wc > -(converted to an wchar_t) > +(converted to a wchar_t) > back onto the input stream pointed to by > .Fa stream . > The pushed-backed wide characters will be returned by subsequent reads on the >
Re: libagentx: agentx.3: small grammar fix
On Tue, Feb 02, 2021 at 06:04:08PM +1100, Eddie Youseph wrote: > Hi, > > A small grammar fix for the agentx.3 manpage. > fixed, thanks. jmc > RCS file: /cvs/src/lib/libagentx/agentx.3,v > retrieving revision 1.5 > diff -u -p -u -p -r1.5 agentx.3 > --- lib/libagentx/agentx.3 3 Dec 2020 22:47:21 - 1.5 > +++ lib/libagentx/agentx.3 2 Feb 2021 06:51:07 - > @@ -529,7 +529,7 @@ Set the return value to an opaque value. > .It Fn agentx_varbind_counter64 > Set the return value to an uint64_t of type counter64. > .It Fn agentx_varbind_notfound > -When the request is of type GET return an nosuchinstance error. > +When the request is of type GET return a nosuchinstance error. > When the request is of type GETNEXT or GETBULK return an endofmibview error. > On endofmibview the next object is queried. > This function can only be called on objects that contain one or more > *_dynamic >
ypxfr: ypxfr.8: small grammar fix
Hi, A small grammar fix for ypxfr.8 RCS file: /cvs/src/usr.sbin/ypserv/ypxfr/ypxfr.8,v retrieving revision 1.22 diff -u -p -u -p -r1.22 ypxfr.8 --- usr.sbin/ypserv/ypxfr/ypxfr.8 21 Nov 2015 19:43:50 - 1.22 +++ usr.sbin/ypserv/ypxfr/ypxfr.8 2 Feb 2021 07:26:18 - @@ -45,7 +45,7 @@ .Nm ypxfr is the utility in YP that transfers maps to the local host. .Pp -Since the YP master transfers a map when it has changed, an YP slave should +Since the YP master transfers a map when it has changed, a YP slave should check for missed maps regularly. This can be done via an entry in .Xr crontab 5 .
Re: uhidpp(4): logitech hid++ device driver
On Sat, Jan 30, 2021 at 01:18:07PM +0200, Ville Valkonen wrote: > On Sat, 2021-01-30 at 08:36 +0100, Anton Lindqvist wrote: > > On Fri, Jan 29, 2021 at 10:15:05PM +0200, Ville Valkonen wrote: > > > Hi, > > > > > > I have a bit oldish Logitech M705 mouse, bought around 2010-2011. > > > Regarding the dmesg (on below) I can see it gets attached correctly > > > to > > > uhiddp0 but doesn't report battery levels. Here's the line from > > > dmesg: > > > uhidpp0 at uhidev2 device 1 mouse "M705" serial xx-xx-x-xx, device > > > 2 keyboard "K750" serial xx-xx-xx-xx. > > > And corresponding sysctl values: > > > hw.sensors.uhidpp0.raw0=unknown (battery levels) > > > hw.sensors.uhidpp0.raw1=unknown (battery levels) > > > hw.sensors.uhidpp0.percent0=unknown (battery level) > > > hw.sensors.uhidpp0.percent1=unknown (battery level) > > > > > > Not sure if censoring of serial has any value, though. > > > > Glad to see it attaches fine to a receiver with more than one device > > paired. I only have one device myself and have therefore never been > > enable to verify this. > > > > Could you enable UHIDPP_DEBUG and send me the output? > > > > > On Ubuntu battery levels are detected correctly so I could probably > > > take a USB dump with Wireshark and compare the differences. > > > > Taking a USB dump on your Linux machine would be very helpful. > > Hi, > > Yes. Also remembered that you were mentioning about the debug flag but > completely forgot that while testing. Then just before going to sleep > recalled the debug flag. Here are the results with debug enabled: > > uhidev0 at uhub0 port 1 configuration 1 interface 0 "Logitech USB Receiver" > rev 2.00/12.10 addr 3 > uhidev0: iclass 3/1 > ukbd0 at uhidev0: 8 variable keys, 6 key codes > wskbd1 at ukbd0 mux 1 > wskbd1: connecting to wsdisplay0 > uhidev1 at uhub0 port 1 configuration 1 interface 1 "Logitech USB Receiver" > rev 2.00/12.10 addr 3 > uhidev1: iclass 3/1, 8 report ids > ums0 at uhidev1 reportid 2: 16 buttons, Z and W dir > wsmouse2 at ums0 mux 0 > uhid0 at uhidev1 reportid 3: input=4, output=0, feature=0 > uhid1 at uhidev1 reportid 4: input=1, output=0, feature=0 > uhid2 at uhidev1 reportid 8: input=1, output=0, feature=0 > uhidev2 at uhub0 port 1 configuration 1 interface 2 "Logitech USB Receiver" > rev 2.00/12.10 addr 3 > uhidev2: iclass 3/0, 33 report ids > uhidpp0 at uhidev2hidpp_send_report: 10 ff 83 b5 [30 00 00] > uhidpp_intr: 11 ff 83 b5 [30 c4 b4 96 9e 04 00 00 00 01 00 00 00 00 00 00] > hidpp_send_report: 10 ff 83 b5 [20 00 00] > uhidpp_intr: 11 ff 83 b5 [20 09 08 10 1b 04 00 02 06 00 00 00 00 00 00 00] > hidpp_send_report: 10 ff 83 b5 [40 00 00] > uhidpp_intr: 11 ff 83 b5 [40 04 4d 37 30 35 00 00 00 00 00 00 00 00 00 00] > device 1 mouse "M705" serial xx-xx-xx-9ehidpp_send_report: 10 ff 83 b5 [31 > 00 00] > uhidpp_intr: 11 ff 83 b5 [31 8d 37 6a 6f 1a 40 00 00 03 00 00 00 00 00 00] > hidpp_send_report: 10 ff 83 b5 [21 00 00] > uhidpp_intr: 11 ff 83 b5 [21 08 14 40 02 04 00 01 07 00 00 00 00 00 00 00] > hidpp_send_report: 10 ff 83 b5 [41 00 00] > uhidpp_intr: 11 ff 83 b5 [41 04 4b 37 35 30 00 00 00 00 00 00 00 00 00 00] > , device 2 keyboard "K750" serial xx-xx-xx-6fhidpp_send_report: 10 ff 83 b5 > [32 00 00] > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > hidpp_send_report: 10 ff 83 b5 [33 00 00] > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > hidpp_send_report: 10 ff 83 b5 [34 00 00] > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > hidpp_send_report: 10 ff 83 b5 [35 00 00] > uhidpp_intr: 10 ff 8f 83 [b5 03 00] > hidpp_send_report: 10 ff 80 00 [10 09 00] > uhidpp_intr: 10 ff 80 00 [00 00 00] > > > That's when the mouse was off. When I switched on the mouse kernel > panicked. I couldn't break into DDB or alternatively failed to type > correct commands blindly. Eventually had to shutdown the system by > pressing the power button. Picture of the panic is here: > https://imgur.com/a/QRAD5v1 Thanks for the report. Updated diff which should fix the panic: * Fix a bug in uhidpp_is_notification() causing notifications to be detected as responses * Delay installation of sensors * Enable uhidpp on all architectures >From the panic, I can see that your device only supports HID++ 1.0. Querying the battery status works a bit differently compared to HID++ 2.0. I don't have a 1.0 device but can probably give this a try if you're willing to try out future diffs. However, it would ease development by getting this in and continue development in tree. Anyone willing to ok? > Btw. Time has passed since my previous kernel compile. I saw the > procedure has changed a bit since then. I initially tried to compile > debug flags by prepending `option UHIDPP_DEBUG` to > sys/arch/amd64/compile/GENERIC.MP but couldn't see debug lines in > dmesg. By doing the "old way" I got the debug lines: > cd arch/amd64/conf > cp GENERIC.MP HIDPP.MP > # Add debug flags at this point > config HIDPP.MP > and compiling as usual. Is this the correct way to do it? For debug
tmux: tmux.1: small grammar fix
Hi, A small grammar fix for the tmux manpage. Index: usr.bin/tmux/tmux.1 === RCS file: /cvs/src/usr.bin/tmux/tmux.1,v retrieving revision 1.814 diff -u -p -u -p -r1.814 tmux.1 --- usr.bin/tmux/tmux.1 29 Jan 2021 09:48:43 - 1.814 +++ usr.bin/tmux/tmux.1 2 Feb 2021 06:51:15 - @@ -1362,7 +1362,7 @@ a pane ID such as .Ql %0 ; .Ql %* for all panes in the attached session; -an window ID such as +a window ID such as .Ql @0 ; or .Ql @*
libmenu: menu_driver.3, menu_post.3: small grammar fixes
Hi, Couple of grammar fixes for libmenu menu_driver.3 and menu_post.3 Index: lib/libmenu/menu_driver.3 === RCS file: /cvs/src/lib/libmenu/menu_driver.3,v retrieving revision 1.7 diff -u -p -u -p -r1.7 menu_driver.3 --- lib/libmenu/menu_driver.3 12 Jan 2010 23:22:08 - 1.7 +++ lib/libmenu/menu_driver.3 2 Feb 2021 06:51:08 - @@ -52,7 +52,7 @@ Printable characters (which must be posi checked according to the program's locale settings. .TP 3 - -The input is the KEY_MOUSE special key associated with an mouse event. +The input is the KEY_MOUSE special key associated with a mouse event. .PP The menu driver requests are as follows: .TP 5 Index: lib/libmenu/menu_post.3 === RCS file: /cvs/src/lib/libmenu/menu_post.3,v retrieving revision 1.8 diff -u -p -u -p -r1.8 menu_post.3 --- lib/libmenu/menu_post.3 15 Nov 2015 22:10:16 - 1.8 +++ lib/libmenu/menu_post.3 2 Feb 2021 06:51:08 - @@ -44,7 +44,7 @@ int unpost_menu(MENU *menu); .SH DESCRIPTION The function \fBpost_menu\fR displays a menu to its associated subwindow. To trigger physical display of the subwindow, use \fBrefresh\fR or some equivalent -\fBcurses\fR routine (the implicit \fBdoupdate\fR triggered by an \fBcurses\fR +\fBcurses\fR routine (the implicit \fBdoupdate\fR triggered by a \fBcurses\fR input request will do). \fBpost_menu\fR resets the selection status of all items. .PP The function \fBunpost_menu\fR erases menu from its associated subwindow.
libform: form_driver.3, form_fieldtype.3: Small grammar fixes
Hi, Some grammar fixes for libform. Index: lib/libform/form_driver.3 === RCS file: /cvs/src/lib/libform/form_driver.3,v retrieving revision 1.8 diff -u -p -u -p -r1.8 form_driver.3 --- lib/libform/form_driver.3 12 Jan 2010 23:22:07 - 1.8 +++ lib/libform/form_driver.3 2 Feb 2021 06:51:08 - @@ -52,7 +52,7 @@ Printable characters (which must be posi checked according to the program's locale settings. .TP 3 - -The input is the KEY_MOUSE special key associated with an mouse event. +The input is the KEY_MOUSE special key associated with a mouse event. .PP The form driver requests are as follows: .TP 5 @@ -263,7 +263,7 @@ a REQ_NEXT_PAGE is generated for a doubl a REQ_LAST_FIELD is generated for a triple-click. .RE .PP -If you click at an field inside the display area of the form: +If you click at a field inside the display area of the form: .RS .TP 3 - @@ -274,7 +274,7 @@ If you double-click a field, the form cursor is positioned to that field and \fBE_UNKNOWN_COMMAND\fR is returned. This return value makes sense, -because a double click usually means that an field-specific action should +because a double click usually means that a field-specific action should be returned. It is exactly the purpose of this return value to signal that an application specific command should be executed. Index: lib/libform/form_fieldtype.3 === RCS file: /cvs/src/lib/libform/form_fieldtype.3,v retrieving revision 1.12 diff -u -p -u -p -r1.12 form_fieldtype.3 --- lib/libform/form_fieldtype.314 Nov 2015 01:35:38 - 1.12 +++ lib/libform/form_fieldtype.32 Feb 2021 06:51:08 - @@ -89,7 +89,7 @@ argument into a single scalar value. .PP The function \fBlink_fieldtype\fR creates a new field type from the two given types. -They are connected by an logical 'OR'. +They are connected by a logical 'OR'. .PP The form driver requests \fBREQ_NEXT_CHOICE\fR and \fBREQ_PREV_CHOICE\fR assume that the possible values of a field form an ordered set, and provide the forms
libc: cgetent.3, ungetwc.3: small grammar fixes
Hi, A couple of small grammar fixes for cgetent.3 and ungetwc.3 Index: lib/libc/gen/cgetent.3 === RCS file: /cvs/src/lib/libc/gen/cgetent.3,v retrieving revision 1.1 diff -u -p -u -p -r1.1 cgetent.3 --- lib/libc/gen/cgetent.3 2 Sep 2019 21:18:41 - 1.1 +++ lib/libc/gen/cgetent.3 2 Feb 2021 06:51:08 - @@ -244,7 +244,7 @@ Upon completion of the database 0 is ret return of a record with possibly more remaining (the end of the database has not been reached yet); 2 is returned if the record contains an unresolved .Ic tc -expansion; \-1 is returned if an system error occurred; and \-2 +expansion; \-1 is returned if a system error occurred; and \-2 is returned if a potential reference loop is detected (see .Ic tc= comments below). Index: lib/libc/stdio/ungetwc.3 === RCS file: /cvs/src/lib/libc/stdio/ungetwc.3,v retrieving revision 1.5 diff -u -p -u -p -r1.5 ungetwc.3 --- lib/libc/stdio/ungetwc.31 Dec 2017 11:18:40 - 1.5 +++ lib/libc/stdio/ungetwc.32 Feb 2021 06:51:08 - @@ -51,7 +51,7 @@ The .Fn ungetwc function pushes the wide character .Fa wc -(converted to an wchar_t) +(converted to a wchar_t) back onto the input stream pointed to by .Fa stream . The pushed-backed wide characters will be returned by subsequent reads on the
libagentx: agentx.3: small grammar fix
Hi, A small grammar fix for the agentx.3 manpage. RCS file: /cvs/src/lib/libagentx/agentx.3,v retrieving revision 1.5 diff -u -p -u -p -r1.5 agentx.3 --- lib/libagentx/agentx.3 3 Dec 2020 22:47:21 - 1.5 +++ lib/libagentx/agentx.3 2 Feb 2021 06:51:07 - @@ -529,7 +529,7 @@ Set the return value to an opaque value. .It Fn agentx_varbind_counter64 Set the return value to an uint64_t of type counter64. .It Fn agentx_varbind_notfound -When the request is of type GET return an nosuchinstance error. +When the request is of type GET return a nosuchinstance error. When the request is of type GETNEXT or GETBULK return an endofmibview error. On endofmibview the next object is queried. This function can only be called on objects that contain one or more *_dynamic
pf route-to: only run pf_test when packets enter and leave the stack
this is part of a high level discussion about when pf runs against a
packet. the options are:
1. pf runs when a packet goes over an interface
or
2. pf runs when a packet enters or leaves the network stack.
for normal packet handling there isn't a difference between these
options. in the routing case a packet comes in on an interface, pf tests
it, then the stack processes it and decides to send it out another
interface, pf tests it again on the way out, the packet goes on the
wire. for packets handled by the local system, a packet comes in on an
interface, pf tests it, the stack processes it locally, something
generates a reply, the stack decides to route that out an interface, pf
tests it on the way out, the reply packet ends up on the wire.
in both situations, you get the same sequence of events if you think
that pf runs when a packet goes over an interface or wether pf runs when
a packet enters or leaves the stack.
however, there is a difference if route-to gets involved. if route-to is
applied on an outbound rule/state, it could change which interface the
packet should be going over.
currently the code implements option 1. this means that if route-to
changes the interface, it reruns pf test for the packet going over the
new interface. i would like to change it to option 2.
the main reason i want to change it is that option 1 creates confusion
for the state table. by default, pf states are floating, meaning that
packets are matched to states regardless of which interface they're
going over. if a packet leaving on em0 is rerouted out em1, both
traversals will end up using the same state, which at best will make the
accounting look weird, or at worst fail some checks in the state and get
dropped.
another reason i want to change this is to make it consistent with
other changes that are made to packet. eg, when nat is applied to
a packet, we don't run pf_test again with the new addresses.
the downside to this change is that the pf_test rerun may have been used
to do things like push a packet out another interface with the first run
through pf, and pick up a broad "nat all packets leaving this interface"
rule on the second one.
however, like most things relating to route-to/reply-to/dup-to, im
pretty sure at this point it's not used a lot, so the impact is minimal.
a lot of changes in this space have already been made, so adding another
simplification is justifiable. if this does remove functionality that
people need, i believe sashan@ has agreed to help me implement route-to
on match rules to give more flexibility and composability of rules.
i've canvassed a few people, and their responses have varied from "i
don't care, route-to is the worst" to "i thought we did option 2
anyway". anyone else want to chime in?
this keeps the behaviour where route-to on a packet coming into the
stack is pushed past it and immediately forwarded to the output
interface. the condition for that is greatly simplified now though.
ok?
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.1106
diff -u -p -r1.1106 pf.c
--- pf.c1 Feb 2021 00:31:05 - 1.1106
+++ pf.c2 Feb 2021 03:44:51 -
@@ -6033,7 +6033,7 @@ pf_route(struct pf_pdesc *pd, struct pf_
(ifp->if_flags & IFF_LOOPBACK) == 0)
ip->ip_src = ifatoia(rt->rt_ifa)->ia_addr.sin_addr;
- if (s->rt != PF_DUPTO && pd->kif->pfik_ifp != ifp) {
+ if (s->rt != PF_DUPTO && pd->dir == PF_IN) {
if (pf_test(AF_INET, PF_OUT, ifp, ) != PF_PASS)
goto bad;
else if (m0 == NULL)
@@ -6178,7 +6178,7 @@ pf_route6(struct pf_pdesc *pd, struct pf
(ifp->if_flags & IFF_LOOPBACK) == 0)
ip6->ip6_src = ifatoia6(rt->rt_ifa)->ia_addr.sin6_addr;
- if (s->rt != PF_DUPTO && pd->kif->pfik_ifp != ifp) {
+ if (s->rt != PF_DUPTO && pd->dir == PF_IN) {
if (pf_test(AF_INET6, PF_OUT, ifp, ) != PF_PASS)
goto bad;
else if (m0 == NULL)
Re: execve -1 errno 12 Cannot allocate memory
Anyone? Philippe Philippe Meunier wrote: >Jonathan Gray wrote: >>MAXTSIZ is 128 MB on i386 >>see sys/arch/i386/include/vmparam.h > >Mark Kettenis wrote: >>sys/arch/i386/include/vmparam.h has: >>#define MAXTSIZ (128*1024*1024) /* max text size */ > >Thanks to both of you for the pointer! > >So what about the patch below? I've checked with a new kernel that it >fixes the problem with chrome (even when using the default limits in >/etc/login.conf). > >Philippe > > >Index: sys/arch/i386/include/vmparam.h >=== >RCS file: /cvs/src/sys/arch/i386/include/vmparam.h,v >retrieving revision 1.56 >diff -u -r1.56 vmparam.h >--- sys/arch/i386/include/vmparam.h17 Apr 2018 15:50:05 - 1.56 >+++ sys/arch/i386/include/vmparam.h31 Jan 2021 09:41:00 - >@@ -46,7 +46,7 @@ > /* > * Virtual memory related constants, all in bytes > */ >-#define MAXTSIZ (128*1024*1024) /* max text size */ >+#define MAXTSIZ (256*1024*1024) /* max text size */ > #ifndef DFLDSIZ > #define DFLDSIZ (64*1024*1024) /* initial data size > limit */ > #endif > >
[PATCH] [www] faq/current.html - fix formatting
Hello, Fix formatting of the snmpd.conf configuration snippet. While there: - reduce whitespace from three to two lines as per the comment:
Re: disklabel: make use of getline(3)
On Sun, 31 Jan 2021 15:43:32 +0100, Christian Weisgerber wrote: > Replace fgetln(3) with getline(3). > > Since getline() returns a C string, we don't need to carry around > the length separately. OK millert@ - todd
Permit reading kern.somaxconn with unix pledge
The kern.somaxconn sysctl was previously permitted under the inet
pledge, which allowed pledged Go applications to listen on AF_INET and
AF_INET6 domains.
https://marc.info/?l=openbsd-tech=158069595809463=2
https://marc.info/?l=openbsd-cvs=158081099810301=2
But Go will also read this sysctl when only using unix domain sockets.
The patch below additionally permits reading this sysctl if the unix
pledge is granted.
Note that for this to be tested and useful (where useful means not
running with the inet pledge), Go's net package also needs a patch:
https://gist.github.com/jrick/878236e2f3735d35d5a737936439cb81
diff b17f936e67043f9c006633bac4e3630f86dd05c2 /usr/src
blob - 9ffb7f2ffb9d05d6dd741e180b62141fb5e91f0b
file + sys/kern/kern_pledge.c
--- sys/kern/kern_pledge.c
+++ sys/kern/kern_pledge.c
@@ -888,7 +888,7 @@ pledge_sysctl(struct proc *p, int miblen, int *mib, vo
return (0);
}
- if ((p->p_p->ps_pledge & PLEDGE_INET)) {
+ if ((p->p_p->ps_pledge & (PLEDGE_INET | PLEDGE_UNIX))) {
if (miblen == 2 && /* kern.somaxconn */
mib[0] == CTL_KERN && mib[1] == KERN_SOMAXCONN)
return (0);
Re: sleep_setup/finish simplification
On Mon, Feb 01, 2021 at 05:11:39PM +0100, Claudio Jeker wrote: > On Mon, Feb 01, 2021 at 04:25:47PM +0100, Martin Pieuchot wrote: > > On 08/12/20(Tue) 10:06, Martin Pieuchot wrote: > > > Diff below aims to simplify the API to put a thread on a sleep queue and > > > reduce it to the following: > > > > > > sleep_setup(); > > > /* check condition or release lock */ > > > sleep_finish(); > > > > > > It is motivated by my work to sleep the SCHED_LOCK() but might as well > > > prevent/fix some bugs. > > > > > > The tricky part of the current implementation is that sleep_setup_signal() > > > can already park/stop the current thread resulting in a context change. > > > Should any custom accounting / lock check happen before that? At least > > > two lock primitives do so currently: drm's schedule_timeout() and > > > rwlock's rw_enter(). > > > > > > As a result of this diff various states can be removed and sleep_finish() > > > contains the following magic: > > > > > > 1. check for signal/parking > > > 2. context switch or remove from sleep queue > > > 3. check for signal/parking > > > > > > Note that sleep_finish() could be simplified even further but I left > > > that for later to ease the review. > > > > Updated diff on top of recent changes from claudio@, still ok? > > The sleep code makes my head spin but looking at this diff applied the > changes make sense and the order remains consistent. > I may have spoken too fast. I see strange issues in firefox with this diff in. Need more time to better understand what is going on. For me firefox hangs on session restore (processes are stuck in poll). -- :wq Claudio
Re: pfsync(4), mention about carp demotion
On Mon, Feb 01, 2021 at 04:35:02PM +, Stuart Henderson wrote: > On 2021/02/01 09:22, Theo de Raadt wrote: > > It should use 'demotion counter' everywhere. Thanks, OK kn
Re: pfsync(4), mention about carp demotion
On 2021/02/01 09:22, Theo de Raadt wrote: > It should use 'demotion counter' everywhere. Index: sbin/ifconfig/ifconfig.8 === RCS file: /cvs/src/sbin/ifconfig/ifconfig.8,v retrieving revision 1.360 diff -u -p -r1.360 ifconfig.8 --- sbin/ifconfig/ifconfig.817 Jan 2021 20:35:31 - 1.360 +++ sbin/ifconfig/ifconfig.81 Feb 2021 16:34:26 - @@ -1405,17 +1405,17 @@ Specify the group. .It Cm carpdemote Op Ar number Increase .Xr carp 4 -demote count for given interface group by +demotion counter for given interface group by .Ar number . Acceptable values are 0 to 128. If .Ar number is omitted, it is increased by 1. -Demote count can be set up to 255. +The maximum value for a demotion counter is 255. .It Cm -carpdemote Op Ar number Decrease .Xr carp 4 -demote count for given interface group by +demotion counter for given interface group by .Ar number . Acceptable values are 0 to 128. If Index: usr.sbin/sasyncd/sasyncd.conf.5 === RCS file: /cvs/src/usr.sbin/sasyncd/sasyncd.conf.5,v retrieving revision 1.19 diff -u -p -r1.19 sasyncd.conf.5 --- usr.sbin/sasyncd/sasyncd.conf.5 10 Feb 2020 13:18:22 - 1.19 +++ usr.sbin/sasyncd/sasyncd.conf.5 1 Feb 2021 16:34:26 - @@ -77,7 +77,7 @@ should track master/slave state on. .Xc Specify on which interface group .Xr sasyncd 8 -should increase the demote counter. +should increase the demotion counter. This has the effect of suppressing .Xr carp 4 preemption while initial Index: share/man/man4/pfsync.4 === RCS file: /cvs/src/share/man/man4/pfsync.4,v retrieving revision 1.36 diff -u -p -r1.36 pfsync.4 --- share/man/man4/pfsync.4 30 Aug 2016 13:56:14 - 1.36 +++ share/man/man4/pfsync.4 1 Feb 2021 16:34:26 - @@ -130,6 +130,14 @@ Only run the pfsync protocol on a truste dedicated to pfsync messages such as a crossover cable between two firewalls. .\" or specify a peer address and protect the traffic with .\" .Xr ipsec 4 . +.Pp +.Nm +will increase the +.Xr carp 4 +demotion counter for any interface groups associated with the interface +by 32 during initialisation, and by 1 if the +.Nm +link is down or if a bulk update fails. .Sh EXAMPLES .Nm and
Re: pfsync(4), mention about carp demotion
It should use 'demotion counter' everywhere. Stuart Henderson wrote: > On 2021/02/01 14:32, Klemens Nanni wrote: > > On Mon, Feb 01, 2021 at 01:13:20PM +, Stuart Henderson wrote: > > > I think this needs documenting somewhere; I had to use the source to > > > remember what triggered "carpdemote 32" on some routers. I am open to > > > suggestions to improving the wording, the way I have it it's useful > > > as a reminder but isn't a great explanation for someone just learning > > > about it.. > > That reads fine to me as is and I agree it helps, thanks. > > > > > Index: pfsync.4 > > > === > > > RCS file: /cvs/src/share/man/man4/pfsync.4,v > > > retrieving revision 1.36 > > > diff -u -p -r1.36 pfsync.4 > > > --- pfsync.4 30 Aug 2016 13:56:14 - 1.36 > > > +++ pfsync.4 1 Feb 2021 13:10:38 - > > > @@ -130,6 +130,14 @@ Only run the pfsync protocol on a truste > > > dedicated to pfsync messages such as a crossover cable between two > > > firewalls. > > > .\" or specify a peer address and protect the traffic with > > > .\" .Xr ipsec 4 . > > > +.Pp > > > +.Nm > > > +will increase the > > > +.Xr carp 4 > > > +demote count for any interface groups associated with the interface > > OK kn with s/demote count/demotion counter/ as that is how at least all > > the demons call it (`man -k any=demot'). > > I deliberately used the same text as in ifconfig, so we have: > > bgpd/ospfd/ospf6d/ripd/relayd: demotion counter > sasyncd: demote counter > ifconfig: demote count > > I don't know which is best, but they should probably be united. > > > > > +by 32 during initialisation, and by 1 if the > > > +.Nm > > > +link is down or if a bulk update fails. > > > .Sh EXAMPLES > > > .Nm > > > and > > > > > >
Re: sleep_setup/finish simplification
On Mon, Feb 01, 2021 at 04:25:47PM +0100, Martin Pieuchot wrote:
> On 08/12/20(Tue) 10:06, Martin Pieuchot wrote:
> > Diff below aims to simplify the API to put a thread on a sleep queue and
> > reduce it to the following:
> >
> > sleep_setup();
> > /* check condition or release lock */
> > sleep_finish();
> >
> > It is motivated by my work to sleep the SCHED_LOCK() but might as well
> > prevent/fix some bugs.
> >
> > The tricky part of the current implementation is that sleep_setup_signal()
> > can already park/stop the current thread resulting in a context change.
> > Should any custom accounting / lock check happen before that? At least
> > two lock primitives do so currently: drm's schedule_timeout() and
> > rwlock's rw_enter().
> >
> > As a result of this diff various states can be removed and sleep_finish()
> > contains the following magic:
> >
> > 1. check for signal/parking
> > 2. context switch or remove from sleep queue
> > 3. check for signal/parking
> >
> > Note that sleep_finish() could be simplified even further but I left
> > that for later to ease the review.
>
> Updated diff on top of recent changes from claudio@, still ok?
The sleep code makes my head spin but looking at this diff applied the
changes make sense and the order remains consistent.
OK claudio@
> Index: dev/dt/dt_dev.c
> ===
> RCS file: /cvs/src/sys/dev/dt/dt_dev.c,v
> retrieving revision 1.10
> diff -u -p -r1.10 dt_dev.c
> --- dev/dt/dt_dev.c 28 Sep 2020 13:16:58 - 1.10
> +++ dev/dt/dt_dev.c 26 Jan 2021 17:20:11 -
> @@ -225,10 +225,8 @@ dtread(dev_t dev, struct uio *uio, int f
> return (EMSGSIZE);
>
> while (!sc->ds_evtcnt) {
> - sleep_setup(, sc, PWAIT | PCATCH, "dtread");
> - sleep_setup_signal();
> - sleep_finish(, !sc->ds_evtcnt);
> - error = sleep_finish_signal();
> + sleep_setup(, sc, PWAIT | PCATCH, "dtread", 0);
> + error = sleep_finish(, !sc->ds_evtcnt);
> if (error == EINTR || error == ERESTART)
> break;
> }
> Index: dev/pci/if_myx.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_myx.c,v
> retrieving revision 1.114
> diff -u -p -r1.114 if_myx.c
> --- dev/pci/if_myx.c 17 Jan 2021 02:52:21 - 1.114
> +++ dev/pci/if_myx.c 26 Jan 2021 17:20:11 -
> @@ -1397,7 +1397,7 @@ myx_down(struct myx_softc *sc)
> (void)myx_cmd(sc, MYXCMD_SET_IFDOWN, , NULL);
>
> while (sc->sc_state != MYX_S_OFF) {
> - sleep_setup(, sts, PWAIT, "myxdown");
> + sleep_setup(, sts, PWAIT, "myxdown", 0);
> membar_consumer();
> sleep_finish(, sc->sc_state != MYX_S_OFF);
> }
> Index: dev/pci/drm/drm_linux.c
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
> retrieving revision 1.76
> diff -u -p -r1.76 drm_linux.c
> --- dev/pci/drm/drm_linux.c 13 Jan 2021 01:04:49 - 1.76
> +++ dev/pci/drm/drm_linux.c 26 Jan 2021 17:22:50 -
> @@ -110,14 +110,14 @@ schedule_timeout(long timeout)
> {
> struct sleep_state sls;
> unsigned long deadline;
> - int wait, spl;
> + int wait, spl, timo = 0;
>
> MUTEX_ASSERT_LOCKED(_mtx);
> KASSERT(!cold);
>
> - sleep_setup(, sch_ident, sch_priority, "schto");
> if (timeout != MAX_SCHEDULE_TIMEOUT)
> - sleep_setup_timeout(, timeout);
> + timo = timeout;
> + sleep_setup(, sch_ident, sch_priority, "schto", timo);
>
> wait = (sch_proc == curproc && timeout > 0);
>
> @@ -125,11 +125,9 @@ schedule_timeout(long timeout)
> MUTEX_OLDIPL(_mtx) = splsched();
> mtx_leave(_mtx);
>
> - sleep_setup_signal();
> -
> if (timeout != MAX_SCHEDULE_TIMEOUT)
> deadline = jiffies + timeout;
> - sleep_finish_all(, wait);
> + sleep_finish(, wait);
> if (timeout != MAX_SCHEDULE_TIMEOUT)
> timeout = deadline - jiffies;
>
> Index: kern/kern_rwlock.c
> ===
> RCS file: /cvs/src/sys/kern/kern_rwlock.c,v
> retrieving revision 1.46
> diff -u -p -r1.46 kern_rwlock.c
> --- kern/kern_rwlock.c11 Jan 2021 18:49:38 - 1.46
> +++ kern/kern_rwlock.c26 Jan 2021 17:20:11 -
> @@ -279,15 +279,13 @@ retry:
> prio = op->wait_prio;
> if (flags & RW_INTR)
> prio |= PCATCH;
> - sleep_setup(, rwl, prio, rwl->rwl_name);
> - if (flags & RW_INTR)
> - sleep_setup_signal();
> + sleep_setup(, rwl, prio, rwl->rwl_name, 0);
>
> do_sleep = !rw_cas(>rwl_owner, o, set);
>
> - sleep_finish(, do_sleep);
> + error = sleep_finish(,
nsd 4.3.5
4.3.5
BUG FIXES:
- Fix #143: xfrd no hysteresis with NOT IMPLEMENTED rcode.
- Fix #144: Typo fix in nsd.conf.5.in.
- For #145: Fix that service of remaining TCP and TLS connections
does not allow new queries to be made, the connection is closed.
Only existing queries and zone transfers are answered, new ones
are rejected by a close of the channel.
- Fix that nsd-control has timeout when connection is down.
- remove windows socket ifdefs from nsd-control.
- Fix #148: CNAME need not be followed after a synthesized CNAME
for a CNAME query.
- Fix configure.ac for autoconf 2.70.
- Fix #150: TXT record validation difference with BIND.
- Fix #151: DNAME not applied more than once to resolve the query.
- Fix #152: '*' in Rdata causes the return code to be NOERROR instead
of NX.
Tests, OKs?
diff --git acx_nlnetlabs.m4 acx_nlnetlabs.m4
index 31e43d67e87..d33352f17b8 100644
--- acx_nlnetlabs.m4
+++ acx_nlnetlabs.m4
@@ -2,7 +2,9 @@
# Copyright 2009, Wouter Wijngaards, NLnet Labs.
# BSD licensed.
#
-# Version 35
+# Version 37
+# 2021-01-05 fix defun for aclocal
+# 2021-01-05 autoconf 2.70 autoupdate and fixes, no AC_TRY_COMPILE
# 2020-08-24 Use EVP_sha256 instead of HMAC_Update (for openssl-3.0.0).
# 2016-03-21 Check -ldl -pthread for libcrypto for ldns and openssl 1.1.0.
# 2016-03-21 Use HMAC_Update instead of HMAC_CTX_Init (for openssl-1.1.0).
@@ -447,15 +449,12 @@ AC_DEFUN([ACX_CHECK_FORMAT_ATTRIBUTE],
AC_MSG_CHECKING(whether the C compiler (${CC-cc}) accepts the "format"
attribute)
AC_CACHE_VAL(ac_cv_c_format_attribute,
[ac_cv_c_format_attribute=no
-AC_TRY_COMPILE(
-[#include
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include
void f (char *format, ...) __attribute__ ((format (printf, 1, 2)));
void (*pf) (char *format, ...) __attribute__ ((format (printf, 1, 2)));
-], [
+]], [[
f ("%s", "str");
-],
-[ac_cv_c_format_attribute="yes"],
-[ac_cv_c_format_attribute="no"])
+]])],[ac_cv_c_format_attribute="yes"],[ac_cv_c_format_attribute="no"])
])
AC_MSG_RESULT($ac_cv_c_format_attribute)
@@ -484,14 +483,11 @@ AC_DEFUN([ACX_CHECK_UNUSED_ATTRIBUTE],
AC_MSG_CHECKING(whether the C compiler (${CC-cc}) accepts the "unused"
attribute)
AC_CACHE_VAL(ac_cv_c_unused_attribute,
[ac_cv_c_unused_attribute=no
-AC_TRY_COMPILE(
-[#include
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include
void f (char *u __attribute__((unused)));
-], [
+]], [[
f ("x");
-],
-[ac_cv_c_unused_attribute="yes"],
-[ac_cv_c_unused_attribute="no"])
+]])],[ac_cv_c_unused_attribute="yes"],[ac_cv_c_unused_attribute="no"])
])
dnl Setup ATTR_UNUSED config.h parts.
@@ -548,7 +544,7 @@ dnl as a requirement so that is gets called before LIBTOOL
dnl because libtools 'AC_REQUIRE' names are right after this one, before
dnl this function contents.
AC_REQUIRE([ACX_LIBTOOL_C_PRE])
-AC_PROG_LIBTOOL
+LT_INIT
])
dnl Detect if u_char type is defined, otherwise define it.
@@ -677,14 +673,14 @@ AC_DEFUN([ACX_SSL_CHECKS], [
AC_MSG_CHECKING([for EVP_sha256 in -lcrypto])
LIBS="$LIBS -lcrypto"
LIBSSL_LIBS="$LIBSSL_LIBS -lcrypto"
-AC_TRY_LINK(, [
+AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[
int EVP_sha256(void);
(void)EVP_sha256();
- ], [
+ ]])],[
AC_MSG_RESULT(yes)
AC_DEFINE([HAVE_EVP_SHA256], 1,
[If you have EVP_sha256])
- ], [
+ ],[
AC_MSG_RESULT(no)
# check if -lwsock32 or -lgdi32 are needed.
BAKLIBS="$LIBS"
@@ -692,10 +688,10 @@ AC_DEFUN([ACX_SSL_CHECKS], [
LIBS="$LIBS -lgdi32 -lws2_32"
LIBSSL_LIBS="$LIBSSL_LIBS -lgdi32 -lws2_32"
AC_MSG_CHECKING([if -lcrypto needs -lgdi32])
-AC_TRY_LINK([], [
+AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[
int EVP_sha256(void);
(void)EVP_sha256();
- ],[
+ ]])],[
AC_DEFINE([HAVE_EVP_SHA256], 1,
[If you have EVP_sha256])
AC_MSG_RESULT(yes)
@@ -706,10 +702,10 @@ AC_DEFUN([ACX_SSL_CHECKS], [
LIBS="$LIBS -ldl"
LIBSSL_LIBS="$LIBSSL_LIBS -ldl"
AC_MSG_CHECKING([if -lcrypto needs -ldl])
-AC_TRY_LINK([], [
+AC_LINK_IFELSE([AC_LANG_PROGRAM([[]], [[
int EVP_sha256(void);
(void)EVP_sha256();
- ],[
+ ]])],[
AC_DEFINE([HAVE_EVP_SHA256], 1,
[If you have EVP_sha256])
AC_MSG_RESULT(yes)
@@ -720,10 +716,10 @@ AC_DEFUN([ACX_SSL_CHECKS], [
Re: sleep_setup/finish simplification
On 08/12/20(Tue) 10:06, Martin Pieuchot wrote:
> Diff below aims to simplify the API to put a thread on a sleep queue and
> reduce it to the following:
>
> sleep_setup();
> /* check condition or release lock */
> sleep_finish();
>
> It is motivated by my work to sleep the SCHED_LOCK() but might as well
> prevent/fix some bugs.
>
> The tricky part of the current implementation is that sleep_setup_signal()
> can already park/stop the current thread resulting in a context change.
> Should any custom accounting / lock check happen before that? At least
> two lock primitives do so currently: drm's schedule_timeout() and
> rwlock's rw_enter().
>
> As a result of this diff various states can be removed and sleep_finish()
> contains the following magic:
>
> 1. check for signal/parking
> 2. context switch or remove from sleep queue
> 3. check for signal/parking
>
> Note that sleep_finish() could be simplified even further but I left
> that for later to ease the review.
Updated diff on top of recent changes from claudio@, still ok?
Index: dev/dt/dt_dev.c
===
RCS file: /cvs/src/sys/dev/dt/dt_dev.c,v
retrieving revision 1.10
diff -u -p -r1.10 dt_dev.c
--- dev/dt/dt_dev.c 28 Sep 2020 13:16:58 - 1.10
+++ dev/dt/dt_dev.c 26 Jan 2021 17:20:11 -
@@ -225,10 +225,8 @@ dtread(dev_t dev, struct uio *uio, int f
return (EMSGSIZE);
while (!sc->ds_evtcnt) {
- sleep_setup(, sc, PWAIT | PCATCH, "dtread");
- sleep_setup_signal();
- sleep_finish(, !sc->ds_evtcnt);
- error = sleep_finish_signal();
+ sleep_setup(, sc, PWAIT | PCATCH, "dtread", 0);
+ error = sleep_finish(, !sc->ds_evtcnt);
if (error == EINTR || error == ERESTART)
break;
}
Index: dev/pci/if_myx.c
===
RCS file: /cvs/src/sys/dev/pci/if_myx.c,v
retrieving revision 1.114
diff -u -p -r1.114 if_myx.c
--- dev/pci/if_myx.c17 Jan 2021 02:52:21 - 1.114
+++ dev/pci/if_myx.c26 Jan 2021 17:20:11 -
@@ -1397,7 +1397,7 @@ myx_down(struct myx_softc *sc)
(void)myx_cmd(sc, MYXCMD_SET_IFDOWN, , NULL);
while (sc->sc_state != MYX_S_OFF) {
- sleep_setup(, sts, PWAIT, "myxdown");
+ sleep_setup(, sts, PWAIT, "myxdown", 0);
membar_consumer();
sleep_finish(, sc->sc_state != MYX_S_OFF);
}
Index: dev/pci/drm/drm_linux.c
===
RCS file: /cvs/src/sys/dev/pci/drm/drm_linux.c,v
retrieving revision 1.76
diff -u -p -r1.76 drm_linux.c
--- dev/pci/drm/drm_linux.c 13 Jan 2021 01:04:49 - 1.76
+++ dev/pci/drm/drm_linux.c 26 Jan 2021 17:22:50 -
@@ -110,14 +110,14 @@ schedule_timeout(long timeout)
{
struct sleep_state sls;
unsigned long deadline;
- int wait, spl;
+ int wait, spl, timo = 0;
MUTEX_ASSERT_LOCKED(_mtx);
KASSERT(!cold);
- sleep_setup(, sch_ident, sch_priority, "schto");
if (timeout != MAX_SCHEDULE_TIMEOUT)
- sleep_setup_timeout(, timeout);
+ timo = timeout;
+ sleep_setup(, sch_ident, sch_priority, "schto", timo);
wait = (sch_proc == curproc && timeout > 0);
@@ -125,11 +125,9 @@ schedule_timeout(long timeout)
MUTEX_OLDIPL(_mtx) = splsched();
mtx_leave(_mtx);
- sleep_setup_signal();
-
if (timeout != MAX_SCHEDULE_TIMEOUT)
deadline = jiffies + timeout;
- sleep_finish_all(, wait);
+ sleep_finish(, wait);
if (timeout != MAX_SCHEDULE_TIMEOUT)
timeout = deadline - jiffies;
Index: kern/kern_rwlock.c
===
RCS file: /cvs/src/sys/kern/kern_rwlock.c,v
retrieving revision 1.46
diff -u -p -r1.46 kern_rwlock.c
--- kern/kern_rwlock.c 11 Jan 2021 18:49:38 - 1.46
+++ kern/kern_rwlock.c 26 Jan 2021 17:20:11 -
@@ -279,15 +279,13 @@ retry:
prio = op->wait_prio;
if (flags & RW_INTR)
prio |= PCATCH;
- sleep_setup(, rwl, prio, rwl->rwl_name);
- if (flags & RW_INTR)
- sleep_setup_signal();
+ sleep_setup(, rwl, prio, rwl->rwl_name, 0);
do_sleep = !rw_cas(>rwl_owner, o, set);
- sleep_finish(, do_sleep);
+ error = sleep_finish(, do_sleep);
if ((flags & RW_INTR) &&
- (error = sleep_finish_signal()) != 0)
+ (error != 0))
return (error);
if (flags & RW_SLEEPFAIL)
return (EAGAIN);
Index: kern/kern_sched.c
Re: [External] : Re: XCP-ng, OpenBSD and network interface changes
Le Mon, Feb 01, 2021 at 01:49:09PM +0100, Alexandr Nedvedicky a écrit :
> Hello Denis,
>
> I think we need to refresh expected value in 'flags'
> with every loop iteration. does diff below help?
>
Thank you but it does not help. Same panic and also same panic if I test with
loop++ > 10.
If loop++ > 100, no more panic but I get :
xnf0 detached
xen0: failed to attach "device/vif/"
> regards
> sashan
>
> 8<---8<---8<--8<
> diff --git a/sys/dev/pv/xen.c b/sys/dev/pv/xen.c
> index 11ce4ca99cd..c93e68614b4 100644
> --- a/sys/dev/pv/xen.c
> +++ b/sys/dev/pv/xen.c
> @@ -1202,20 +1202,22 @@ xen_grant_table_remove(struct xen_softc *sc,
> grant_ref_t ref)
> flags = (ge->ge_table[ref].flags & ~(GTF_reading|GTF_writing)) |
> (ge->ge_table[ref].domid << 16);
> loop = 0;
> while (atomic_cas_uint(ptr, flags, GTF_invalid) != flags) {
> if (loop++ > 10) {
> panic("grant table reference %u is held "
> "by domain %d: frame %#x flags %#x",
> ref + ge->ge_start, ge->ge_table[ref].domid,
> ge->ge_table[ref].frame, ge->ge_table[ref].flags);
> }
> + flags = (ge->ge_table[ref].flags & ~(GTF_reading|GTF_writing)) |
> + (ge->ge_table[ref].domid << 16);
> #if (defined(__amd64__) || defined(__i386__))
> __asm volatile("pause": : : "memory");
> #endif
> }
> ge->ge_table[ref].frame = 0x;
> }
>
> int
> xen_bus_dmamap_create(bus_dma_tag_t t, bus_size_t size, int nsegments,
> bus_size_t maxsegsz, bus_size_t boundary, int flags, bus_dmamap_t *dmamp)
Re: Remove obsolete vnode opv declarations
On Mon, Feb 01, 2021 at 02:14:24PM +, Visa Hankala wrote: > This removes obsolete vnode operation vector declarations from > header . The functions were removed in r1.28 of vfs_init.c. > > OK? OK bluhm@ > Index: sys/systm.h > === > RCS file: src/sys/sys/systm.h,v > retrieving revision 1.150 > diff -u -p -r1.150 systm.h > --- sys/systm.h 27 Dec 2020 11:38:35 - 1.150 > +++ sys/systm.h 1 Feb 2021 14:06:50 - > @@ -152,11 +152,6 @@ int enoioctl(void); > int enxio(void); > int eopnotsupp(void *); > > -struct vnodeopv_desc; > -void vfs_opv_init_explicit(struct vnodeopv_desc *); > -void vfs_opv_init_default(struct vnodeopv_desc *); > -void vfs_op_init(void); > - > int seltrue(dev_t dev, int which, struct proc *); > int selfalse(dev_t dev, int which, struct proc *); > void *hashinit(int, int, int, u_long *);
Remove obsolete vnode opv declarations
This removes obsolete vnode operation vector declarations from header . The functions were removed in r1.28 of vfs_init.c. OK? Index: sys/systm.h === RCS file: src/sys/sys/systm.h,v retrieving revision 1.150 diff -u -p -r1.150 systm.h --- sys/systm.h 27 Dec 2020 11:38:35 - 1.150 +++ sys/systm.h 1 Feb 2021 14:06:50 - @@ -152,11 +152,6 @@ intenoioctl(void); intenxio(void); inteopnotsupp(void *); -struct vnodeopv_desc; -void vfs_opv_init_explicit(struct vnodeopv_desc *); -void vfs_opv_init_default(struct vnodeopv_desc *); -void vfs_op_init(void); - intseltrue(dev_t dev, int which, struct proc *); intselfalse(dev_t dev, int which, struct proc *); void *hashinit(int, int, int, u_long *);
Re: pfsync(4), mention about carp demotion
On 2021/02/01 14:32, Klemens Nanni wrote: > On Mon, Feb 01, 2021 at 01:13:20PM +, Stuart Henderson wrote: > > I think this needs documenting somewhere; I had to use the source to > > remember what triggered "carpdemote 32" on some routers. I am open to > > suggestions to improving the wording, the way I have it it's useful > > as a reminder but isn't a great explanation for someone just learning > > about it.. > That reads fine to me as is and I agree it helps, thanks. > > > Index: pfsync.4 > > === > > RCS file: /cvs/src/share/man/man4/pfsync.4,v > > retrieving revision 1.36 > > diff -u -p -r1.36 pfsync.4 > > --- pfsync.430 Aug 2016 13:56:14 - 1.36 > > +++ pfsync.41 Feb 2021 13:10:38 - > > @@ -130,6 +130,14 @@ Only run the pfsync protocol on a truste > > dedicated to pfsync messages such as a crossover cable between two > > firewalls. > > .\" or specify a peer address and protect the traffic with > > .\" .Xr ipsec 4 . > > +.Pp > > +.Nm > > +will increase the > > +.Xr carp 4 > > +demote count for any interface groups associated with the interface > OK kn with s/demote count/demotion counter/ as that is how at least all > the demons call it (`man -k any=demot'). I deliberately used the same text as in ifconfig, so we have: bgpd/ospfd/ospf6d/ripd/relayd: demotion counter sasyncd: demote counter ifconfig: demote count I don't know which is best, but they should probably be united. > > +by 32 during initialisation, and by 1 if the > > +.Nm > > +link is down or if a bulk update fails. > > .Sh EXAMPLES > > .Nm > > and > > >
Re: pfsync(4), mention about carp demotion
On Mon, Feb 01, 2021 at 01:13:20PM +, Stuart Henderson wrote: > I think this needs documenting somewhere; I had to use the source to > remember what triggered "carpdemote 32" on some routers. I am open to > suggestions to improving the wording, the way I have it it's useful > as a reminder but isn't a great explanation for someone just learning > about it.. That reads fine to me as is and I agree it helps, thanks. > Index: pfsync.4 > === > RCS file: /cvs/src/share/man/man4/pfsync.4,v > retrieving revision 1.36 > diff -u -p -r1.36 pfsync.4 > --- pfsync.4 30 Aug 2016 13:56:14 - 1.36 > +++ pfsync.4 1 Feb 2021 13:10:38 - > @@ -130,6 +130,14 @@ Only run the pfsync protocol on a truste > dedicated to pfsync messages such as a crossover cable between two firewalls. > .\" or specify a peer address and protect the traffic with > .\" .Xr ipsec 4 . > +.Pp > +.Nm > +will increase the > +.Xr carp 4 > +demote count for any interface groups associated with the interface OK kn with s/demote count/demotion counter/ as that is how at least all the demons call it (`man -k any=demot'). > +by 32 during initialisation, and by 1 if the > +.Nm > +link is down or if a bulk update fails. > .Sh EXAMPLES > .Nm > and >
pfsync(4), mention about carp demotion
I think this needs documenting somewhere; I had to use the source to remember what triggered "carpdemote 32" on some routers. I am open to suggestions to improving the wording, the way I have it it's useful as a reminder but isn't a great explanation for someone just learning about it.. Index: pfsync.4 === RCS file: /cvs/src/share/man/man4/pfsync.4,v retrieving revision 1.36 diff -u -p -r1.36 pfsync.4 --- pfsync.430 Aug 2016 13:56:14 - 1.36 +++ pfsync.41 Feb 2021 13:10:38 - @@ -130,6 +130,14 @@ Only run the pfsync protocol on a truste dedicated to pfsync messages such as a crossover cable between two firewalls. .\" or specify a peer address and protect the traffic with .\" .Xr ipsec 4 . +.Pp +.Nm +will increase the +.Xr carp 4 +demote count for any interface groups associated with the interface +by 32 during initialisation, and by 1 if the +.Nm +link is down or if a bulk update fails. .Sh EXAMPLES .Nm and
Re: XCP-ng, OpenBSD and network interface changes
On Sun, Jan 31, 2021 at 2:59 PM Denis Fondras wrote:
> I am using XCP-ng with the latest OpenBSD snapshot.
>
> Whenever I make an hardware change in networking on the VM (connect or
> disconnect an interface, change associated network), the VM panics :
>
> openbsd# panic: grant table reference 5912 is held by domain 0: frame
> 0x1f1a4 flags 0x19
> Stopped at db_enter+0x10: popq %rbp
> TID PID UIDPRFLAGS PFLAGS CPU COMMAND
> *349758 6557900x14000 0x200 0 xenwatch
> db_enter() at db_enter+0x10
> panic(81da7541) at panic+0x12a
> xen_bus_dmamap_unload(820ede50,800e9380) at
> xen_bus_dmamap_unload+0x138
> xnf_tx_ring_destroy(80162000) at xnf_tx_ring_destroy+0x104
> xnf_detach(80162000,0) at xnf_detach+0x55
> config_detach(80162000,0) at config_detach+0x140
> xen_hotplug(8012e200) at xen_hotplug+0x181
> taskq_thread(800dde00) at taskq_thread+0x66
> end trace frame: 0x0, count: 7
> https://www.openbsd.org/ddb.html describes the minimum info required in
> bug reports. Insufficient info makes it difficult to find and fix bugs.
> ddb>
>
> If I apply the following patch, it obviously does not panic and seems to
> work
> correctly :
>
>
Hi Denis,
This is not a real fix unfortunately, you're just ignoring the issue.
Somehow the grant table reference is not released when we perform the
detach.
You can try increasing amount of iterations to 1 (or more) for example
and see
if this is a timing issue.
Cheers,
Mike
> Index: xen.c
> ===
> RCS file: /cvs/src/sys/dev/pv/xen.c,v
> retrieving revision 1.97
> diff -u -p -r1.97 xen.c
> --- xen.c 29 Jun 2020 06:50:52 - 1.97
> +++ xen.c 31 Jan 2021 13:13:07 -
> @@ -1204,7 +1204,7 @@ xen_grant_table_remove(struct xen_softc
> loop = 0;
> while (atomic_cas_uint(ptr, flags, GTF_invalid) != flags) {
> if (loop++ > 10) {
> - panic("grant table reference %u is held "
> + printf("grant table reference %u is held "
> "by domain %d: frame %#x flags %#x",
> ref + ge->ge_start, ge->ge_table[ref].domid,
> ge->ge_table[ref].frame,
> ge->ge_table[ref].flags);
>
> Can someone give me a clue on what _atomic_cas_uint() is ?
>
> Thank you in advance.
>
> Denis
>
> OpenBSD 6.8-current (GENERIC) #9: Sun Jan 31 14:08:42 CET 2021
> r...@openbsd.lab.ledeuns.net:/sys/arch/amd64/compile/GENERIC
> real mem = 1052770304 (1004MB)
> avail mem = 1005694976 (959MB)
> random: good seed from bootblocks
> mpath0 at root
> scsibus0 at mpath0: 256 targets
> mainbus0 at root
> bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xeb01f (11 entries)
> bios0: vendor Xen version "4.13" date 01/21/2021
> bios0: Xen HVM domU
> acpi0 at bios0: ACPI 4.0
> acpi0: sleep states S5
> acpi0: tables DSDT FACP APIC HPET WAET
> acpi0: wakeup devices
> acpitimer0 at acpi0: 3579545 Hz, 32 bits
> acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
> ioapic0 at mainbus0: apid 1 pa 0xfec0, version 11, 48 pins, remapped
> cpu0 at mainbus0: apid 0 (boot processor)
> cpu0: Intel(R) Xeon(R) CPU E5-2407 v2 @ 2.40GHz, 2394.83 MHz, 06-3e-04
> cpu0:
> FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,HV,NXE,PAGE1GB,RDTSCP,LONG,LAHF,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,XSAVEOPT,MELTDOWN
> cpu0: 256KB 64b/line 8-way L2 cache
> cpu0: smt 0, core 0, package 0
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> cpu0: apic clock running at 100MHz
> acpihpet0 at acpi0: 6250 Hz
> acpiprt0 at acpi0: bus 0 (PCI0)
> acpipci0 at acpi0 PCI0
> acpicmos0 at acpi0
> "ACPI0007" at acpi0 not configured
> acpicpu0 at acpi0: C1(@1 halt!)
> cpu0: using VERW MDS workaround (except on vmm entry)
> pvbus0 at mainbus0: Hyper-V 0.0, Xen 4.13
> xen0 at pvbus0: features 0x2705, 64 grant table frames, event channel 2
> xbf0 at xen0 backend 0 channel 6: disk
> scsibus1 at xbf0: 1 targets
> sd0 at scsibus1 targ 0 lun 0:
> sd0: 10240MB, 512 bytes/sector, 20971520 sectors
> xbf1 at xen0 backend 0 channel 7: cdrom
> xbf1: timed out waiting for backend to connect
> xnf0 at xen0 backend 0 channel 7: address 76:88:23:28:25:f4
> xnf1 at xen0 backend 0 channel 8: address 62:36:ed:68:46:3c
> xnf2 at xen0 backend 0 channel 9: address be:04:e2:f3:7d:75
> pci0 at mainbus0 bus 0
> pchb0 at pci0 dev 0 function 0 "Intel 82441FX" rev 0x02
> pcib0 at pci0 dev 1 function 0 "Intel 82371SB ISA" rev 0x00
> pciide0 at pci0 dev 1 function 1 "Intel 82371SB IDE" rev 0x00: DMA,
> channel 0 wired to compatibility, channel 1 wired to compatibility
> pciide0: channel 0 disabled (no drives)
> atapiscsi0 at pciide0 channel 1 drive 1
> scsibus2 at atapiscsi0: 2 targets
> cd0 at scsibus2 targ 0 lun
