Re: How to verify linux-next

[Pintu Kumar]

Thanks Mr. Tso for your reply.
Please find my reply inline.

On Sat, Sep 30, 2017 at 3:20 AM, Theodore Ts'o <tytso@xxxxxxx> wrote:
> On Fri, Sep 29, 2017 at 07:56:41PM +0530, Pintu Kumar wrote:
>> BTW, I am more interested in my another query about QEMU arm.
>> This will be much quicker and easy for me.
>> But the problem is I wanted to use multiple ssh shell on qemu.
>> Also I needed a pre-built rootfs image for qemu-arm, cortex-a9
>> versatilepb machine.
>
> If you want to get more useful help, it might be interesting if you
> were to specify exactly what kind of "verification" you are interested
> in doing.  What sort of kernel testing are you interested in doing?
> What part of the kernel are you interested in testing?  The fact that
> you are trying to test both a Ubuntu x86 box as will as a virtual ARM
> box makes it unclear what part of the kernel you are most intested in
> testing.
>
I need to submit a patch to mainline which should be verified against
linux-next tree with latest API.
My patch is already working with 4.10 LTS version but I need to upgrade.

> In particular, why do you care about accessing the VM via ssh /
> networking?  What sort of testing do you plan to do after manage to
> get the kernel running?   And do you care what distribution you use?
>
My patch is related to some test utility based on client/server model.
So, I need 2 terminal, one for server and one for client.
No, I really don't care about distribution, whichever works this way is
good for me. So I a trying both ways: Ububntu(x86) or qemu (arm).
The point is, I should be able to test my patch with linux-next.

> I have a huge amount of test automation built for testing kernel file
> systems.  This includes building root_fs images for x86 for use with
> kvm[1], and arm chroots for use in testing Android systems[2].  There
> is also a turn-key images for running tests using the Google Cloud
> Platform[3], and even a Dockerfile[4] so people can run kernel tests
> using a private Kubernetes cluster.
>
> [1] https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-xfstests.md
> [2] https://thunk.org/android-xfstests
> [3] https://thunk.org/gce-xfstests
> [4] https://github.com/tytso/xfstests-bld/blob/master/kvm-xfstests/Dockerfile
>
> If you don't have a file-system centric view of the world, and want to
> do more generalized kernel testing, the above might not be as
> interesting to you, although some of the utilities in the xfstests-bld
> git tree for setting up and building in build chroots, using
> debootstrap to create root_fs.img files, scripts for manipulating
> xUnit test result files (the XML format used by Jenkins), using 9p to
> communicate between the host system running qemu/kvm and the test VM,
> etc.
>
> The point is that if you really want to get serious about kernel
> testing, you should really think hard about test automation.  And in
> that world, using networking often makes things harder, not easier.
> For kvm-xfstests we just do our communications using the serial port,
> which made it easy for us to adapt things for android-xfstests, where
> we comunicate test runner script via "adb shell".   For gce-xfstests
> things _do_ get a bit more complicated, where the test summary gets
> e-mail'ed back to the developer, while the full set of test artifacts
> are archived on Google Cloud Storage.  But one of the most powerful
> things about my setup is vast majority of the test automation code
> stays the same regardless of whether the kernel being tested is being
> run in KVM, on a physical Android hardware, or in the Cloud using
> GCE.
>
>> 2) Let, please point me to a pre-built qemu-arm busy box image with
>> full features.
>
> Define "full features".  Busy box images are generally _not_ full
> featured.  There is a reason why I use a minimal Debian system; a lot
> of the tests I run require bash, and modern shell utilities, and
> Python so I can have scripts which manipulate xUnit XML files.
> Nevertheless, the complete x86 test VM is still only 87 megs, which is
> still small enough that it doesn't cause me any problems.
>
Qemu Busybox -> full feature for me means: I should be able to connect
Qemu with my PUTTY session, and open 2 terminal.
Moreover, I should be able to do scp to my qemu machine from my
ubuntu pc.

> On the other hand, since I find networking in the test VM to be
> completely superfluous (and in fact, gets in the way, since a VM which
> is on the corporate network can be a security problem, and may run
> afoul of corporate I/T security policies --- and if you don't have
> those kinds of security policies, you really should....).  So my
> root_fs's general have no networking support whatsoever.  It keeps
> $WORK's secops team *much* happier.  :-)
>

I am really sorry for the confusion.
Ok, lets talk one by one.
1) How to resolve linux-next build error with ubuntu virtual box 5.1.28

Any quick pointers on this will really help me to quickly verify my
patch and submit.

In file included from ./arch/x86/include/asm/atomic.h:7:0,
                 from ./include/linux/atomic.h:4,
                 from ./include/linux/mm_types_task.h:12,
                 from ./include/linux/mm_types.h:4,
                 from arch/x86/kvm/irq.h:25,
                 from arch/x86/kvm/vmx.c:19:
arch/x86/kvm/vmx.c: In function â__pi_post_blockâ:
./arch/x86/include/asm/cmpxchg.h:129:2: warning: â__retâ is used
uninitialized in this function [-Wuninitialized]
  __ret;        \
  ^
./arch/x86/include/asm/cmpxchg.h:86:21: note: â__retâ was declared here
  __typeof__(*(ptr)) __ret;     \
                     ^
./arch/x86/include/asm/cmpxchg.h:133:2: note: in expansion of macro
â__raw_cmpxchgâ
  __raw_cmpxchg((ptr), (old), (new), (size), LOCK_PREFIX)
  ^
./arch/x86/include/asm/cmpxchg.h:148:2: note: in expansion of macro â__cmpxchgâ
  __cmpxchg(ptr, old, new, sizeof(*(ptr)))
  ^
arch/x86/kvm/vmx.c:11732:11: note: in expansion of macro âcmpxchgâ
  } while (cmpxchg(&pi_desc->control, old.control,
           ^
  CC      kernel/trace/trace_seq.o
  CC      kernel/trace/trace_stat.o
In function â__pi_post_blockâ,
    inlined from âpi_post_blockâ at arch/x86/kvm/vmx.c:11831:2,
    inlined from âvmx_post_blockâ at arch/x86/kvm/vmx.c:11840:2:
./arch/x86/include/asm/cmpxchg.h:127:3: error: call to
â__cmpxchg_wrong_sizeâ declared with attribute error: Bad argument
size for cmpxchg
   __cmpxchg_wrong_size();     \




>                                         - Ted