lkml.org 
[lkml]   [2021]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH net-next 5/6] devlink: Reshuffle resource registration logic
On Thu, Nov 18, 2021 at 05:48:13PM -0800, Jakub Kicinski wrote:
> On Thu, 18 Nov 2021 09:50:20 +0200 Leon Romanovsky wrote:
> > And it shouldn't. devlink_resource_find() will return valid resource only
> > if there driver is completely bogus with races or incorrect allocations of
> > resource_id.
> >
> > devlink_*_register(..)
> > mutex_lock(&devlink->lock);
> > if (devlink_*_find(...)) {
> > mutex_unlock(&devlink->lock);
> > return ....;
> > }
> > .....
> >
> > It is almost always wrong from locking and layering perspective the pattern above,
> > as it is racy by definition if not protected by top layer.
> >
> > There are exceptions from the rule above, but devlink is clearly not the
> > one of such exceptions.
>
> Just drop the unnecessary "cleanup" patches and limit the amount
> of driver code we'll have to revert if your approach fails.

My approach works, exactly like it works in other subsystems.
https://lore.kernel.org/netdev/cover.1636390483.git.leonro@nvidia.com/

We are waiting to see your proposal extended to support parallel devlink
execution and to be applied to real drivers.
https://lore.kernel.org/netdev/20211030231254.2477599-1-kuba@kernel.org/

Anyway, you are maintainer, you want half work, you will get half work.

>
> I spent enough time going back and forth with you.
>
> Please.

Disagreements are hard for everyone, not only for you.

Thanks

\
 
 \ /
  Last update: 2021-11-19 16:39    [W:0.104 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site