From nobody Sun Jul 2 19:52:46 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QvKTw5vJbz4hc63 for ; Sun, 2 Jul 2023 19:52:52 +0000 (UTC) (envelope-from cliftonr@volcano.org) Received: from omta38.uswest2.a.cloudfilter.net (omta38.uswest2.a.cloudfilter.net [35.89.44.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QvKTv6N3Rz3PrF for ; Sun, 2 Jul 2023 19:52:51 +0000 (UTC) (envelope-from cliftonr@volcano.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of cliftonr@volcano.org designates 35.89.44.37 as permitted sender) smtp.mailfrom=cliftonr@volcano.org; dmarc=none Received: from eig-obgw-5003a.ext.cloudfilter.net ([10.0.29.159]) by cmsmtp with ESMTP id FvkKqnzyRQFHRG37pqVh6d; Sun, 02 Jul 2023 19:52:49 +0000 Received: from gator4150.hostgator.com ([192.185.4.162]) by cmsmtp with ESMTPS id G37oqQBAtdcygG37pqMVRN; Sun, 02 Jul 2023 19:52:49 +0000 X-Authority-Analysis: v=2.4 cv=QbN1A+Xv c=1 sm=1 tr=0 ts=64a1d591 a=UsLNsgIQu5Rwd0y+KnVsSA==:117 a=wNkKhEd54xca6NfFpypmcg==:17 a=IkcTkHD0fZMA:10 a=ws7JD89P4LkA:10 a=ENOBcGDIfdYA:10 a=6I5d2MoRAAAA:8 a=GjEiR67sAAAA:8 a=Lueq0QKXb3i0uZKH0LoA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=B-DU53zI3E2b2plE8BPh:22 Received: from dhcp-72-234-209-134.hawaiiantel.net ([72.234.209.134]:53324 helo=[10.0.0.12]) by gator4150.hostgator.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1qG37o-000OGg-2P for freebsd-hackers@freebsd.org; Sun, 02 Jul 2023 14:52:48 -0500 Message-ID: <2ad2965e-ccc4-a202-2a58-0b2970aad925@volcano.org> Date: Sun, 2 Jul 2023 09:52:46 -1000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: top vs. array sorted_state's out of bounds indexing (and related issues) Content-Language: en-US To: freebsd-hackers@freebsd.org References: From: Clifton Royston In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4150.hostgator.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - volcano.org X-BWhitelist: no X-Source-IP: 72.234.209.134 X-Source-L: No X-Exim-ID: 1qG37o-000OGg-2P X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: dhcp-72-234-209-134.hawaiiantel.net ([10.0.0.12]) [72.234.209.134]:53324 X-Source-Auth: cliftonr@volcano.org X-Email-Count: 2 X-Org: HG=hgshared;ORG=hostgator; X-Source-Cap: Y2xpZnRvbnI7Y2xpZnRvbnI7Z2F0b3I0MTUwLmhvc3RnYXRvci5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfIBXX05cy/+wW4zGjvCF7NUjf8vSXmoW1wusQrE3iYsmejrW3C837sPigknQnWWiGFjIjoIO0zkzNwbo/qBlp2Wp2WmHal2EDskYV6g1kGqAPunQSu9w u1tZkprx3icPjDBjXcY6JOH3Akw9Fm8iqnuzAnNlQOK46MeGwsQavthFEJZ9eutl+vZWNjDU9CYbLfsFusurVghrdYX78Zf1OAY= X-Spamd-Result: default: False [-3.44 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; NEURAL_HAM_MEDIUM(-0.94)[-0.944]; R_SPF_ALLOW(-0.20)[+ip4:35.89.44.32/29]; RCVD_IN_DNSWL_LOW(-0.10)[35.89.44.37:from]; MIME_GOOD(-0.10)[text/plain]; RWL_MAILSPIKE_GOOD(-0.10)[35.89.44.37:from]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:16509, ipnet:35.80.0.0/12, country:US]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; HAS_X_ANTIABUSE(0.00)[]; BLOCKLISTDE_FAIL(0.00)[72.234.209.134:server fail,192.185.4.162:server fail,35.89.44.37:server fail]; RCVD_COUNT_THREE(0.00)[4]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; HAS_X_SOURCE(0.00)[]; DMARC_NA(0.00)[volcano.org]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4QvKTv6N3Rz3PrF X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 6/19/2023 6:05 AM, Konstantin Belousov wrote: > On Sun, Jun 18, 2023 at 09:23:06PM -0700, Mark Millard wrote: >> usr.bin/top/machine.c (from main) has: >> >> /* >> . . . The process states are ordered as follows (from least >> * to most important): WAIT, zombie, sleep, stop, start, run. The >> * array declaration below maps a process state index into a number >> * that reflects this ordering. >> */ >> >> static int sorted_state[] = { >> 0, /* not used */ >> 3, /* sleep */ >> 1, /* ABANDONED (WAIT) */ >> 6, /* run */ >> 5, /* start */ >> 2, /* zombie */ >> 4 /* stop */ >> }; >> >> Note the elements are 0..6, so 7 elements. >> >> It is accessed via code like: >> >> sorted_state[(unsigned char)(b)->ki_stat] [...] >> /* >> * These were process status values (p_stat), now they are only used in >> * legacy conversion code. >> */ >> #define SIDL 1 /* Process being created by fork. */ >> #define SRUN 2 /* Currently runnable. */ >> #define SSLEEP 3 /* Sleeping on an address. */ >> #define SSTOP 4 /* Process debugging or suspension. */ >> #define SZOMB 5 /* Awaiting collection by parent. */ >> #define SWAIT 6 /* Waiting for interrupt. */ >> #define SLOCK 7 /* Blocked on a lock. */ >> [...] >> There is also the issue that: >> >> SIDL is misidentified as: sleep >> SRUN is misidentified as: ABANDONED (WAIT) >> SSLEEP is misidentified as: run >> SZOMB is misidentified as: start >> SWAIT is misidentified as: zombie >> SLOCK is out of bounds (as indicated above). >> >> So the sort order in top is not as documented. >> >> >> For reference, from sys/kern/kern_proc.c : >> >> if (p->p_state == PRS_NORMAL) { /* approximate. */ >> if (TD_ON_RUNQ(td) || >> TD_CAN_RUN(td) || >> TD_IS_RUNNING(td)) { >> kp->ki_stat = SRUN; >> } else if (P_SHOULDSTOP(p)) { >> kp->ki_stat = SSTOP; >> } else if (TD_IS_SLEEPING(td)) { >> kp->ki_stat = SSLEEP; >> } else if (TD_ON_LOCK(td)) { >> kp->ki_stat = SLOCK; >> } else { >> kp->ki_stat = SWAIT; >> } >> } else if (p->p_state == PRS_ZOMBIE) { >> kp->ki_stat = SZOMB; >> } else { >> kp->ki_stat = SIDL; >> } > https://reviews.freebsd.org/D40607   I rarely comment here and hesitate to now, but out of curiosity I looked at the original report and at the chain of commits.   It appears to me that in making the code more readable the final result may have accidentally inverted the sort order from the intended values (mostly.)  A casual test wouldn't show this, as unless the sort order in top were changed, normally it would only come into play for two processes with equal CPU % and ticks which seems unlikely.   Perhaps I'm simply misreading the original which was itself confused on the index values, but it appears from the original *comments*, as opposed to the effects, that higher values are intended to sort as higher list priority. For example, run was originally supposed to be mapped to 6 (largest value), start to 5, and so on down to zombie mapped to 2 and WAIT to 1.   The rewrite with designated initializers in  rGbc2ac2585aa8 now maps - in descending value order -  [SSLEEP] = 6, [SSTOP] = 5, [SWAIT] = 4 ... [SRUN] = 1.   As long as this is being fixed, shouldn't it read more like this: /*  *  proc_compare - comparison function for "qsort"  *    Compares the resource consumption of two processes using five  *    distinct keys.  The keys (in descending order of importance) are:  *    percent cpu, cpu ticks, state, resident set size, total virtual  *    memory usage.  The process states are ordered as follows (from most  *    to least important):  run, zombie, idle, interrupt wait, stop, sleep.  *    The array declaration below maps a process state index into a  *    number that reflects this ordering.  */ static const int sorted_state[] = {     [SRUN] =    6,    /* running/runnable    */     [SZOMB] =    5,    /* zombie        */     [SIDL] =    4,    /* being created    */     [SWAIT] =    3,    /* intr            */     [SSTOP] =    2,    /* stopped/suspended    */     [SSLEEP] =    1,    /* sleeping        */   I haven't read the entire context of how the values get used in the comparison, so it's possible I have this wrong.   I'm assuming where SIDL and SWAIT should fall based on the revised comments in rGd636fc5bd1e2 and the assumption that the original comment "(from least to most important)" was misread as "(from most to least important)" as I think one would normally want to see the "run" processes ahead of the "sleep" processes etc.   Best regards,   -- Clifton (My apologies if this comes out garbled, as seemingly I have to fight Thunderbird to edit for plain text output.) -- Clifton Royston From nobody Sun Jul 2 21:44:10 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QvMyS5X25z4lkmF for ; Sun, 2 Jul 2023 21:44:16 +0000 (UTC) (envelope-from cliftonr@volcano.org) Received: from omta40.uswest2.a.cloudfilter.net (omta40.uswest2.a.cloudfilter.net [35.89.44.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QvMyR3HTTz4J4w for ; Sun, 2 Jul 2023 21:44:15 +0000 (UTC) (envelope-from cliftonr@volcano.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of cliftonr@volcano.org designates 35.89.44.39 as permitted sender) smtp.mailfrom=cliftonr@volcano.org; dmarc=none Received: from eig-obgw-5008a.ext.cloudfilter.net ([10.0.29.246]) by cmsmtp with ESMTP id FjZVqnbzEbK1VG4rdqMAs7; Sun, 02 Jul 2023 21:44:14 +0000 Received: from gator4150.hostgator.com ([192.185.4.162]) by cmsmtp with ESMTPS id G4rcqaxFPW9zGG4rdqFP1J; Sun, 02 Jul 2023 21:44:13 +0000 X-Authority-Analysis: v=2.4 cv=To31ORbh c=1 sm=1 tr=0 ts=64a1efad a=UsLNsgIQu5Rwd0y+KnVsSA==:117 a=wNkKhEd54xca6NfFpypmcg==:17 a=IkcTkHD0fZMA:10 a=ws7JD89P4LkA:10 a=ENOBcGDIfdYA:10 a=6I5d2MoRAAAA:8 a=GjEiR67sAAAA:8 a=4eTaKvC7j1EQiMHch4AA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=B-DU53zI3E2b2plE8BPh:22 Received: from dhcp-72-234-209-134.hawaiiantel.net ([72.234.209.134]:56568 helo=[10.0.0.12]) by gator4150.hostgator.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1qG4rc-0023Bx-2B for freebsd-hackers@freebsd.org; Sun, 02 Jul 2023 16:44:12 -0500 Message-ID: Date: Sun, 2 Jul 2023 11:44:10 -1000 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: top vs. array sorted_state's out of bounds indexing (and related issues) Content-Language: en-US From: Clifton Royston To: freebsd-hackers@freebsd.org References: <2ad2965e-ccc4-a202-2a58-0b2970aad925@volcano.org> In-Reply-To: <2ad2965e-ccc4-a202-2a58-0b2970aad925@volcano.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4150.hostgator.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - volcano.org X-BWhitelist: no X-Source-IP: 72.234.209.134 X-Source-L: No X-Exim-ID: 1qG4rc-0023Bx-2B X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: dhcp-72-234-209-134.hawaiiantel.net ([10.0.0.12]) [72.234.209.134]:56568 X-Source-Auth: cliftonr@volcano.org X-Email-Count: 1 X-Org: HG=hgshared;ORG=hostgator; X-Source-Cap: Y2xpZnRvbnI7Y2xpZnRvbnI7Z2F0b3I0MTUwLmhvc3RnYXRvci5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfPHPS6wKrVNzLVMRRbFf46fbfoskGuEs/+fmoLVSoU6Gc1n2m1ssyK9Uef+JDknWLjrXxh/RvGYTvueri1Lh67efSmCOKo7HyRnJUxoPD3ZhcO6C2Vqs BxRqLfHVV7yXJS12iOTB42LiRtAmN8LvZhAiGIlAg7dU2KZM2kwSbSLgaYGBgVz6ZO5ARNGRnBNx7PReeA0WL0dsQfHy2+9E1xc= X-Spamd-Result: default: False [-3.37 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; NEURAL_HAM_MEDIUM(-0.97)[-0.973]; R_SPF_ALLOW(-0.20)[+ip4:35.89.44.32/29]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[35.89.44.39:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; HAS_X_ANTIABUSE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:16509, ipnet:35.80.0.0/12, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; HAS_X_SOURCE(0.00)[]; ARC_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[35.89.44.39:from]; DMARC_NA(0.00)[volcano.org]; TO_DN_NONE(0.00)[]; BLOCKLISTDE_FAIL(0.00)[192.185.4.162:server fail,72.234.209.134:server fail,35.89.44.39:server fail]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspamd-Queue-Id: 4QvMyR3HTTz4J4w X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 7/2/2023 9:52 AM, Clifton Royston wrote: > On 6/19/2023 6:05 AM, Konstantin Belousov wrote: >> On Sun, Jun 18, 2023 at 09:23:06PM -0700, Mark Millard wrote: >>> usr.bin/top/machine.c (from main) has: [...] >>> >>> static int sorted_state[] = { >>> 0, /* not used */ >>> 3, /* sleep */ >>> 1, /* ABANDONED (WAIT) */ >>> 6, /* run */ >>> 5, /* start */ >>> 2, /* zombie */ >>> 4 /* stop */ >>> }; >>> >>> Note the elements are 0..6, so 7 elements. >>> >>> It is accessed via code like: >>> >>> sorted_state[(unsigned char)(b)->ki_stat] > [...] >>> /* >>> * These were process status values (p_stat), now they are only used in >>> * legacy conversion code. >>> */ >>> #define SIDL 1 /* Process being created by fork. */ >>> #define SRUN 2 /* Currently runnable. */ >>> #define SSLEEP 3 /* Sleeping on an address. */ >>> #define SSTOP 4 /* Process debugging or suspension. */ >>> #define SZOMB 5 /* Awaiting collection by parent. */ >>> #define SWAIT 6 /* Waiting for interrupt. */ >>> #define SLOCK 7 /* Blocked on a lock. */ >>> > [...] >>> } else if (TD_ON_LOCK(td)) { >>> kp->ki_stat = SLOCK; > [...] >> https://reviews.freebsd.org/D40607 > > I rarely comment here and hesitate to now, but out of curiosity I > looked at the original report and at the chain of commits. > > It appears to me that in making the code more readable the final > result may have accidentally inverted the sort order from the intended > values (mostly.) A casual test wouldn't show this, as unless the sort > order in top were changed, normally it would only come into play for > two processes with equal CPU % and ticks which seems unlikely. [...] And, following up to myself, I now realized that both the committed patch *and* my reply completely missed addressing the original issue Mark reported: No value for the index SLOCK is included in the array initializer, so SLOCK is still not translated to a meaningful index, and AFAICT it is not included in the dimensions! I expect it would still result in the same out-of-bounds indexing problem Mark reported for that case. A further corrected comment and array initializer: /* * proc_compare - comparison function for "qsort" * Compares the resource consumption of two processes using five * distinct keys. The keys (in descending order of importance) are: * percent cpu, cpu ticks, state, resident set size, total virtual * memory usage. The process states are ordered as follows (from most * to least important): run, zombie, idle (being created), interrupt * wait, blocked on lock, stop, sleep. * The array declaration below maps a process state index into a * number that reflects this ordering. */ static const int sorted_state[] = { [SRUN] = 7, /* Currently runnable. */ [SZOMB] = 6, /* Awaiting collection by parent. */ [SIDL] = 5, /* Process being created by fork. */ [SWAIT] = 4, /* Waiting for interrupt. */ [SLOCK] = 3, /* Blocked on a lock. */ [SSTOP] = 2, /* Process debugging or suspension. */ [SSLEEP] = 1, /* Sleeping on an address. */ } Best regards, -- Clifton -- Clifton Royston From nobody Sun Jul 2 22:45:10 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QvPK33dvYz4lPq1 for ; Sun, 2 Jul 2023 22:45:27 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic311-24.consmr.mail.gq1.yahoo.com (sonic311-24.consmr.mail.gq1.yahoo.com [98.137.65.205]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QvPK21gzjz3MZv for ; Sun, 2 Jul 2023 22:45:26 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="t/TDpBkc"; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.205 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688337924; bh=YbQuR496XDMabU6/HsfZPTDP6awpqs60f2mOYoKWF+0=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=t/TDpBkcfdHaOEmDep7zUNZUUA0xFZXA5+190cgorGt0BKfuv3cJutSXSpIsinMmhMkssgl3YRJUYpB0kklaQNz07iBgH0P9f2bP0AT+wMSddb5aJyOx6bz5+gR7YZ728NwKFculmiNw19GQcFRzIjMzFXdQ1LivxxgcJ3eb3oXC0oS42dca3hVRF8wNoS6uXEuW7OJKI5uYZ1RxMJtBACskB+7kedVYA6o4NPL+iHtPYpl0fKZ6G/QQr5uLmGmccmerPKVHe2hc2P2fkoYvYztALHM+4jdpkCDh1CS3vEO4MFRc+JDjgP/hG7MpoyUrzN+63Pxv1GEWjFh4xQy8eQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1688337924; bh=8gRDlrEnr1JndffV83u/k97j3APO7kMjSRAwbNNSMrp=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=P7QkOQlsaAiUpX1RrKSgKzfVe2xXmlgiMXuXNQnKtpM+8DsTFC5lM0EKxWDtb0CVIliOn71SWtLnyh0fswAg1GbKQq3dRTMmfo70MOS+ttuP/iXCJOC3TWu2/pXmLxsavPzKQnxAQYz01mHD5wOqix/De1o2hWbeG8aJ1udYzGl1Xjklo27B2rAdHeQeiCaIzjinKRmKbnymva15IQCgvUXC67QzyWmqFJD/xpx+yFRRIS+xpHQCM/5Nkvc3ssydJ6zONhRtK3bYKs4rbYVEnIrXrzx+LoBgQ0EDIRBc2AGFQitcURgrH3lqEjPiwPVM/98MMoSPCRok6GSMWaw+ug== X-YMail-OSG: 4OlZIJAVM1kEsSkzouu8217MsXoZOABzgocVFfCC8HRnIMKO1iUtQGXGErL6jzH eJeJn0HAt_juGCwYXy5XN5AyHB22NqL94W6c0aclMBOzN5xHkfXkM33JjwKJsKlme_ZkzT3DGqRN AYrAHeWNbEVvj0sfsHStQmB_1YTxpBGUZy5vKwcCsfu.hwkeKJ7T9j6LrpXskQv2.AlNgFThBLxn V_9bBe.mYyc5RVMajDXzTtmHAExy7xHHaFQVE4U_kF6xATWzcJJnDI3.EA7DIaUHnTVA6_YBxCwc qaHnB9DRY37QNMhECrAEJkXvE.kOwAlXMYrjQyj23bGOSyrtZOsbCTktpeoXJBOGhZPK3oHeqH34 WYWrRv4ZHLr0nfUxKZDv5wfVU6lyEMGSLgRj4iZI3AcdAhci3keYNQRffefPHsd8F1IiQfvNqnmO lNjpmJ238Z.XAwZ64_in0VwwiSbp59IOCwiWYMJQb2kJZ8TYGtNIdBwFCBRfZcFa3QPP0fa0imTd MazxTI0LQF3mW5AX5evdtLmVMfPTIBoeF8oWNv4qXi4wm04nDFs9XiOM4Am6bG4ytEGmDL0Gj_u9 yTqnGLcV9EY0Db5uWVqc5r5uLPlPOlfaLjh.p3.nRtEaU0Z_BTLLJJxEml_MDmfQqbczInLgL8sR Yi2V5KFKBWdmx6IJwOLMKtOwBdMCyBh5LkGqQKKNkLi64epXq8oRx3MHztaKFSNknIllorWoSMLd dz5CVymA7RCY9h2OkvwSsrXwGU_luuHKVjW6Xd5a_XWOGdU.2kPC_5acd7saEtMYos1sVxMl73OO L720ZJc3b6uWbx_AantBy4xPOA9nV.HOvbvm1vStOHofAY_WMne90sM1Fv7AsacW9OqxN9IhK8wC 9TOSaqnx3n4f6GfirUp5w.FIR3_O3.nH5tNbdhIyM3m5OrbRHL6WzNM0JmIy_sno_FdtpAQoGNP6 IkhfZ4QV7EbwzeX3GQXXY9vmJ0ldpG4Bk7acQ3G_LUbYF8XOS0xJ7Pg_HxyTu64f.pHbrYRUnAVM zFuX7cbUGYUUq_F4JUc5x4DXEx9AVgCYq.CEbK38huU_kpnJtXJtUPa8TFKhoP_KoTi0lImEaFVE 1XWRfcaHYQ.SxcxKLPlB9buvecwjywO7VTVQmqikFnwI7XD0YnviIgIbbv46G5B6Bqd8TKM8Yk6U 3sUYbv8V9hftWonVtar4RhbvECuYam9v7.WrTylkilySinBwwjslcI4hQPlwEdWzhhnl_0WMvdh4 hUaYIqmUjAMAiV5O1hZ.7jlmK2lgaZnAWFQMPp8bdfyVOkCrLlfKQO_riPXi8Zrfp.02XpO5oVZ9 AYzr6iynDarNRiFFEIlxhSvCwOf0THxlhlSnrc4qb7VHZz3g44oJfnvPu0033ZVxIowz4Nu5Kd5P kmuWCruj_Z8hASRx8sq06jEyvQ1GiPtscpUCZNxGKqfYC6VqX1C.._rLADtbpvBEydz9a7TsOZNJ s1CILX7CnFo5JrWidSMw4PK2khJqmbFOMD.d058TSVTpl9mmi7PzIeZQ9sgCVfeVbNs.TCWMb3xr TtODCttqn9XZOLTAz6MQYju3TFT5HNWNM88jK74Wl5yOombD38poMvdfb125HF0nNj4jmRqh7euW yZNFjRW8CltJiUIcjX10b5vKyzFk8NQH0_OtNHUsCo5pxPzPLYQr.Rrxt0Ux0tckbDVjfxVS4asc 9bG5SBRW02bnn_S2poWSsNOMagy1smctwAMaL7IbvutIqYt0bQ0xxXiONdqMT7zNoosG9VCxi7be faGNqDhc.CVSB_N24TDprzRMdpVE8Q.nGHDKnVpArZIWNf_733NpjGrm04WSigmHeUnV5hMQOj0o lFP2wB7z5qabI9cPGNIe0IHkjIMNXESG3bKI9YcrbO1lV.4PiUA6ykR31zt86Jc.2OOGnMXaYKz7 JqU4J9PpMz2exXGMHgWqqGPOPKqKyP3APRl1TDlpxER76q9.4sldxobDq1Z7IyhYXfzucBjnqvT8 414DmALH6PnKhS3jPbt1IT8gvdTQCa3xPryrE4e4PmXsSkyXSjvIEVZUEoy4x_Z15VwJ6L857E89 xhd59uqBzcoDWsLk1jtGT2NOZIb7wcD.BbthKQ5SJaCnOXyLip8e81PROOOE4fvymVR3JBfB33C. 2el..VQNvUPJLcfKVrmtwLleY7kU6eiPzHv9JOOpZRSw92FiSY_h5wSTFmMIcqfCbf4Rwn8.VBlG DSDR7zMjqSYQtl2UP8ED0Jv3lGtnitnJao9oH.sDIvMMxSd4afDhZkqS3VHZ3pEVhYtAjyGyuOJ0 - X-Sonic-MF: X-Sonic-ID: 7260f396-7eed-4438-b288-10e8862bac99 Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sun, 2 Jul 2023 22:45:24 +0000 Received: by hermes--production-bf1-5d96b4b9f-jv67c (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dc0e7531edaab47a77528a0b69c8f629; Sun, 02 Jul 2023 22:45:22 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: top vs. array sorted_state's out of bounds indexing (and related issues) Message-Id: Date: Sun, 2 Jul 2023 15:45:10 -0700 To: cliftonr@volcano.org, FreeBSD Hackers X-Mailer: Apple Mail (2.3731.600.7) References: X-Spamd-Result: default: False [1.38 / 15.00]; NEURAL_SPAM_MEDIUM(0.73)[0.734]; NEURAL_SPAM_LONG(0.60)[0.596]; NEURAL_SPAM_SHORT(0.55)[0.545]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.205:from]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DKIM_TRACE(0.00)[yahoo.com:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.65.205:from] X-Rspamd-Queue-Id: 4QvPK21gzjz3MZv X-Spamd-Bar: + X-ThisMailContainsUnwantedMimeParts: N Clifton Royston wrote on Date: Sun, 02 Jul 2023 21:44:10 UTC : > On 7/2/2023 9:52 AM, Clifton Royston wrote: > > On 6/19/2023 6:05 AM, Konstantin Belousov wrote: > >> On Sun, Jun 18, 2023 at 09:23:06PM -0700, Mark Millard wrote: > >>> usr.bin/top/machine.c (from main) has: > [...] > >>> > >>> static int sorted_state[] = { > >>> 0, /* not used */ > >>> 3, /* sleep */ > >>> 1, /* ABANDONED (WAIT) */ > >>> 6, /* run */ > >>> 5, /* start */ > >>> 2, /* zombie */ > >>> 4 /* stop */ > >>> }; > >>> > >>> Note the elements are 0..6, so 7 elements. > >>> > >>> It is accessed via code like: > >>> > >>> sorted_state[(unsigned char)(b)->ki_stat] > > [...] > >>> /* > >>> * These were process status values (p_stat), now they are only > used in > >>> * legacy conversion code. > >>> */ > >>> #define SIDL 1 /* Process being created by fork. */ > >>> #define SRUN 2 /* Currently runnable. */ > >>> #define SSLEEP 3 /* Sleeping on an address. */ > >>> #define SSTOP 4 /* Process debugging or suspension. */ > >>> #define SZOMB 5 /* Awaiting collection by parent. */ > >>> #define SWAIT 6 /* Waiting for interrupt. */ > >>> #define SLOCK 7 /* Blocked on a lock. */ > >>> > > [...] > >>> } else if (TD_ON_LOCK(td)) { > >>> kp->ki_stat = SLOCK; > > [...] > >> https://reviews.freebsd.org/D40607 > > > > I rarely comment here and hesitate to now, but out of curiosity I > > looked at the original report and at the chain of commits. > > > > It appears to me that in making the code more readable the final > > result may have accidentally inverted the sort order from the intended > > values (mostly.) A casual test wouldn't show this, as unless the sort > > order in top were changed, normally it would only come into play for > > two processes with equal CPU % and ticks which seems unlikely. > [...] > > And, following up to myself, I now realized that both the committed > patch *and* my reply completely missed addressing the original issue > Mark reported: > > No value for the index SLOCK is included in the array initializer, Not true now. See below. > so > SLOCK is still not translated to a meaningful index, and AFAICT it is > not included in the dimensions! SLOCK has a element in the array now. See below. > I expect it would still result in the > same out-of-bounds indexing problem Mark reported for that case. Nope. See below. > A further corrected comment and array initializer: > > /* > * proc_compare - comparison function for "qsort" > * Compares the resource consumption of two processes using five > * distinct keys. The keys (in descending order of importance) are: > * percent cpu, cpu ticks, state, resident set size, total virtual > * memory usage. The process states are ordered as follows (from most > * to least important): run, zombie, idle (being created), interrupt > * wait, blocked on lock, stop, sleep. > * The array declaration below maps a process state index into a > * number that reflects this ordering. > */ > > static const int sorted_state[] = { > [SRUN] = 7, /* Currently runnable. */ > [SZOMB] = 6, /* Awaiting collection by parent. */ > [SIDL] = 5, /* Process being created by fork. */ > [SWAIT] = 4, /* Waiting for interrupt. */ > [SLOCK] = 3, /* Blocked on a lock. */ > [SSTOP] = 2, /* Process debugging or suspension. */ > [SSLEEP] = 1, /* Sleeping on an address. */ > } [I ignore here specific choices/views of what sort order should result.] Looking at modern /usr/main-src/usr.bin/top/machine.c in main's source I see: static const int sorted_state[] = { [SIDL] = 3, /* being created */ [SRUN] = 1, /* running/runnable */ [SSLEEP] = 6, /* sleeping */ [SSTOP] = 5, /* stopped/suspended */ [SZOMB] = 2, /* zombie */ [SWAIT] = 4, /* intr */ [SLOCK] = 7, /* blocked on lock */ }; In other words, after substitutions for the macros: static const int sorted_state[] = { [1] = 3, /* being created */ [2] = 1, /* running/runnable */ [3] = 6, /* sleeping */ [4] = 5, /* stopped/suspended */ [5] = 2, /* zombie */ [6] = 4, /* intr */ [7] = 7, /* blocked on lock */ }; That notation means (being explicit about the size and the implicit [0] case): static const int sorted_state[8] = { [0] = 0, /* implicit case */ [1] = 3, /* being created */ [2] = 1, /* running/runnable */ [3] = 6, /* sleeping */ [4] = 5, /* stopped/suspended */ [5] = 2, /* zombie */ [6] = 4, /* intr */ [7] = 7, /* blocked on lock */ }; It spans all the indexes for use of: #define SIDL 1 /* Process being created by fork. */ #define SRUN 2 /* Currently runnable. */ #define SSLEEP 3 /* Sleeping on an address. */ #define SSTOP 4 /* Process debugging or suspension. */ #define SZOMB 5 /* Awaiting collection by parent. */ #define SWAIT 6 /* Waiting for interrupt. */ #define SLOCK 7 /* Blocked on a lock. */ So there is no out of bounds access for any of those named values. === Mark Millard marklmi at yahoo.com From nobody Mon Jul 3 15:44:37 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qvqxh3zpHz4lWnc for ; Mon, 3 Jul 2023 15:45:12 +0000 (UTC) (envelope-from hiroo@oikumene.net) Received: from barleycorn.oikumene.net (tk2-231-25124.vs.sakura.ne.jp [160.16.110.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qvqxg1WfXz4GFM for ; Mon, 3 Jul 2023 15:45:11 +0000 (UTC) (envelope-from hiroo@oikumene.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of hiroo@oikumene.net designates 160.16.110.128 as permitted sender) smtp.mailfrom=hiroo@oikumene.net; dmarc=none Received: from nowhere.oikumene.ukehi.net (KD059129091046.ppp-bb.dion.ne.jp [59.129.91.46]) by barleycorn.oikumene.net (Postfix) with ESMTPSA id 5108361FC8 for ; Tue, 4 Jul 2023 00:45:07 +0900 (JST) Received: from localhost (nowhere.oikumene.ukehi.net [192.168.8.24]) by nowhere.oikumene.ukehi.net (8.17.2/8.17.1) with ESMTPS id 363Fj7nH037991 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 4 Jul 2023 00:45:07 +0900 (JST) (envelope-from hiroo@oikumene.net) X-Authentication-Warning: nowhere.oikumene.ukehi.net: Host nowhere.oikumene.ukehi.net [192.168.8.24] claimed to be localhost From: Hiroo Ono To: Subject: screenshot for vt(4) Date: Tue, 04 Jul 2023 00:44:37 +0900 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Message-ID: User-Agent: Trojita/0.7; Qt/5.15.8; xcb; AnyBSD4.4FreeBSD; Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.29 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.995]; R_SPF_ALLOW(-0.20)[+ip4:160.16.110.128:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[oikumene.net]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:9370, ipnet:160.16.0.0/17, country:JP]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4Qvqxg1WfXz4GFM X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hello, I made a patch to enable screenshot with vt(4). The patch is here. https://reviews.freebsd.org/D40858 I would like to hear comments and reviews if it can be merged to FreeBSD. When I mentioned it on mastodon, the patch lacked one file, sorry. Please try this if you want to get the patch in one file. http://barleycorn.oikumene.net/ports-patch/0001-Implement-screenshot-with-vt-= 4.patch There are three types of screenshot. 1. vidcontrol -p text < /dev/ttyv0 > screenshot.txt which generate plain text output. 2. vidcontrol -p term < /dev/ttyv0 > screenshot.txt which generate text with ansi escape sequences. 3. vidcontrol -p raw < /dev/ttyv0 > screenshot.raw which generate a raw picture file. The raw file can be converted to PNG via separate program. http://barleycorn.oikumene.net/ports-patch/vtraw2png.tar.gz=20 https://helixteamhub.cloud/individual674914/projects/vtraw2png/repositories/v= traw2png/tree/default It needs libpng (graphics/png). It only supports 32bit depth, but I think it is enough for vt(4). Sorry if=20= I am wrong. I only tested this patch on i386(vga) and amd64(efifb). The vga fb does not=20= support raw output (it does not have vt_fb_ioctl function). Best regards. From nobody Mon Jul 3 15:53:59 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qvr8V0D1kz4lcXy for ; Mon, 3 Jul 2023 15:54:34 +0000 (UTC) (envelope-from hiroo@oikumene.net) Received: from barleycorn.oikumene.net (tk2-231-25124.vs.sakura.ne.jp [160.16.110.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qvr8S3PNPz4KVt for ; Mon, 3 Jul 2023 15:54:32 +0000 (UTC) (envelope-from hiroo@oikumene.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of hiroo@oikumene.net designates 160.16.110.128 as permitted sender) smtp.mailfrom=hiroo@oikumene.net; dmarc=none Received: from nowhere.oikumene.ukehi.net (KD059129091046.ppp-bb.dion.ne.jp [59.129.91.46]) by barleycorn.oikumene.net (Postfix) with ESMTPSA id 40AC561F8E for ; Tue, 4 Jul 2023 00:54:30 +0900 (JST) Received: from localhost (nowhere.oikumene.ukehi.net [192.168.8.24]) by nowhere.oikumene.ukehi.net (8.17.2/8.17.1) with ESMTPS id 363FsUJf038876 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 4 Jul 2023 00:54:30 +0900 (JST) (envelope-from hiroo@oikumene.net) X-Authentication-Warning: nowhere.oikumene.ukehi.net: Host nowhere.oikumene.ukehi.net [192.168.8.24] claimed to be localhost From: Hiroo Ono To: Subject: Re: screenshot for vt(4) Date: Tue, 04 Jul 2023 00:53:59 +0900 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Message-ID: In-Reply-To: References: User-Agent: Trojita/0.7; Qt/5.15.8; xcb; AnyBSD4.4FreeBSD; Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.30 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip4:160.16.110.128:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[oikumene.net]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:9370, ipnet:160.16.0.0/17, country:JP]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4Qvr8S3PNPz4KVt X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Sorry, forgot to mention that there are examples here: http://barleycorn.oikumene.net/ports-patch/ On 2023=E5=B9=B47=E6=9C=884=E6=97=A5=E7=81=AB=E6=9B=9C=E6=97=A5 0=E6=99=8244=E5= =88=8637=E7=A7=92 JST, Hiroo Ono wrote: > Hello, > > I made a patch to enable screenshot with vt(4). The patch is here. > https://reviews.freebsd.org/D40858 > > I would like to hear comments and reviews if it can be merged to FreeBSD. > When I mentioned it on mastodon, the patch lacked one file, sorry. > Please try this if you want to get the patch in one file. > http://barleycorn.oikumene.net/ports-patch/0001-Implement-screenshot-with-v= t-4.patch > > There are three types of screenshot. > 1. vidcontrol -p text < /dev/ttyv0 > screenshot.txt > which generate plain text output. > 2. vidcontrol -p term < /dev/ttyv0 > screenshot.txt > which generate text with ansi escape sequences. > 3. vidcontrol -p raw < /dev/ttyv0 > screenshot.raw > which generate a raw picture file. > > The raw file can be converted to PNG via separate program. > http://barleycorn.oikumene.net/ports-patch/vtraw2png.tar.gz=20 > https://helixteamhub.cloud/individual674914/projects/vtraw2png/repositories= /vtraw2png/tree/default > It needs libpng (graphics/png). > It only supports 32bit depth, but I think it is enough for=20 > vt(4). Sorry if I am wrong. > > I only tested this patch on i386(vga) and amd64(efifb). The vga=20 > fb does not support raw output (it does not have vt_fb_ioctl=20 > function). > > Best regards. > > > From nobody Mon Jul 3 20:26:28 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QvyBv4dr8z4lnSr for ; Mon, 3 Jul 2023 20:27:03 +0000 (UTC) (envelope-from hiroo@oikumene.net) Received: from barleycorn.oikumene.net (tk2-231-25124.vs.sakura.ne.jp [160.16.110.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QvyBs59KZz4P71 for ; Mon, 3 Jul 2023 20:27:01 +0000 (UTC) (envelope-from hiroo@oikumene.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of hiroo@oikumene.net designates 160.16.110.128 as permitted sender) smtp.mailfrom=hiroo@oikumene.net; dmarc=none Received: from nowhere.oikumene.ukehi.net (KD059129091046.ppp-bb.dion.ne.jp [59.129.91.46]) by barleycorn.oikumene.net (Postfix) with ESMTPSA id 4251E61FC8 for ; Tue, 4 Jul 2023 05:26:58 +0900 (JST) Received: from localhost (nowhere.oikumene.ukehi.net [192.168.8.24]) by nowhere.oikumene.ukehi.net (8.17.2/8.17.1) with ESMTPS id 363KQwF2066303 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 4 Jul 2023 05:26:58 +0900 (JST) (envelope-from hiroo@oikumene.net) X-Authentication-Warning: nowhere.oikumene.ukehi.net: Host nowhere.oikumene.ukehi.net [192.168.8.24] claimed to be localhost From: Hiroo Ono To: Subject: Re: screenshot for vt(4) Date: Tue, 04 Jul 2023 05:26:28 +0900 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Message-ID: <5de73c09-86ac-4059-8f69-7fe5511e23e3@oikumene.net> In-Reply-To: References: User-Agent: Trojita/0.7; Qt/5.15.8; xcb; AnyBSD4.4FreeBSD; Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.11 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.987]; NEURAL_HAM_MEDIUM(-0.83)[-0.827]; R_SPF_ALLOW(-0.20)[+ip4:160.16.110.128:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[oikumene.net]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:9370, ipnet:160.16.0.0/17, country:JP]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4QvyBs59KZz4P71 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hello, I missed one point. There is no fb image buffer for ttys not displayed, so vidcontrol -p raw=20 can only grab what you are seeing on the monitor, regardless of which tty=20 you specify. Also, vtraw2png have a bug that colors are not properly converted. On 2023=E5=B9=B47=E6=9C=884=E6=97=A5=E7=81=AB=E6=9B=9C=E6=97=A5 0=E6=99=8253=E5= =88=8659=E7=A7=92 JST, Hiroo Ono wrote: > Sorry, forgot to mention that there are examples here: > http://barleycorn.oikumene.net/ports-patch/ > > On 2023=E5=B9=B47=E6=9C=884=E6=97=A5=E7=81=AB=E6=9B=9C=E6=97=A5 0=E6=99=824= 4=E5=88=8637=E7=A7=92 JST, Hiroo Ono wrote: >> Hello, >>=20 >> I made a patch to enable screenshot with vt(4). The patch is here. >> https://reviews.freebsd.org/D40858 >>=20 >> I would like to hear comments and reviews if it can be merged to FreeBSD. >> When I mentioned it on mastodon, the patch lacked one file, sorry. ... > > > > From nobody Mon Jul 3 20:32:39 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QvyKd5kKNz4lpPV for ; Mon, 3 Jul 2023 20:32:53 +0000 (UTC) (envelope-from tomek@cedro.info) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QvyKd5Kvyz4QTS for ; Mon, 3 Jul 2023 20:32:53 +0000 (UTC) (envelope-from tomek@cedro.info) Authentication-Results: mx1.freebsd.org; none Received: by mail-yb1-xb36.google.com with SMTP id 3f1490d57ef6-c2cf29195f8so5632152276.1 for ; Mon, 03 Jul 2023 13:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cedro.info; s=google; t=1688416372; x=1691008372; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FEEbmvUsAJgEcWns2TN9FDfB0HyjxXWz9PnDaplHbtg=; b=R6f7tNjOCsVGh36zgADWFdCs1s/Sb5642Z8tiBTrtNT88ZeU+gJ/uv33N587hch68D TYPH4ShkZCF44B32ah992SbjzYTCMx6AI5nfX7inRD+yjFxeDs8NqYgUbvndoz/vRKbH cm33aOWpLWUMJkjIzfGmr3tK2rlOY1Lf28C/7oZlGuJPY1uvxR60jl/nyqUDCXC4vLDX 4XKRr2v59wIs4KF+A4S+INKoYJbPP9tYWIVB9jTMXsDqnebV9X6Ra10WXEHY7zYdJFMd zBEn93bojGa9L7sC16yQW5ID9EZ3eVlp9XRaV6QJ9n5nM9FdEyj/m5UCSunOzxwTGvEP EkLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688416372; x=1691008372; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=FEEbmvUsAJgEcWns2TN9FDfB0HyjxXWz9PnDaplHbtg=; b=j3Aam2huFXHx5MF3fNWDS0l37oTN2JQ4urooZ6ldMycxfLg+Iqk3aVb3g12wm99NUq 0zXzKib1cqEtsCpziv6qWWBP9vEgVgSqHHyMEAIBeGXELeAbD586/xYzRhpDFrdoB/yj Wtv8YJ7DUVLHimaDPtEtmkxivOLNJiR/Kvy29Wsg92pOuoyP6faoUSXB55a4CNkFkJtT PUEs3ZFfuKM0+0ny5ze/Q/ys82+r0faSekZ1ISubQsQ0gfNTOL9oArs4bge/psjm17tn DS6eL6G499XsJae286MOkH0qbGhwEkvZ12KBZbKfb3gWmSBRqGEGnJXOGbzLYhNhkAY8 cL3w== X-Gm-Message-State: ABy/qLZTNBAptTdWOoO62WE0kjOk5LzKDdZsnuxgIWwtzdfxqEzTOOCr lkUt3zN30vGBBAi+QicdFHw6QthJSPsJkHo8JyY= X-Google-Smtp-Source: APBJJlFu8g0BxXZk+95HThHBFcIlcf6wG/EFYzvLhg50TtCnDdAuhbFoRTbMMzetVTRJY1/exhiU7Q== X-Received: by 2002:a25:25d3:0:b0:bfe:d92b:3970 with SMTP id l202-20020a2525d3000000b00bfed92b3970mr9775230ybl.63.1688416372520; Mon, 03 Jul 2023 13:32:52 -0700 (PDT) Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com. [209.85.219.175]) by smtp.gmail.com with ESMTPSA id t36-20020a252d24000000b00c4f175716fcsm1013987ybt.20.2023.07.03.13.32.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Jul 2023 13:32:52 -0700 (PDT) Received: by mail-yb1-f175.google.com with SMTP id 3f1490d57ef6-c2cf29195f8so5632138276.1 for ; Mon, 03 Jul 2023 13:32:51 -0700 (PDT) X-Received: by 2002:a25:3754:0:b0:c4e:24d:ae7f with SMTP id e81-20020a253754000000b00c4e024dae7fmr4931147yba.58.1688416371675; Mon, 03 Jul 2023 13:32:51 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Tomek CEDRO Date: Mon, 3 Jul 2023 22:32:39 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: screenshot for vt(4) To: Hiroo Ono Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4QvyKd5Kvyz4QTS X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Mon, Jul 3, 2023 at 5:45=E2=80=AFPM Hiroo Ono wrote: > Hello, > I made a patch to enable screenshot with vt(4). The patch is here. > https://reviews.freebsd.org/D40858 Very cool if this could be easily attached (but disabled by default) to PrintScreen button and save terminal shot in some predefined location (i.e. ~/.vt/screenshots/) :-) There is also nice tool to record and share terminal sessions that I use sometimes :-) https://asciinema.org/ --=20 CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From nobody Mon Jul 3 22:19:52 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qw0jl0N2Lz4lR2n for ; Mon, 3 Jul 2023 22:20:27 +0000 (UTC) (envelope-from hiroo@oikumene.net) Received: from barleycorn.oikumene.net (tk2-231-25124.vs.sakura.ne.jp [160.16.110.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qw0jj6bCcz3nT7 for ; Mon, 3 Jul 2023 22:20:25 +0000 (UTC) (envelope-from hiroo@oikumene.net) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of hiroo@oikumene.net designates 160.16.110.128 as permitted sender) smtp.mailfrom=hiroo@oikumene.net; dmarc=none Received: from nowhere.oikumene.ukehi.net (KD059129091046.ppp-bb.dion.ne.jp [59.129.91.46]) by barleycorn.oikumene.net (Postfix) with ESMTPSA id 6430761F8E for ; Tue, 4 Jul 2023 07:20:22 +0900 (JST) Received: from localhost (nowhere.oikumene.ukehi.net [192.168.8.24]) by nowhere.oikumene.ukehi.net (8.17.2/8.17.1) with ESMTPS id 363MKMvQ019640 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 4 Jul 2023 07:20:22 +0900 (JST) (envelope-from hiroo@oikumene.net) X-Authentication-Warning: nowhere.oikumene.ukehi.net: Host nowhere.oikumene.ukehi.net [192.168.8.24] claimed to be localhost From: Hiroo Ono To: Subject: Re: screenshot for vt(4) Date: Tue, 04 Jul 2023 07:19:52 +0900 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Message-ID: In-Reply-To: <5de73c09-86ac-4059-8f69-7fe5511e23e3@oikumene.net> References: <5de73c09-86ac-4059-8f69-7fe5511e23e3@oikumene.net> User-Agent: Trojita/0.7; Qt/5.15.8; xcb; AnyBSD4.4FreeBSD; Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.06 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.95)[-0.946]; NEURAL_HAM_MEDIUM(-0.82)[-0.818]; R_SPF_ALLOW(-0.20)[+ip4:160.16.110.128:c]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[oikumene.net]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:9370, ipnet:160.16.0.0/17, country:JP]; MIME_TRACE(0.00)[0:+]; TO_DN_NONE(0.00)[]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_XAW(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Queue-Id: 4Qw0jj6bCcz3nT7 X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On 2023=E5=B9=B47=E6=9C=884=E6=97=A5=E7=81=AB=E6=9B=9C=E6=97=A5 5=E6=99=8226=E5= =88=8628=E7=A7=92 JST, Hiroo Ono wrote: > Hello, > Also, vtraw2png have a bug that colors are not properly converted. It is fixed now. >> http://barleycorn.oikumene.net/ports-patch/ From nobody Tue Jul 4 04:34:35 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qw91m0bV2z4l4sR for ; Tue, 4 Jul 2023 04:34:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qw91k4hlCz4PGD for ; Tue, 4 Jul 2023 04:34:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 2001:470:d5e7:1::1 is neither permitted nor denied by domain of kostikbel@gmail.com) smtp.mailfrom=kostikbel@gmail.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=gmail.com (policy=none) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.17.1/8.17.1) with ESMTPS id 3644YZRs073513 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 4 Jul 2023 07:34:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 3644YZRs073513 Received: (from kostik@localhost) by tom.home (8.17.1/8.17.1/Submit) id 3644YZKK073512; Tue, 4 Jul 2023 07:34:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 4 Jul 2023 07:34:35 +0300 From: Konstantin Belousov To: Clifton Royston Cc: freebsd-hackers@freebsd.org Subject: Re: top vs. array sorted_state's out of bounds indexing (and related issues) Message-ID: References: <2ad2965e-ccc4-a202-2a58-0b2970aad925@volcano.org> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2ad2965e-ccc4-a202-2a58-0b2970aad925@volcano.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=4.0.0 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on tom.home X-Spamd-Result: default: False [1.02 / 15.00]; NEURAL_SPAM_LONG(0.96)[0.959]; NEURAL_SPAM_MEDIUM(0.96)[0.958]; NEURAL_HAM_SHORT(-0.90)[-0.899]; MIME_GOOD(-0.10)[text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCPT_COUNT_TWO(0.00)[2]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; TO_DN_SOME(0.00)[]; HAS_XAW(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_TLS_LAST(0.00)[] X-Rspamd-Queue-Id: 4Qw91k4hlCz4PGD X-Spamd-Bar: + X-ThisMailContainsUnwantedMimeParts: N On Sun, Jul 02, 2023 at 09:52:46AM -1000, Clifton Royston wrote: > On 6/19/2023 6:05 AM, Konstantin Belousov wrote: > > On Sun, Jun 18, 2023 at 09:23:06PM -0700, Mark Millard wrote: > > > usr.bin/top/machine.c (from main) has: > > > > > > /* > > > . . . The process states are ordered as follows (from least > > > * to most important): WAIT, zombie, sleep, stop, start, run. The > > > * array declaration below maps a process state index into a number > > > * that reflects this ordering. > > > */ > > > > > > static int sorted_state[] = { > > > 0, /* not used */ > > > 3, /* sleep */ > > > 1, /* ABANDONED (WAIT) */ > > > 6, /* run */ > > > 5, /* start */ > > > 2, /* zombie */ > > > 4 /* stop */ > > > }; > > > > > > Note the elements are 0..6, so 7 elements. > > > > > > It is accessed via code like: > > > > > > sorted_state[(unsigned char)(b)->ki_stat] > [...] > > > /* > > > * These were process status values (p_stat), now they are only used in > > > * legacy conversion code. > > > */ > > > #define SIDL 1 /* Process being created by fork. */ > > > #define SRUN 2 /* Currently runnable. */ > > > #define SSLEEP 3 /* Sleeping on an address. */ > > > #define SSTOP 4 /* Process debugging or suspension. */ > > > #define SZOMB 5 /* Awaiting collection by parent. */ > > > #define SWAIT 6 /* Waiting for interrupt. */ > > > #define SLOCK 7 /* Blocked on a lock. */ > > > > [...] > > > There is also the issue that: > > > > > > SIDL is misidentified as: sleep > > > SRUN is misidentified as: ABANDONED (WAIT) > > > SSLEEP is misidentified as: run > > > SZOMB is misidentified as: start > > > SWAIT is misidentified as: zombie > > > SLOCK is out of bounds (as indicated above). > > > > > > So the sort order in top is not as documented. > > > > > > > > > For reference, from sys/kern/kern_proc.c : > > > > > > if (p->p_state == PRS_NORMAL) { /* approximate. */ > > > if (TD_ON_RUNQ(td) || > > > TD_CAN_RUN(td) || > > > TD_IS_RUNNING(td)) { > > > kp->ki_stat = SRUN; > > > } else if (P_SHOULDSTOP(p)) { > > > kp->ki_stat = SSTOP; > > > } else if (TD_IS_SLEEPING(td)) { > > > kp->ki_stat = SSLEEP; > > > } else if (TD_ON_LOCK(td)) { > > > kp->ki_stat = SLOCK; > > > } else { > > > kp->ki_stat = SWAIT; > > > } > > > } else if (p->p_state == PRS_ZOMBIE) { > > > kp->ki_stat = SZOMB; > > > } else { > > > kp->ki_stat = SIDL; > > > } > > https://reviews.freebsd.org/D40607 > >   I rarely comment here and hesitate to now, but out of curiosity I looked > at the original report and at the chain of commits. > >   It appears to me that in making the code more readable the final result > may have accidentally inverted the sort order from the intended values > (mostly.)  A casual test wouldn't show this, as unless the sort order in top > were changed, normally it would only come into play for two processes with > equal CPU % and ticks which seems unlikely. > >   Perhaps I'm simply misreading the original which was itself confused on > the index values, but it appears from the original *comments*, as opposed to > the effects, that higher values are intended to sort as higher list > priority. For example, run was originally supposed to be mapped to 6 > (largest value), start to 5, and so on down to zombie mapped to 2 and WAIT > to 1. IMO no, the lower values put the process closer to the start of the sorted list. Could you provide an argument that this is not true? The chain is ORDERKEY_STATE compare_XXX compares get_process_info qsort(compares[idx]) The result is that lowest weight process appears at the beginning of the sorted process list. This is exactly what we want, IMHO: running first, sleeping last, and other states ordered somewhat arbitrary in between. > >   The rewrite with designated initializers in  rGbc2ac2585aa8 now maps - in > descending value order -  [SSLEEP] = 6, [SSTOP] = 5, [SWAIT] = 4 ... [SRUN] > = 1. > >   As long as this is being fixed, shouldn't it read more like this: > > /* > >  *  proc_compare - comparison function for "qsort" > >  *    Compares the resource consumption of two processes using five > >  *    distinct keys.  The keys (in descending order of importance) are: > >  *    percent cpu, cpu ticks, state, resident set size, total virtual > >  *    memory usage.  The process states are ordered as follows (from most > >  *    to least important):  run, zombie, idle, interrupt wait, stop, sleep. > >  *    The array declaration below maps a process state index into a > >  *    number that reflects this ordering. > >  */ > > static const int sorted_state[] = { > >     [SRUN] =    6,    /* running/runnable    */ > >     [SZOMB] =    5,    /* zombie        */ > >     [SIDL] =    4,    /* being created    */ > >     [SWAIT] =    3,    /* intr            */ > >     [SSTOP] =    2,    /* stopped/suspended    */ > >     [SSLEEP] =    1,    /* sleeping        */ > > >   I haven't read the entire context of how the values get used in the > comparison, so it's possible I have this wrong. > >   I'm assuming where SIDL and SWAIT should fall based on the revised > comments in rGd636fc5bd1e2 and the assumption that the original comment > "(from least to most important)" was misread as "(from most to least > important)" as I think one would normally want to see the "run" processes > ahead of the "sleep" processes etc. > >   Best regards, > >   -- Clifton > > (My apologies if this comes out garbled, as seemingly I have to fight > Thunderbird to edit for plain text output.) > > -- > > Clifton Royston > > From nobody Tue Jul 4 18:25:10 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QwWS61BThz4lnKL for ; Tue, 4 Jul 2023 18:25:26 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QwWS50bNRz44pX; Tue, 4 Jul 2023 18:25:25 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=R8fFCs4u; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 2607:f8b0:4864:20::a33 as permitted sender) smtp.mailfrom=asomers@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-47e57b8498aso706147e0c.2; Tue, 04 Jul 2023 11:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688495122; x=1691087122; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lw4l7P9lkrmv5InhAOsIgeLiY/verNX0uV8yhsdDetI=; b=R8fFCs4uyMPL+3IzQdL/zOFKJSO+UkM9IBTwcXXmCablwlqRF/2RNNtDVyAJbyfHij C41pE4J6xYFrlnE1FjdIQdS9S1wXCTZ0F0WXccqUMd2Bope/FaezJ02nzYl78Fbdt7FM ur0TT9Z5yPmVQNKcOgrRwZNcnaFM2/s0zuDtZJZMLNlAJ97bQ6WtZ6JMRvut6Ho/wTrE CXfUHIdAVHMDkZMPatJbXDbAkhTTvvjP29QBHpOoyQCK2tvfVLDPhFSHbuJQ9k4Cc4ro Cqs2tGG+XCfYKheFiAltPEsua25CDeNRd6+c/xICemcn0rTCDLYBVYA3PQKZVx8nmbgE 8wQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688495122; x=1691087122; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lw4l7P9lkrmv5InhAOsIgeLiY/verNX0uV8yhsdDetI=; b=P1Ao4cYhoCMBN4l8OJqfhA2L7dEUzV0Ho2z6PGnX0QYu5OUY3eJsKnmE+pQqDJuaSf LJQHrKAu+Yn7aXIiKVXY7tR/5XeCG9lhn1SrGZC7eH6Qu6zQ7Plbob/QsvJ97u9b03eH Niv2Dhng5t+55qO+P+qddWKvkpXhF//E1fZod7Ngcou0J+sNYEJ8Ugz1af1mz0ykGRK8 0V+tW/7DK0w1FpidIagNwrteYC3uJgvgX3Es8aDgEEugyN7qRC6zR55eoM6Hff12E/ZO w8RtBmOcFZQKrdqbCVao2Y38x1xPd+0utpqvmXs7jUCyPYFq2RgqY9PN5a+/SPVT31h2 7l1A== X-Gm-Message-State: ABy/qLZ2MxwHFwHLMf2rSq5FsYsB3VkOmmNduNSdFmbEijuqBGgSvG14 Qp+ON4AroZ4WvW/dHjCz/d84x+qbuu9RO0oXr3B99SWxih+fVg== X-Google-Smtp-Source: APBJJlE/+oTkYKpGfBJByreDtMkFXiy+Jgszj167egV+ng7t6n0+QBevoAltAbUkPZcyjaJ4RBCfpt3Sj6mBFfgWfLM= X-Received: by 2002:a1f:458f:0:b0:47e:19b4:85e9 with SMTP id s137-20020a1f458f000000b0047e19b485e9mr4553969vka.0.1688495122470; Tue, 04 Jul 2023 11:25:22 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: alan somers Date: Tue, 4 Jul 2023 11:25:10 -0700 Message-ID: Subject: Re: Should close() release locks atomically? To: Alan Somers Cc: Konstantin Belousov , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-0.87 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-0.99)[-0.989]; NEURAL_SPAM_MEDIUM(0.89)[0.889]; NEURAL_HAM_SHORT(-0.77)[-0.769]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a33:from]; FREEFALL_USER(0.00)[asomers]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; DKIM_TRACE(0.00)[gmail.com:+]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QwWS50bNRz44pX X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N On Sat, Jun 24, 2023 at 8:29=E2=80=AFAM Alan Somers w= rote: > > On Fri, Jun 23, 2023 at 1:53=E2=80=AFPM Alan Somers = wrote: > > > > On Fri, Jun 23, 2023 at 1:48=E2=80=AFPM Konstantin Belousov wrote: > > > > > > On Fri, Jun 23, 2023 at 01:11:34PM -0700, Alan Somers wrote: > > > > On Fri, Jun 23, 2023 at 1:03=E2=80=AFPM Konstantin Belousov wrote: > > > > > > > > > > On Fri, Jun 23, 2023 at 12:00:36PM -0700, Alan Somers wrote: > > > > > > The close() syscall automatically releases locks. Should it do= so > > > > > > atomically or is a delay permitted? I can't find anything in o= ur man > > > > > > pages or the open group specification that says. > > > > > > > > > > > > The distinction matters when using O_NONBLOCK. For example: > > > > > > > > > > > > fd =3D open(..., O_DIRECT | O_EXLOCK | O_NONBLOCK); //succeeds > > > > > > // do some I/O > > > > > > close(fd); > > > > > > fd =3D open(..., O_DIRECT | O_EXLOCK | O_NONBLOCK); //fails wit= h EAGAIN! > > > > > > > > > > > > I see this error frequently on a heavily loaded system. It isn= 't a > > > > > > typical thread race though; ktrace shows that only one thread t= ries to > > > > > > open the file in question. From the ktrace, I can see that the= final > > > > > > open() comes immediately after the close(), with no intervening > > > > > > syscalls from that thread. It seems that close() doesn't relea= se the > > > > > > lock right away. I wouldn't notice if I weren't using O_NONBLO= CK. > > > > > > > > > > > > Should this be considered a bug? If so I could try to come up = with a > > > > > > minimal test case. But it's somewhat academic, since I plan to > > > > > > refactor the code in a way that will eliminate the duplicate op= en(). > > > > > What type of the object is behind fd? O_NONBLOCK affects open it= self. > > > > > We release flock after object close method, but before close(2) r= eturns. > > > > > > > > This is a plain file on ZFS. > > > > > > Can you write a self-contained example, and check the same issue e.g.= on > > > tmpfs? > > > > I just reproduced it on tmpfs. A minimal test case will take some more= time... > > I'm afraid that I haven't been successful in creating a minimal test > case. My original test case, while it reliably reproduces the > problem, is huge. I'm sorry, but I think I'm going to declare ENOTIME > and get back to the aforementioned refactoring. I've finally succeeded in writing a minimal test case. The critical piece I was missing before was that other threads were forking in the background. Even though the file is opened O_CLOEXEC, the child process briefly keeps it locked. However, the file ought to get unlocked whenever _either_ that parent calls close() or the child calls fdcloseexec. So I don't understand how it could fail to get unlocked. I've posted the test case to Bugzilla. Let's move discussion there. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272367 -Alan From nobody Wed Jul 5 12:57:26 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Qx07N6J6cz4m7Sc for ; Wed, 5 Jul 2023 12:57:36 +0000 (UTC) (envelope-from Stephane.ROCHOY@stormshield.eu) Received: from mail.stormshield.eu (mail.stormshield.eu [91.212.116.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stormshield.eu", Issuer "Stormshield Servers CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qx07M1PFQz4N4S for ; Wed, 5 Jul 2023 12:57:35 +0000 (UTC) (envelope-from Stephane.ROCHOY@stormshield.eu) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=stormshield.eu header.s=signer header.b=NXvT0nIY; spf=pass (mx1.freebsd.org: domain of Stephane.ROCHOY@stormshield.eu designates 91.212.116.25 as permitted sender) smtp.mailfrom=Stephane.ROCHOY@stormshield.eu; dmarc=pass (policy=quarantine) header.from=stormshield.eu DKIM-Signature: v=1; a=rsa-sha256; d=stormshield.eu; s=signer; c=simple/simple; t=1688561847; h=from:subject:to:date:message-id; bh=P5d+fnkC8VTTjdBEC2xhnx/+sefHCe4i5FJK6ubwsQo=; b=NXvT0nIYnC23CxXSuaYSV9Yqdhcm7EeW2CxBY3N7wUHmNcCE3MZ93aluIZ9L8WGXwFEmKRZ5ikE pOOq/B1skTPZZMmT54tQMlZlc2/qTYc3JxVAe8ndbw0Lo3UaE6/sL83hZ4T3gBS0xBAHHtEAJSkP7 XPdE0PMKwT/Ygp88l+3qaZbUXJ+krbXaOwqTJs0OczNfVBtzIUH7p05OIjEyRvjejSh7h9xe9CYxz TFEkd8sLE22i2p0hXMNGVDucJ7yBgS5D89LZCx9CUyos0VQoOnG/4PEzrGrCMS9o75YROBflCtgqq NLGfyPao3h7gCpjYoFGV5nVyTT/Bq+v4bE3Q== Received: from cthulhu.stephaner.labo.int (10.100.17.16) by ICTDCCEXCH001.one.local (10.180.4.1) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.16; Wed, 5 Jul 2023 14:57:26 +0200 Received: by cthulhu.stephaner.labo.int (Postfix, from userid 1001) id A78711FDC9; Wed, 5 Jul 2023 14:57:26 +0200 (CEST) User-agent: mu4e 1.2.0; emacs 27.1 From: Stephane Rochoy To: Subject: Opening ARMv7 vmcores with LLDB Date: Wed, 5 Jul 2023 14:57:26 +0200 Message-ID: <86ilayjz2h.fsf@cthulhu.stephaner.labo.int> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.100.17.16] X-ClientProxiedBy: ICTDCCEXCH001.one.local (10.180.4.1) To ICTDCCEXCH001.one.local (10.180.4.1) X-Spamd-Result: default: False [-3.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-0.998]; NEURAL_HAM_SHORT(-0.90)[-0.899]; DMARC_POLICY_ALLOW(-0.50)[stormshield.eu,quarantine]; R_DKIM_ALLOW(-0.20)[stormshield.eu:s=signer]; R_SPF_ALLOW(-0.20)[+ip4:91.212.116.25/32]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[stormshield.eu:+]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; HAS_XOIP(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; ASN(0.00)[asn:49068, ipnet:91.212.116.0/24, country:FR] X-Rspamd-Queue-Id: 4Qx07M1PFQz4N4S X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N Hi Hackers, I struggle with lldb to open vmcores written by a 13.1 arm.armv7 kernel. I'm using LLDB 16.0.6 (from devel/llvm16) as follow: $ uname -a FreeBSD sns-debug-armv7.jail.=E2=80=A6 13.2-STABLE FreeBSD=20 14.0-CURRENT #14 =E2=80=A6-n258033-20b8fbf116f7: =E2=80=A6/arm64.aarch64/sys/AMP= ERE arm $ sysctl hw.machine_arch hw.machine_arch: armv7 $ file vmcore.last kernel vmcore.last: FreeBSD kernel minidump for arm, little endian, version 2 kernel: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), dynamically linked, interpreter /red/herring, BuildID[sha1]=3Db3d5fba55e096b9675ec3e374f73faa4c5c8df02, for FreeBSD 13.1, not stripped $ lldb16 -c vmcore.last kernel (lldb) target create "kernel" --core "vmcore.last" Core file '/home/stephaner/t/vmcore.last' (arm) was loaded. (lldb) bt error: Command requires a process which is currently stopped. (lldb) The previous commands are run from a jail built with=20 freebsd-ci[1]: OSRELEASE=3D13.2-STABLE-02a7d117b5914dd8c42b8d98fe92faca381148bd TARGET=3Darm TARGET_ARCH=3Darmv7 Despite looking at Moritz Systems'[2] blog regarding their (great) work I'm unable to tell if ARMv7 is supposed to be supported. The patches seems to be only about arm64, i386 and x86_64. (AFAIK their work landed somewhere in LLVM 15, that's why I'm using 16.) Any hint would be greatly appreciated :) [1] https://github.com/freebsd/freebsd-ci.git [2] https://www.moritz.systems/tags/lldb/ Regards, -- St=C3=A9phane Rochoy O: Stormshield From nobody Fri Jul 7 20:45:53 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QyQv60M3Lz4lybc for ; Fri, 7 Jul 2023 21:06:58 +0000 (UTC) (envelope-from yuri@FreeBSD.org) Received: from shell1.rawbw.com (shell1.rawbw.com [198.144.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4QyQv51k7Bz47tW for ; Fri, 7 Jul 2023 21:06:57 +0000 (UTC) (envelope-from yuri@FreeBSD.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=softfail (mx1.freebsd.org: 198.144.192.42 is neither permitted nor denied by domain of yuri@FreeBSD.org) smtp.mailfrom=yuri@FreeBSD.org; dmarc=none Received: from [192.168.5.3] (c-73-202-23-161.hsd1.ca.comcast.net [73.202.23.161]) (authenticated bits=0) by shell1.rawbw.com (8.15.1/8.15.1) with ESMTPSA id 367KjsoP041582 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Fri, 7 Jul 2023 13:45:54 -0700 (PDT) (envelope-from yuri@FreeBSD.org) X-Authentication-Warning: shell1.rawbw.com: Host c-73-202-23-161.hsd1.ca.comcast.net [73.202.23.161] claimed to be [192.168.5.3] Message-ID: <693faa01-ca5e-a71c-4e5c-aea4f505ce54@tsoft.com> Date: Fri, 7 Jul 2023 13:45:53 -0700 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Freebsd hackers list From: Yuri Subject: What is the equivalent of the linux system call clone() on FreeBSD? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [2.20 / 15.00]; VIOLATED_DIRECT_SPF(3.50)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.30)[-0.298]; RCVD_NO_TLS_LAST(0.10)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; MLMMJ_DEST(0.00)[freebsd-hackers@FreeBSD.org]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[yuri]; ARC_NA(0.00)[]; TO_DOM_EQ_FROM_DOM(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; HAS_XAW(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:7961, ipnet:198.144.192.0/19, country:US]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; GREYLIST(0.00)[pass,body] X-Rspamd-Queue-Id: 4QyQv51k7Bz47tW X-Spamd-Bar: ++ X-ThisMailContainsUnwantedMimeParts: N Linux has the clone() function that allows the caller more control over process cloning than the fork(2) function does. FreeBSD only has clone() in its Linux emulator code for Linux apps, but it seems to be missing in the system. Is there a library that implements functionality similar to Linux's clone()? Otherwise, how can clone() calls like this https://github.com/cea-hpc/wi4mpi/blob/master/src/common/helper.c#L82 be resolved on FreeBSD? Thanks, Yuri From nobody Fri Jul 7 21:23:34 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QyRH10Vv5z4m3bJ; Fri, 7 Jul 2023 21:24:13 +0000 (UTC) (envelope-from marietto2008@gmail.com) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QyRH02lCPz4FKb; Fri, 7 Jul 2023 21:24:12 +0000 (UTC) (envelope-from marietto2008@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=Vty4GDHG; spf=pass (mx1.freebsd.org: domain of marietto2008@gmail.com designates 2a00:1450:4864:20::634 as permitted sender) smtp.mailfrom=marietto2008@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-993a37b79e2so289648566b.1; Fri, 07 Jul 2023 14:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688765051; x=1691357051; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=Hp5adKXiGcMsRchgrFjdwRa0QIe8Hhf2c7Nz9L0LaS8=; b=Vty4GDHGyiyVECcbNQBkqXc8M6892m33GSi2ROGnpiiVTVymqBh8X+MPGv7CYDWqDl n5iiWSx4xBgKtkB7cs5h388AQdI9Yrk2BmUcS9O+W3XN7C2g2DJIgESNVfxjmQUqkX6B oMFvb7oJMwVYG548bGJRIPJ9m7G+2oOvgoVUqbgmiqKeXM3EZJDT42fZsjpDKMwosk7l 7QAJQkn/HJWx4ux88BbCmoLkBsPorfZv8x+RoeO7cGzziR/lLEMceeAe0tqvus+YLUk3 WmNFLRlD9CuD5v7NrWHRY4eik+1sPEjwfo0XEOOYxLL3e3hgXX3J0Rhh0KYlUE8eqSjX YDLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688765051; x=1691357051; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Hp5adKXiGcMsRchgrFjdwRa0QIe8Hhf2c7Nz9L0LaS8=; b=KHKc6S79YjRNAMT93MWn/TdPgZt0VX9yHXZxwwwefecASqqIvU6as+pA610gkqQVHy Qlj0gNyp9+5qe6j70UBK7G7ThQVHVHGlGU6fvICPwgtTHWkB0FoFIqUlW18RrkXuxFrp VcXUTgGoLbTkX0XgqDfxKor57sRVphLq3el6bPDaBZFBzHulBmStFBzidMHi0Lae2SuU 1vIZNK0bcwzPi0TTl2v2dWZI0S5oSPdzNUvPpabCXTA5yUod5tZB96DglsR/Y+GLngnT vw/N9NFHNxm99VKyvgqswhvEHXW1cz3VqhKHrfe6wTEi5cAR7nwzbg14RD7Ys6ZNtaUG qH2g== X-Gm-Message-State: ABy/qLalqSqklWQfNUyJ5Bu3CNVk12fT7Q2vylYdMurpcRa3VDzbK5Nb lNgh6G20bAT6IPeC6lV4g7loAeOn6TyhlpKyBHI= X-Google-Smtp-Source: APBJJlHvuWx2cGKBhHE7yrF2dFlKznEwX5TlNjQiE7/9u7v4chicYdjIZvp4cynMPvCIYHKIXzXCl+QYJYMH12D6Y9k= X-Received: by 2002:a17:906:7499:b0:98e:16b9:6c8c with SMTP id e25-20020a170906749900b0098e16b96c8cmr5169099ejl.14.1688765050496; Fri, 07 Jul 2023 14:24:10 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 From: Mario Marietto Date: Fri, 7 Jul 2023 23:23:34 +0200 Message-ID: Subject: Etnaviv Mesa graphics works good ? To: Ruslan Bukin , freebsd-arm@freebsd.org, freebsd-hackers , FreeBSD Mailing List , FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000f1abe205ffec40b0" X-Spamd-Result: default: False [-2.79 / 15.00]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.79)[-0.793]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::634:from]; MLMMJ_DEST(0.00)[freebsd-arm@freebsd.org,freebsd-hackers@freebsd.org,freebsd-questions@freebsd.org,freebsd-current@freebsd.org]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DKIM_TRACE(0.00)[gmail.com:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_SOME(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QyRH02lCPz4FKb X-Spamd-Bar: -- X-ThisMailContainsUnwantedMimeParts: N --000000000000f1abe205ffec40b0 Content-Type: text/plain; charset="UTF-8" Hello. Do any of you guys have a success story of using Etnaviv Mesa driver with whatever graphics on ARM platform? Is it possible to start X11/Wayland/FB with a Vivante GPU and RGB/MIPI display? -- Mario. --000000000000f1abe205ffec40b0 Content-Type: text/html; charset="UTF-8"
Hello.

Do any of you guys have a success story of using Etnaviv Mesa driver with whatever graphics on ARM platform? Is it possible to start X11/Wayland/FB with a Vivante GPU and RGB/MIPI display?

--
Mario.
--000000000000f1abe205ffec40b0-- From nobody Fri Jul 7 21:31:59 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QyRS13yjZz4m5M6 for ; Fri, 7 Jul 2023 21:32:01 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QyRS13R7fz4KDP; Fri, 7 Jul 2023 21:32:01 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id Hn2fqTuJCLAoIHt3Zq5p6B; Fri, 07 Jul 2023 21:32:01 +0000 Received: from spqr.komquats.com ([70.66.152.170]) by cmsmtp with ESMTPA id Ht3XqlrTf3fOSHt3Yqip6Z; Fri, 07 Jul 2023 21:32:01 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=64a88451 a=y8EK/9tc/U6QY+pUhnbtgQ==:117 a=y8EK/9tc/U6QY+pUhnbtgQ==:17 a=1iAygoCLSLMiyICj:21 a=kj9zAlcOel0A:10 a=ws7JD89P4LkA:10 a=GLwY3u6AAAAA:8 a=NEAV23lmAAAA:8 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=SzGwXmrm7qdw6aBcXBkA:9 a=CjuIK1q_8ugA:10 a=aH_FkMqe1q5rCaEqSjHH:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 a=LK5xJRSDVpKd5WXXoEvA:22 a=Kgq7MUCeuSZxtnmdROSF:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 9C0222172; Fri, 7 Jul 2023 14:31:59 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 94845291; Fri, 7 Jul 2023 14:31:59 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Yuri cc: Freebsd hackers list Subject: Re: What is the equivalent of the linux system call clone() on FreeBSD? In-reply-to: <693faa01-ca5e-a71c-4e5c-aea4f505ce54@tsoft.com> References: <693faa01-ca5e-a71c-4e5c-aea4f505ce54@tsoft.com> Comments: In-reply-to Yuri message dated "Fri, 07 Jul 2023 13:45:53 -0700." List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Jul 2023 14:31:59 -0700 Message-Id: <20230707213159.94845291@slippy.cwsent.com> X-CMAE-Envelope: MS4xfEQWIbLWyxvkGaP7v9gymLMQssspBAqHlG+QHGryoGIr19Ti6diU72iQQLmEG0QF4kkIpyt74HAd0ohZQIXGQ5s0QwEhRrfQiEWl+0k/K1S4s16SzxOt 785cD8IzKhq6IoNw4cstaAEY+vTeOUYvFFwcePTpTWUmeXgYm29QpZH2TserluYkAzk77XmpU095mNQfgXRp+zXC0L1wazHUcS+bUECbj7Cb9XyApI+LY0pL 1TJzD14lgF09M4wOx2pf7Q== X-Rspamd-Queue-Id: 4QyRS13R7fz4KDP X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N In message <693faa01-ca5e-a71c-4e5c-aea4f505ce54@tsoft.com>, Yuri writes: > Linux has the clone() function that allows the caller more control over > process cloning than the fork(2) function does. > > FreeBSD only has clone() in its Linux emulator code for Linux apps, but > it seems to be missing in the system. > > Is there a library that implements functionality similar to Linux's clone()? > > Otherwise, how can clone() calls like this > https://github.com/cea-hpc/wi4mpi/blob/master/src/common/helper.c#L82 be > resolved on FreeBSD? Linux replaced fork() and pthread_create() with clone(). > > > Thanks, > > Yuri > > > -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Fri Jul 7 21:53:41 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QyRx35sDPz4m9py for ; Fri, 7 Jul 2023 21:53:43 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QyRx25Rmfz3G1h; Fri, 7 Jul 2023 21:53:42 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Authentication-Results: mx1.freebsd.org; none Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 11D7B3C0199; Fri, 7 Jul 2023 21:53:41 +0000 (UTC) Date: Fri, 7 Jul 2023 21:53:41 +0000 From: Brooks Davis To: Yuri Cc: Freebsd hackers list Subject: Re: What is the equivalent of the linux system call clone() on FreeBSD? Message-ID: References: <693faa01-ca5e-a71c-4e5c-aea4f505ce54@tsoft.com> List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <693faa01-ca5e-a71c-4e5c-aea4f505ce54@tsoft.com> X-Rspamd-Queue-Id: 4QyRx25Rmfz3G1h X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Fri, Jul 07, 2023 at 01:45:53PM -0700, Yuri wrote: > Linux has the clone() function that allows the caller more control over > process cloning than the fork(2) function does. > > FreeBSD only has clone() in its Linux emulator code for Linux apps, but > it seems to be missing in the system. > > Is there a library that implements functionality similar to Linux's clone()? > > Otherwise, how can clone() calls like this > https://github.com/cea-hpc/wi4mpi/blob/master/src/common/helper.c#L82 be > resolved on FreeBSD? clone is at least partially implemented in terms of rfork(2) flags. It's not immediately obvious what the code is doing so I can't comment if you'll be able to do what you need rfork if if you really need a clone implementation. -- Brooks From nobody Sat Jul 8 16:09:32 2023 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QywFh6XRdz4lKWR for ; Sat, 8 Jul 2023 16:09:44 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QywFh66QWz41T9; Sat, 8 Jul 2023 16:09:44 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1688832584; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qf+W2/Wg6nJ4pgASAaDGYOuxgK8f2Y4Q+CRACrdCigo=; b=lUoi+s4+51AJ1aee7CVY9rzV6qEgnzixDidcXKVlxCsVgC/ovR09xofoQkYzeW7NP1Q/Xe 4LkgiCRZ9M1+hkUuUPJBl2wZQOJza8bzn/kCO3uJOYIDaj+s4tusy5WMazBLnVWb47Zcwm /QUl8hkSHk87twTolx0CAfwiQe8Ed6JvilAs4AaGMIsJqMIY241Qb2sVtg83xwEa4JHygi ixtdA7OMjhqt2o/jNSrviDbVSeR9wcEAkXRkSBGAOt0RxSUx4eP31Su7m6c5k1TqB7HQGZ TdCQM0ueN8wMFuNI7lvah3NIp4k8yuP/VLu9DIos4NOsxFjdl/3A2tksPGVptA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1688832584; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qf+W2/Wg6nJ4pgASAaDGYOuxgK8f2Y4Q+CRACrdCigo=; b=BYKn2Qb6Wt5fJ0+UNmryvvxMM1xxzyeZbNR5x4p2QzPhjgTGmw6lUM3YzyKPh3XOId+8mq Quxw6HYE52TDu7ouvSGawyqeVTWiabubTy878QGKviFLBYswVv4IjvJzEu5hpzOK2X71ra pi+z2UyUfO3da9NXqpuQr2tXX3CpbtG6renAT4A4eLgt54DNJ0FIibe9xirfGeQdF5ooPk X7pO3LNudR+gphYFZYcaSymrWTSA/Uks/M1r91BCdDO6A37Pz99ePAgeGAM7BTQbEM5n23 FeurBeRHgULMXXcTCsHmRplCoLlohQ4MIEtEeMh6vViQQjfTxg8CX9KBcqqvUA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1688832584; a=rsa-sha256; cv=none; b=Zn61Y//5bZ5rUl3iN2qgbr/4G1wGSf7t1RtsAy/bauLs6rJRbCdZHLg/dN5vkW0XPy9vZQ wk6loiI1UXOBzR78/SJ2LSgzdPjCU9SnWI3AmmkbTlx1mCg3p6wm+eJ5vcKGldfSyx11AV drKLLhgG9PbMNKErL0vi6Gq7xBDZa35HMTc6nPTXi5GBVLuNUJN+2IKDkC2eUU+NC0rwo2 6mOj9sbPz0egDrqdEyut2LQ2UIJTCLnWZ358+2uf+ivaYS7Dv+Wj2gwCBVpEjUXs9990Ww 7wyyOKFZxQ6Y3F1h+i+W6NKKswtVc3u0zIB7bY75kBuVsAf9+EaHQcjtmmGdSw== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QywFh50mfzGy6; Sat, 8 Jul 2023 16:09:44 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host86-141-212-56.range86-141.btcentralplus.com [86.141.212.56]) by smtp.theravensnest.org (Postfix) with ESMTPSA id B1E8E82BA; Sat, 8 Jul 2023 17:09:43 +0100 (BST) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: What is the equivalent of the linux system call clone() on FreeBSD? From: David Chisnall In-Reply-To: Date: Sat, 8 Jul 2023 17:09:32 +0100 Cc: Yuri , Freebsd hackers list Content-Transfer-Encoding: quoted-printable Message-Id: <1866F21E-9EBC-48C3-A4FC-76A87895A6F1@FreeBSD.org> References: <693faa01-ca5e-a71c-4e5c-aea4f505ce54@tsoft.com> To: Brooks Davis X-Mailer: Apple Mail (2.3731.600.7) X-ThisMailContainsUnwantedMimeParts: N On 7 Jul 2023, at 22:53, Brooks Davis wrote: >=20 > clone is at least partially implemented in terms of rfork(2) flags. > It's not immediately obvious what the code is doing so I can't comment > if you'll be able to do what you need rfork if if you really need a > clone implementation. The Linux kernel doesn=E2=80=99t really have a notion of threads as = distinct from processes. This leads to some really annoying things (the = Linux equivalent of PROC_PDEATHSIG_CTL kills the child process when the = parent thread exits, even if it is not the main thread in the parent = process and the parent is still happily running). This means that clone = (/ clone3) is not just standing in for rfork, it is also standing in for = thr_new. Depending on exactly what you=E2=80=99re doing with clone, you may want = one of: - rfork - pdfork - thr_new Unfortunately, rfork does not have a pdfork-like variant (yet) and so = there are some combinations of rfork flags that don=E2=80=99t let you = use process descriptors (procfds in Linux), whereas in Linux these are = orthogonal. David