Re: pipex(4): kill pipexintr()
On Mon, 3 Aug 2020 23:36:09 +0300
Vitaliy Makkoveev wrote:
> On Tue, Aug 04, 2020 at 01:26:14AM +0900, YASUOKA Masahiko wrote:
>> Comments?
>
> You introduce `cookie' as
>
> cookie = session->protocol << 16 | session->session_id;
>
> also multicast sessions initialized as
>
> session->protocol = PIPEX_PROTO_NONE;
> session->session_id = ifindex;
>
> `protocol' and `session_id' come from userland, so I like to have checks
> like below. It's allow us to avoid `cookie' be broken while
> `pr_session_id' exceeds 16 bit integer. Also userland should not pass
> PIPEX_PROTO_NONE as `pr_protocol' because we shouldn't have multicast
> and not multicast sessions with the same `cookie'.
>
> cut begin
>
> pipex_init_session(struct pipex_session **rsession,
> struct pipex_session_req *req)
> {
> if (req->pr_protocol == PIPEX_PROTO_NONE)
> return (EINVAL);
pipex_init_session() has the same check already.
287 int
288 pipex_init_session(struct pipex_session **rsession,
289 struct pipex_session_req *req)
290 {
(snip)
297 switch (req->pr_protocol) {
298 #ifdef PIPEX_PPPOE
299 case PIPEX_PROTO_PPPOE:
(snip)
333 default:
334 return (EPROTONOSUPPORT);
335 }
>
> if (req->pr_session_id > 0x)
> return (EINVAL);
>
> cut end
req->pr_session_id can't be > 0x since it's uint16_t.
> Also cookies introduce invalidation problem. Yes, it has low
> probability, but we can have operation order like below:
>
> 1. enqueue session with `protocol' = 0xaa and `session_id' = 0xbb, and
> `cookie' = 0xaabb
> 2. kill this session
> 3. create new session `protocol' = 0xaa and `session_id' = 0xbb
> 4. this newly created session will be used by pipexintr()
>
> As I have seen while played with refcounters, session can be enqueued
> more than 10 times...
The diff makes the problem worse, but it could happen already if the
session-id is reused.
> Also It's not obvious that interface index will never exceed 16 bit
> counter. It's unsigned int and may be underlay counter's resolution
> will be expanded in future. So I like to have at least corresponding
> assertion in pipex_iface_init().
Right. This is fixable with another unique number.
> So, may be my first solution is the best here. And, as mpi@ pointed,
> ipsec(4) should be reworked to allow parallelism.
Does first mean killing the pipexintr?
What I explained was wrong. I'm sorry about this.
On Fri, 31 Jul 2020 09:36:32 +0900 (JST)
YASUOKA Masahiko wrote:
> A packet of L2TP/IPsec (encapsulated IP/PPP/L2TP/UDP/ESP/UDP/IP) is
> processed like:
>
>ipv4_input
> ...
>udp_input
> ipsec_common_input
> esp_input
>crypto_dispatch
> => crypto_taskq_mp_safe
>
>kthread "crynlk"
> crypto_invoke
>... (*1)
> crypto_done
> esp_input_cb
>ipsec_common_input_cb
> ip_deliver
>udp_input
> pipex_l2tp_input
>pipex_common_input
> (*2)
> pipex_ppp_input
>pipex_mppe_input (*3)
> pipex_ppp_input
>pipex_ip_input
> ipv4_input
>...
This should be
kthread "crynlk"
crypto_invoke
... (*1)
crypto_done
kthread "crypto" < another thread
ipsec_input_cb < this is missed
esp_input_cb
ipsec_common_input_cb
ip_deliver
udp_input
pipex_l2tp_input
pipex_common_input
(*2)
pipex_ppp_input
pipex_mppe_input (*3)
pipex_ppp_input
pipex_ip_input
ipv4_input
...
> At *2 there was a queue. "crynlk" is a busy thread, since it is doing
> decryption at *1. I think it's better pipex input is be done by
> another thread than crypto since it also has decryption at *3.
This is false. *3 is done by another thread.
It is the same if crypto driver is not CRYPTOCAP_F_MPSAFE.
(crypto_invoke() is done by the caller's thread and the callback
(ipsec_input_cb) is called by"crypto" thread.)
So I have no actual reason to keep the queues.
ok yasuoka for the diff which kills pipexintr.
Re: pipex(4): kill pipexintr()
On Tue, Aug 04, 2020 at 01:26:14AM +0900, YASUOKA Masahiko wrote:
> On Sat, 1 Aug 2020 18:52:27 +0300
> Vitaliy Makkoveev wrote:
> > On Sat, Aug 01, 2020 at 07:44:17PM +0900, YASUOKA Masahiko wrote:
> >> I'm not sure when it is broken, in old versions, it was assumed the
> >> pipex queues are empty when pipex_iface_stop() is called. The problem
> >> mvs@ found is the assumption is not true any more.
> >>
> >> pipex has a mechanism that delete a session when the queues are empty.
> >>
> >> 819 Static void
> >> 820 pipex_timer(void *ignored_arg)
> >> 821 {
> >> (snip)
> >> 854 case PIPEX_STATE_CLOSED:
> >> 855 /*
> >> 856 * mbuf queued in pipexinq or pipexoutq
> >> may have a
> >> 857 * refererce to this session.
> >> 858 */
> >> 859 if (!mq_empty() ||
> >> !mq_empty())
> >> 860 continue;
> >> 861
> >> 862 pipex_destroy_session(session);
> >> 863 break;
> >>
> >> I think using this is better.
> >>
> >> How about this?
> >
> > Unfortunately your diff is incorrect. It introduces memory leaks and
> > breaks pppx(4). Also it is incomplete.
>
> Thank you for your feedbacks.
>
> > We have multiple ways to kill pipex(sessions):
> >
> > 1. pppx(4)
> >
> > We have `struct pppx_if' which has pointer to corresponding session and
> > this session is accessed directly within pppx(4) layer. Since we can't
> > destroy `ppp_if' in pipex(4) layer we can't destroy these sessions by
> > pipex_timer(). The only way to destroy them is pppx_if_destroy() which:
> >
> > 1. unlink session by pipex_unlink_session()
> > 2. detach corresponding `ifnet' by if_detach()
> > 3. release session by pipex_rele_session()
> >
> > It's unsafe because mbuf queues can have references to this session.
>
> Yes.
>
> > 2. pppac(4)
> >
> > We have no direct access to corresponding sessions within pppac(4)
> > layer. Also there are multiple ways to do this:
> >
> > 1. pipex_ioctl() with `PIPEXSMODE' command. Underlay pipex_iface_stop()
> > walks through `pipex_session_list' and destroy sessions by
> > pipex_destroy_session() call. It's unsafe because we don't check queues.
> >
> > 2. pipex_ioctl() with `PIPEXDSESSION'. pipex_close_session() will change
> > session's state and pipex_timer() will kill this sessions later. This
> > is the only safe way.
> >
> > 3. pipex_iface_fini(). The same as `PIPEXSMODE', pipex_iface_stop()
> > kills sessions, Which is also unsafe. Also we have another use after
> > free issue:
> >
> > cut begin
> >
> > pipex_iface_fini(struct pipex_iface_context *pipex_iface)
> > {
> > pool_put(_session_pool, pipex_iface->multicast_session);
> > NET_LOCK();
> > pipex_iface_stop(pipex_iface);
> > NET_UNLOCK();
> > }
> >
> > cut end
> >
> > `multicast_session' should be protected too. It also can be pushed to
> > `pipexoutq'.
>
> Yes, I missed this point.
>
> > Also since this time pipexintr() and pipex_iface_fini() are
> > both serialized by KERNEL_LOCK() too we can't destroy `multicast_session'
> > which is in use by pipexintr(). But when we will drop KERNEL_LOCK()
> > around pipexintr() we can catch use after free issue here. I already did
> > diff for move this pool_put() under NET_LOCK(), but it was rejectedi by
> > mpi@ because:
> >
> > cut begin
> > pipex_iface_fini() should be called on the last reference of the
> >
> > descriptor. So this shouldn't be necessary. If there's an issue
> >
> > with the current order of the operations, we should certainly fix
> >
> > it differently.
> > cut end
>
> Yes, I understand what mpi@ is saying. But this is a separate story.
>
> > So I repeat it again: npppd(8) can be killed in every moment by SIGKILL
> > or by SIGSEGV and pppacclose() will be called and it will call
> > pipex_iface_fini(). `multicast_session' can be used in this moment by
> > pipexintr().
> >
> > And no locks protect `multicast_session' itself.
> >
> > The two diffs I proposed in this thread solve problems caused by
> > pipexintr().
>
> There are a lot of ways to solve the problems.
>
> The diff I sent few days ago is to destruct the pipex sessions in the
> pipex timer. As you pointed out it has some problems. Those problems
> can be fixed, but I'd suggest another way. I attached at last.
>
> The problem exposed is "use-after-free". Since I think this is not a
> problem of parallel processing, having reference counter seems too
> much for me.
This is object life time problem and it isn't MP specific. Since we do
all operations under lock we can avoid atomic operations for counter
modifications. Also we will introduce these counters just before
introduce fine grained locks for pipex(4)
Re: use runtime clock for ktime in drm
On Mon, Aug 03, 2020 at 07:16:46PM +1000, Jonathan Gray wrote:
> Scott mentioned that ktime should be using a runtime clock which stops
> during suspend. The exception to this is ktime_get_bootime() which does
> not stop when suspended.
>
> This is described in
> https://www.kernel.org/doc/html/latest/core-api/timekeeping.html
>
> There was perhaps some confusion as CLOCK_MONOTONIC does not count
> time suspended on linux but does for us.
I'm concerned that this will create a clock mismatch in some of the
drivers.
My incomplete understanding of the situation is that parts of recent
graphics drivers are now implemented in userspace. For instance, in
xenocara/lib I see that mesa and libdrm both use clock_gettime(2).
The code in question does not look like test code.
So, if userspace is using CLOCK_MONOTONIC and the kernel is using
nanoruntime(9), the clocks are no longer the same and their timestamps
are no longer comparable. Then, if userspace is looking at kernel
timestamps, or vice versa, I would expect strange side effects. You
probably wouldn't see them until after the first suspend/resume on a
given machine.
Is that possible?
If so, a full switch to the runtime clock would require corresponding
changes in userspace. Probably switching to CLOCK_UPTIME in the right
spots.
> Index: include/linux/ktime.h
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/include/linux/ktime.h,v
> retrieving revision 1.5
> diff -u -p -r1.5 ktime.h
> --- include/linux/ktime.h 29 Jul 2020 09:52:21 - 1.5
> +++ include/linux/ktime.h 3 Aug 2020 08:26:55 -
> @@ -28,7 +28,7 @@ static inline ktime_t
> ktime_get(void)
> {
> struct timespec ts;
> - nanouptime();
> + nanoruntime();
> return TIMESPEC_TO_NSEC();
> }
>
> @@ -36,7 +36,7 @@ static inline ktime_t
> ktime_get_raw(void)
> {
> struct timespec ts;
> - nanouptime();
> + nanoruntime();
> return TIMESPEC_TO_NSEC();
> }
>
> Index: include/linux/timekeeping.h
> ===
> RCS file: /cvs/src/sys/dev/pci/drm/include/linux/timekeeping.h,v
> retrieving revision 1.8
> diff -u -p -r1.8 timekeeping.h
> --- include/linux/timekeeping.h 29 Jul 2020 09:52:21 - 1.8
> +++ include/linux/timekeeping.h 3 Aug 2020 08:28:30 -
> @@ -3,7 +3,6 @@
> #ifndef _LINUX_TIMEKEEPING_H
> #define _LINUX_TIMEKEEPING_H
>
> -#define ktime_get_boottime() ktime_get()
> #define get_seconds()gettime()
>
> static inline time_t
> @@ -24,6 +23,14 @@ static inline uint64_t
> ktime_get_ns(void)
> {
> return ktime_get();
> +}
> +
> +static inline ktime_t
> +ktime_get_boottime(void)
> +{
> + struct timespec ts;
> + nanouptime();
> + return TIMESPEC_TO_NSEC();
> }
>
> #endif
>
Re: Improve ure(4) performance
On Mon, Aug 03, 2020 at 09:07:39AM -0700, Jonathon Fletcher wrote: > > Assuming no issues with this, I would like to get it into the tree. This > patch predates Marcus' usbd_abort_pipe patch by a few weeks. Let me know > if you want an updated patch against HEAD after his patch. > > After reports from multiple people, this patch improves tx performance on > ure from about 90-110MBps to between about 250MBps (Mikolaj), 290MBps > (Joshua), > 550MBps (me), 1900MBps (Kevin), depending on ure device, network setup, and > underlying hardware. > No issues on my end. All works really nice. I managed to have couple of Zoom calls on ure(4) and card didn't crash like before Jonathon's diff. I've also updated the tree with the diff after usbd_abort_pipe commit from mglocker@ and so far I don't see any issues. Network card seems stable. At the time of the writing machine has 21 hours of uptime. -- Regards, Mikolaj
Add Gear Head keyboard usbdev
Hi,
I noticed the kernel was just printing out the generic hex device id
rather than the name of my keyboard so I did some checking and
there is a vendor id for "Gear Head" keyboards. These keyboards are
sometimes resold under different names like Octogen or Sanoxy, but
they are rebranded Gear Head keyboards.
Attached is a diff that identifies them as such. I got the usb id
info from http://www.linux-usb.org/usb.ids
Output of usbdevs -v for the aforementioned device on kernel
without patch:
addr 04: 0b38:0010 vendor 0x0b38, product 0x0010
low speed, power 100 mA, config 1, rev 1.02
driver: uhidev2
driver: uhidev3
Same output on kernel as per diff below:
addr 04: 0b38:0010 Gear Head, 107-Key Keyboard
low speed, power 100 mA, config 1, rev 1.02
driver: uhidev2
driver: uhidev3
Hope the naming scheme is OK, I can change it if needed.
Thanks,
Tom
Index: sys/dev/usb/usbdevs
===
RCS file: /cvs/src/sys/dev/usb/usbdevs,v
retrieving revision 1.719
diff -u -p -r1.719 usbdevs
--- sys/dev/usb/usbdevs 22 Jul 2020 11:12:40 - 1.719
+++ sys/dev/usb/usbdevs 3 Aug 2020 14:08:51 -
@@ -406,6 +406,7 @@ vendor NEODIO 0x0aec Neodio
vendor OPTION 0x0af0 Option
vendor ASUS0x0b05 ASUS
vendor TODOS 0x0b0c Todos Data System
+vendor GEARHEAD0x0b38 Gear Head
vendor OCT 0x0b39 Omnidirectional Control Technology
vendor TEKRAM 0x0b3b Tekram Technology
vendor HAL 0x0b41 HAL Corporation
@@ -2054,6 +2055,10 @@ product GARMIN GPSMAP62S 0x2459 GPSmap 6
/* GCT Semiconductor products */
product GCTSEMICON INSTALL 0x7f40 GDM720x MASS storage mode
+
+/* Gear Head products */
+product GEARHEAD GHKB 0x0003 Gear Head Keyboard
+product GEARHEAD GHKB107 0x0010 Gear Head 107-Key Keyboard
/* GEMPLUS products */
product GEMPLUS PROXPU 0x5501 Prox-PU/CU
Index: sys/dev/usb/usbdevs.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs.h,v
retrieving revision 1.731
diff -u -p -r1.731 usbdevs.h
--- sys/dev/usb/usbdevs.h 22 Jul 2020 11:13:20 - 1.731
+++ sys/dev/usb/usbdevs.h 3 Aug 2020 14:08:51 -
@@ -413,6 +413,7 @@
#defineUSB_VENDOR_OPTION 0x0af0 /* Option */
#defineUSB_VENDOR_ASUS 0x0b05 /* ASUS */
#defineUSB_VENDOR_TODOS0x0b0c /* Todos Data System */
+#define USB_VENDOR_GEARHEAD0x0b38 /* Gear Head */
#defineUSB_VENDOR_OCT 0x0b39 /* Omnidirectional Control
Technology */
#defineUSB_VENDOR_TEKRAM 0x0b3b /* Tekram Technology */
#defineUSB_VENDOR_HAL 0x0b41 /* HAL Corporation */
@@ -2061,6 +2062,10 @@
/* GCT Semiconductor products */
#defineUSB_PRODUCT_GCTSEMICON_INSTALL 0x7f40 /* GDM720x MASS
storage mode */
+
+/* Gear Head products */
+#define USB_PRODUCT_GEARHEAD_GHKB 0x0003 /* Gear Head Keyboard */
+#define USB_PRODUCT_GEARHEAD_GHKB107 0x0010 /* Gear Head 107-key
Keyboard */
/* GEMPLUS products */
#defineUSB_PRODUCT_GEMPLUS_PROXPU 0x5501 /* Prox-PU/CU */
Index: sys/dev/usb/usbdevs_data.h
===
RCS file: /cvs/src/sys/dev/usb/usbdevs_data.h,v
retrieving revision 1.725
diff -u -p -r1.725 usbdevs_data.h
--- sys/dev/usb/usbdevs_data.h 22 Jul 2020 11:13:20 - 1.725
+++ sys/dev/usb/usbdevs_data.h 3 Aug 2020 14:08:51 -
@@ -4210,6 +4210,14 @@ const struct usb_known_product usb_known
"GDM720x MASS storage mode",
},
{
+ USB_VENDOR_GEARHEAD, USB_PRODUCT_GEARHEAD_GHKB,
+ "Keyboard",
+ },
+ {
+ USB_VENDOR_GEARHEAD, USB_PRODUCT_GEARHEAD_GHKB107,
+ "107-Key Keyboard",
+ },
+ {
USB_VENDOR_GEMPLUS, USB_PRODUCT_GEMPLUS_PROXPU,
"Prox-PU/CU",
},
@@ -14280,6 +14288,10 @@ const struct usb_known_vendor usb_known_
{
USB_VENDOR_HP2,
"Hewlett Packard",
+ },
+ {
+ USB_VENDOR_GEARHEAD,
+ "Gear Head",
},
{ 0, NULL }
};
Re: pipex(4): kill pipexintr()
On Sat, 1 Aug 2020 18:52:27 +0300
Vitaliy Makkoveev wrote:
> On Sat, Aug 01, 2020 at 07:44:17PM +0900, YASUOKA Masahiko wrote:
>> I'm not sure when it is broken, in old versions, it was assumed the
>> pipex queues are empty when pipex_iface_stop() is called. The problem
>> mvs@ found is the assumption is not true any more.
>>
>> pipex has a mechanism that delete a session when the queues are empty.
>>
>> 819 Static void
>> 820 pipex_timer(void *ignored_arg)
>> 821 {
>> (snip)
>> 854 case PIPEX_STATE_CLOSED:
>> 855 /*
>> 856 * mbuf queued in pipexinq or pipexoutq may
>> have a
>> 857 * refererce to this session.
>> 858 */
>> 859 if (!mq_empty() ||
>> !mq_empty())
>> 860 continue;
>> 861
>> 862 pipex_destroy_session(session);
>> 863 break;
>>
>> I think using this is better.
>>
>> How about this?
>
> Unfortunately your diff is incorrect. It introduces memory leaks and
> breaks pppx(4). Also it is incomplete.
Thank you for your feedbacks.
> We have multiple ways to kill pipex(sessions):
>
> 1. pppx(4)
>
> We have `struct pppx_if' which has pointer to corresponding session and
> this session is accessed directly within pppx(4) layer. Since we can't
> destroy `ppp_if' in pipex(4) layer we can't destroy these sessions by
> pipex_timer(). The only way to destroy them is pppx_if_destroy() which:
>
> 1. unlink session by pipex_unlink_session()
> 2. detach corresponding `ifnet' by if_detach()
> 3. release session by pipex_rele_session()
>
> It's unsafe because mbuf queues can have references to this session.
Yes.
> 2. pppac(4)
>
> We have no direct access to corresponding sessions within pppac(4)
> layer. Also there are multiple ways to do this:
>
> 1. pipex_ioctl() with `PIPEXSMODE' command. Underlay pipex_iface_stop()
> walks through `pipex_session_list' and destroy sessions by
> pipex_destroy_session() call. It's unsafe because we don't check queues.
>
> 2. pipex_ioctl() with `PIPEXDSESSION'. pipex_close_session() will change
> session's state and pipex_timer() will kill this sessions later. This
> is the only safe way.
>
> 3. pipex_iface_fini(). The same as `PIPEXSMODE', pipex_iface_stop()
> kills sessions, Which is also unsafe. Also we have another use after
> free issue:
>
> cut begin
>
> pipex_iface_fini(struct pipex_iface_context *pipex_iface)
> {
> pool_put(_session_pool, pipex_iface->multicast_session);
> NET_LOCK();
> pipex_iface_stop(pipex_iface);
> NET_UNLOCK();
> }
>
> cut end
>
> `multicast_session' should be protected too. It also can be pushed to
> `pipexoutq'.
Yes, I missed this point.
> Also since this time pipexintr() and pipex_iface_fini() are
> both serialized by KERNEL_LOCK() too we can't destroy `multicast_session'
> which is in use by pipexintr(). But when we will drop KERNEL_LOCK()
> around pipexintr() we can catch use after free issue here. I already did
> diff for move this pool_put() under NET_LOCK(), but it was rejectedi by
> mpi@ because:
>
> cut begin
> pipex_iface_fini() should be called on the last reference of the
>
> descriptor. So this shouldn't be necessary. If there's an issue
>
> with the current order of the operations, we should certainly fix
>
> it differently.
> cut end
Yes, I understand what mpi@ is saying. But this is a separate story.
> So I repeat it again: npppd(8) can be killed in every moment by SIGKILL
> or by SIGSEGV and pppacclose() will be called and it will call
> pipex_iface_fini(). `multicast_session' can be used in this moment by
> pipexintr().
>
> And no locks protect `multicast_session' itself.
>
> The two diffs I proposed in this thread solve problems caused by
> pipexintr().
There are a lot of ways to solve the problems.
The diff I sent few days ago is to destruct the pipex sessions in the
pipex timer. As you pointed out it has some problems. Those problems
can be fixed, but I'd suggest another way. I attached at last.
The problem exposed is "use-after-free". Since I think this is not a
problem of parallel processing, having reference counter seems too
much for me.
The diff is not to refer the session by a pointer, but by the id.
The idea is come from IPsec tdb.
Comments?
diff --git a/sys/net/pipex.c b/sys/net/pipex.c
index 2ad7757fee9..5f24381878c 100644
--- a/sys/net/pipex.c
+++ b/sys/net/pipex.c
@@ -148,6 +148,7 @@ void
pipex_iface_init(struct pipex_iface_context *pipex_iface, u_int ifindex)
{
struct pipex_session *session;
+ struct pipex_hash_head *chain;
pipex_iface->pipexmode = 0;
pipex_iface->ifindex = ifindex;
@@ -168,7 +169,12 @@ pipex_iface_init(struct
Re: Improve ure(4) performance
On Thu, Jul 30, 2020 at 06:56:48PM +, Mikolaj Kucharski wrote:
> On Thu, Jul 30, 2020 at 07:58:23AM -0700, Jonathon Fletcher wrote:
> >
> > Mikolaj,
> >
> > I hope the patch has been stable for you. I do have an update - it appears
> > that a splx(s) got lost along the way (from the end of ure_txeof). This
> > patch adds that back in and has some minor cleanup (variable name, cleanup
> > defines, adjust the setting of flags and buffer sizes based on device type).
> > I have been running this for a couple of days now.
>
> Yes, no issues so far. I managed to have on Google Meet call, audio only
> and one Zoom call (was surprised it actually worked on OpenBSD, but
> needed to fake user agent to Linux). Network card didn't fail like
> before your diff during VoIP calls. That's really great. I just compiled
> new version of the kernel with your below patch, will reboot my laptop
> tonight to switch to that new kernel. Thank you!
Assuming no issues with this, I would like to get it into the tree. This
patch predates Marcus' usbd_abort_pipe patch by a few weeks. Let me know
if you want an updated patch against HEAD after his patch.
After reports from multiple people, this patch improves tx performance on
ure from about 90-110MBps to between about 250MBps (Mikolaj), 290MBps (Joshua),
550MBps (me), 1900MBps (Kevin), depending on ure device, network setup, and
underlying hardware.
Thanks,
Jonathon
> >
> > Index: sys/dev/usb/if_urereg.h
> > ===
> > RCS file: /cvs/src/sys/dev/usb/if_urereg.h,v
> > retrieving revision 1.8
> > diff -u -p -u -r1.8 if_urereg.h
> > --- sys/dev/usb/if_urereg.h 7 Dec 2019 08:45:28 - 1.8
> > +++ sys/dev/usb/if_urereg.h 28 Jul 2020 15:30:41 -
> > @@ -494,28 +494,30 @@ struct ure_txpkt {
> > #define URE_ENDPT_TX 1
> > #define URE_ENDPT_MAX 2
> >
> > -#defineURE_TX_LIST_CNT 8
> > +#defineURE_TX_LIST_CNT 1
> > #defineURE_RX_LIST_CNT 1
> > -#defineURE_RX_BUF_ALIGNsizeof(uint64_t)
> > +#defineURE_TX_BUF_ALIGN4
> > +#defineURE_RX_BUF_ALIGN8
> >
> > -#defineURE_TXBUFSZ 16384
> > -#defineURE_8152_RXBUFSZ16384
> > -#defineURE_8153_RXBUFSZ32768
> > +#defineURE_TX_BUFSZ16384
> > +#defineURE_8152_RX_BUFSZ 16384
> > +#defineURE_8153_RX_BUFSZ 32768
> >
> > struct ure_chain {
> > struct ure_softc*uc_sc;
> > struct usbd_xfer*uc_xfer;
> > char*uc_buf;
> > - struct mbuf *uc_mbuf;
> > - int uc_accum;
> > - int uc_idx;
> > + uint32_tuc_buflen;
> > + uint32_tuc_bufmax;
> > + struct mbuf_listuc_mbuf_list;
> > + SLIST_ENTRY(ure_chain) uc_list;
> > + uint8_t uc_idx;
> > };
> >
> > struct ure_cdata {
> > - struct ure_chaintx_chain[URE_TX_LIST_CNT];
> > - struct ure_chainrx_chain[URE_RX_LIST_CNT];
> > - int tx_prod;
> > - int tx_cnt;
> > + struct ure_chainure_rx_chain[URE_RX_LIST_CNT];
> > + struct ure_chainure_tx_chain[URE_TX_LIST_CNT];
> > + SLIST_HEAD(ure_list_head, ure_chain)ure_tx_free;
> > };
> >
> > struct ure_softc {
> > @@ -541,7 +543,7 @@ struct ure_softc {
> >
> > struct timeval ure_rx_notice;
> > int ure_rxbufsz;
> > - int ure_tx_list_cnt;
> > + int ure_txbufsz;
> >
> > int ure_phyno;
> >
> > Index: sys/dev/usb/if_ure.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/if_ure.c,v
> > retrieving revision 1.16
> > diff -u -p -u -r1.16 if_ure.c
> > --- sys/dev/usb/if_ure.c10 Jul 2020 13:26:41 - 1.16
> > +++ sys/dev/usb/if_ure.c28 Jul 2020 22:56:29 -
> > @@ -117,11 +117,13 @@ void ure_miibus_writereg(struct device
> > void ure_lock_mii(struct ure_softc *);
> > void ure_unlock_mii(struct ure_softc *);
> >
> > -inture_encap(struct ure_softc *, struct mbuf *);
> > +inture_encap_txpkt(struct mbuf *, char *, uint32_t);
> > +inture_encap_xfer(struct ifnet *, struct ure_softc *,
> > struct ure_chain *);
> > void ure_rxeof(struct usbd_xfer *, void *, usbd_status);
> > void ure_txeof(struct usbd_xfer *, void *, usbd_status);
> > -inture_rx_list_init(struct ure_softc *);
> > -inture_tx_list_init(struct ure_softc *);
> > +inture_xfer_list_init(struct ure_softc *, struct ure_chain
> > *,
> > + uint32_t, int);
> > +void ure_xfer_list_free(struct ure_softc *, struct ure_chain
> > *, int);
> >
> > void
Re: [PATCH]: Add a check for upgrade feature to sysupgrade(8)
On Mon, 3 Aug 2020 13:28:38 +0200 Emil Engler : > ## Abstract > This patch adds an argument to sysupgrade(8) which makes it possible > to check if an upgrade is available, similar to "syspatch -c". > This works both, for snapshots and releases. > > ## Usage > Add "-c" to sysupgrade. > If the script exits with a zero, an upgrade is available. If it fails > you are already on the newest version or an upgrade cannot be pulled > for whatever reason. > > ## Motivation > I want a cronjob on my desktop (which is on -current) that checks > regularly if a new snapshot is available and notifies me if this is > the case. syspatch(8) already has such a feature, so why not add > one to sysupgrade? Also it could be useful on -stable and -release > systems. it seems to me you could use this in your crontab sysupgrade -n | grep "Already on last snapshot" || sh send_mail_new_snasphot.sh
Re: softraid/bioctl cant find device /dev/bio
On Mon, Aug 3, 2020 at 11:38 AM Brian Brombacher wrote: > > > > On Aug 3, 2020, at 9:54 AM, sven falempin > wrote: > > > > Hello > > > > I saw a similar issue in the mailing list around decembre 2019, > > following an electrical problem softraid doesn't bring devices ups > > > > > > # ls /dev/sd?? > > /dev/sd0a /dev/sd0g /dev/sd0m /dev/sd1c /dev/sd1i /dev/sd1o /dev/sd2e > > /dev/sd2k > > /dev/sd0b /dev/sd0h /dev/sd0n /dev/sd1d /dev/sd1j /dev/sd1p /dev/sd2f > > /dev/sd2l > > /dev/sd0c /dev/sd0i /dev/sd0o /dev/sd1e /dev/sd1k /dev/sd2a /dev/sd2g > > /dev/sd2m > > /dev/sd0d /dev/sd0j /dev/sd0p /dev/sd1f /dev/sd1l /dev/sd2b /dev/sd2h > > /dev/sd2n > > /dev/sd0e /dev/sd0k /dev/sd1a /dev/sd1g /dev/sd1m /dev/sd2c /dev/sd2i > > /dev/sd2o > > /dev/sd0f /dev/sd0l /dev/sd1b /dev/sd1h /dev/sd1n /dev/sd2d /dev/sd2j > > /dev/sd2p > > # dmesg | grep 6.7 > > OpenBSD 6.7 (RAMDISK_CD) #177: Thu May 7 11:19:02 MDT 2020 > > # dmesg | grep sd > >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > > wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) > > sd0 at scsibus1 targ 0 lun 0: > > t10.ATA_QEMU_HARDDISK_Q > > M5_ > > sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin > > sd1 at scsibus1 targ 1 lun 0: > > t10.ATA_QEMU_HARDDISK_Q > > M7_ > > sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin > > wskbd0 at pckbd0: console keyboard, using wsdisplay1 > > softraid0: trying to bring up sd2 degraded > > softraid0: sd2 was not shutdown properly > > softraid0: sd2 is offline, will not be brought online > > # bioctl -d sd2 > > bioctl: Can't locate sd2 device via /dev/bio > > # > > > > I suspect a missing devices in /dev ( but it seems i have the required > one ) > > and MAKEDEV all of course did a `uid 0 on /: out of inodes` > > > > I have backups but i ' d like to fix the issue ! > > Hi Sven, > > The device sd2 wasn’t attached by softraid, your /dev/bio is fine. This > can happen if softraid fails to find all component disks or the metadata on > one or more components does not match expectations (newer metadata seen on > other disks). Make sure all of the component disks are working. If that > is not the issue, you may need to re-run the command that you used to > create the array and include -C force. Be very careful doing this, I > suggest running the command once without -C force to ensure it found all > the components and fails to bring the array up due to the same error > message you got (attempt to bring up degraded). > > If you’re not careful, you can blow out the whole array. > > -Brian > > > The disk looks fine, the disklabel is ok, the array is just sd0 and sda1 both got the disklabel RAID part, shall i do further checks ? # bioctl -c 1 -l /dev/sd0a,/dev/sd1a softraid0 softraid0: trying to bring up sd2 degraded softraid0: sd2 was not shutdown properly softraid0: sd2 is offline, will not be brought online softraid0: trying to bring up sd2 degraded softraid0: sd2 was not shutdown properly softraid0: sd2 is offline, will not be brought online I wouldnt like to blow the whole array ! sd0a should be in perfect condition but unsure about sd1a, i probably need to bioctl -R sd1 -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Re: softraid/bioctl cant find device /dev/bio
> On Aug 3, 2020, at 9:54 AM, sven falempin wrote: > > Hello > > I saw a similar issue in the mailing list around decembre 2019, > following an electrical problem softraid doesn't bring devices ups > > > # ls /dev/sd?? > /dev/sd0a /dev/sd0g /dev/sd0m /dev/sd1c /dev/sd1i /dev/sd1o /dev/sd2e > /dev/sd2k > /dev/sd0b /dev/sd0h /dev/sd0n /dev/sd1d /dev/sd1j /dev/sd1p /dev/sd2f > /dev/sd2l > /dev/sd0c /dev/sd0i /dev/sd0o /dev/sd1e /dev/sd1k /dev/sd2a /dev/sd2g > /dev/sd2m > /dev/sd0d /dev/sd0j /dev/sd0p /dev/sd1f /dev/sd1l /dev/sd2b /dev/sd2h > /dev/sd2n > /dev/sd0e /dev/sd0k /dev/sd1a /dev/sd1g /dev/sd1m /dev/sd2c /dev/sd2i > /dev/sd2o > /dev/sd0f /dev/sd0l /dev/sd1b /dev/sd1h /dev/sd1n /dev/sd2d /dev/sd2j > /dev/sd2p > # dmesg | grep 6.7 > OpenBSD 6.7 (RAMDISK_CD) #177: Thu May 7 11:19:02 MDT 2020 > # dmesg | grep sd >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) > sd0 at scsibus1 targ 0 lun 0: > t10.ATA_QEMU_HARDDISK_Q > M5_ > sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin > sd1 at scsibus1 targ 1 lun 0: > t10.ATA_QEMU_HARDDISK_Q > M7_ > sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin > wskbd0 at pckbd0: console keyboard, using wsdisplay1 > softraid0: trying to bring up sd2 degraded > softraid0: sd2 was not shutdown properly > softraid0: sd2 is offline, will not be brought online > # bioctl -d sd2 > bioctl: Can't locate sd2 device via /dev/bio > # > > I suspect a missing devices in /dev ( but it seems i have the required one ) > and MAKEDEV all of course did a `uid 0 on /: out of inodes` > > I have backups but i ' d like to fix the issue ! Hi Sven, The device sd2 wasn’t attached by softraid, your /dev/bio is fine. This can happen if softraid fails to find all component disks or the metadata on one or more components does not match expectations (newer metadata seen on other disks). Make sure all of the component disks are working. If that is not the issue, you may need to re-run the command that you used to create the array and include -C force. Be very careful doing this, I suggest running the command once without -C force to ensure it found all the components and fails to bring the array up due to the same error message you got (attempt to bring up degraded). If you’re not careful, you can blow out the whole array. -Brian > > -- > -- > - > Knowing is not enough; we must apply. Willing is not enough; we must do
softraid/bioctl cant find device /dev/bio
Hello I saw a similar issue in the mailing list around decembre 2019, following an electrical problem softraid doesn't bring devices ups # ls /dev/sd?? /dev/sd0a /dev/sd0g /dev/sd0m /dev/sd1c /dev/sd1i /dev/sd1o /dev/sd2e /dev/sd2k /dev/sd0b /dev/sd0h /dev/sd0n /dev/sd1d /dev/sd1j /dev/sd1p /dev/sd2f /dev/sd2l /dev/sd0c /dev/sd0i /dev/sd0o /dev/sd1e /dev/sd1k /dev/sd2a /dev/sd2g /dev/sd2m /dev/sd0d /dev/sd0j /dev/sd0p /dev/sd1f /dev/sd1l /dev/sd2b /dev/sd2h /dev/sd2n /dev/sd0e /dev/sd0k /dev/sd1a /dev/sd1g /dev/sd1m /dev/sd2c /dev/sd2i /dev/sd2o /dev/sd0f /dev/sd0l /dev/sd1b /dev/sd1h /dev/sd1n /dev/sd2d /dev/sd2j /dev/sd2p # dmesg | grep 6.7 OpenBSD 6.7 (RAMDISK_CD) #177: Thu May 7 11:19:02 MDT 2020 # dmesg | grep sd dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) sd0 at scsibus1 targ 0 lun 0: t10.ATA_QEMU_HARDDISK_Q M5_ sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin sd1 at scsibus1 targ 1 lun 0: t10.ATA_QEMU_HARDDISK_Q M7_ sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin wskbd0 at pckbd0: console keyboard, using wsdisplay1 softraid0: trying to bring up sd2 degraded softraid0: sd2 was not shutdown properly softraid0: sd2 is offline, will not be brought online # bioctl -d sd2 bioctl: Can't locate sd2 device via /dev/bio # I suspect a missing devices in /dev ( but it seems i have the required one ) and MAKEDEV all of course did a `uid 0 on /: out of inodes` I have backups but i ' d like to fix the issue ! -- -- - Knowing is not enough; we must apply. Willing is not enough; we must do
Re: [PATCH]: Add a check for upgrade feature to sysupgrade(8)
Indeed, it will still download and install it. It is unsuitable because after the mail was sent it can already be too late and it can take lots of network bandwidth. This can be problematic for various reasons. On 2020-08-03 15:10, Stuart Henderson wrote: > On 2020/08/03 13:50, Solene Rapenne wrote: >> On Mon, 3 Aug 2020 13:28:38 +0200 >> Emil Engler : >> >>> ## Abstract >>> This patch adds an argument to sysupgrade(8) which makes it possible >>> to check if an upgrade is available, similar to "syspatch -c". >>> This works both, for snapshots and releases. >>> >>> ## Usage >>> Add "-c" to sysupgrade. >>> If the script exits with a zero, an upgrade is available. If it fails >>> you are already on the newest version or an upgrade cannot be pulled >>> for whatever reason. >>> >>> ## Motivation >>> I want a cronjob on my desktop (which is on -current) that checks >>> regularly if a new snapshot is available and notifies me if this is >>> the case. syspatch(8) already has such a feature, so why not add >>> one to sysupgrade? Also it could be useful on -stable and -release >>> systems. >> >> it seems to me you could use this in your crontab >> >> sysupgrade -n | grep "Already on last snapshot" || sh >> send_mail_new_snasphot.sh >> > > That won't just check, it will stage the release for install on next boot. >
Re: [PATCH]: Add a check for upgrade feature to sysupgrade(8)
On 2020/08/03 13:50, Solene Rapenne wrote: > On Mon, 3 Aug 2020 13:28:38 +0200 > Emil Engler : > > > ## Abstract > > This patch adds an argument to sysupgrade(8) which makes it possible > > to check if an upgrade is available, similar to "syspatch -c". > > This works both, for snapshots and releases. > > > > ## Usage > > Add "-c" to sysupgrade. > > If the script exits with a zero, an upgrade is available. If it fails > > you are already on the newest version or an upgrade cannot be pulled > > for whatever reason. > > > > ## Motivation > > I want a cronjob on my desktop (which is on -current) that checks > > regularly if a new snapshot is available and notifies me if this is > > the case. syspatch(8) already has such a feature, so why not add > > one to sysupgrade? Also it could be useful on -stable and -release > > systems. > > it seems to me you could use this in your crontab > > sysupgrade -n | grep "Already on last snapshot" || sh > send_mail_new_snasphot.sh > That won't just check, it will stage the release for install on next boot.
[PATCH]: Add a check for upgrade feature to sysupgrade(8)
## Abstract
This patch adds an argument to sysupgrade(8) which makes it possible
to check if an upgrade is available, similar to "syspatch -c".
This works both, for snapshots and releases.
## Usage
Add "-c" to sysupgrade.
If the script exits with a zero, an upgrade is available. If it fails
you are already on the newest version or an upgrade cannot be pulled
for whatever reason.
## Motivation
I want a cronjob on my desktop (which is on -current) that checks
regularly if a new snapshot is available and notifies me if this is
the case. syspatch(8) already has such a feature, so why not add
one to sysupgrade? Also it could be useful on -stable and -release
systems.
## Notes
This was already brought up a year ago by Andrew Klaus, however it
got no feedback at all. Also this diff is a smaller one.
The Message-ID of that patch:
c714aaea-208a-346f-9d83-20e590888fb1
Feedback and thoughts?
Index: usr.sbin/sysupgrade/sysupgrade.8
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.8,v
retrieving revision 1.10
diff -u -p -u -p -r1.10 sysupgrade.8
--- usr.sbin/sysupgrade/sysupgrade.83 Oct 2019 12:43:58 - 1.10
+++ usr.sbin/sysupgrade/sysupgrade.83 Aug 2020 10:44:53 -
@@ -14,7 +14,7 @@
.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\"
-.Dd $Mdocdate: October 3 2019 $
+.Dd $Mdocdate: August 3 2020 $
.Dt SYSUPGRADE 8
.Os
.Sh NAME
@@ -22,7 +22,7 @@
.Nd upgrade system to the next release or a new snapshot
.Sh SYNOPSIS
.Nm
-.Op Fl fkn
+.Op Fl fknc
.Op Fl r | s
.Op Ar installurl
.Sh DESCRIPTION
@@ -60,6 +60,9 @@ By default they will be deleted after th
Fetch and verify the files and create
.Pa /bsd.upgrade
but do not reboot.
+.It Fl c
+Check if there is an upgrade available. It will succeed if a new version
+is available or will fail if not.
.It Fl r
Upgrade to the next release.
This is the default if the system is currently running a release.
Index: usr.sbin/sysupgrade/sysupgrade.sh
===
RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v
retrieving revision 1.39
diff -u -p -u -p -r1.39 sysupgrade.sh
--- usr.sbin/sysupgrade/sysupgrade.sh 4 Jul 2020 18:30:46 - 1.39
+++ usr.sbin/sysupgrade/sysupgrade.sh 3 Aug 2020 10:44:53 -
@@ -34,7 +34,7 @@ ug_err()
usage()
{
- ug_err "usage: ${0##*/} [-fkn] [-r | -s] [installurl]"
+ ug_err "usage: ${0##*/} [-fknc] [-r | -s] [installurl]"
}
unpriv()
@@ -75,12 +75,14 @@ SNAP=false
FORCE=false
KEEP=false
REBOOT=true
+CHECK=false
-while getopts fknrs arg; do
+while getopts fkncrs arg; do
case ${arg} in
f) FORCE=true;;
k) KEEP=true;;
n) REBOOT=false;;
+ c) CHECK=true;;
r) RELEASE=true;;
s) SNAP=true;;
*) usage;;
@@ -146,6 +148,14 @@ rm SHA256.sig
if cmp -s /var/db/installed.SHA256 SHA256 && ! $FORCE; then
echo "Already on latest snapshot."
+ if $CHECK; then
+ exit 1
+ fi
+ exit 0
+fi
+
+if $CHECK; then
+ echo "Upgrade is available"
exit 0
fi
Re: [Patch] Remove unused functions in httpd's proc(?)
Ross L Richardson(open...@rlr.id.au) on 2020.08.03 15:25:05 +1000:
> cppcheck reports that proc_iev and proc_ispeer are unused.
>
> Unless they are wanted for consistency with other versions of proc.c,
> tbey can be removed.
Yes, proc.c should stay the same across
./sbin/iked/proc.c
./usr.sbin/httpd/proc.c
./usr.sbin/relayd/proc.c
./usr.sbin/snmpd/proc.c
./usr.sbin/switchd/proc.c
./usr.sbin/vmd/proc.c
and i would have taken care of doing that with your other diff touching it.
These functions are used elsewhere, so lets keep them.
/Benno
>
> Ross
>
>
> Index: httpd.h
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
> retrieving revision 1.148
> diff -u -p -r1.148 httpd.h
> --- httpd.h 30 Jul 2020 21:06:19 - 1.148
> +++ httpd.h 3 Aug 2020 05:21:39 -
> @@ -803,8 +803,6 @@ intproc_forward_imsg(struct privsep *,
> enum privsep_procid, int);
> struct imsgbuf *
>proc_ibuf(struct privsep *, enum privsep_procid, int);
> -struct imsgev *
> - proc_iev(struct privsep *, enum privsep_procid, int);
> int proc_flush_imsg(struct privsep *, enum privsep_procid, int);
> void imsg_event_add(struct imsgev *);
> int imsg_compose_event(struct imsgev *, uint16_t, uint32_t,
> Index: proc.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/proc.c,v
> retrieving revision 1.38
> diff -u -p -r1.38 proc.c
> --- proc.c9 Sep 2018 21:06:51 - 1.38
> +++ proc.c3 Aug 2020 05:21:39 -
> @@ -43,24 +43,11 @@ void proc_open(struct privsep *, int, i
> void proc_accept(struct privsep *, int, enum privsep_procid,
> unsigned int);
> void proc_close(struct privsep *);
> -int proc_ispeer(struct privsep_proc *, unsigned int, enum privsep_procid);
> void proc_shutdown(struct privsep_proc *);
> void proc_sig_handler(int, short, void *);
> void proc_range(struct privsep *, enum privsep_procid, int *, int *);
> int proc_dispatch_null(int, struct privsep_proc *, struct imsg *);
>
> -int
> -proc_ispeer(struct privsep_proc *procs, unsigned int nproc,
> -enum privsep_procid type)
> -{
> - unsigned inti;
> -
> - for (i = 0; i < nproc; i++)
> - if (procs[i].p_id == type)
> - return (1);
> - return (0);
> -}
> -
> enum privsep_procid
> proc_getid(struct privsep_proc *procs, unsigned int nproc,
> const char *proc_name)
> @@ -819,15 +806,6 @@ proc_ibuf(struct privsep *ps, enum privs
>
> proc_range(ps, id, , );
> return (>ps_ievs[id][n].ibuf);
> -}
> -
> -struct imsgev *
> -proc_iev(struct privsep *ps, enum privsep_procid id, int n)
> -{
> - int m;
> -
> - proc_range(ps, id, , );
> - return (>ps_ievs[id][n]);
> }
>
> /* This function should only be called with care as it breaks async I/O */
>
Re: [Patch] Remove unused functions in httpd[.ch]
ok
Ross L Richardson(open...@rlr.id.au) on 2020.08.03 15:37:50 +1000:
> cppcheck reports that kv_inherit(), kv_log(), and print_time() are unused.
>
> The patch below deletes them.
>
> Ross
> --
>
> Index: httpd.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.c,v
> retrieving revision 1.69
> diff -u -p -r1.69 httpd.c
> --- httpd.c 30 Jul 2020 21:06:19 - 1.69
> +++ httpd.c 3 Aug 2020 05:35:09 -
> @@ -1059,50 +1059,6 @@ kv_free(struct kv *kv)
> }
>
> struct kv *
> -kv_inherit(struct kv *dst, struct kv *src)
> -{
> - memset(dst, 0, sizeof(*dst));
> - memcpy(dst, src, sizeof(*dst));
> - TAILQ_INIT(>kv_children);
> -
> - if (src->kv_key != NULL) {
> - if ((dst->kv_key = strdup(src->kv_key)) == NULL) {
> - kv_free(dst);
> - return (NULL);
> - }
> - }
> - if (src->kv_value != NULL) {
> - if ((dst->kv_value = strdup(src->kv_value)) == NULL) {
> - kv_free(dst);
> - return (NULL);
> - }
> - }
> -
> - return (dst);
> -}
> -
> -int
> -kv_log(struct evbuffer *log, struct kv *kv)
> -{
> - char*msg;
> -
> - if (log == NULL)
> - return (0);
> - if (asprintf(, " [%s%s%s]",
> - kv->kv_key == NULL ? "(unknown)" : kv->kv_key,
> - kv->kv_value == NULL ? "" : ": ",
> - kv->kv_value == NULL ? "" : kv->kv_value) == -1)
> - return (-1);
> - if (evbuffer_add(log, msg, strlen(msg)) == -1) {
> - free(msg);
> - return (-1);
> - }
> - free(msg);
> -
> - return (0);
> -}
> -
> -struct kv *
> kv_find(struct kvtree *keys, struct kv *kv)
> {
> struct kv *match;
> @@ -1270,22 +1226,6 @@ print_host(struct sockaddr_storage *ss,
> buf[0] = '\0';
> return (NULL);
> }
> - return (buf);
> -}
> -
> -const char *
> -print_time(struct timeval *a, struct timeval *b, char *buf, size_t len)
> -{
> - struct timeval tv;
> - unsigned long h, sec, min;
> -
> - timerclear();
> - timersub(a, b, );
> - sec = tv.tv_sec % 60;
> - min = tv.tv_sec / 60 % 60;
> - h = tv.tv_sec / 60 / 60;
> -
> - snprintf(buf, len, "%.2lu:%.2lu:%.2lu", h, min, sec);
> return (buf);
> }
>
> Index: httpd.h
> ===
> RCS file: /cvs/src/usr.sbin/httpd/httpd.h,v
> retrieving revision 1.148
> diff -u -p -r1.148 httpd.h
> --- httpd.h 30 Jul 2020 21:06:19 - 1.148
> +++ httpd.h 3 Aug 2020 05:35:09 -
> @@ -731,8 +731,6 @@ void kv_delete(struct kvtree *, struct
> struct kv*kv_extend(struct kvtree *, struct kv *, char *);
> void kv_purge(struct kvtree *);
> void kv_free(struct kv *);
> -struct kv*kv_inherit(struct kv *, struct kv *);
> -int kv_log(struct evbuffer *, struct kv *);
> struct kv*kv_find(struct kvtree *, struct kv *);
> int kv_cmp(struct kv *, struct kv *);
> struct media_type
> @@ -751,7 +749,6 @@ struct auth *auth_add(struct serverauth
> struct auth *auth_byid(struct serverauth *, uint32_t);
> void auth_free(struct serverauth *, struct auth *);
> const char *print_host(struct sockaddr_storage *, char *, size_t);
> -const char *print_time(struct timeval *, struct timeval *, char *, size_t);
> const char *printb_flags(const uint32_t, const char *);
> void getmonotime(struct timeval *);
>
>
Re: [Patch] Remove redundant condition in httpd's server_http.c
ok
Ross L Richardson(open...@rlr.id.au) on 2020.08.03 15:06:31 +1000:
> cppcheck reports this [and other less simple things].
>
> Ross
>
> Index: server_http.c
> ===
> RCS file: /cvs/src/usr.sbin/httpd/server_http.c,v
> retrieving revision 1.139
> diff -u -p -r1.139 server_http.c
> --- server_http.c 22 May 2020 07:18:17 - 1.139
> +++ server_http.c 3 Aug 2020 05:01:26 -
> @@ -1273,8 +1273,7 @@ server_response(struct httpd *httpd, str
> hostname, FNM_CASEFOLD);
> }
> if (ret == 0 &&
> - (portval == -1 ||
> - (portval != -1 && portval == srv_conf->port))) {
> + (portval == -1 || portval == srv_conf->port)) {
> /* Replace host configuration */
> clt->clt_srv_conf = srv_conf;
> srv_conf = NULL;
>
use runtime clock for ktime in drm
Scott mentioned that ktime should be using a runtime clock which stops
during suspend. The exception to this is ktime_get_bootime() which does
not stop when suspended.
This is described in
https://www.kernel.org/doc/html/latest/core-api/timekeeping.html
There was perhaps some confusion as CLOCK_MONOTONIC does not count
time suspended on linux but does for us.
Index: include/linux/ktime.h
===
RCS file: /cvs/src/sys/dev/pci/drm/include/linux/ktime.h,v
retrieving revision 1.5
diff -u -p -r1.5 ktime.h
--- include/linux/ktime.h 29 Jul 2020 09:52:21 - 1.5
+++ include/linux/ktime.h 3 Aug 2020 08:26:55 -
@@ -28,7 +28,7 @@ static inline ktime_t
ktime_get(void)
{
struct timespec ts;
- nanouptime();
+ nanoruntime();
return TIMESPEC_TO_NSEC();
}
@@ -36,7 +36,7 @@ static inline ktime_t
ktime_get_raw(void)
{
struct timespec ts;
- nanouptime();
+ nanoruntime();
return TIMESPEC_TO_NSEC();
}
Index: include/linux/timekeeping.h
===
RCS file: /cvs/src/sys/dev/pci/drm/include/linux/timekeeping.h,v
retrieving revision 1.8
diff -u -p -r1.8 timekeeping.h
--- include/linux/timekeeping.h 29 Jul 2020 09:52:21 - 1.8
+++ include/linux/timekeeping.h 3 Aug 2020 08:28:30 -
@@ -3,7 +3,6 @@
#ifndef _LINUX_TIMEKEEPING_H
#define _LINUX_TIMEKEEPING_H
-#define ktime_get_boottime() ktime_get()
#define get_seconds() gettime()
static inline time_t
@@ -24,6 +23,14 @@ static inline uint64_t
ktime_get_ns(void)
{
return ktime_get();
+}
+
+static inline ktime_t
+ktime_get_boottime(void)
+{
+ struct timespec ts;
+ nanouptime();
+ return TIMESPEC_TO_NSEC();
}
#endif
