On Wed, Aug 08, 2018 at 06:15:53PM +0800, Yongqin Liu wrote:
On Wed, 8 Aug 2018 at 16:44, Greg KH greg@kroah.com wrote:
On Wed, Aug 08, 2018 at 04:19:10PM +0800, Yongqin Liu wrote:
Hi, All Sorry, I am following the instructions in Documentation/networking/netdev-FAQ.txt to send out this mail, if I was wrong or there are more things I need to do, please let me know.
After investigated on some failures of the android VtsKernelNetTest module test, I found that without the change of "ipv4+ipv6: Make INET*_ESP select CRYPTO_ECHAINIV", the config of CRYPTO_ECHAINIV will be generated as m by default in the .config file, which needs more module loading process to be done. But with the 4.9 and 4.14 kernels which have the change, CRYPTO_ECHAINIV will be generated as y by default in the .config file.
We could set config of CRYPTO_ECHAINIV to y explicitly to generated the correct .config file,
That would be the easiest solution here, right? Why can you not do that?
but having the change of "ipv4+ipv6: Make INET*_ESP select CRYPTO_ECHAINIV" cherry picked into the 4.4 stable kernel looks more like the right solution.
The commit id for that change is 32b6170ca59ccf07d0e394561e54b2cd9726038c, it's already in 4.9 and 4.14 kernels, like here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/net/...
Yes, because it showed up in 4.5 :)
Shouldn't your device configurations for 4.4 already be long done? You had better not be working on new systems with a 4.4 kernel, otherwise you are in big trouble for many other reasons. So your configuration should already be finished so I fail to see how backporting this is really going to solve anyone's problems.
Hmm, the background is that we did android VtsKernelNetTest test across different kernels, and found that the same tests failed with 4.4 kernel. With setting CRYPTO_ECHAINIV to y explicitly for specific platform, or applying this change to specific kernel, like the kernel for HiKey platform, that would only help to fix the problem for HiKey platform. If there are any other platforms that use 4.4 kernel, they might have the same problem, and they will need to do the same thing again separately to have that problem resolved. but if we have the change applied into the 4.4 stable kernel, all platforms that based on 4.4 kernel would have this problem fixed after they updated to the latest 4.4 stable kernel, that is why we want to have this change applied into the 4.4 stable kernel.
Ok, that's reasonable, now queued up.
greg k-h