Re: [cfs_trace_lock_tcd] BUG: unable to handle kernel NULL pointer dereference at 00000050

2018-04-18 Thread Fengguang Wu 

Hi James,

On Wed, Apr 18, 2018 at 02:59:15PM +0100, James Simmons wrote:



Hello,

FYI this happens in mainline kernel 4.17.0-rc1.
It looks like a new regression.

[7.587002]  lnet_selftest_init+0x2c4/0x5d9:
lnet_selftest_init at 
drivers/staging/lustre/lnet/selftest/module.c:134
[7.587002]  ? lnet_selftest_exit+0x8d/0x8d:
lnet_selftest_init at 
drivers/staging/lustre/lnet/selftest/module.c:90


Are you running lnet selftest ?


Perhaps yes -- it's randconfig boot test and the .config does include
CONFIG_LNET_SELFTEST:

   CONFIG_LNET=y
   CONFIG_LNET_MAX_PAYLOAD=1048576
==> CONFIG_LNET_SELFTEST=y
   CONFIG_LNET_XPRT_IB=y


Is this a UMP setup?


Yes, .config has:

   # CONFIG_SMP is not set


The reason I ask is that their is a SMP handling bug in lnet
selftest. If you look at the mailing list I pushed a SMP patch
series. Can you try that series and tell me if it works for you.


So it looks your fixup patch is not for this case? Anyway the
reproduce-* script attached in the previous email should be fairly
straightforward to try out for reproducing the bug.

Thanks,
Fengguang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [Y2038] [PATCH v4 02/10] include: Move compat_timespec/ timeval to compat_time.h

2018-03-17 Thread Fengguang Wu 

On Thu, Mar 15, 2018 at 09:04:04AM +0100, Arnd Bergmann wrote:

On Thu, Mar 15, 2018 at 3:51 AM, Deepa Dinamani  wrote:

On Wed, Mar 14, 2018 at 1:52 PM, Arnd Bergmann  wrote:

On Wed, Mar 14, 2018 at 4:50 AM, Deepa Dinamani  wrote:

The file arch/arm64/kernel/process.c needs asm/compat.h also to be
included directly since this is included conditionally from
include/compat.h. This does seem to be typical of arm64 as I was not
completely able to get rid of asm/compat.h includes for arm64 in this
series. My plan is to have separate patches to get rid of asm/compat.h
includes for the architectures that are not straight forward to keep
this series simple.
I will fix this and update the series.



I ran across the same thing in two more files during randconfig testing on
arm64 now, adding this fixup on top for the moment, but maybe there
is a better way:


I was looking at how Al tested his uaccess patches:
https://www.spinics.net/lists/linux-fsdevel/msg108752.html

He seems to be running the kbuild bot tests on his own git.
Is it possible to verify it this way on the 2038 tree? Or, I could
host a tree also.


The kbuild bot should generally pick up any branch on git.kernel.org,
and the patches sent to the mailing list. It tests a lot of things
configurations, but I tend to find some things that it doesn't find
by doing lots of randconfig builds on fewer target architectures
(I only build arm, arm64 and x86 regularly).

I remember that there was some discussion about a method
to get the bot to test other branches (besides asking Fengguang
to add it manually), but I don't remember what came out of that.


People can send email to me or l...@intel.com for adding new git URLs
to 0day tests. Such requests are very welcome. Server load is not a
problem -- don't worry about your git pushes adding our test load.
By default all branches in a git tree will be tested, unless there are
explicit blacklist/whitelist.

We also have scripts to scan git.kernel.org/github/LKML looking for
possible new git URLs to add to 0day kbuild tests. However depending
on the team's maintenance pressure they may or may not run frequently.

Thanks,
Fengguang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging/atomisp: fix platform_no_drv_owner.cocci warnings

2017-03-01 Thread Fengguang Wu 

On Wed, Mar 01, 2017 at 10:58:59PM +0100, Daniel Glöckner wrote:

On Wed, Mar 01, 2017 at 06:30:17PM +0800, kbuild test robot wrote:

drivers/staging/media/atomisp/i2c/imx/imx.c:2486:3-8: No need to set .owner 
here. The core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Alan Cox <a...@linux.intel.com>
Signed-off-by: Fengguang Wu <fengguang...@intel.com>



May I ask which repository this patch is based on?


