Received: by 10.223.164.221 with SMTP id h29csp1091204wrb; Wed, 1 Nov 2017 10:16:25 -0700 (PDT) X-Google-Smtp-Source: ABhQp+RhilF1KxnMi4Setjs2dDEdGo+jgEHveZ6mzBx9wxMqXwRt6IcumzsjfrBd9JxRqgqEe75C X-Received: by 10.159.194.196 with SMTP id u4mr291479plz.49.1509556585605; Wed, 01 Nov 2017 10:16:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509556585; cv=none; d=google.com; s=arc-20160816; b=q3+cODIzrvOrUku3tVzu8VtD7+aNXD+tOcsgiPPqZuCW32D6B0l/3Cf6vZnIMC8JBF D4Bt1nmlrertoXC8A07eqGmmy0q4Rchd3qLr9JzZuaDZ8lQKg426iwbdNSAJPwhi0DVj 9m3+nkGlz5Z2uKIOQ55efUfoaDi3r4u974GLOnoHo9zWOysogBMW/vohl5NxMApH5bo0 dKrRGdBDklWJNNkKd+FWd66eGAeX32un9sg73iPvS/oVgxjv6JTCeLkJS4SnC7PedNvh x4oM/4IJPBjXRmHvJNC+2dHKH6R6zVO2uWT/HYEb/gk8vILGWjiJEXTTdLMaI7hcxUuy 0g1A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=RypkcKmoO2r711KgppVrnnovIR97N0UI5K8tR3sGKcA=; b=NBSJC3k5HA9sleyTSFPBpTEXWpBce5JlUJ6vFXALiKAApWxlaHwEzZWJX/s9RSLkUI xPe7uRWd/t0utEC1UNt25v8Aj9+11NYYudmNDzAuVjOnEKBUt3KH7YFRDvPbHyzcZxUy eRkUb/6XqaLijzWCD09szZoy5FdvcBO5ZHiTbK6qS+XJKW7UWarzKzdIMwnoLq8PusIC UjW2UFSotYxgdZT6lQCXPnc3QNOe5WVu0BJZSs6RaSxWKX6Kiraic4DhKF3cEit6iNP2 ZjLJLg5i6UYJR/UjiAugd6wtfvS7QrfABh6vFl9WNL3cROK5gB3rx0D3qLQXx3vp6/F6 sKuQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UqGfj89I; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k13si1467421pgn.761.2017.11.01.10.16.12; Wed, 01 Nov 2017 10:16:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UqGfj89I; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754712AbdKAROZ (ORCPT + 99 others); Wed, 1 Nov 2017 13:14:25 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:49915 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751681AbdKAROX (ORCPT ); Wed, 1 Nov 2017 13:14:23 -0400 Received: by mail-lf0-f65.google.com with SMTP id w21so3324158lfc.6; Wed, 01 Nov 2017 10:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RypkcKmoO2r711KgppVrnnovIR97N0UI5K8tR3sGKcA=; b=UqGfj89Ipb3W4/Im4cJonip9VVDeJHMItFlc7uK4np4kqtKqC+hSPCEJk7PIJTuqRW KaQNoIg4YO1TOheTeJH3QH70cQpFW91KAfi8HxHNgrDNV4DEwmRsitU3tlCGLi5Oo7+Q kYR1tFB/4GqdjUJQBxIMcXi7mAX8Z2nX3vUW+AS9fnQIkpFWACUE0Pl9zIeLseb3AzKZ 1b6v8zvBK1wDvYcNfB4ndgYaSW3gcQgpRes3ruc8bgLPPaLMK0YIQeYFbX/HhwtBuR44 GcsZHhhQH6Riou6ux1pUDtU7NtC2IFlSYSN+LwxRJsphXNUuZShSw2qGSeN1jQoJeOe3 ErZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RypkcKmoO2r711KgppVrnnovIR97N0UI5K8tR3sGKcA=; b=i6L1sjUTuil6BAcxAHwpElJXtPisoQeldKVTL+jzKWszK7N4FByPMvm/NbDrGLUFNv DXSua17ZpNi9TYckK7UZRQYoeF8pDZNCzU7j3lK1sAXPjTloZLmNCGS5qgiX3QoCn+4K aHp6CvlkeeD0mGAoPV8fq9eQmXWepGsS2K7+VWHbzacXF470vNNlEj+4/+I7+XAVK5QZ xecNU7x80onOuzSOLAtevp3x3iJzyInz3NyESYGPhH83RpaRl2+qspb/1rRm765FTjOD 1+pvZRO5bTtWzGxp73UsDbkHFPydTrcvQi3V59mK0q2AJEDxfJwf6JSJBmN28imduV+t iXTw== X-Gm-Message-State: AMCzsaXFmX+aNpWQWexH2LqhRtlBU+hZYOSneBj172zsWsQ+0Ttb34M/ Ov/SpHupOdiPxbHGC/RA/x8nqpIwbDWGo7rScVE= X-Received: by 10.25.228.129 with SMTP id x1mr151471lfi.232.1509556461631; Wed, 01 Nov 2017 10:14:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.167.79 with HTTP; Wed, 1 Nov 2017 10:14:21 -0700 (PDT) In-Reply-To: References: <1508801195-5369-1-git-send-email-pintu.ping@gmail.com> <20171029142128.GB13676@yexl-desktop> <8e7d8bbb-ec51-b693-aa35-1af73c163299@redhat.com> <19d76d06-1aba-351c-9b7f-2c861828501c@redhat.com> From: Pintu Kumar Date: Wed, 1 Nov 2017 22:44:21 +0530 Message-ID: Subject: Re: [lkp-robot] [android/ion] 5fb70554d6: kernel_selftests.android.make_fail To: shuah@kernel.org Cc: Laura Abbott , kernel test robot , linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Greg Kroah-Hartman , dvhart@infradead.org, Bamvor Zhang Jian , Pintu Kumar , lkp@01.org, Shuah Khan Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 1, 2017 at 10:27 PM, Shuah Khan wrote: > On 11/01/2017 10:26 AM, Pintu Kumar wrote: >> On Wed, Nov 1, 2017 at 8:34 PM, Shuah Khan wrote: >>> On 11/01/2017 04:12 AM, Pintu Kumar wrote: >>>> On Wed, Nov 1, 2017 at 3:28 AM, Laura Abbott wrote: >>>>> On 10/31/2017 03:21 AM, Pintu Kumar wrote: >>>>>> On Tue, Oct 31, 2017 at 2:32 AM, Laura Abbott wrote: >>>>>>> On 10/30/2017 12:12 AM, Pintu Kumar wrote: >>>>>>>> On Sun, Oct 29, 2017 at 7:51 PM, kernel test robot >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> FYI, we noticed the following commit (built with gcc-6): >>>>>>>>> >>>>>>>>> commit: 5fb70554d68e2ea032b6a28b082801d8b7b76cb8 ("android/ion: userspace test utility for ion buffer sharing") >>>>>>>>> url: https://github.com/0day-ci/linux/commits/Pintu-Agarwal/android-ion-userspace-test-utility-for-ion-buffer-sharing/20171025-022548 >>>>>>>>> >>>>>>>>> >>>>>>>>> in testcase: kernel_selftests >>>>>>>>> with following parameters: >>>>>>>>> >>>>>>>>> >>>>>>>>> test-description: The kernel contains a set of "self tests" under the tools/testing/selftests/ directory. These are intended to be small unit tests to exercise individual code paths in the kernel. >>>>>>>>> test-url: https://www.kernel.org/doc/Documentation/kselftest.txt >>>>>>>>> >>>>>>>>> >>>>>>>>> on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 64G memory >>>>>>>>> >>>>>>>>> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace): >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> KERNEL SELFTESTS: linux_headers_dir is /usr/src/linux-headers-x86_64-rhel-7.2-5fb70554d68e2ea032b6a28b082801d8b7b76cb8 >>>>>>>>> 2017-10-26 22:18:16 ln -sf /usr/bin/gcc-5 /usr/bin/gcc >>>>>>>>> >>>>>>>>> 2017-10-26 22:18:16 make run_tests -C android >>>>>>>>> make: Entering directory '/usr/src/linux-selftests-x86_64-rhel-7.2-5fb70554d68e2ea032b6a28b082801d8b7b76cb8/tools/testing/selftests/android' >>>>>>>>> make[1]: Entering directory '/usr/src/linux-selftests-x86_64-rhel-7.2-5fb70554d68e2ea032b6a28b082801d8b7b76cb8/tools/testing/selftests/android/ion' >>>>>>>>> gcc -I../../../../../drivers/staging/android/uapi/ -Wall -O2 -g ionapp_export.c ipcsocket.c ionutils.c -o ionapp_export >>>>>>>>> In file included from ionapp_export.c:28:0: >>>>>>>>> ionutils.h:4:17: fatal error: ion.h: No such file or directory >>>>>>>>> compilation terminated. >>>>>>>>> In file included from ionutils.c:9:0: >>>>>>>>> ionutils.h:4:17: fatal error: ion.h: No such file or directory >>>>>>>>> compilation terminated. >>>>>>>> >>>>>>>> This utility requires ion.h header file which should be included from >>>>>>>> kernel source tree: drivers/staging/android/ion/uapi/ >>>>>>>> This is already mentioned in the ion/Makefile >>>>>>>> Looks like this ion.h is not getting included inside the linux_headers_dir ? >>>>>>>> >>>>>>>> Shall I include the ion.h locally in my selftests? >>>>>>>> Or, is there a better way to include the header directly... >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> I can't reproduce this in any of my environments but if I had to guess, >>>>>>> it's because you have >>>>>>> >>>>>>> #include "ion.h" >>>>>>> >>>>>>> which is supposed to look in the local path. >>>>>>> >>>>>> >>>>>> I don't think this is the problem. >>>>>> It just means, first it will look into the local path, then it will >>>>>> look into the include path which is specified in the Makefile. >>>>>> And, in the Makefile I have already included the path where it exists. >>>>>> INCLUDEDIR := -I../../../../../drivers/staging/android/uapi/ >>>>>> >>>>> >>>>> Ah yeah you are right >>>>> >>>>>> I think the problem is in general, and not specific to this test. >>>>>> Because, when I manually try to install the kernel headers, I could >>>>>> not find the "ion.h" there, or none of the headers from >>>>>> drivers/staging/android/ >>>>>> # make headers_install ARCH=i386 INSTALL_HDR_PATH=../headers/ >>>>>> >>>>>> But, I can see the drivers/android/ header files. >>>>>> >>>>>> Now the question is, how to include the header files from staging >>>>>> folder to kernel headers ? >>>>>> >>>>>> As per reference from some other selftests (such as: gpio/Makefile, >>>>>> vm/Makefile, etc.), I also tried the following. >>>>>> >>>>>> ../../../../../drivers/staging/android/uapi/ion.h: >>>>>> make -C ../../../../.. headers_install >>>>>> INSTALL_HDR_PATH=$(shell pwd)/../../../../usr/ >>>>>> >>>>>> But this also does not help in installing the ion.h header file in >>>>>> kernel_header path. >>>>>> >>>>>> Any other pointers to fix this issue ? >>>>>> >>>>> >>>>> The staging uapi headers don't look to be installed with the >>>>> standard install command. This makes sense given that staging >>>>> drivers are well staging and not yet stable. >>>>> >>>>> The tools/gpio Makefile seems to do this trick to allow compilation >>>>> outside the kernel tree (it is a dependency for the gpio selftest) >>>>> >>>>> # >>>>> # We need the following to be outside of kernel tree >>>>> # >>>>> $(OUTPUT)include/linux/gpio.h: ../../include/uapi/linux/gpio.h >>>>> mkdir -p $(OUTPUT)include/linux 2>&1 || true >>>>> ln -sf $(CURDIR)/../../include/uapi/linux/gpio.h $@ >>>>> >>>>> prepare: $(OUTPUT)include/linux/gpio.h >>>>> >>>> >>>> I tried something similar, but it did not help. >>>> Or may be I could not understand how to incorporate this into my code >>>> to make it work. >>>> Basically, when I do make in gpio, it automatically does this using: >>>> make -C headers_install. >>>> But in my case, this command is not getting invoked, using the following: >>>> ../../../../../drivers/staging/android/uapi/ion.h: >>>> make -C ../../../../.. headers_install >>>> INSTALL_HDR_PATH=$(shell pwd)/../../../../usr/ >>>> >>>> >>>> https://kernelnewbies.org/KernelHeaders >>>> It says: >>>> [The correct way to address this problem is to isolate the specific >>>> interfaces that you need, e.g. a single header file that is patched in >>>> a new kernel providing the ioctl numbers for a character device used >>>> by your program. In your own program, add a copy of that source file, >>>> with a notice that it should be kept in sync with new kernel >>>> versions.] >>>> >>>> According to this, it looks like we should maintain the local copy of >>>> the header file, until it is available. >>>> I also saw a similar approach in other selftests. >>>> >>>> So, for time being shall I create a local copy of ion.h ? >>>> >>> >>> Sorry. I am late in responding. >>> >>>> >>>>> Maybe something like that needs to happen here unless Shuah has >>>>> any better ideas for headers? >>>>> >>> >>> Since staging headers aren't included in the headers install for good >>> reasons, I have two suggestions: >>> >>> 1. Use bpf as an example: >>> >>> You will find a local include/uapi under bpf and the Makefile looks >>> there first for headers. >>> >>> Also, as Greg suggested, please add comments to indicate that this >>> header needs to be kept in sync with one from staging. >>> >>> This does make a copy of the header which isn't great. >>> >>> 2. Add a include line in the Makefile directly to point to the uapi >>> >>> drivers/staging/android/uapi >>> >>> The downside to this approach is if selftests are built outside the >>> tree, then that would be a problem. However, being able to build selftests >>> outside the tree requires creating a tarball of the sources first. This >>> header could be added for that special case. >>> >>> I would recommend option 2 to go forward and if that doesn't work, we can >>> refine it. >> >> Thank you for your reply and suggestions. >> The option 2 is already present, if you see my Makefile. >> But this option does not work if built outside the kernel source tree. >> So, I am trying to maintain a local copy of ion.h >> >> > > So where does the test source reside for outside builds? Is this test hosted > on GitHub? > > I am not opposed to the idea of a local copy. I am trying to understand the > outside env. that this test needs to be built? I am assuming ion test gets built > as an independent test and nor from kernel source tree? > Sorry, I already pushed the local copy patch. I saw your reply later. But we can continue our discussion to find more proper solution. I really don't know about this test robot. I just got this build failure logs. I tried all cases within the kernel source including the kselftest_install.sh. I guess, what this tests does is, create kernel_headers inside a folder, then copy all selftests also inside this folder and then fire the test one by one. But I really don't have any idea how it works. For me also, if I have to test my code outside kernel tree, I usually copy ion.h header file locally and test it. But, still I have one question about staging tree kernel headers. How the kernel headers are created in case of Android where it uses the ion and other headers heavily? Thanks, Pintu > thaks, > -- Shuah > From 1582883784759466761@xxx Wed Nov 01 17:00:11 +0000 2017 X-GM-THRID: 1582662213253057274 X-Gmail-Labels: Inbox,Category Forums