netdev - Re: [net-next 10/15] net/tls: Perform immediate device ctx cleanup when possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220707091442.01354da7@kernel.org>
Date:   Thu, 7 Jul 2022 09:14:42 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Saeed Mahameed <saeed@...nel.org>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Saeed Mahameed <saeedm@...dia.com>, netdev@...r.kernel.org,
        Tariq Toukan <tariqt@...dia.com>,
        Maxim Mikityanskiy <maximmi@...dia.com>
Subject: Re: [net-next 10/15] net/tls: Perform immediate device ctx cleanup
 when possible

On Wed, 6 Jul 2022 23:51:14 -0700 Saeed Mahameed wrote:
> On 06 Jul 19:21, Jakub Kicinski wrote:
> >On Wed,  6 Jul 2022 16:24:16 -0700 Saeed Mahameed wrote:  
> >> From: Tariq Toukan <tariqt@...dia.com>
> >>
> >> TLS context destructor can be run in atomic context. Cleanup operations
> >> for device-offloaded contexts could require access and interaction with
> >> the device callbacks, which might sleep. Hence, the cleanup of such
> >> contexts must be deferred and completed inside an async work.
> >>
> >> For all others, this is not necessary, as cleanup is atomic. Invoke
> >> cleanup immediately for them, avoiding queueuing redundant gc work.
> >>
> >> Signed-off-by: Tariq Toukan <tariqt@...dia.com>
> >> Reviewed-by: Maxim Mikityanskiy <maximmi@...dia.com>
> >> Signed-off-by: Saeed Mahameed <saeedm@...dia.com>  
> >
> >Not sure if posting core patches as part of driver PRs is a good idea,
> >if I ack this now the tag will not propagate.  
> 
> I agree, how about the devlink lock removal  ? same thing ? 

I didn't have the same reaction to the devlink part, perhaps because
of the clear driver dependency there and the fact we discussed that 
work thoroughly before.

Looking at it again it seems like the problem is that these are really
two independent series squashed together, no? Multiple driver features
mixed up in a series is fine but when changing the core let's stick to
clearer separation.

The objective is to get reviewers engaged, and it's really easy to miss
the core changes among the driver ones in a large multi-purpose series.

On the topic of PRs, does it matter to you if the core changes are
posted as a PR? I presume it's okay for those to come out as a normal
series with a proper subject and applied from the list?