virtifos kernel build is broken after kernel upgrade

[jcvenegas]

Description of problem

(The virtios-dev tag changed recently to a new version:

Linux 5.8-rc4

This already include some patches.

CI jobs tha build virtiofs kernel fail with:

08:53:58 patching file net/vmw_vsock/virtio_transport_common.c
08:53:58 Reversed (or previously applied) patch detected!  Assume -R? [n] 
08:53:58 Apply anyway? [n] 
08:53:58 Skipping patch.
08:53:58 1 out of 1 hunk ignored -- saving rejects to file net/vmw_vsock/virtio_transport_common.c.rej
08:53:58 Failed at 72: "${kernel_repo_dir}/kernel/build-kernel.sh" -e setup

We should move the old kernel verision or remove the patch if kata CI works well with the new kernel version. Ideally we should have a tag that does not change.

\cc @fidencio @c3d

[fidencio]

/cc @dagrh

[dagrh]

@jcvenegas Is it the virtio-fs-dev branch you're currently following? Would you prefer to just work from tags and we can give you a new tag to switch to when you're ready @rhvgoyal

[amshinde]

@dagrh Yes, we are using virtio-fs-dev dev branch for the kernel instead of a tag. We would prefer to use a tag there instead of a branch, so that Kata CI does not break unexpectedly. @jcvenegas Looks like the new branch is based of a release candidate version, I would prefer to stick to a stable version.

[jcvenegas]

@amshinde @dagrh you are right, seems that this is a branch, I was not aware of it, could you create a tag with the old version of virtiofs that you had. It would be nice if includes the kernel version e.g 5.4.11-virtiofs-0.5

[rhvgoyal]

I do create new tags based on dates. So an older tag is this. I am assuming you must have been using that previously.

https://gitlab.com/virtio-fs/linux/-/tree/vivek-april-09-2020

[amshinde]

@rhvgoyal We are using the virtio-fs-dev branch previously. Can you push tags on the branch?

[rhvgoyal]

@amshinde I guess you are referring to "annotated tags". I am using "lightweight tags" right now. I rebase my branch frequently and annotated tag will not be visible if you just do "git log" after rebase. Anyway, going forward I can create "annotated tags". But I am not sure how it will help.

[rhvgoyal]

I guess one advantage of annotated tags is that it will allow me to put a commit message and I can try to give some details about the changes.

[jcvenegas]

@rhvgoyal thanks for pointing to the tags. I will send a PR to move to it.

[jcvenegas]

@rhvgoyal sorry, we have one more request, could we have a more generic name for the kernel? kata-$(date) the kernel tag would be the more close to stable 5.6 release (not release-candiate).

• The name is because it is part of the release notes.
• The kernel request is as Archana point would be nice to have some work based in at least a final released kernel.

[rhvgoyal]

Ok, next time I will rebase patches dax patches on top of a released kernel (and not -rc) kernel.

I can keep tag name as "kata-$(date)". That's fine. I just need to replace "Vivek" with "kata".

[jcvenegas]

@rhvgoyal thanks a lot :) when the new tag name vivek-april-09-2020 -> kata-april-09-2020 is ready, I will send a PR to fix our CI

[rhvgoyal]

@jcvenegas How about including kernel version in tag name as well. Say "kata-v5.6-april-09-2020". This shows what kernel version it is and also shows what date patches were pushed on/released. That allows us to release multiple version of patches with same base kernel.

[rhvgoyal]

Ok, I created a tag "kata-v5.6-april-09-2020". Check it out.

https://gitlab.com/virtio-fs/linux/-/commits/kata-v5.6-april-09-2020