From: Leon Romanovsky <leon@kernel.org>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [PATCH net-next] devlink: Make devlink_register to be void
Date: Wed, 22 Sep 2021 11:55:59 +0300 [thread overview]
Message-ID: <YUrvn3ss4NTL+QKY@unreal> (raw)
In-Reply-To: <20210921053956.11ac7156@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Tue, Sep 21, 2021 at 05:39:56AM -0700, Jakub Kicinski wrote:
> On Tue, 21 Sep 2021 05:19:06 +0300 Leon Romanovsky wrote:
> > On Mon, Sep 20, 2021 at 02:04:07PM -0700, Jakub Kicinski wrote:
> > > On Mon, 20 Sep 2021 13:39:15 -0700 Jakub Kicinski wrote:
> > > > On Mon, 20 Sep 2021 17:41:44 +0300 Leon Romanovsky wrote:
> > [...]
> > > >
> > > > Unlike unused functions bringing back error handling may be
> > > > non-trivial. I'd rather you deferred such cleanups until you're
> > > > ready to post your full rework and therefore give us some confidence
> > > > the revert will not be needed.
> > >
> > > If you disagree you gotta repost, new devlink_register call got added
> > > in the meantime.
> >
> > This is exactly what I afraid, new devlink API users are added faster
> > than I can cleanup them.
> >
> > For example, let's take a look on newly added ipc_devlink_init(), it is
> > called conditionally "if (stage == IPC_MEM_EXEC_STAGE_BOOT) {". How can
> > it be different stage if we are in driver .probe() routine?
> >
> > They also introduced devlink_sio.devlink_read_pend and
> > devlink_sio.read_sem to protect from something that right position of
> > devlink_register() will fix. I also have serious doubts that their
> > current protection is correct, once they called to devlink_params_publish()
> > the user can crash the system, because he can access the parameters before
> > they initialized their protection.
> >
> > So yes, I disagree. We will need to make sure that devlink_register()
> > can't fail and it will make life easier for everyone (no need to unwind)
> > while we put that command being last in probe sequence.
>
> Remains to be seen if return type makes people follow correct ordering.
They will :)
After I'll fix all drivers that uses devlink_register :(, I'll add annotation to
all exported devlink calls will have one of three options:
1. WARN_ON(!xa_get_mark(&devlinks, devlink->index, DEVLINK_REGISTERED)) - call must be after devlink_register().
2. WARN_ON(xa_get_mark(&devlinks, devlink->index, DEVLINK_REGISTERED)) - call must be before devlink_register().
3. don't care - should be small number of such APIs and very good rationale why.
>
> > If I repost, will you take it? I don't want to waste anyone time if it
> > is not.
>
> Yeah, go for it.
WARNING: multiple messages have this Message-ID (diff)
From: Leon Romanovsky <leon@kernel.org>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "David S . Miller" <davem@davemloft.net>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Andrew Lunn <andrew@lunn.ch>, Ariel Elior <aelior@marvell.com>,
Bin Luo <luobin9@huawei.com>,
Claudiu Manoil <claudiu.manoil@nxp.com>,
Coiby Xu <coiby.xu@gmail.com>,
Derek Chickles <dchickles@marvell.com>,
drivers@pensando.io, Felix Manlunas <fmanlunas@marvell.com>,
Florian Fainelli <f.fainelli@gmail.com>,
Geetha sowjanya <gakula@marvell.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
GR-everest-linux-l2@marvell.com, GR-Linux-NIC-Dev@marvell.com,
hariprasad <hkelam@marvell.com>, Ido Schimmel <idosch@nvidia.com>,
intel-wired-lan@lists.osuosl.org,
Ioana Ciornei <ioana.ciornei@nxp.com>,
Jerin Jacob <jerinj@marvell.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Jiri Pirko <jiri@nvidia.com>,
Jonathan Lemon <jonathan.lemon@gmail.com>,
Linu Cherian <lcherian@marvell.com>,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-rdma@vger.kernel.org, linux-staging@lists.linux.dev,
Manish Chopra <manishc@marvell.com>,
Michael Chan <michael.chan@broadcom.com>,
netdev@vger.kernel.org, oss-drivers@corigine.com,
Richard Cochran <richardcochran@gmail.com>,
Saeed Mahameed <saeedm@nvidia.com>,
Salil Mehta <salil.mehta@huawei.com>,
Satanand Burla <sburla@marvell.com>,
Shannon Nelson <snelson@pensando.io>,
Simon Horman <simon.horman@corigine.com>,
Subbaraya Sundeep <sbhatta@marvell.com>,
Sunil Goutham <sgoutham@marvell.com>,
Taras Chornyi <tchornyi@marvell.com>,
Tariq Toukan <tariqt@nvidia.com>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
UNGLinuxDriver@microchip.com, Vadym Kochan <vkochan@marvell.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Yisen Zhuang <yisen.zhuang@huawei.com>
Subject: Re: [PATCH net-next] devlink: Make devlink_register to be void
Date: Wed, 22 Sep 2021 11:55:59 +0300 [thread overview]
Message-ID: <YUrvn3ss4NTL+QKY@unreal> (raw)
In-Reply-To: <20210921053956.11ac7156@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
On Tue, Sep 21, 2021 at 05:39:56AM -0700, Jakub Kicinski wrote:
> On Tue, 21 Sep 2021 05:19:06 +0300 Leon Romanovsky wrote:
> > On Mon, Sep 20, 2021 at 02:04:07PM -0700, Jakub Kicinski wrote:
> > > On Mon, 20 Sep 2021 13:39:15 -0700 Jakub Kicinski wrote:
> > > > On Mon, 20 Sep 2021 17:41:44 +0300 Leon Romanovsky wrote:
> > [...]
> > > >
> > > > Unlike unused functions bringing back error handling may be
> > > > non-trivial. I'd rather you deferred such cleanups until you're
> > > > ready to post your full rework and therefore give us some confidence
> > > > the revert will not be needed.
> > >
> > > If you disagree you gotta repost, new devlink_register call got added
> > > in the meantime.
> >
> > This is exactly what I afraid, new devlink API users are added faster
> > than I can cleanup them.
> >
> > For example, let's take a look on newly added ipc_devlink_init(), it is
> > called conditionally "if (stage == IPC_MEM_EXEC_STAGE_BOOT) {". How can
> > it be different stage if we are in driver .probe() routine?
> >
> > They also introduced devlink_sio.devlink_read_pend and
> > devlink_sio.read_sem to protect from something that right position of
> > devlink_register() will fix. I also have serious doubts that their
> > current protection is correct, once they called to devlink_params_publish()
> > the user can crash the system, because he can access the parameters before
> > they initialized their protection.
> >
> > So yes, I disagree. We will need to make sure that devlink_register()
> > can't fail and it will make life easier for everyone (no need to unwind)
> > while we put that command being last in probe sequence.
>
> Remains to be seen if return type makes people follow correct ordering.
They will :)
After I'll fix all drivers that uses devlink_register :(, I'll add annotation to
all exported devlink calls will have one of three options:
1. WARN_ON(!xa_get_mark(&devlinks, devlink->index, DEVLINK_REGISTERED)) - call must be after devlink_register().
2. WARN_ON(xa_get_mark(&devlinks, devlink->index, DEVLINK_REGISTERED)) - call must be before devlink_register().
3. don't care - should be small number of such APIs and very good rationale why.
>
> > If I repost, will you take it? I don't want to waste anyone time if it
> > is not.
>
> Yeah, go for it.
next prev parent reply other threads:[~2021-09-22 8:55 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-20 14:41 [Intel-wired-lan] [PATCH net-next] devlink: Make devlink_register to be void Leon Romanovsky
2021-09-20 14:41 ` Leon Romanovsky
2021-09-20 20:39 ` [Intel-wired-lan] " Jakub Kicinski
2021-09-20 20:39 ` Jakub Kicinski
2021-09-20 21:04 ` [Intel-wired-lan] " Jakub Kicinski
2021-09-20 21:04 ` Jakub Kicinski
2021-09-21 2:19 ` [Intel-wired-lan] " Leon Romanovsky
2021-09-21 2:19 ` Leon Romanovsky
2021-09-21 12:39 ` [Intel-wired-lan] " Jakub Kicinski
2021-09-21 12:39 ` Jakub Kicinski
2021-09-22 8:55 ` Leon Romanovsky [this message]
2021-09-22 8:55 ` Leon Romanovsky
2021-09-21 7:02 ` [Intel-wired-lan] " Jiri Pirko
2021-09-21 7:02 ` Jiri Pirko
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=YUrvn3ss4NTL+QKY@unreal \
--to=leon@kernel.org \
--cc=intel-wired-lan@osuosl.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.