Re: iked(8): Increase the default Child SA data lifetime limit
Vitaliy Makkoveev wrote: > > ssh_packet_need_rekeying() appears to have some nice decisions. The > > idea is to rekey based upon time, primarily. > > It does the same: the two limits and rekying starts when you exceeded > any of them. But in the ssh case we have no massive traffic load, so we > reach time limit first. The ipsec case is opposite. First off, this is not ipsec. This is a iked decision. And thus the iked case is only the opposite of ssh because iked has ludicrously small data limits. I doubt this choice was made purposefully. Correct me if I am wrong about ssh: debug1: rekey in after 134217728 blocks Imagine AES is being used such that blocksize is 16. So ssh will rekey at 2GB data, also note this is a non-datagram model, it is a session that stops such that no traffic is lost. And this 2G is generally the data rekey decision for a flow by _a single user_. But IPSEC is not moving a single user's data! And as a result of this, datagrams get lost. Seems a poor tradeoff to lose packets when turning on crypto. So 2GB is a ludicrous position to take, very much like "the cipher being used is unsafe". Please explain how AES is suddenly this poor. If there are unsafe cipher choices, then those specific unsafe ones should make tighter datasize choices, but the modern ciphers we have are much better so their choices should be huge. I suspect the first step is to make the rekey decision be based upon the strength of the ciphers.
Re: iked(8): Increase the default Child SA data lifetime limit
> On 3 Aug 2021, at 04:22, Theo de Raadt wrote: > > Joerg Sonnenberger wrote: > >> On Tue, Aug 03, 2021 at 01:12:54AM +0300, Vitaliy Makkoveev wrote: >>> Index: sbin/iked/types.h >>> === >>> RCS file: /cvs/src/sbin/iked/types.h,v >>> retrieving revision 1.43 >>> diff -u -p -r1.43 types.h >>> --- sbin/iked/types.h 13 May 2021 15:20:48 - 1.43 >>> +++ sbin/iked/types.h 2 Aug 2021 21:41:55 - >>> @@ -67,7 +67,7 @@ >>> #define IKED_CYCLE_BUFFERS 8 /* # of static buffers for mapping */ >>> #define IKED_PASSWORD_SIZE 256 /* limited by most EAP types */ >>> >>> -#define IKED_LIFETIME_BYTES536870912 /* 512 Mb */ >>> +#define IKED_LIFETIME_BYTES1073741824 /* 512 Mb */ >>> #define IKED_LIFETIME_SECONDS 10800 /* 3 hours */ >>> >>> #define IKED_E 0x1000 /* Decrypted flag */ >>> >> >> Comment and value don't match? Also, isn't 512MB quite low with modern >> crypto algorithms? > > I think the low values are exceedingly cynical, and should be increased > substantially. Which value looks more appropriate here? 1G, 10G? I guess it depends on bandwidth which is different. My main idea is to have the window for rekeying about the half of hard limit. 1G was chosen to keep the original rekeying frequency. Also Hrvoje reported the problem disappeared with unpatched kernel and 4G bytes limit. 95% of 4G is about 205M, so I guess 1G for hard and 410-512M for soft limit is enough as default value. Which could be overridden in iked.conf(5). > > ssh_packet_need_rekeying() appears to have some nice decisions. The > idea is to rekey based upon time, primarily. It does the same: the two limits and rekying starts when you exceeded any of them. But in the ssh case we have no massive traffic load, so we reach time limit first. The ipsec case is opposite.
Re: iked(8): Increase the default Child SA data lifetime limit
Joerg Sonnenberger wrote: > On Tue, Aug 03, 2021 at 01:12:54AM +0300, Vitaliy Makkoveev wrote: > > Index: sbin/iked/types.h > > === > > RCS file: /cvs/src/sbin/iked/types.h,v > > retrieving revision 1.43 > > diff -u -p -r1.43 types.h > > --- sbin/iked/types.h 13 May 2021 15:20:48 - 1.43 > > +++ sbin/iked/types.h 2 Aug 2021 21:41:55 - > > @@ -67,7 +67,7 @@ > > #define IKED_CYCLE_BUFFERS 8 /* # of static buffers for mapping */ > > #define IKED_PASSWORD_SIZE 256 /* limited by most EAP types */ > > > > -#define IKED_LIFETIME_BYTES536870912 /* 512 Mb */ > > +#define IKED_LIFETIME_BYTES1073741824 /* 512 Mb */ > > #define IKED_LIFETIME_SECONDS 10800 /* 3 hours */ > > > > #define IKED_E 0x1000 /* Decrypted flag */ > > > > Comment and value don't match? Also, isn't 512MB quite low with modern > crypto algorithms? I think the low values are exceedingly cynical, and should be increased substantially. ssh_packet_need_rekeying() appears to have some nice decisions. The idea is to rekey based upon time, primarily.
Re: iked(8): Increase the default Child SA data lifetime limit
On Tue, Aug 03, 2021 at 01:12:54AM +0300, Vitaliy Makkoveev wrote: > Index: sbin/iked/types.h > === > RCS file: /cvs/src/sbin/iked/types.h,v > retrieving revision 1.43 > diff -u -p -r1.43 types.h > --- sbin/iked/types.h 13 May 2021 15:20:48 - 1.43 > +++ sbin/iked/types.h 2 Aug 2021 21:41:55 - > @@ -67,7 +67,7 @@ > #define IKED_CYCLE_BUFFERS 8 /* # of static buffers for mapping */ > #define IKED_PASSWORD_SIZE 256 /* limited by most EAP types */ > > -#define IKED_LIFETIME_BYTES 536870912 /* 512 Mb */ > +#define IKED_LIFETIME_BYTES 1073741824 /* 512 Mb */ > #define IKED_LIFETIME_SECONDS10800 /* 3 hours */ > > #define IKED_E 0x1000 /* Decrypted flag */ > Comment and value don't match? Also, isn't 512MB quite low with modern crypto algorithms? Joerg
iked(8): Increase the default Child SA data lifetime limit
iked(8) uses 3 hours and 512 megabytes of processed data as default lifetime hard limits for Child SA. Also it sets 85-95% of these values as soft limit. iked(8) should perform rekeying before we reach hard limit otherwise this SA will be killed and the tunnel stopped. With default values the window is only 25-52 megabytes and we easily consume them before rekeying and the tunnel stops. Hrvoje Popovski complained about such stops when he has tested ipsec(4) related diffs. I also tried iked(8) with my macos and found that simple "ping -f ..." makes rekeying impossible. The hard limit could be modified in iked.conf(5) by setting "lifetime xxx bytes yyy", but the 5% difference between hard and soft limits forces to set bytes limit big enough, about 4G and more, which could be bad for security reason. I propose to increase the default hard limit at least up to 1G. Also I propose to decrease the soft limit down to 50-60% of hard limit. This keeps the rekeying frequency but increases the update window to 410-512 megabytes. Also this allow to keep bytes in "lifetime" setting small enough. Index: sbin/iked/iked.conf.5 === RCS file: /cvs/src/sbin/iked/iked.conf.5,v retrieving revision 1.85 diff -u -p -r1.85 iked.conf.5 --- sbin/iked/iked.conf.5 11 Apr 2021 23:27:06 - 1.85 +++ sbin/iked/iked.conf.5 2 Aug 2021 21:41:55 - @@ -586,8 +586,8 @@ parameter defines the Child SA expiratio SA was in use and by the number of .Ar bytes that were processed using the SA. -Default values are 3 hours and 512 megabytes which means that SA will be -rekeyed before reaching the time limit or 512 megabytes of data +Default values are 3 hours and 1024 megabytes which means that SA will be +rekeyed before reaching the time limit or 1024 megabytes of data will pass through. Zero values disable rekeying. .Pp Index: sbin/iked/pfkey.c === RCS file: /cvs/src/sbin/iked/pfkey.c,v retrieving revision 1.77 diff -u -p -r1.77 pfkey.c --- sbin/iked/pfkey.c 2 Mar 2021 03:31:25 - 1.77 +++ sbin/iked/pfkey.c 2 Aug 2021 21:41:55 - @@ -603,8 +603,8 @@ pfkey_sa(int sd, uint8_t satype, uint8_t sa_ltime_soft.sadb_lifetime_exttype = SADB_EXT_LIFETIME_SOFT; sa_ltime_soft.sadb_lifetime_len = sizeof(sa_ltime_soft) / 8; - /* set randomly to 85-95% */ - jitter = 850 + arc4random_uniform(100); + /* set randomly to 50-60% */ + jitter = 500 + arc4random_uniform(100); sa_ltime_soft.sadb_lifetime_bytes = (sa_ltime_hard.sadb_lifetime_bytes * jitter) / 1000; sa_ltime_soft.sadb_lifetime_addtime = Index: sbin/iked/types.h === RCS file: /cvs/src/sbin/iked/types.h,v retrieving revision 1.43 diff -u -p -r1.43 types.h --- sbin/iked/types.h 13 May 2021 15:20:48 - 1.43 +++ sbin/iked/types.h 2 Aug 2021 21:41:55 - @@ -67,7 +67,7 @@ #define IKED_CYCLE_BUFFERS 8 /* # of static buffers for mapping */ #define IKED_PASSWORD_SIZE 256 /* limited by most EAP types */ -#define IKED_LIFETIME_BYTES536870912 /* 512 Mb */ +#define IKED_LIFETIME_BYTES1073741824 /* 512 Mb */ #define IKED_LIFETIME_SECONDS 10800 /* 3 hours */ #define IKED_E 0x1000 /* Decrypted flag */
Re: [patch] dhcpleased(8): No new lease when trunk(4) failover
On Mon, Aug 02, 2021 at 11:36:47PM +0200, Jesper Wallin wrote:
> On Mon, Aug 02, 2021 at 08:28:00PM +0200, Florian Obser wrote:
> > On 2021-07-28 23:02 +02, Jesper Wallin wrote:
> > > Hi tech@
> > >
> > > I've setup my machine to use trunk(4) with re(4) and iwm(4) as failover,
> > > to make life easier when switching between wired and wireless
> > > networking. The wired network at home is on a different subnet from
> > > the wireless network, so when I unplug the cable, a DHCP request is
> >
> > I don't think this is a correct configuration (I accidentally made this
> > work in 2019, sorry about that).
> > Can't you use
> > inet autoconf
> > in hostname.re0 *and* hostname.iwm0?
>
> Oh? I've used this configuration for little over 3 years now and I
> thought the IP/configuration should be trunk0 based on the examples in
> trunk(4) and https://www.openbsd.org/faq/faq6.html#Wireless.
>
> I *could* do it the way you suggest, of course, but I thought this was a
> bug/regression, as it worked fine with dhclient(8). In my network
> configuration, of separating the wired and wireless network, it wouldn't
> be an issue. On networks where the wired and wireless network are on
> the same subnet though, it would be a shame to lose the ability to have
> it seemlessly jump from one to another without losing any connections.
Err, scratch that last paragraph. If they're on the same network, why
would a DHCPREQUEST be needed?! Note to self, think before posting.
Too much Monday today.
> > > required to get my connection to work again. Before, dhcpleased(8),
> > > dhclient(8) handled this as expected.
> > >
> > > I skimmed through the code to try to understand how dhclient(8) handles
> > > this, but I'm not sure I fully understand this. My first take was to
> > > change the rtfilter, as I noticed dhclient(8) was listening for way more
> > > things. But after some testing I learned that RTM_IFINFO was enough,
> > > even if trunk(4) remains "active" and UP when the cable is unplugged.
> > >
> > > This solution might not be optimal, as I've basically just removed some
> > > of the checks in engine_update_iface() that return early if nothing has
> > > changed on the interface. At least it solves my issue with trunk(4) and
> > > so far I haven't managed to spawn any dragons from this. Though, this
> > > might cause engine_update_iface() to fully more often?
> > >
> > > Thoughts?
> > >
> > > Index: engine.c
> > > ===
> > > RCS file: /cvs/src/sbin/dhcpleased/engine.c,v
> > > retrieving revision 1.22
> > > diff -u -p -r1.22 engine.c
> > > --- engine.c 26 Jul 2021 09:26:36 - 1.22
> > > +++ engine.c 28 Jul 2021 20:39:45 -
> > > @@ -586,7 +586,6 @@ void
> > > engine_update_iface(struct imsg_ifinfo *imsg_ifinfo)
> > > {
> > > struct dhcpleased_iface *iface;
> > > - int need_refresh = 0;
> > >
> > > iface = get_dhcpleased_iface_by_id(imsg_ifinfo->if_index);
> > >
> > > @@ -604,32 +603,14 @@ engine_update_iface(struct imsg_ifinfo *
> > > memcpy(>hw_address, _ifinfo->hw_address,
> > > sizeof(struct ether_addr));
> > > LIST_INSERT_HEAD(_interfaces, iface, entries);
> > > - need_refresh = 1;
> > > } else {
> > > - if (memcmp(>hw_address, _ifinfo->hw_address,
> > > - sizeof(struct ether_addr)) != 0) {
> > > - memcpy(>hw_address, _ifinfo->hw_address,
> > > - sizeof(struct ether_addr));
> > > - need_refresh = 1;
> > > - }
> > > - if (imsg_ifinfo->rdomain != iface->rdomain) {
> > > - iface->rdomain = imsg_ifinfo->rdomain;
> > > - need_refresh = 1;
> > > - }
> > > - if (imsg_ifinfo->running != iface->running) {
> > > - iface->running = imsg_ifinfo->running;
> > > - need_refresh = 1;
> > > - }
> > > -
> > > - if (imsg_ifinfo->link_state != iface->link_state) {
> > > - iface->link_state = imsg_ifinfo->link_state;
> > > - need_refresh = 1;
> > > - }
> > > + memcpy(>hw_address, _ifinfo->hw_address,
> > > + sizeof(struct ether_addr));
> > > + iface->rdomain = imsg_ifinfo->rdomain;
> > > + iface->running = imsg_ifinfo->running;
> > > + iface->link_state = imsg_ifinfo->link_state;
> > > }
> > >
> > > - if (!need_refresh)
> > > - return;
> > > -
> > > if (iface->running && LINK_STATE_IS_UP(iface->link_state)) {
> > > if (iface->requested_ip.s_addr == INADDR_ANY)
> > > parse_lease(iface, imsg_ifinfo);
> > > @@ -641,6 +622,7 @@ engine_update_iface(struct imsg_ifinfo *
> > > } else
> > > state_transition(iface, IF_DOWN);
> > > }
> > > +
> > > struct dhcpleased_iface*
> > > get_dhcpleased_iface_by_id(uint32_t if_index)
> > > {
> > > Index: frontend.c
>
Re: [patch] dhcpleased(8): No new lease when trunk(4) failover
On Mon, Aug 02, 2021 at 08:28:00PM +0200, Florian Obser wrote:
> On 2021-07-28 23:02 +02, Jesper Wallin wrote:
> > Hi tech@
> >
> > I've setup my machine to use trunk(4) with re(4) and iwm(4) as failover,
> > to make life easier when switching between wired and wireless
> > networking. The wired network at home is on a different subnet from
> > the wireless network, so when I unplug the cable, a DHCP request is
>
> I don't think this is a correct configuration (I accidentally made this
> work in 2019, sorry about that).
> Can't you use
> inet autoconf
> in hostname.re0 *and* hostname.iwm0?
Oh? I've used this configuration for little over 3 years now and I
thought the IP/configuration should be trunk0 based on the examples in
trunk(4) and https://www.openbsd.org/faq/faq6.html#Wireless.
I *could* do it the way you suggest, of course, but I thought this was a
bug/regression, as it worked fine with dhclient(8). In my network
configuration, of separating the wired and wireless network, it wouldn't
be an issue. On networks where the wired and wireless network are on
the same subnet though, it would be a shame to lose the ability to have
it seemlessly jump from one to another without losing any connections.
> > required to get my connection to work again. Before, dhcpleased(8),
> > dhclient(8) handled this as expected.
> >
> > I skimmed through the code to try to understand how dhclient(8) handles
> > this, but I'm not sure I fully understand this. My first take was to
> > change the rtfilter, as I noticed dhclient(8) was listening for way more
> > things. But after some testing I learned that RTM_IFINFO was enough,
> > even if trunk(4) remains "active" and UP when the cable is unplugged.
> >
> > This solution might not be optimal, as I've basically just removed some
> > of the checks in engine_update_iface() that return early if nothing has
> > changed on the interface. At least it solves my issue with trunk(4) and
> > so far I haven't managed to spawn any dragons from this. Though, this
> > might cause engine_update_iface() to fully more often?
> >
> > Thoughts?
> >
> > Index: engine.c
> > ===
> > RCS file: /cvs/src/sbin/dhcpleased/engine.c,v
> > retrieving revision 1.22
> > diff -u -p -r1.22 engine.c
> > --- engine.c26 Jul 2021 09:26:36 - 1.22
> > +++ engine.c28 Jul 2021 20:39:45 -
> > @@ -586,7 +586,6 @@ void
> > engine_update_iface(struct imsg_ifinfo *imsg_ifinfo)
> > {
> > struct dhcpleased_iface *iface;
> > - int need_refresh = 0;
> >
> > iface = get_dhcpleased_iface_by_id(imsg_ifinfo->if_index);
> >
> > @@ -604,32 +603,14 @@ engine_update_iface(struct imsg_ifinfo *
> > memcpy(>hw_address, _ifinfo->hw_address,
> > sizeof(struct ether_addr));
> > LIST_INSERT_HEAD(_interfaces, iface, entries);
> > - need_refresh = 1;
> > } else {
> > - if (memcmp(>hw_address, _ifinfo->hw_address,
> > - sizeof(struct ether_addr)) != 0) {
> > - memcpy(>hw_address, _ifinfo->hw_address,
> > - sizeof(struct ether_addr));
> > - need_refresh = 1;
> > - }
> > - if (imsg_ifinfo->rdomain != iface->rdomain) {
> > - iface->rdomain = imsg_ifinfo->rdomain;
> > - need_refresh = 1;
> > - }
> > - if (imsg_ifinfo->running != iface->running) {
> > - iface->running = imsg_ifinfo->running;
> > - need_refresh = 1;
> > - }
> > -
> > - if (imsg_ifinfo->link_state != iface->link_state) {
> > - iface->link_state = imsg_ifinfo->link_state;
> > - need_refresh = 1;
> > - }
> > + memcpy(>hw_address, _ifinfo->hw_address,
> > + sizeof(struct ether_addr));
> > + iface->rdomain = imsg_ifinfo->rdomain;
> > + iface->running = imsg_ifinfo->running;
> > + iface->link_state = imsg_ifinfo->link_state;
> > }
> >
> > - if (!need_refresh)
> > - return;
> > -
> > if (iface->running && LINK_STATE_IS_UP(iface->link_state)) {
> > if (iface->requested_ip.s_addr == INADDR_ANY)
> > parse_lease(iface, imsg_ifinfo);
> > @@ -641,6 +622,7 @@ engine_update_iface(struct imsg_ifinfo *
> > } else
> > state_transition(iface, IF_DOWN);
> > }
> > +
> > struct dhcpleased_iface*
> > get_dhcpleased_iface_by_id(uint32_t if_index)
> > {
> > Index: frontend.c
> > ===
> > RCS file: /cvs/src/sbin/dhcpleased/frontend.c,v
> > retrieving revision 1.15
> > diff -u -p -r1.15 frontend.c
> > --- frontend.c 27 Jul 2021 18:17:37 - 1.15
> > +++ frontend.c 28 Jul 2021 20:39:45 -
> > @@ -605,11 +605,9 @@ update_iface(struct if_msghdr
Re: [patch] dhcpleased(8): No new lease when trunk(4) failover
On 2021-07-28 23:02 +02, Jesper Wallin wrote:
> Hi tech@
>
> I've setup my machine to use trunk(4) with re(4) and iwm(4) as failover,
> to make life easier when switching between wired and wireless
> networking. The wired network at home is on a different subnet from
> the wireless network, so when I unplug the cable, a DHCP request is
I don't think this is a correct configuration (I accidentally made this
work in 2019, sorry about that).
Can't you use
inet autoconf
in hostname.re0 *and* hostname.iwm0?
> required to get my connection to work again. Before, dhcpleased(8),
> dhclient(8) handled this as expected.
>
> I skimmed through the code to try to understand how dhclient(8) handles
> this, but I'm not sure I fully understand this. My first take was to
> change the rtfilter, as I noticed dhclient(8) was listening for way more
> things. But after some testing I learned that RTM_IFINFO was enough,
> even if trunk(4) remains "active" and UP when the cable is unplugged.
>
> This solution might not be optimal, as I've basically just removed some
> of the checks in engine_update_iface() that return early if nothing has
> changed on the interface. At least it solves my issue with trunk(4) and
> so far I haven't managed to spawn any dragons from this. Though, this
> might cause engine_update_iface() to fully more often?
>
> Thoughts?
>
> Index: engine.c
> ===
> RCS file: /cvs/src/sbin/dhcpleased/engine.c,v
> retrieving revision 1.22
> diff -u -p -r1.22 engine.c
> --- engine.c 26 Jul 2021 09:26:36 - 1.22
> +++ engine.c 28 Jul 2021 20:39:45 -
> @@ -586,7 +586,6 @@ void
> engine_update_iface(struct imsg_ifinfo *imsg_ifinfo)
> {
> struct dhcpleased_iface *iface;
> - int need_refresh = 0;
>
> iface = get_dhcpleased_iface_by_id(imsg_ifinfo->if_index);
>
> @@ -604,32 +603,14 @@ engine_update_iface(struct imsg_ifinfo *
> memcpy(>hw_address, _ifinfo->hw_address,
> sizeof(struct ether_addr));
> LIST_INSERT_HEAD(_interfaces, iface, entries);
> - need_refresh = 1;
> } else {
> - if (memcmp(>hw_address, _ifinfo->hw_address,
> - sizeof(struct ether_addr)) != 0) {
> - memcpy(>hw_address, _ifinfo->hw_address,
> - sizeof(struct ether_addr));
> - need_refresh = 1;
> - }
> - if (imsg_ifinfo->rdomain != iface->rdomain) {
> - iface->rdomain = imsg_ifinfo->rdomain;
> - need_refresh = 1;
> - }
> - if (imsg_ifinfo->running != iface->running) {
> - iface->running = imsg_ifinfo->running;
> - need_refresh = 1;
> - }
> -
> - if (imsg_ifinfo->link_state != iface->link_state) {
> - iface->link_state = imsg_ifinfo->link_state;
> - need_refresh = 1;
> - }
> + memcpy(>hw_address, _ifinfo->hw_address,
> + sizeof(struct ether_addr));
> + iface->rdomain = imsg_ifinfo->rdomain;
> + iface->running = imsg_ifinfo->running;
> + iface->link_state = imsg_ifinfo->link_state;
> }
>
> - if (!need_refresh)
> - return;
> -
> if (iface->running && LINK_STATE_IS_UP(iface->link_state)) {
> if (iface->requested_ip.s_addr == INADDR_ANY)
> parse_lease(iface, imsg_ifinfo);
> @@ -641,6 +622,7 @@ engine_update_iface(struct imsg_ifinfo *
> } else
> state_transition(iface, IF_DOWN);
> }
> +
> struct dhcpleased_iface*
> get_dhcpleased_iface_by_id(uint32_t if_index)
> {
> Index: frontend.c
> ===
> RCS file: /cvs/src/sbin/dhcpleased/frontend.c,v
> retrieving revision 1.15
> diff -u -p -r1.15 frontend.c
> --- frontend.c27 Jul 2021 18:17:37 - 1.15
> +++ frontend.c28 Jul 2021 20:39:45 -
> @@ -605,11 +605,9 @@ update_iface(struct if_msghdr *ifm, stru
> }
> }
>
> - if (memcmp(>ifinfo, , sizeof(iface->ifinfo)) != 0) {
> - memcpy(>ifinfo, , sizeof(iface->ifinfo));
> - frontend_imsg_compose_main(IMSG_UPDATE_IF, 0, >ifinfo,
> - sizeof(iface->ifinfo));
> - }
> + memcpy(>ifinfo, , sizeof(iface->ifinfo));
> + frontend_imsg_compose_main(IMSG_UPDATE_IF, 0, >ifinfo,
> + sizeof(iface->ifinfo));
> }
>
> void
>
--
I'm not entirely sure you are real.
date -j and seconds since the Epoch
Hi, Bryan Vyhmeister found a strange behavior in date(1): # date -f %s -j 1627519989 Thu Jul 29 01:53:09 PDT 2021 # date -u -f %s -j 1627519989 Thu Jul 29 00:53:09 UTC 2021 Looks like PDT is GMT-1, which of course is wrong. The problem arises from the -f option. The argument of date(1) is passed to strptime(3). Normally, this will return a broken down time in the local timezone. But the '%s' format makes an exception and returns a date in UTC. The patch below isn't very beautiful, but fixes the problem: # date -f %s -j 1627519989 Wed Jul 28 17:53:09 PDT 2021 Gerhard Index: bin/date/date.c === RCS file: /cvs/src/bin/date/date.c,v retrieving revision 1.56 diff -u -p -r1.56 date.c --- bin/date/date.c 8 Aug 2019 02:17:51 - 1.56 +++ bin/date/date.c 2 Aug 2021 07:56:15 - @@ -219,7 +219,11 @@ setthetime(char *p, const char *pformat) } /* convert broken-down time to UTC clock time */ - if ((tval = mktime(lt)) == -1) + if (pformat && strcmp(pformat, "%s") == 0) + tval = timegm(lt); + else + tval = mktime(lt); + if (tval == -1) errx(1, "specified date is outside allowed range"); if (jflag)
Re: Do not spin on the NET_LOCK() in kqueue
On 29/07/21(Thu) 15:36, Alexander Bluhm wrote: > > > New diff fixing a locking dance pointed out by visa@. > > Not tested this one yet. But here is a combination of all the > others. > > http://bluhm.genua.de/perform/results/2021-07-27T07:41:29Z/perform.html Thanks for testing. These tests show that the contention is moving around. But as it is now there is no visible effect on having solock-free kqueue filters. So I'm retracting this diff for now as it only postpones what we are about: remove the KERNEL_LOCK() from sowakeup().
