Re: update xf86-video-amdgpu to latest git
On Thu, Jul 08, 2021 at 05:29:01PM +1000, Jonathan Gray wrote: > The latest xf86-video-amdgpu release was in 2019. > > xf86-video-amdgpu-19.1.0..origin/master 8>< snipped just finished rebuilding xenocara build fine booted fine none of my previous issues (see links below) happening yet. -current: kern.version=OpenBSD 6.9-current (GENERIC.MP) #120: Thu Jul 8 23:45:06 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP amdgpu0: PICASSO 10 CU rev 0x01 this were my system issues/reports: https://marc.info/?l=openbsd-misc=161131537616993=2 https://marc.info/?l=openbsd-misc=161736536311231=2 since my last update i have updated the BIOS FW (3.06) rgc
Re: crypto(9): remove unused members from 'cryptocap' structure
On Fri, Jul 09, 2021 at 11:48:42PM +0300, Vitaliy Makkoveev wrote: > Sorry for delay. > > I removed `cc_koperations' and `cc_queued'. > > Do we have interest of statistics provided by cc_operations and cc_bytes > couters? Is it useful? I don't know. But usually when hunting bugs I am happy about any counter the gives me a clue. bluhm
Re: Read/Write whole fusebufs
On 08/06/21(Tue) 23:32, Helg wrote:
> Hello tech@
>
> Due to the challenges of having a large diff reviewed I've had another
> think about how I can break up the FUSE changes so that they are smaller
> and easier to review.
>
> This is the first of these diffs.
>
> The current design uses a fixed size fusebuf that consists of a header
> and a union of structs that are used for different VFS operations. In
> addition, there may be data of variable size associated with an
> operation. e.g. the buffer passed to write(2). see fb_setup(9).
>
> If there is additional data to be exchanged between libfuse and the
> kernel then libfuse uses an ioctl on the device to read or write this
> variable sized data after the fusebuf has been read or written. This is
> not how the fuse protocol works on Linux. Instead, the fusebuf is read
> or written in a single read(2) or write(2). This change is the first
> step in setting the OpenBSD implementation up for improved compatibility
> in the fuse kernel interface.
>
> The fusebuf struct is shared between the kernel and libfuse but its
> layout differs slightly between the two. The kernel has knowledge of the
> size of data that it is sending or receiving (e.g. read, write, readdir,
> link, lookup) and so can malloc the exact amount of memory required.
> libfuse must read the entire fusebuf but doesn't know its size in
> advance so must have a buffer large enough to cater for the worst case
> scenario. Since libfuse now uses a fixed size fusebuf, it no longer
> needs to free the variable memory previously allocated for the data.
>
> stsp@ has been kind enough to provide initial feedback. Is it now ready
> for an official OK?
Please do not use MIN() provided by in userland. The
consensus is to define MINIMUM locally. If you need
please annotate why. You can grep for examples in src/bin...
With that fixed the diff is ok mpi@.
Note that your change is an ABI break, that said the fuse(4) device isn't
standard and I doubt anything use it outside of the base libfuse. So I
don't think any special care is needed. However I don't know if it is
worth mentioning it somehow that people don't end up with a mismatch of
userland/kernel.
> Index: lib/libfuse/fuse.c
> ===
> RCS file: /cvs/src/lib/libfuse/fuse.c,v
> retrieving revision 1.51
> diff -u -p -r1.51 fuse.c
> --- lib/libfuse/fuse.c28 Jun 2019 13:32:42 - 1.51
> +++ lib/libfuse/fuse.c8 Jun 2021 14:15:29 -
> @@ -154,9 +154,9 @@ fuse_loop(struct fuse *fuse)
> {
> struct fusebuf fbuf;
> struct fuse_context ctx;
> - struct fb_ioctl_xch ioexch;
> struct kevent event[5];
> struct kevent ev;
> + ssize_t fbuf_size;
> ssize_t n;
> int ret;
>
> @@ -201,29 +201,15 @@ fuse_loop(struct fuse *fuse)
> strsignal(signum));
> }
> } else if (ret > 0) {
> - n = read(fuse->fc->fd, , sizeof(fbuf));
> - if (n != sizeof(fbuf)) {
> + n = read(fuse->fc->fd, , FUSEBUFSIZE);
> + fbuf_size = sizeof(fbuf.fb_hdr) + sizeof(fbuf.FD) +
> + fbuf.fb_len;
> + if (n != fbuf_size) {
> fprintf(stderr, "%s: bad fusebuf read\n",
> __func__);
> return (-1);
> }
>
> - /* check if there is data something present */
> - if (fbuf.fb_len) {
> - fbuf.fb_dat = malloc(fbuf.fb_len);
> - if (fbuf.fb_dat == NULL)
> - return (-1);
> - ioexch.fbxch_uuid = fbuf.fb_uuid;
> - ioexch.fbxch_len = fbuf.fb_len;
> - ioexch.fbxch_data = fbuf.fb_dat;
> -
> - if (ioctl(fuse->fc->fd, FIOCGETFBDAT,
> - ) == -1) {
> - free(fbuf.fb_dat);
> - return (-1);
> - }
> - }
> -
> ctx.fuse = fuse;
> ctx.uid = fbuf.fb_uid;
> ctx.gid = fbuf.fb_gid;
> @@ -238,26 +224,13 @@ fuse_loop(struct fuse *fuse)
> return (-1);
> }
>
> - n = write(fuse->fc->fd, , sizeof(fbuf));
> - if (fbuf.fb_len) {
> - if (fbuf.fb_dat == NULL) {
> - fprintf(stderr, "%s: fb_dat is Null\n",
> - __func__);
> - return (-1);
> - }
> -
Re: crypto(9): remove unused members from 'cryptocap' structure
On Tue, Jun 29, 2021 at 05:25:41PM +0200, Alexander Bluhm wrote:
> On Fri, Jun 18, 2021 at 11:49:25PM +0300, Vitaliy Makkoveev wrote:
> > I'm lurking in crypto(9) and I found 'cryptocap' structure has unused
> > members. Do we want to keep them or they could gone?
>
> Looks like statistics that are never evluated. We should move, but
> I am not sure about the direction.
>
> What happened to the kstat feature? It is in the tree, but was
> never enabled.
>
> I we revive this, the counters cc_operations and cc_bytes could
> stay there. If not, they are useless and can go away.
>
> cc_koperations and cc_queued are not used at all. OK to remove them.
>
> bluhm
>
Sorry for delay.
I removed `cc_koperations' and `cc_queued'.
Do we have interest of statistics provided by cc_operations and cc_bytes
couters? Is it useful?
> > Index: sys/crypto/crypto.c
> > ===
> > RCS file: /cvs/src/sys/crypto/crypto.c,v
> > retrieving revision 1.82
> > diff -u -p -r1.82 crypto.c
> > --- sys/crypto/crypto.c 30 Mar 2020 17:48:39 - 1.82
> > +++ sys/crypto/crypto.c 18 Jun 2021 20:13:52 -
> > @@ -431,9 +431,6 @@ crypto_invoke(struct cryptop *crp)
> > if (crypto_drivers[hid].cc_process == NULL)
> > goto migrate;
> >
> > - crypto_drivers[hid].cc_operations++;
> > - crypto_drivers[hid].cc_bytes += crp->crp_ilen;
> > -
> > error = crypto_drivers[hid].cc_process(crp);
> > if (error) {
> > if (error == ERESTART) {
> > Index: sys/crypto/cryptodev.h
> > ===
> > RCS file: /cvs/src/sys/crypto/cryptodev.h,v
> > retrieving revision 1.71
> > diff -u -p -r1.71 cryptodev.h
> > --- sys/crypto/cryptodev.h 10 Aug 2017 18:57:20 - 1.71
> > +++ sys/crypto/cryptodev.h 18 Jun 2021 20:13:52 -
> > @@ -195,17 +195,9 @@ struct cryptop {
> >
> > /* Crypto capabilities structure */
> > struct cryptocap {
> > - u_int64_t cc_operations; /* Counter of how many ops done */
> > - u_int64_t cc_bytes; /* Counter of how many bytes done */
> > - u_int64_t cc_koperations; /* How many PK ops done */
> > -
> > u_int32_t cc_sessions;/* How many sessions allocated */
> > -
> > /* Symmetric/hash algorithms supported */
> > int cc_alg[CRYPTO_ALGORITHM_MAX + 1];
> > -
> > - int cc_queued; /* Operations queued */
> > -
> > u_int8_tcc_flags;
> > #define CRYPTOCAP_F_CLEANUP 0x01
> > #define CRYPTOCAP_F_SOFTWARE0x02
>
Re: forwarding in parallel
Hi,
If I understood your diff right, pipex(4) is also affected through:
ip_local()
-> ip_deliver()
-> (*pr_input)()
-> gre_input()
-> gre_input_key()
-> gre_input_1()
-> pipex_pptp_input()
> On 7 Jul 2021, at 00:05, Alexander Bluhm wrote:
>
> Hi,
>
> Thank a lot to Hrvoje Popovski for testing my diff and to sashan@
> and dlg@ for fixing all the fallout in pf and pseudo drivers.
>
> Are there any bugs left? I think everything has been fixed.
>
> To make progress I think it should be commited. Then we get MP
> pressure on the network stack in real live. This allows us to fix
> bugs, optimize, and unlock further.
>
> Performance comarison is here:
> http://bluhm.genua.de/perform/results/2021-07-06T08:17:07Z/perform.html
>
> I think the spreading of the results comes from the kernel lock
> around arp and neighbor discovery. These should be relaxed carefully
> later.
>
> Here you see that the CPUs are much more busy during forwarding:
> http://bluhm.genua.de/perform/results/2021-07-06T08:17:07Z/2021-07-06T00%3A00%3A00Z/btrace/ssh_perform%40lt13_iperf3_-c10.3.46.36_-P10_-t10-btrace-kstack.0.svg
> http://bluhm.genua.de/perform/results/2021-07-06T08:17:07Z/patch-sys-ip-multiqueue-arp-klock.0/btrace/ssh_perform%40lt13_iperf3_-c10.3.46.36_-P10_-t10-btrace-kstack.0.svg
>
> ok to commit?
>
> bluhm
>
> Index: net/if.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/if.c,v
> retrieving revision 1.642
> diff -u -p -r1.642 if.c
> --- net/if.c 30 Jun 2021 13:23:33 - 1.642
> +++ net/if.c 6 Jul 2021 15:37:41 -
> @@ -238,7 +238,7 @@ int ifq_congestion;
>
> intnetisr;
>
> -#define NET_TASKQ 1
> +#define NET_TASKQ 4
> struct taskq *nettqmp[NET_TASKQ];
>
> struct task if_input_task_locked = TASK_INITIALIZER(if_netisr, NULL);
> @@ -834,10 +834,10 @@ if_input_process(struct ifnet *ifp, stru
>* to PF globals, pipex globals, unicast and multicast addresses
>* lists and the socket layer.
>*/
> - NET_LOCK();
> + NET_RLOCK_IN_SOFTNET();
> while ((m = ml_dequeue(ml)) != NULL)
> (*ifp->if_input)(ifp, m);
> - NET_UNLOCK();
> + NET_RUNLOCK_IN_SOFTNET();
> }
>
> void
> @@ -895,6 +895,12 @@ if_netisr(void *unused)
> KERNEL_UNLOCK();
> }
> #endif
> + if (n & (1 << NETISR_IP))
> + ipintr();
> +#ifdef INET6
> + if (n & (1 << NETISR_IPV6))
> + ip6intr();
> +#endif
> #if NPPP > 0
> if (n & (1 << NETISR_PPP)) {
> KERNEL_LOCK();
> @@ -3316,12 +3322,15 @@ unhandled_af(int af)
> * globals aren't ready to be accessed by multiple threads in
> * parallel.
> */
> -int nettaskqs = NET_TASKQ;
> +int nettaskqs;
>
> struct taskq *
> net_tq(unsigned int ifindex)
> {
> struct taskq *t = NULL;
> +
> + if (nettaskqs == 0)
> + nettaskqs = min(NET_TASKQ, ncpus);
>
> t = nettqmp[ifindex % nettaskqs];
>
> Index: net/if_ethersubr.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/if_ethersubr.c,v
> retrieving revision 1.274
> diff -u -p -r1.274 if_ethersubr.c
> --- net/if_ethersubr.c7 Mar 2021 06:02:32 - 1.274
> +++ net/if_ethersubr.c6 Jul 2021 15:37:47 -
> @@ -222,7 +222,10 @@ ether_resolve(struct ifnet *ifp, struct
>
> switch (af) {
> case AF_INET:
> + KERNEL_LOCK();
> + /* XXXSMP there is a MP race in arpresolve() */
> error = arpresolve(ifp, rt, m, dst, eh->ether_dhost);
> + KERNEL_UNLOCK();
> if (error)
> return (error);
> eh->ether_type = htons(ETHERTYPE_IP);
> @@ -245,7 +248,10 @@ ether_resolve(struct ifnet *ifp, struct
> break;
> #ifdef INET6
> case AF_INET6:
> + KERNEL_LOCK();
> + /* XXXSMP there is a MP race in nd6_resolve() */
> error = nd6_resolve(ifp, rt, m, dst, eh->ether_dhost);
> + KERNEL_UNLOCK();
> if (error)
> return (error);
> eh->ether_type = htons(ETHERTYPE_IPV6);
> Index: net/ifq.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/net/ifq.c,v
> retrieving revision 1.43
> diff -u -p -r1.43 ifq.c
> --- net/ifq.c 20 Feb 2021 04:37:26 - 1.43
> +++ net/ifq.c 6 Jul 2021 15:37:13 -
> @@ -243,7 +243,7 @@ void
> ifq_init(struct ifqueue *ifq, struct ifnet *ifp, unsigned int idx)
> {
> ifq->ifq_if = ifp;
> - ifq->ifq_softnet = net_tq(ifp->if_index); /* + idx */
> + ifq->ifq_softnet = net_tq(ifp->if_index + idx);
> ifq->ifq_softc = NULL;
>
> mtx_init(>ifq_mtx, IPL_NET);
> @@ -617,7
Re: xmm(4): WIP diff for Intel XMM7360 LTE modem
On 2021/07/09 16:33, Stuart Henderson wrote:
> Notes so far:
>
> > +xmmc*)
> > + dev=${U%.*}
> > + func=${U#*.}
> > + M xmmc$U c 101 $(($(($dev*16))+$func)) 660
> > + ;;
>
> "sh MAKEDEV xmmc" isn't enough, it needs "sh MAKEDEV xmmc.0"
>
> > + ret = EIO;
> > + syslog(LOG_ERR, "FCC unlock not implemented, yet");
>
> Thus ends my initial experimentation ;)
>
oh; it's just in xmmctl of course! With the horrible python thing, I have
a working connection.
Re: more MAKEDEV cleanup
On 05/04/21(Mon) 09:25, Miod Vallat wrote:
> The following diff attempts to clean up a few loose ends in the current
> MAKEDEV files:
>
> - remove no-longer applicable device definitions (MSCP and SMD disks,
> this kind of thing).
> - makes sure all platforms use the same `ramdisk' target for
> installation media devices, rather than a mix of `ramd' and `ramdisk'.
> - moves as many `ramdisk' devices to MI land (bio, diskmap, random,
> etc).
> - reduces the number of block devices in `ramdisk' targets to only one
> per device, since the installer script will invoke MAKEDEV by itself
> for the devices it needs to use.
> - sort device names in `all' and `ramdisk' MI lists to make maintainence
> easier. This causes some ordering change in the `all' target in the
> generated MAKEDEVs.
Looks good to me.
> Index: MAKEDEV.common
> ===
> RCS file: /OpenBSD/src/etc/MAKEDEV.common,v
> retrieving revision 1.113
> diff -u -p -r1.113 MAKEDEV.common
> --- MAKEDEV.common12 Feb 2021 10:26:33 - 1.113
> +++ MAKEDEV.common5 Apr 2021 09:18:49 -
> @@ -114,7 +114,7 @@ dnl make a 'disktgt' macro that automati
> dnl disktgt(rd, {-rd-})
> dnl
> dnl target(all,rd,0)
> -dnl target(ramd,rd,0)
> +dnl target(ramdisk,rd,0)
> dnl disk_q(rd)
> dnl __devitem(rd, {-rd*-}, {-rd-})dnl
> dnl
> @@ -122,62 +122,60 @@ dnl Note: not all devices are generated
> dnlits own extra list.
> dnl
> divert(1)dnl
> +target(all, acpi)dnl
> +target(all, apm)dnl
> +target(all, bio)dnl
> +target(all, bpf)dnl
> +twrget(all, com, tty0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b)dnl
> +twrget(all, czs, cua, a, b, c, d)dnl
> +target(all, diskmap)dnl
> +target(all, dt)dnl
> twrget(all, fdesc, fd)dnl
> -target(all, st, 0, 1)dnl
> -target(all, std)dnl
> -target(all, ra, 0, 1, 2, 3)dnl
> -target(all, rx, 0, 1)dnl
> -target(all, wd, 0, 1, 2, 3)dnl
> -target(all, xd, 0, 1, 2, 3)dnl
> +target(all, fuse)dnl
> +target(all, hotplug)dnl
> +target(all, joy, 0, 1)dnl
> +target(all, kcov)dnl
> +target(all, kstat)dnl
> +target(all, local)dnl
> +target(all, lpt, 0, 1, 2)dnl
> +twrget(all, lpt, lpa, 0, 1, 2)dnl
> +target(all, par, 0)dnl
> +target(all, pci, 0, 1, 2, 3)dnl
> target(all, pctr)dnl
> target(all, pctr0)dnl
> target(all, pf)dnl
> -target(all, apm)dnl
> -target(all, acpi)dnl
> +target(all, pppac)dnl
> +target(all, pppx)dnl
> +target(all, ptm)dnl
> +target(all, pty, 0)dnl
> +target(all, pvbus, 0, 1)dnl
> +target(all, radio, 0)dnl
> +target(all, rmidi, 0, 1, 2, 3, 4, 5, 6, 7)dnl
> +twrget(all, rnd, random)dnl
> +twrget(all, speak, speaker)dnl
> +target(all, st, 0, 1)dnl
> +target(all, std)dnl
> +target(all, switch, 0, 1, 2, 3)dnl
> +target(all, tap, 0, 1, 2, 3)dnl
> twrget(all, tth, ttyh, 0, 1)dnl
> target(all, ttyA, 0, 1)dnl
> -twrget(all, mac_tty0, tty0, 0, 1)dnl
> -twrget(all, tzs, tty, a, b, c, d)dnl
> -twrget(all, czs, cua, a, b, c, d)dnl
> target(all, ttyc, 0, 1, 2, 3, 4, 5, 6, 7)dnl
> -twrget(all, com, tty0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, a, b)dnl
> -twrget(all, mmcl, mmclock)dnl
> -target(all, lpt, 0, 1, 2)dnl
> -twrget(all, lpt, lpa, 0, 1, 2)dnl
> -target(all, joy, 0, 1)dnl
> -twrget(all, rnd, random)dnl
> -target(all, uk, 0)dnl
> -twrget(all, vi, video, 0, 1)dnl
> -twrget(all, speak, speaker)dnl
> -target(all, asc, 0)dnl
> -target(all, radio, 0)dnl
> +target(all, tun, 0, 1, 2, 3)dnl
> target(all, tuner, 0)dnl
> -target(all, rmidi, 0, 1, 2, 3, 4, 5, 6, 7)dnl
> +twrget(all, tzs, tty, a, b, c, d)dnl
> target(all, uall)dnl
> -target(all, pci, 0, 1, 2, 3)dnl
> -twrget(all, wsmouse, wscons)dnl
> -target(all, par, 0)dnl
> -target(all, apci, 0)dnl
> -target(all, local)dnl
> -target(all, ptm)dnl
> -target(all, hotplug)dnl
> -target(all, pppx)dnl
> -target(all, pppac)dnl
> -target(all, fuse)dnl
> +target(all, uk, 0)dnl
> +twrget(all, vi, video, 0, 1)dnl
> target(all, vmm)dnl
> -target(all, pvbus, 0, 1)dnl
> -target(all, bpf)dnl
> -target(all, kcov)dnl
> -target(all, dt)dnl
> -target(all, kstat)dnl
> +target(all, vnd, 0, 1, 2, 3)dnl
> +target(all, vscsi, 0)dnl
> +target(all, wd, 0, 1, 2, 3)dnl
> +twrget(all, wsmouse, wscons)dnl
> dnl
> _mkdev(all, {-all-}, {-dnl
> show_target(all)dnl
> -})dnl
> dnl
> -dnl XXX some arches use ramd, others ramdisk - needs to be fixed eventually
> -__devitem(ramdisk, ramdisk, Ramdisk kernel devices,nothing)dnl
> -dnl
> target(usb, usb, 0, 1, 2, 3, 4, 5, 6, 7)dnl
> target(usb, uhid, 0, 1, 2, 3, 4, 5, 6, 7)dnl
> twrget(usb, fido, fido)dnl
> @@ -208,26 +206,26 @@ __devitem(ch, {-ch*-}, SCSI media change
> _mcdev(ch, ch*, ch, {-major_ch_c-}, 660, operator)dnl
> __devitem(uk, uk*, Unknown SCSI devices)dnl
> _mcdev(uk, uk*, uk, {-major_uk_c-}, 640, operator)dnl
> -dnl XXX see ramdisk above
> -__devitem(ramd, ramdisk, Ramdisk kernel devices,nothing)dnl
> dnl
> -_mkdev(ramd, ramdisk, {-dnl
> -show_target(ramd)dnl
> +__devitem(ramdisk, ramdisk, Ramdisk kernel devices,nothing)dnl
> +_mkdev(ramdisk, ramdisk, {-dnl
>
Re: xmm(4): WIP diff for Intel XMM7360 LTE modem
Notes so far:
> +xmmc*)
> + dev=${U%.*}
> + func=${U#*.}
> + M xmmc$U c 101 $(($(($dev*16))+$func)) 660
> + ;;
"sh MAKEDEV xmmc" isn't enough, it needs "sh MAKEDEV xmmc.0"
> + ret = EIO;
> + syslog(LOG_ERR, "FCC unlock not implemented, yet");
Thus ends my initial experimentation ;)
Re: forwarding in parallel with ipsec panic
I think we see two problems here: 1. With non parallel forwarding the IPsec traffic stalls after a while. Compiled with ENCDEBUG I get this message for each received ESP packet: esp_input_cb: authentication failed for packet in SA 10.3.45.35/83089fff I can reproduce it more or less after 30 seconds full traffic. At first I suspected some rekeying event, but I cannot find them in the logs anymore. I added some kernel locks into the pfkey path, but it does not help. Restarting iked fixes the situation by deleting and adding new SAs. I am using cryptosoft with auth gmac-aes-128 enc aes-gcm. The error message shows that the authentication of the packet does not match the expected value of the crypto on the receiving side. I don't know whether the packet is corrupted when sending or some crypto parameter are wrong on the receiving side. Although I found some MP bugs in crypto, they look not relvant in our case. Everything there should be protected by kernel lock. 2. With parallel forwarding the kernel crashes. > That means simultaneous ipsp_spd_lookup() execution breaks not only > `tdb_policy_head' but the 'ipo->ipo_tdb' pointer too. I have seen double removes from tdb_policy_head. It looked like _Q_INVALID in ddb. mvs@ has fixed some bugs, but the issue remains and Hrvoje can reproduce variations of it. > Also I like to remind, about the logic we have in sys/net/pfkeyv2.c: > > 2017/* > 2018 * XXXSMP IPsec data structures are not ready to be > 2019 * accessed by multiple Network threads in parallel, > 2020 * so force all packets to be processed by the first > 2021 * one. > 2022 */ > 2023extern int nettaskqs; > 2024nettaskqs = 1; > > It seems to be not working with parallel forwarding diff. In general our IPsec stack is not MP save. But this hack should ensure that only one thread is running in IPsec. I am also wondering why the workaround is not working around properly. Currently I am concentrating on 1, maybe a fix there helps for 2. At genua we have a diff for tdb refcounting. tobhe@ investigates if we can integrate it into OpenBSD. But it is huge. bluhm
Re: update xf86-video-amdgpu to latest git
Hello, X1 gen5 continues to work fine. X1 gen9 x11 stopped crashing and is now usable! (Tiger lake) Thank you! Eric On Thu, 8 Jul 2021 at 09:41, Jonathan Gray wrote: > > The latest xf86-video-amdgpu release was in 2019. > > xf86-video-amdgpu-19.1.0..origin/master > > minus commits we already have > cb27a5b Handle NULL fb_ptr in pixmap_get_fb > e2cd67a Bail from amdgpu_pixmap_get_handle with ShadowFB > edcbe5f Fix link failure with gcc 10 > > With a X_PRIVSEP path added to amdgpu_probe.c to handle the change from > drmOpen() to open(). > > aedbf47 Include xf86drm.h instead of sarea.h > 6ed4863 Drop dri.h includes > 6234a1b Fix drmmode_crtc_scanout_create logic > 6bd3dc6 Check for AMDGPU_CREATE_PIXMAP_SCANOUT in amdgpu_glamor_create_pixmap > 2202cdf Replace a few more instances of "master" > 0d1d479 Fix build against ABI_VIDEODRV_VERSION 25.2 > 442efe7 Make drmmode_crtc_scanout_create/destroy static > 99f3c82 Drop struct drmmode_scanout altogether in favour of PixmapPtrs > cfce4b3 Drop bo/width/height members from struct drmmode_scanout > 680b9a2 Fix return value check of drmIoctl() > e923642 gitlab CI: update to use the latest CI templates > 0732f81 glamor: Make pixmap scanout compatible if its dimensions are > 42a3148 Factor out common code to amdgpu_probe() > eeaaf37 Introduce amdgpu_device_setup helper > 1c9742e Kill off drmOpen/Close/drmSetInterfaceVersion in favour of drmDevices > 2dd7307 Use the device_id straight from gpu_info > 655b3c5 Reuse the existing busid string > b357a84 Store the busid string in AMDGPUEnt > 2c0c154 Remove NULL check after a "cannot fail" function > 16ae0d0 Fixup the amdgpu_bus_id() string format > abbe23f Remove drmCheckModesettingSupported and kernel module loading, on > Linux > 0b3bc7a Use ODEV_ATTRIB_PATH where possible for the device node. > fd66f5c kms: Handle changes to SourceValidate call chain in xserver 19 > > Index: driver/xf86-video-amdgpu/Makefile.in > === > RCS file: /cvs/xenocara/driver/xf86-video-amdgpu/Makefile.in,v > retrieving revision 1.2 > diff -u -p -r1.2 Makefile.in > --- driver/xf86-video-amdgpu/Makefile.in16 Apr 2019 01:59:34 - > 1.2 > +++ driver/xf86-video-amdgpu/Makefile.in8 Jul 2021 07:13:57 - > @@ -314,6 +314,7 @@ pdfdir = @pdfdir@ > prefix = @prefix@ > program_transform_name = @program_transform_name@ > psdir = @psdir@ > +runstatedir = @runstatedir@ > sbindir = @sbindir@ > sharedstatedir = @sharedstatedir@ > srcdir = @srcdir@ > Index: driver/xf86-video-amdgpu/README.md > === > RCS file: /cvs/xenocara/driver/xf86-video-amdgpu/README.md,v > retrieving revision 1.1.1.1 > diff -u -p -r1.1.1.1 README.md > --- driver/xf86-video-amdgpu/README.md 16 Apr 2019 01:49:01 - > 1.1.1.1 > +++ driver/xf86-video-amdgpu/README.md 7 Jul 2021 13:42:19 - > @@ -9,7 +9,7 @@ Please > to the Xorg bugzilla. > > The > -[master development code > repository](https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu) > +[main development code > repository](https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu) > can be found at FreeDesktop Gitlab. > > Please use merge requests for patch submission. > Index: driver/xf86-video-amdgpu/aclocal.m4 > === > RCS file: /cvs/xenocara/driver/xf86-video-amdgpu/aclocal.m4,v > retrieving revision 1.2 > diff -u -p -r1.2 aclocal.m4 > --- driver/xf86-video-amdgpu/aclocal.m4 16 Apr 2019 01:59:34 - 1.2 > +++ driver/xf86-video-amdgpu/aclocal.m4 8 Jul 2021 07:13:54 - > @@ -19,9 +19,9 @@ You have another version of autoconf. I > If you have problems, you may need to regenerate the build system entirely. > To do so, use the procedure documented by the package, typically > 'autoreconf'.])]) > > -dnl pkg.m4 - Macros to locate and utilise pkg-config. -*- Autoconf -*- > -dnl serial 11 (pkg-config-0.29.1) > -dnl > +# pkg.m4 - Macros to locate and utilise pkg-config. -*- Autoconf -*- > +# serial 12 (pkg-config-0.29.2) > + > dnl Copyright Š 2004 Scott James Remnant . > dnl Copyright Š 2012-2015 Dan Nicholson > dnl > @@ -62,7 +62,7 @@ dnl > dnl See the "Since" comment for each macro you use to see what version > dnl of the macros you require. > m4_defun([PKG_PREREQ], > -[m4_define([PKG_MACROS_VERSION], [0.29.1]) > +[m4_define([PKG_MACROS_VERSION], [0.29.2]) > m4_if(m4_version_compare(PKG_MACROS_VERSION, [$1]), -1, > [m4_fatal([pkg.m4 version $1 or higher is required but > ]PKG_MACROS_VERSION[ found])]) > ])dnl PKG_PREREQ > @@ -163,7 +163,7 @@ AC_ARG_VAR([$1][_CFLAGS], [C compiler fl > AC_ARG_VAR([$1][_LIBS], [linker flags for $1, overriding pkg-config])dnl > > pkg_failed=no > -AC_MSG_CHECKING([for $1]) > +AC_MSG_CHECKING([for $2]) > > _PKG_CONFIG([$1][_CFLAGS], [cflags], [$2]) > _PKG_CONFIG([$1][_LIBS], [libs], [$2]) > @@ -173,11 +173,11 @@ and $1[]_LIBS
Re: free() sizes in zlib
mpi reminded me of this diff.
On Tue, May 14, 2019 at 01:51:05PM +, Miod Vallat wrote:
> This tries to keep diffability against upstream, hence a questionable
> choice of the size type for zcfree() - but all sizes should fit in 32
> bits anyway.
>
> Since all zcfree routines used in the tree cope with NULL arguments
> (including the various alloc.c used by the boot blocks), I have
> simplified TRY_FREE to compensate for the growth.
Below is a rebased version. Having just gone through the update dance, I
don't think this will make future updates significantly harder (there is
also the question whether there will ever be another one).
The diff is easy to check and works for me.
Index: net/ppp-deflate.c
===
RCS file: /cvs/src/sys/net/ppp-deflate.c,v
retrieving revision 1.16
diff -u -p -r1.16 ppp-deflate.c
--- net/ppp-deflate.c 5 Mar 2021 09:21:08 - 1.16
+++ net/ppp-deflate.c 9 Jul 2021 06:42:33 -
@@ -66,7 +66,7 @@ struct deflate_state {
#define DEFLATE_OVHD 2 /* Deflate overhead/packet */
static void*zcalloc(void *, u_int items, u_int size);
-static voidzcfree(void *, void *ptr);
+static voidzcfree(void *, void *ptr, u_int size);
static void*z_comp_alloc(u_char *options, int opt_len);
static void*z_decomp_alloc(u_char *options, int opt_len);
static voidz_comp_free(void *state);
@@ -133,9 +133,9 @@ zcalloc(void *notused, u_int items, u_in
}
void
-zcfree(void *notused, void *ptr)
+zcfree(void *notused, void *ptr, u_int size)
{
-free(ptr, M_DEVBUF, 0);
+free(ptr, M_DEVBUF, size);
}
/*
Index: lib/libz/deflate.c
===
RCS file: /cvs/src/sys/lib/libz/deflate.c,v
retrieving revision 1.4
diff -u -p -r1.4 deflate.c
--- lib/libz/deflate.c 4 Jul 2021 14:24:49 - 1.4
+++ lib/libz/deflate.c 9 Jul 2021 06:36:17 -
@@ -1080,12 +1080,12 @@ int ZEXPORT deflateEnd (strm)
status = strm->state->status;
/* Deallocate in reverse order of allocations: */
-TRY_FREE(strm, strm->state->pending_buf);
-TRY_FREE(strm, strm->state->head);
-TRY_FREE(strm, strm->state->prev);
-TRY_FREE(strm, strm->state->window);
+TRY_FREE(strm, strm->state->pending_buf, strm->state->pending_buf_size);
+TRY_FREE(strm, strm->state->head, strm->state->hash_size * sizeof(Pos));
+TRY_FREE(strm, strm->state->prev, strm->state->w_size * sizeof(Pos));
+TRY_FREE(strm, strm->state->window, strm->state->w_size * 2 * sizeof(Pos));
-ZFREE(strm, strm->state);
+ZFREE(strm, strm->state, sizeof(deflate_state));
strm->state = Z_NULL;
return status == BUSY_STATE ? Z_DATA_ERROR : Z_OK;
Index: lib/libz/infback.c
===
RCS file: /cvs/src/sys/lib/libz/infback.c,v
retrieving revision 1.7
diff -u -p -r1.7 infback.c
--- lib/libz/infback.c 4 Jul 2021 14:24:49 - 1.7
+++ lib/libz/infback.c 9 Jul 2021 06:36:23 -
@@ -684,7 +684,7 @@ z_streamp strm;
{
if (strm == Z_NULL || strm->state == Z_NULL || strm->zfree == (free_func)0)
return Z_STREAM_ERROR;
-ZFREE(strm, strm->state);
+ZFREE(strm, strm->state, sizeof(struct inflate_state));
strm->state = Z_NULL;
Tracev((stderr, "inflate: end\n"));
return Z_OK;
Index: lib/libz/inflate.c
===
RCS file: /cvs/src/sys/lib/libz/inflate.c,v
retrieving revision 1.16
diff -u -p -r1.16 inflate.c
--- lib/libz/inflate.c 4 Jul 2021 14:24:49 - 1.16
+++ lib/libz/inflate.c 9 Jul 2021 06:32:09 -
@@ -183,7 +183,7 @@ int windowBits;
if (windowBits && (windowBits < 8 || windowBits > 15))
return Z_STREAM_ERROR;
if (state->window != Z_NULL && state->wbits != (unsigned)windowBits) {
-ZFREE(strm, state->window);
+ZFREE(strm, state->window, 1U << state->wbits);
state->window = Z_NULL;
}
@@ -231,7 +231,7 @@ int stream_size;
state->mode = HEAD; /* to pass state test in inflateReset2() */
ret = inflateReset2(strm, windowBits);
if (ret != Z_OK) {
-ZFREE(strm, state);
+ZFREE(strm, state, sizeof(struct inflate_state));
strm->state = Z_NULL;
}
return ret;
@@ -1368,8 +1368,8 @@ z_streamp strm;
if (inflateStateCheck(strm))
return Z_STREAM_ERROR;
state = (struct inflate_state FAR *)strm->state;
-if (state->window != Z_NULL) ZFREE(strm, state->window);
-ZFREE(strm, strm->state);
+if (state->window != Z_NULL) ZFREE(strm, state->window, 1U <<
state->wbits);
+ZFREE(strm, strm->state, sizeof(struct inflate_state));
strm->state = Z_NULL;
Tracev((stderr, "inflate: end\n"));
return Z_OK;
@@ -1568,7 +1568,7 @@ z_streamp source;
window = (unsigned char FAR *)
ZALLOC(source, 1U << state->wbits, sizeof(unsigned char));
if
