From: Dan Carpenter <dan.carpenter@oracle.com>
To: kbuild@lists.01.org
Subject: Re: [PATCH net-next 09/12] net: dsa: tag_ocelot: create separate tagger for Seville
Date: Mon, 15 Feb 2021 17:15:21 +0300 [thread overview]
Message-ID: <20210215141521.GC2222@kadam> (raw)
In-Reply-To: <20210215131931.4nibzc53doqiignb@skbuf>
[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]
On Mon, Feb 15, 2021 at 03:19:31PM +0200, Vladimir Oltean wrote:
> Hi Dan,
>
> On Mon, Feb 15, 2021 at 04:00:04PM +0300, Dan Carpenter wrote:
> > db->index is less than db->num_ports which 32 or less but sometimes it
> > comes from the device tree so who knows.
>
> The destination port mask is copied into a 12-bit field of the packet,
> starting at bit offset 67 and ending at 56:
>
> static inline void ocelot_ifh_set_dest(void *injection, u64 dest)
> {
> packing(injection, &dest, 67, 56, OCELOT_TAG_LEN, PACK, 0);
> }
>
> So this DSA tagging protocol supports at most 12 bits, which is clearly
> less than 32. Attempting to send to a port number > 12 will cause the
> packing() call to truncate way before there will be 32-bit truncation
> due to type promotion of the BIT(port) argument towards u64.
>
> > The ocelot_ifh_set_dest() function takes a u64 though and that
> > suggests that BIT() should be changed to BIT_ULL().
>
> I understand that you want to silence the warning, which fundamentally
> comes from the packing() API which works with u64 values and nothing of
> a smaller size. So I can send a patch which replaces BIT(port) with
> BIT_ULL(port), even if in practice both are equally fine.
I don't have a strong feeling about this... Generally silencing
warnings just to make a checker happy is the wrong idea.
To be honest, I normally ignore these warnings. But I have been looking
at them recently to try figure out if we could make it so it would only
generate a warning where "db->index" was known as possibly being in the
32-63 range. So I looked at this one.
And now I see some ways that Smatch could have parsed this better...
regards,
dan carpenter
WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: kbuild-all@lists.01.org
Subject: Re: [PATCH net-next 09/12] net: dsa: tag_ocelot: create separate tagger for Seville
Date: Mon, 15 Feb 2021 17:15:21 +0300 [thread overview]
Message-ID: <20210215141521.GC2222@kadam> (raw)
In-Reply-To: <20210215131931.4nibzc53doqiignb@skbuf>
[-- Attachment #1: Type: text/plain, Size: 1731 bytes --]
On Mon, Feb 15, 2021 at 03:19:31PM +0200, Vladimir Oltean wrote:
> Hi Dan,
>
> On Mon, Feb 15, 2021 at 04:00:04PM +0300, Dan Carpenter wrote:
> > db->index is less than db->num_ports which 32 or less but sometimes it
> > comes from the device tree so who knows.
>
> The destination port mask is copied into a 12-bit field of the packet,
> starting at bit offset 67 and ending at 56:
>
> static inline void ocelot_ifh_set_dest(void *injection, u64 dest)
> {
> packing(injection, &dest, 67, 56, OCELOT_TAG_LEN, PACK, 0);
> }
>
> So this DSA tagging protocol supports at most 12 bits, which is clearly
> less than 32. Attempting to send to a port number > 12 will cause the
> packing() call to truncate way before there will be 32-bit truncation
> due to type promotion of the BIT(port) argument towards u64.
>
> > The ocelot_ifh_set_dest() function takes a u64 though and that
> > suggests that BIT() should be changed to BIT_ULL().
>
> I understand that you want to silence the warning, which fundamentally
> comes from the packing() API which works with u64 values and nothing of
> a smaller size. So I can send a patch which replaces BIT(port) with
> BIT_ULL(port), even if in practice both are equally fine.
I don't have a strong feeling about this... Generally silencing
warnings just to make a checker happy is the wrong idea.
To be honest, I normally ignore these warnings. But I have been looking
at them recently to try figure out if we could make it so it would only
generate a warning where "db->index" was known as possibly being in the
32-63 range. So I looked at this one.
And now I see some ways that Smatch could have parsed this better...
regards,
dan carpenter
WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: kbuild@lists.01.org, "David S . Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, lkp@intel.com, kbuild-all@lists.01.org,
Andrew Lunn <andrew@lunn.ch>,
Florian Fainelli <f.fainelli@gmail.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
Richard Cochran <richardcochran@gmail.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Vladimir Oltean <vladimir.oltean@nxp.com>
Subject: Re: [PATCH net-next 09/12] net: dsa: tag_ocelot: create separate tagger for Seville
Date: Mon, 15 Feb 2021 17:15:21 +0300 [thread overview]
Message-ID: <20210215141521.GC2222@kadam> (raw)
In-Reply-To: <20210215131931.4nibzc53doqiignb@skbuf>
On Mon, Feb 15, 2021 at 03:19:31PM +0200, Vladimir Oltean wrote:
> Hi Dan,
>
> On Mon, Feb 15, 2021 at 04:00:04PM +0300, Dan Carpenter wrote:
> > db->index is less than db->num_ports which 32 or less but sometimes it
> > comes from the device tree so who knows.
>
> The destination port mask is copied into a 12-bit field of the packet,
> starting at bit offset 67 and ending at 56:
>
> static inline void ocelot_ifh_set_dest(void *injection, u64 dest)
> {
> packing(injection, &dest, 67, 56, OCELOT_TAG_LEN, PACK, 0);
> }
>
> So this DSA tagging protocol supports at most 12 bits, which is clearly
> less than 32. Attempting to send to a port number > 12 will cause the
> packing() call to truncate way before there will be 32-bit truncation
> due to type promotion of the BIT(port) argument towards u64.
>
> > The ocelot_ifh_set_dest() function takes a u64 though and that
> > suggests that BIT() should be changed to BIT_ULL().
>
> I understand that you want to silence the warning, which fundamentally
> comes from the packing() API which works with u64 values and nothing of
> a smaller size. So I can send a patch which replaces BIT(port) with
> BIT_ULL(port), even if in practice both are equally fine.
I don't have a strong feeling about this... Generally silencing
warnings just to make a checker happy is the wrong idea.
To be honest, I normally ignore these warnings. But I have been looking
at them recently to try figure out if we could make it so it would only
generate a warning where "db->index" was known as possibly being in the
32-63 range. So I looked at this one.
And now I see some ways that Smatch could have parsed this better...
regards,
dan carpenter
next prev parent reply other threads:[~2021-02-15 14:15 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-13 0:14 [PATCH net-next 00/12] PTP for DSA tag_ocelot_8021q Vladimir Oltean
2021-02-13 0:14 ` [PATCH net-next 01/12] net: mscc: ocelot: stop returning IRQ_NONE in ocelot_xtr_irq_handler Vladimir Oltean
2021-02-13 0:14 ` [PATCH net-next 02/12] net: mscc: ocelot: only drain extraction queue on error Vladimir Oltean
2021-02-13 0:14 ` [PATCH net-next 03/12] net: mscc: ocelot: better error handling in ocelot_xtr_irq_handler Vladimir Oltean
2021-02-13 0:14 ` [PATCH net-next 04/12] net: mscc: ocelot: use DIV_ROUND_UP helper in ocelot_port_inject_frame Vladimir Oltean
2021-02-13 0:14 ` [PATCH net-next 05/12] net: mscc: ocelot: refactor ocelot_port_inject_frame out of ocelot_port_xmit Vladimir Oltean
2021-02-13 0:14 ` [PATCH net-next 06/12] net: dsa: tag_ocelot: avoid accessing ds->priv in ocelot_rcv Vladimir Oltean
2021-02-13 0:14 ` [PATCH net-next 07/12] net: mscc: ocelot: use common tag parsing code with DSA Vladimir Oltean
2021-02-13 0:14 ` [PATCH net-next 08/12] net: dsa: tag_ocelot: single out PTP-related transmit tag processing Vladimir Oltean
2021-02-13 0:14 ` [PATCH net-next 09/12] net: dsa: tag_ocelot: create separate tagger for Seville Vladimir Oltean
2021-02-15 13:00 ` Dan Carpenter
2021-02-15 13:00 ` Dan Carpenter
2021-02-15 13:00 ` Dan Carpenter
2021-02-15 13:19 ` Vladimir Oltean
2021-02-15 14:15 ` Dan Carpenter [this message]
2021-02-15 14:15 ` Dan Carpenter
2021-02-15 14:15 ` Dan Carpenter
2021-02-15 14:49 ` Vladimir Oltean
2021-02-13 0:14 ` [PATCH net-next 10/12] net: mscc: ocelot: refactor ocelot_xtr_irq_handler into ocelot_xtr_poll Vladimir Oltean
2021-02-13 0:14 ` [PATCH net-next 11/12] net: dsa: felix: setup MMIO filtering rules for PTP when using tag_8021q Vladimir Oltean
2021-02-13 0:14 ` [PATCH net-next 12/12] net: dsa: tag_ocelot_8021q: add support for PTP timestamping Vladimir Oltean
2021-02-13 7:42 ` kernel test robot
2021-02-13 7:42 ` kernel test robot
2021-02-13 11:14 ` Vladimir Oltean
-- strict thread matches above, loose matches on Subject: below --
2021-02-13 2:32 [PATCH net-next 09/12] net: dsa: tag_ocelot: create separate tagger for Seville kernel test robot
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=20210215141521.GC2222@kadam \
--to=dan.carpenter@oracle.com \
--cc=kbuild@lists.01.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.