**** BEGIN LOGGING AT Tue Feb 11 02:59:58 2020 Feb 11 10:15:08 * ldir tiptoes in Feb 11 10:16:04 *booh* Feb 11 10:17:30 gaaahh!! Feb 11 10:18:24 * ldir walks out - it turns out I'm being dragged out by the other half. ldir is bemused.... again Feb 11 10:42:41 anyone tested this https://patchwork.ozlabs.org/project/openwrt/list/?series=155924 (ath10k-ct: update to 2020-01-29) and can give me Tested-by: ? :) Feb 11 11:10:17 sigh... I hate ustream Feb 11 11:43:19 jow: what are you cooking? Feb 11 11:47:04 debugging uhttpd/ustream-tls issues Feb 11 11:47:20 and it seems that entire setup is conceptionally broken Feb 11 12:04:45 ah, fun Feb 11 12:24:06 * ldir ambles in Feb 11 12:25:41 ynezz: for ath10k-ct, Tested-by: Stefan Lippers-Hollmann ipq806x/ qca9984 and ipq40xx/ ipq4019+qca9986 Feb 11 12:29:57 I've been running that since january 30th Feb 11 12:33:03 slh64: thanks! Feb 11 13:14:12 jow: any objections? seems correct to me https://patchwork.ozlabs.org/patch/1174815/ (uhttpd: cancel script killing only if process ends) Feb 11 13:20:56 ynezz: well it is a change in behaviour Feb 11 13:21:24 but fine with me Feb 11 13:33:35 how would you otherwise kill that script if it would never finish? problem of the script? Feb 11 13:40:57 the proper solution would be introducing a separate read timeout I guess. Thats how other servers handle it Feb 11 13:41:16 one timeout until the first content, then another body read timeout Feb 11 13:46:02 ok, thanks Feb 11 14:20:35 I think I tracked down the uhttpd/ustream/ssl interaction issue... but not sure if the fix is viable Feb 11 14:28:30 jow: and whats the problem ? Feb 11 14:35:31 when more than max_script_requests (default 3) CGI HTTPS requests are made to uhttpd, the excess requests are deferred and queued in memory Feb 11 14:36:09 the related ustream client socket descriptors remain in the uloop though and continue receiving client data (request headers, post data etc.) Feb 11 14:36:45 ustream will buffer the received data in its internal buffer list until that is exhausted at which point it raises the read_blocked flag Feb 11 14:37:40 the upper layer (ssl) ustream read_blocked state is then propagated into the lower layer (tcp) ustream Feb 11 14:39:21 upon receving an uloop read notify, the ustream handler first tries to allocate buffer space, then it receives socket data into the allocated bufer spaces Feb 11 14:39:42 if it fails to reserve buffer state (triggering read_blocked) it will bail out and do nothing Feb 11 14:40:19 which is fine, but since the underlying uloop is edge triggered and not level triggered, that client socket readable event is effectively "lost" and never redelivered Feb 11 14:40:59 ok Feb 11 14:41:05 i had to read that twice Feb 11 14:41:23 possibly introduce a pending flag ? Feb 11 14:41:37 end result is that the deferred cgi program is started and partially fed with post data (typically 4KB) Feb 11 14:42:04 but then that entire event machinery comes to a halt since the uloop will never retrigger a read event for that particular connection Feb 11 14:42:18 how about rather than process edge trigegrs set a flag and in a 2nd iteration process them, then only reset the flag if it succeded Feb 11 14:42:36 the cgi program continues to wait in a blocking read(stdin...) until its eventually killed due to execution timeout Feb 11 14:43:16 I think I found a minimal invasive fix, but I am not sure if it is complete or whether it would fail with larger inputs or other request constellations Feb 11 14:47:06 http://sprunge.us/F4ibwA Feb 11 14:48:42 looks legit Feb 11 16:21:24 I just pushed 15a0701cdde8 ("kernel: rewrite run_parsers_by_type() to use add_mtd_partitions()"), ping me about your devices not booting anymore **** ENDING LOGGING AT Wed Feb 12 03:00:33 2020