From nobody Thu Mar 06 14:43:27 2025 X-Original-To: wireless@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 4Z7scJ3PFgz5phPT for ; Thu, 06 Mar 2025 14:43:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lf1-f51.google.com (mail-lf1-f51.google.com [209.85.167.51]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Z7scJ1fKkz3JMn; Thu, 06 Mar 2025 14:43:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-f51.google.com with SMTP id 2adb3069b0e04-54955222959so824843e87.3; Thu, 06 Mar 2025 06:43:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741272222; x=1741877022; h=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=sPI6Whx2iXOzoa9R692rwLb+YcXlbhRiKAxOG/l1BhQ=; b=DnC+Bk1IpOzKuXR1fue7JDVwcf3wmqOJkKh33Y2tWPcax9W+kLjVLWp57B3XX5WYbl fV5d2E6CMcbpBXENkn1JwI7lqs7kPb3yIo0kLJ5rDqKtfd1LyT7xEBG+Wo/uZ0T6q4m2 ULNP+5a2Pw2z9/OWHXOkrqVwcDI93li/SICYLPQq1PjICGXK5SFeAclbOEU9mdNDgf+9 oTPenAqbTtxrwdKBdFEevKAFFF47h47AIxmjf++KJ0vn3wv80yYCyzUjYGCfUop/kCVG qfBThu6lOCqmz630S8WJcmYyUrErKIs0l2lM9LQFoqCcY0CPOMobFBwz1/5jmcFI6Ee2 BYVg== X-Forwarded-Encrypted: i=1; AJvYcCVb8VcZtCzHgFTn7YcmaEEhkPctco0nCDAyqTPXgiuh0927V2QFXXcOke4yP/NneOdd8IVnfJnTIQ==@freebsd.org X-Gm-Message-State: AOJu0YyoKNBwGTf0ZIEenKuTyg96puTjCErnIvkXACY7Es6bYamB3mqs 01jWclppBDyqoYJ9wCksRIQL/GLVcWhHRCOGG661dGZzldnulcopMLSXY4/we1pLdDSi4bQY5fB eNge05Zh98sJZP2ZSEbbFWgU4Tf7BCA== X-Gm-Gg: ASbGnct7TiEiqgmjaBdr7m6t6EeVGuhx9DzSTvmWvbkiJoMS+RzkC4PHghvwcsM+LdM LiFeda9bIxKrxtyTd2MEUyjVRyWVPHLgNXCCHkoOcVhGYGR6yOfqIHt/6QJFULU1yYTmszFRSGt jJ+wyM8Hl2dWAKzkYjjyjW1DiJlTM= X-Google-Smtp-Source: AGHT+IHnC2vf5ugmK8d3v8mIbGBYyEdzaZUKdaWzs648jmylo6F50Bijh94tU9FmCo9fQwlty4JfahN8MQlbKBru3Dc= X-Received: by 2002:a05:6512:1056:b0:545:c5f:8551 with SMTP id 2adb3069b0e04-5497d37705amr2668592e87.35.1741272221371; Thu, 06 Mar 2025 06:43:41 -0800 (PST) List-Id: Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-wireless List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-wireless@freebsd.org Sender: owner-freebsd-wireless@FreeBSD.org MIME-Version: 1.0 References: <38523r8n-46pr-9r68-8049-47pqqr774711@SerrOFQ.bet> <63xz4b6wrnhr4zwune5sbdflumjk5nlqwkq35cm2yh55sskkm7@nebya5fcoknu> <6257760p-p535-8p6q-8096-9489q6on4837@serrofq.bet> In-Reply-To: <6257760p-p535-8p6q-8096-9489q6on4837@serrofq.bet> From: Adrian Chadd Date: Thu, 6 Mar 2025 06:43:27 -0800 X-Gm-Features: AQ5f1Jp3rsXZ2LLrfE2gRvcrHeXACrY7u5fVuj_ojA9B1uABTA-ghdqyQzDuezo Message-ID: Subject: Re: HEADS UP! Do not update on main currently (panic - on boot) To: "Bjoern A. Zeeb" Cc: Baptiste Daroussin , FreeBSD wireless mailing list Content-Type: multipart/alternative; boundary="0000000000003656fb062fad8805" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Queue-Id: 4Z7scJ1fKkz3JMn X-Spamd-Bar: ---- --0000000000003656fb062fad8805 Content-Type: text/plain; charset="UTF-8" On Thu, 6 Mar 2025 at 06:34, Bjoern A. Zeeb wrote: > > Or multiple: > - unlocked register writes > - rtwn_cmd_sleepable() which defers it to a task which doesn't fly but > simply opens more problems, especially for the "SET" operation; > otherwise you'll have to hold all packets until you get a callback > (I presume) [and make sure crypto state doesn't change anymore]. > Even more fun, you have to make sure a del key is done before doing > another set; which either will have to error or sleep again if the > del is sitll pending so simply "reduces chances", or use the taskq > for serialization as well (going back to holding packets while any > crypto operation is in progress). > I did that for my ath10k driver - i buffered frames in a per-node queue until the key set/update finished, and then i unblocked. PITA, but it needed to be done. I had to do the buffering anyway - I needed to buffer frames until the firmware BSS JOIN command completed. So if you'd like, after we get the crypto cleanup stuff finished enough and landed, I can tackle seqno next (which removes the TX lock) and then I can work on pushing some per-STA queue pause stuff into net80211 so we can delay passing traffic until STA JOIN and key create/update. That way it's fixed for everyone. -adrian --0000000000003656fb062fad8805 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, 6 Mar 2025 at 06:34, Bjoern A.= Zeeb <bz@freebsd.org> wrote:
=C2=A0

Or multiple:
- unlocked register writes
- rtwn_cmd_sleepable() which defers it to a task which doesn't fly but<= br> =C2=A0 =C2=A0simply opens more problems, especially for the "SET"= operation;
=C2=A0 =C2=A0otherwise you'll have to hold all packets until you get a = callback
=C2=A0 =C2=A0(I presume) [and make sure crypto state doesn't change any= more].
=C2=A0 =C2=A0Even more fun, you have to make sure a del key is done before = doing
=C2=A0 =C2=A0another set; which either will have to error or sleep again if= the
=C2=A0 =C2=A0del is sitll pending so simply "reduces chances", or= use the taskq
=C2=A0 =C2=A0for serialization as well (going back to holding packets while= any
=C2=A0 =C2=A0crypto operation is in progress).

I did that for my ath10k driver - i buffered frames in a per-node q= ueue until the
key set/update finished, and then i unblocked. PIT= A, but it needed to be done.
I had to do the buffering anyway - I= needed to buffer frames until the firmware
BSS JOIN command comp= leted.

So if you'd like, after we get the cryp= to cleanup stuff finished enough and
landed, I can tackle seqno n= ext (which removes the TX lock) and then I can
work on pushing so= me per-STA queue pause stuff into net80211 so we can
delay passin= g traffic until STA JOIN and key create/update. That way it's
fixed for everyone.



-adrian

--0000000000003656fb062fad8805--