The email is replying to this one, which shows Greg's staging tree.

 Date: Wed, 1 Mar 2017 18:30:16 +0800
 From: kbuild test robot <fengguang...@intel.com>
 To: Alan Cox <a...@linux.intel.com>
 Cc: de...@driverdev.osuosl.org, Greg Kroah-Hartman 
<gre...@linuxfoundation.org>, kbuild-...@01.org
 Subject: [kbuild-all] [staging:staging-testing 209/209] 
drivers/staging/media/atomisp/i2c/gc2235.c:37:41: fatal error:
 linux/atomisp_gmin_platform.h: No such file or directory
 
 tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git staging-testing

 head:   628b2b91d50c74e2475a11a0db5978d9a36d2026
 commit: 628b2b91d50c74e2475a11a0db5978d9a36d2026 [209/209] staging/atomisp: 
Add support for the Intel IPU v2
 config: i386-allmodconfig (attached as .config)
 compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
 reproduce:
 git checkout 628b2b91d50c74e2475a11a0db5978d9a36d2026
 # save the attached .config to linux build tree
 make ARCH=i386


Does Intel finally attempt to upstream the atomisp driver?


It looks so.

Thanks,
Fengguang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH] staging: i4l: icn: fix memdup_user.cocci warnings

2016-08-23 Thread Fengguang Wu 

On Mon, Aug 22, 2016 at 09:19:36PM -0400, Greg KH wrote:

On Tue, Aug 23, 2016 at 08:36:58AM +0800, kbuild test robot wrote:

drivers/staging/i4l/icn/icn.c:813:11-18: WARNING opportunity for memdup_user

 Use memdup_user rather than duplicating its implementation
 This is a little bit restricted to reduce false positives

Generated by: scripts/coccinelle/api/memdup_user.cocci

CC: Sudip Mukherjee <sudipm.mukher...@gmail.com>
Signed-off-by: Fengguang Wu <fengguang...@intel.com>
---

 0 files changed

rule starting on line 17: position variables or mixed modifs interfere with 
comm_assoc isobool (
(

(
(unknown *to == NULL)
  >>> IS_ERR(rule starting on line 17:to)

|
!unknown *to
  >>> IS_ERR(rule starting on line 17:to)

)
|
(unknown *NULL == unknown *to)
  >>> IS_ERR(rule starting on line 17:to)

) || ...)


There's no patch here, did something go wrong?


Yes, the above error messages look like problems in the cocci script.
CC Julia for possible inputs.

Hi Julia, here is the context of the problem:

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 
staging-testing
head:   f5a9a15f8fd4168e415e94f5dce367f3cef08e03
commit: ee05e5f7113ea0b0db7eff7011a534c92fec2648 [251/347] staging: i4l: icn: 
donot assign in if statement

coccinelle warnings: (new ones prefixed by >>)


drivers/staging/i4l/icn/icn.c:813:11-18: WARNING opportunity for memdup_user


Thanks,
Fengguang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [kbuild-all] [PATCH v17 net-next 1/1] hv_sock: introduce Hyper-V Sockets

2016-07-19 Thread Fengguang Wu 

On Tue, Jul 19, 2016 at 07:52:53PM -0700, David Miller wrote:

From: Dexuan Cui 
Date: Wed, 20 Jul 2016 01:48:18 +


From: kbuild test robot [mailto:l...@intel.com]
Sent: Wednesday, July 20, 2016 1:10

Hi,

[auto build test WARNING on net-next/master]

url:https://github.com/0day-ci/linux/commits/Dexuan-Cui/introduce-
Hyper-V-VM-Sockets-hv_sock/20160715-223433
config: x86_64-randconfig-a0-07191719 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64

All warnings (new ones prefixed by >>):

   net/hv_sock/af_hvsock.c: In function 'hvsock_open_connection':
   net/hv_sock/af_hvsock.c:693: warning: 'hvsk' may be used uninitialized in
this function
   net/hv_sock/af_hvsock.c:693: warning: 'new_hvsk' may be used
uninitialized in this function
   net/hv_sock/af_hvsock.c:697: warning: 'new_sk' may be used uninitialized
in this function
   net/hv_sock/af_hvsock.c: In function 'hvsock_sendmsg_wait':
   net/hv_sock/af_hvsock.c:1053: warning: 'ret' may be used uninitialized in
this function
>> net/hv_sock/af_hvsock.o: warning: objtool: hvsock_on_channel_cb()+0x1d:
function has unreachable instruction


These warnings are all false alarms.


But you still have to quiet them.


