From: Jakub Raczynski <j.raczynski@samsung.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev@vger.kernel.org, k.tegowski@samsung.com,
k.domagalski@samsung.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, mcoquelin.stm32@gmail.com,
alexandre.torgue@foss.st.com,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net 1/2] net/stmmac: Protect against zero queue DTS config
Date: Wed, 8 Jul 2026 09:18:17 +0200 [thread overview]
Message-ID: <ak35uSDb8YGJDixt@AMDC4622.eu.corp.samsungelectronics.net> (raw)
In-Reply-To: <d4fb7a9f-c0bb-4ced-8428-14bd2aa66d85@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 2008 bytes --]
On Tue, Jul 07, 2026 at 08:57:28PM +0200, Andrew Lunn wrote:
> On Tue, Jul 07, 2026 at 07:44:30PM +0200, Jakub Raczynski wrote:
> > Commit 8a7bca6de6de protected against inputing number of tx/rx_queues_to_use
> > over kernel supported limit in DTS config. AI review mentioned that we also
> > should protect against zero queue input, because this would cause issues
> > down the line. Missing config is not an issue as stmmac_plat_dat_alloc()
> > does apply '1' by default.
> >
> > Fix this by adding check for zero queues input during DTS parsing
> >
> > Fixes: 8a7bca6de6de ("net/stmmac: Apply MTL_MAX queue limit if config missing")
>
> I'm not sure a Fixes: is justified here. Does this bother somebody? As
> far as i understand, for this to actually do something the system is
> broken anyway?
Yes, more below
>
> > if (!of_property_read_u32(rx_node, "snps,rx-queues-to-use", &value)) {
> > if (value > MTL_MAX_RX_QUEUES)
> > value = MTL_MAX_RX_QUEUES;
> > + else if (value == 0)
> > + value = 1;
>
> If the DT is broken, don't we want it to be fixed? -EINVAL would make
> it obvious.
>
> Andrew
>
EINVAL would be better, I agree.
Mentioned patch changed U8_MAX -> MTL_MAX_RX_QUEUES (and TX), because
inputing more just panicked kernel and there was already verification for
that, so it was fixed by silent fix of incorrect value.
We triggered this while were testing XGMAC hardware that supports 16 queues
(current driver limit is 8). Original fix having EINVAL would also be good.
Inputing 0 is much less honest mistake but rather some testing how kernel
handles other/incorrect values. So at the very least, this should not be able
to panic kernel. But as above, I agree EINVAL actually would fit better here,
that will be for V2, and so it would for original 8a7bca6de6de.
Whether it justifies Fixes or not, I am not sure, it is real possibility to
trigger panic if system has dynamic DTS loading (CONFIG_OF_OVERLAY) on
system with wrong permissions.
BR
Jakub Raczynski
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2026-07-08 7:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20260707174437eucas1p2cedaa017eea6cd5696535b17925a3b53@eucas1p2.samsung.com>
2026-07-07 17:44 ` [PATCH net 0/2] net/stmmac: Verify more wrong DTS configuration Jakub Raczynski
2026-07-07 17:44 ` [PATCH net 1/2] net/stmmac: Protect against zero queue DTS config Jakub Raczynski
2026-07-07 18:57 ` Andrew Lunn
2026-07-08 7:18 ` Jakub Raczynski [this message]
2026-07-07 17:44 ` [PATCH net 2/2] net/stmmac: Verify provided DTS AXI setup Jakub Raczynski
2026-07-07 19:04 ` Andrew Lunn
2026-07-08 7:27 ` Jakub Raczynski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ak35uSDb8YGJDixt@AMDC4622.eu.corp.samsungelectronics.net \
--to=j.raczynski@samsung.com \
--cc=alexandre.torgue@foss.st.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=k.domagalski@samsung.com \
--cc=k.tegowski@samsung.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox