From nobody Thu Feb 10 17:59:00 2022 X-Original-To: freebsd-transport@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 8B54A19B178D for ; Thu, 10 Feb 2022 17:59:14 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jvkym1RdMz3pvJ for ; Thu, 10 Feb 2022 17:59:12 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 0601E8D4A15D; Thu, 10 Feb 2022 17:59:03 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 77C8DE707D9; Thu, 10 Feb 2022 17:59:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id KAdxRfbjFV-l; Thu, 10 Feb 2022 17:59:02 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id CA49BE707B1; Thu, 10 Feb 2022 17:59:01 +0000 (UTC) Date: Thu, 10 Feb 2022 17:59:00 +0000 (UTC) From: "Bjoern A. Zeeb" To: Drew Gallatin cc: Ryan Stone , "" Subject: Re: panic: syncache: mbuf too small In-Reply-To: Message-ID: References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-transport List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-transport@freebsd.org X-BeenThere: freebsd-transport@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4Jvkym1RdMz3pvJ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 2a01:4f8:13b:39f::9f:25 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:39f::9f:25]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[zabbadoz.net]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[freebsd-transport]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: N On Wed, 9 Feb 2022, Drew Gallatin wrote: > Good point. It looks like TCP already does this for tcp_output(): > > #ifdef INET6 > if (MHLEN < hdrlen + max_linkhdr) > m = m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR); > else > #endif > m = m_gethdr(M_NOWAIT, MT_DATA); > A few comments: (a) there's no reason anymore (especially after the bwn/bwi numbers I saw) that the above is limited to IPv6 so that #ifdef should go; and without looking at the code I'd hope there'd be a follow-up length check. (b) if one wireless driver bumps max_linkhdr on the system it bumps it for everything; in theory we could do it on a per-interface basis but that's just route lookups and all kinds of things probably not in the right place these days and more complications. (c) despite (b) of course a "server" w/o wireless or a machine without a problemtic driver would currently not hit the more pessimistic path and be good with m_gethdr() in these cases. (d) I currently can avoid (and successfully did) this with the rtw88 which triggered it for me; eventually I'll have to find a better solution for it but for the next weeks I'll be good. (e) So even if we are good for now, looking through mbuf.h made me "cry" the other day. It's very well engineered but the simplicity it once had is long gone; but that remains a story for another day (maybe the 2nd half of this year). /bz -- Bjoern A. Zeeb r15:7