Agreed.

However the last warning

   objtool: hvsock_on_channel_cb()+0x1d: function has unreachable 
instruction

is my fault -- it turns out to be a problem with old gcc-4.4 and
gcc-4.6 which we enabled 2 days ago. I just disabled reporting this
odd warning because it complaints on ~1 functions all over the
place, which can only be sanely fixed in the toolchain.

Thanks,
Fengguang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [kbuild-all] [PATCH v17 net-next 1/1] hv_sock: introduce Hyper-V Sockets

2016-07-19 Thread Fengguang Wu 

Yes, sorry for the noises!


>> net/hv_sock/af_hvsock.o: warning: objtool: hvsock_on_channel_cb()+0x1d:
function has unreachable instruction


These warnings are all false alarms.

Thanks,
-- Dexuan
___
kbuild-all mailing list
kbuild-...@lists.01.org
https://lists.01.org/mailman/listinfo/kbuild-all

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] chardev: add missing line break in pr_warn

2016-07-12 Thread Fengguang Wu 

To fix super long dmesg error lines like

 CHRDEV "dummy_stm.0" major number 224 goes below the dynamic allocation rangeCHRDEV 
"dummy_stm.1" major number 223 goes below the dynamic allocation rangeswapper: page 
allocation failure: order:8, mode:0x26040c0(GFP_KERNEL|__GFP_COMP|__GFP_NOTRACK)

After fix, it should look like

 CHRDEV "dummy_stm.0" major number 224 goes below the dynamic allocation range
 CHRDEV "dummy_stm.1" major number 223 goes below the dynamic allocation range
 swapper: page allocation failure: order:8, 
mode:0x26040c0(GFP_KERNEL|__GFP_COMP|__GFP_NOTRACK)

Reported-by: Philip Li <philip...@intel.com>
Signed-off-by: Fengguang Wu <fengguang...@intel.com>
---
fs/char_dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/char_dev.c b/fs/char_dev.c
index 687471d..6edd825 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -92,7 +92,7 @@ __register_chrdev_region(unsigned int major, unsigned int 
baseminor,
}

if (i < CHRDEV_MAJOR_DYN_END)
-   pr_warn("CHRDEV \"%s\" major number %d goes below the 
dynamic allocation range",
+   pr_warn("CHRDEV \"%s\" major number %d goes below the 
dynamic allocation range\n",
name, i);

if (i == 0) {
--
2.8.1

___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH char-misc] mei: bus: () can be static

2015-03-02 Thread Fengguang Wu 
On Mon, Mar 02, 2015 at 12:41:05PM +0300, Dan Carpenter wrote:
 On Mon, Mar 02, 2015 at 11:49:23AM +0800, kbuild test robot wrote:
  drivers/hv/vmbus_drv.c:51:5: sparse: symbol 'hyperv_panic_event' was not 
  declared. Should it be static?
  drivers/hv/vmbus_drv.c:51:5: sparse: symbol 'hyperv_panic_event' was not 
  declared. Should it be static?
  drivers/hv/vmbus_drv.c:51:5: sparse: symbol 'hyperv_panic_event' was not 
  declared. Should it be static?
  drivers/hv/vmbus_drv.c:51:5: sparse: symbol 'hyperv_panic_event' was not 
  declared. Should it be static?
 
 The subject and the patch don't match.

Sorry it's a bug. Root cause is, char-misc is a non-rebaseable tree,
so the script checks out the branch HEAD before generating the patch.
Then it gets the wrong title (which is based on the HEAD commit's subject).
Fixed now.

Thanks,
Fengguang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [visorchipset] invalid opcode: 0000 [#1] PREEMPT SMP

2014-04-07 Thread Fengguang Wu 
Hi Benjamin,

 Fengguang,
 
 I ran your script against freshly-checked-out source from staging-next, and 
 was not able to reproduce the error with it. My boot log is attached. I 
 noticed that your log did not have Hypervisor detected: KVM in the trace. 
 The KVM options in your script also differ substantially from the ones shown 
 at the end of your trace...
 
 When I reran your script with the -cpu Haswell,+smep,+smap option I was 
 able to get the same result as you. IMHO KVM should not be setting this bit 
 if it's emulating bare metal.

Sorry.. We tried to provide a simplified reproduce script and in your
case, it has a significant mismatch with the real KVM options. We'll
fix it, thanks for pointing it out!

Thanks,
Fengguang
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel