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] [day] [month] [year] [list]
Date: Tue, 25 Jul 2023 08:55:41 +0200
From: Hannes Reinecke <hare@...e.de>
To: Sagi Grimberg <sagi@...mberg.me>, Jakub Kicinski <kuba@...nel.org>
Cc: Christoph Hellwig <hch@....de>, Keith Busch <kbusch@...nel.org>,
 linux-nvme@...ts.infradead.org, Eric Dumazet <edumazet@...gle.com>,
 Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCHv8 0/6] net/tls: fixes for NVMe-over-TLS

On 7/24/23 21:44, Sagi Grimberg wrote:
> 
>>>>> Reviewed-by: Jakub Kicinski <kuba@...nel.org>
>>>>>
>>>>> Sagi, I _think_ a stable branch with this should be doable,
>>>>> would you like one, or no rush?
>>>>
>>>> I guess a stable branch would not be too bad; I've got another
>>>> set of patches for the NVMe side, too.
>>>> Sagi?
>>>
>>> I don't think there is a real need for this to go to stable, nothing
>>> is using it. Perhaps the MSG_EOR patches can go to stable in case
>>> there is some userspace code that wants to rely on it.
>>
>> I'm probably using the wrong word. I mean a branch based on -rc3 that's
>> not going to get rebased so the commits IDs match and we can both pull
>> it in. Not stable as in Greg KH.
> 
> Are you aiming this for 6.5 ? We are unlikely to get the nvme bits in
> this round. I also don't think there is a conflict so the nvme bits
> can go in for 6.6 and later the nvme tree will pull the tls updates.

I really would love to get this into 6.5, as then we can do a clean 
rebase of the NVMe development tree off 6.5, knowing that we won't have 
to touch the networking. Otherwise you have to be sure to fork the 6.6 
development branch off the right point.

But then I'm not doing the forking, so really all I care is that the 
networking bits are present in the 6.6 NVMe development branch ...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                Kernel Storage Architect
hare@...e.de                              +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