From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=none smtp.mailfrom=mojatatu.com; dkim=pass header.d=mojatatu-com.20230601.gappssmtp.com; arc=pass; dmarc=none Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by mail.toke.dk (Postfix) with ESMTPS id B2CADE0167F for ; Fri, 13 Mar 2026 16:56:41 +0100 (CET) Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-82418b0178cso1414538b3a.1 for ; Fri, 13 Mar 2026 08:56:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773417399; cv=none; d=google.com; s=arc-20240605; b=T/l8ylk4PeceKSGj7XoNKxtgxcUss6JtU9C1DWJ0yFl9FlEu8biu3hY4RaS69BNKMF sjDIWhXQWio+xP3ga0rIEbNTkrdKGchfDYj6n/r/lHey6cnQentMDCJYXt+Q3RDp1vOB +Sxunfa44qaeWa2QDofsJHgn5KLSoq8nu6nSR6ldIVzKZkzt78965HIbzAFwQtJmDrqp QNNTS9HMo5Q/X8/vZRbZNLx0j6KUux9chHHUu7MXllyVnYmuf5ZfxlyXtNuhk2lBiaCE knJtg6MbjI79o+IwJu+3cd01fm+HfKeBinjzMYd1jg+ZDxQ09ZVStJvGCVEIzN3BIpTU Jzlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=nsUa3+3B6RN4LCDLMBVKPL0aCncmwB7rIzU/94GsesA=; fh=f5tK8fL+2z5cguhXXVkZLn5PHVLGjYXcyekO8l8m6jY=; b=CUfs2Pvn3m5O1hpNGw5Kbt/QUF0mS80JGifShzYnIXP2GdJueev/YXo8Gyon56KETa weTnzJmQ53YPIY2DfU4nsdQDXYsv3TTy8CgWngIYtFWv1aq9SmYh3O8UayDQkUvLko3h EpNKIS7g9RvFtZ4+sx+bf2REN1KQWU5D24F5uf5/qKq/TSj8Mx0RDBr8vVkg014seBWR jOjmxjat/KVASfJ1MYxthR4E0Th+usQc56N7jW7WqdbljELayIaosXql6F5G4hsT5Ilq twmi+QKwHw6eZPLyU79x3m2C7y0X0JqLC/HzwGFQtbYtI2idWgxXoggI4thQ8RdukMwp egQA==; darn=lists.bufferbloat.net ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mojatatu-com.20230601.gappssmtp.com; s=20230601; t=1773417399; x=1774022199; darn=lists.bufferbloat.net; 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=nsUa3+3B6RN4LCDLMBVKPL0aCncmwB7rIzU/94GsesA=; b=NP8F187FyPU4j3ttkTQrK6jBI7L7FccFl5PZXHjGbUxAu7GX20KrofHd6udwWrBg4l 0tMPuNDhNTcElMnontluOu1nrtK6rgyuOKKTjvBJB1ogkXB3pKiX8hW9bvHv4RTtL/Pb GF6CK+NiIPn874MiHqEhkHa3haDb8SCnsyZidvqgZPZQgdrMR5DQzQhC5Cuv0Bp9gwUC mxsYx01HDFvmss0pdAsIhCvqt5d/gJ1WP/yVZqJGSlo/pIzcFx4onkk3DN7UzZFXH4OF KgOdaDIBhA66zgbvKCZdrTv8wqoGMAlT4h+8opCRIwR219iC0M1pq9fu18y7SkFKhKTA BW1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773417399; x=1774022199; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=nsUa3+3B6RN4LCDLMBVKPL0aCncmwB7rIzU/94GsesA=; b=d8I7k9kiYc4ZiBNJ1D+5sUW7ahChptk49f9zefy8/bPGGB1+Hf41n8eMibijUm7Kbf fNaawDb5n/G4dSp0wIpwPqx0rjd2AvSUQrar4bo0uTyphKiS8E0y2dneDKIaIh8X1ilu 2xy1sMBeL9mWvopG6WXJXmipzWH8HpcRprrkAmodUBgtvbJg5oGgNeL3Zi0dNR0LnIns 7gUStt1+tYOKy1K3jfJL8Y5foVfvJU+epxh+mvOntxgVmlonHwoz+yD+UnD3YX1KfgXE IZQbLW1LrxrP0rBdWeDCfmfzzkA7e2pGGxGKdI0bxpYJjWMMEH4980swI/PFf3SBv5z1 BeHQ== X-Forwarded-Encrypted: i=1; AJvYcCUxN1zdsX2ltdEua72ih6ZjOdgj9l5rgfhTjEcymbCPTKXc4DGA5OwEmgNzNe286+iygKE9@lists.bufferbloat.net X-Gm-Message-State: AOJu0YzJRp+xSd3UDzNMYfpZgkgvGaDrOL0hRtYcBu/+skr6sZzgpy8s ELq/vZHunB2IsJSOQGxbZrweTdSPd4rz4+25WjkNeobpCS8DPUEPls+9abTHqzzbNtYIGnlvkVd eGGTDmjPM1R2+sFypM0ETGyjeaLYkufk+yE9v9S4H X-Gm-Gg: ATEYQzxES+TPOhKILujpTxkZEfDDrIZiIhdsGMFZWvBHA5a6ChA9pWgk7jQ2BMBNozT wxf0jdjBiRpVoLb14zemGF7YpWyixd0M3uxPLVA0H6tMtmjy3pZtNELy3pQ9QbF99RBCRzhHoNr /RqYMEuquHa/cDveAndkErpnuEwZ0oKuHH8xBop+ttVoOguTeCYcaEUfRRRNSLRcMyAFabEx450 KxLK8e3grgA3kjbgIuWDDO2vhekjcj3iupxtQSmmoz7vcbNf/upG+6CyoXx/qKiVZY52LWbcqlW Nd1Ebsbxgunl7YA= X-Received: by 2002:a05:6a00:7598:b0:827:28ba:ff00 with SMTP id d2e1a72fcca58-82a19711a89mr2559770b3a.18.1773417398762; Fri, 13 Mar 2026 08:56:38 -0700 (PDT) MIME-Version: 1.0 References: <20260307212058.169511-1-jhs@mojatatu.com> <20260310184713.7e810431@kernel.org> <20260311175249.54abe1b6@kernel.org> <20260312165113.773a5f44@kernel.org> In-Reply-To: <20260312165113.773a5f44@kernel.org> From: Jamal Hadi Salim Date: Fri, 13 Mar 2026 11:56:26 -0400 X-Gm-Features: AaiRm50MOGl4w3-L4BgOwap80DymsQR40mcNnEN5B2Df3vQGH6sofP4bOPy4H1Y Message-ID: To: Jakub Kicinski Cc: netdev@vger.kernel.org, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, horms@kernel.org, jiri@resnulli.us, toke@toke.dk, vinicius.gomes@intel.com, stephen@networkplumber.org, vladbu@nvidia.com, cake@lists.bufferbloat.net, bpf@vger.kernel.org, ghandatmanas@gmail.com, km.kim1503@gmail.com, security@kernel.org, Victor Nogueira Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Message-ID-Hash: RY22USXGES5OBCZ34U434DSSM5FWHR2F X-Message-ID-Hash: RY22USXGES5OBCZ34U434DSSM5FWHR2F X-MailFrom: jhs@mojatatu.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Cake] Re: [PATCH net] net/sched: Mark qdisc for deletion if graft cannot delete List-Id: Cake - FQ_codel the next generation Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu, Mar 12, 2026 at 7:51=E2=80=AFPM Jakub Kicinski wr= ote: > > On Thu, 12 Mar 2026 16:36:48 -0400 Jamal Hadi Salim wrote: > > > > Two of the several (I think 4!) patches we had took a similar path.= I > > > > am trying to remember at least one variant was bad for performance = and > > > > the other was unstable. Let's see if we can revive it and take a > > > > closer look. BTW - none were pretty, it was maybe half the lines of > > > > code but touched many things. > > > > > > FWIW / of course, we have to apply similar change to all(?) callers o= f > > > __tcf_qdisc_find in cls_api. So LOC-wise it may end up also pretty lo= ng. > > > And it's not going to help the already spaghetti-looking locking. But > > > even if it's more LoC I quite like the idea of containing the poopy > > > code to where problems originate which is the lockless filter handlin= g. > > > Fingers crossed.. > > > > Something like attached. > > Unfortunately after running it for a few hours it reproduced. > > The action code path (entered by virtue of filter code path execution) > > releases the rtnl when attempting to load an action module. A parallel > > qdisc operation waiting for the lock then grabs it and we hit the same > > issue... > > > > So now we have to be more invasive and start coordinating the action > > code etc, which is not appealing. Thoughts? > > I see. Doesn't seem entirely crazy to let tcf_proto_lookup_ops() > return -EAGAIN without actually loading the module, and have it's > call path (of which there are only 2?) do the module loading once > all the locks are released. The call paths handle the EAGAIN and > retry already they just assume tcf_proto_lookup_ops() has loaded > the module so they don't have to. I might not be entirely following what you are saying. The core issue is not module loading perse. We can avoid module loading in tcf_proto_lookup_ops while the rtnl lock is released and the qdisc refcnt is greater than 1 (which is what the patch i sent attempted). The new quark is when we have actions associated with the filter. I will send you a much lengthier description of the issue in an hour or two to get us on the same page. cheers, jamal