Re: [PATCH] staging/atomisp: fix platform_no_drv_owner.cocci warnings
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 Signed-off-by: Fengguang Wu 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 To: Alan Cox Cc: de...@driverdev.osuosl.org, Greg Kroah-Hartman , 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: [cfs_trace_lock_tcd] BUG: unable to handle kernel NULL pointer dereference at 00000050
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: [visorchipset] invalid opcode: 0000 [#1] PREEMPT SMP
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
Re: [PATCH char-misc] mei: bus: () can be static
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
[PATCH] chardev: add missing line break in pr_warn
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
Signed-off-by: Fengguang Wu
---
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: [kbuild-all] [PATCH v17 net-next 1/1] hv_sock: introduce Hyper-V Sockets
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
Re: [kbuild-all] [PATCH v17 net-next 1/1] hv_sock: introduce Hyper-V Sockets
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: [PATCH] staging: i4l: icn: fix memdup_user.cocci warnings
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 Signed-off-by: Fengguang Wu --- 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: [Y2038] [PATCH v4 02/10] include: Move compat_timespec/ timeval to compat_time.h
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
