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: <20220707172922.loqztmiwwij3ilgy@sx1>
Date:   Thu, 7 Jul 2022 10:29:22 -0700
From:   Saeed Mahameed <saeed@...nel.org>
To:     Jakub Kicinski <kuba@...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 07 Jul 09:14, Jakub Kicinski wrote:
>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.
>

I see, i will make the separation when I have core patches.

>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?
No i don't mind that at all, it just means that some patchsets will have
to go different path than what i have for mlx5, not a big deal