From: Vladimir Oltean
[ Upstream commit db34a4714c013b644eec2de0ec81b1f0373b8b93 ]
Because ptp_qoriq_settime is being called prior to spin_lock_init, the
following stack trace can be seen at driver probe time:
[2.269117] the code is fine but needs lockdep annotation.
[2.274569] turning
On Tue, Jul 10, 2018 at 11:33:42AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the rdma tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
>
> In file included from include/linux/printk.h:336:0,
> from incl
c/gpio@e605
> CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted 5.1.0-rc2-koelsch+ #407
> Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
> Workqueue: events deferred_probe_work_func
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack)
On pon, 2014-09-29 at 04:25 +, 함명주 wrote:
> >
> > Kernel built with extcon and charger-manager.
> >
> > After connecting the USB cable sleeping function was called from atomic
> > context:
> > [ 63.328648] BUG: sleeping function called from invalid co
linked in:
[ 95.051430] CPU: 1 PID: 3067 Comm: bash Tainted: GW
3.16.0-11355-g7a6eca5-dirty #3015
[ 95.060058] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 95.067766] [] (show_stack) from []
(dump_stack+0x70/0xbc)
[ 95.074953] [] (dump_stack) from
3.16-stable review patch. If anyone has any objections, please let me know.
--
From: Stephen Boyd
commit 3c5445ce3a0c6d6935911212b735772af5115517 upstream.
We allocate the cpufreq table after calling rcu_read_lock(),
which disables preemption. This causes scheduling while
> 4.6.0-rc5-next-20160426+ #1114 Not tainted
> ---
> include/trace/events/clk.h:59 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1,
; > > 4.6.0-rc5-next-20160426+ #1114 Not tainted
> > > ---
> > > include/trace/events/clk.h:59 suspicious rcu_dereference_check() usage!
> > >
> > > other info that might help us debug this:
> > >
> > >
> > &g
() usage!
> >
> > other info that might help us debug this:
> >
> >
> > RCU used illegally from idle CPU!
> > rcu_scheduler_active = 1, debug_locks = 0
> > RCU used illegally from extended quiescent state!
> > 2 locks held by swapper/0/0
; > > > 8< --
> > > > ===
> > > > [ INFO: suspicious RCU usage. ]
> > > > 4.6.0-rc5-next-20160426+ #1114 Not tainted
> > > > ---
> > > > include/trace/events
h:59 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> RCU used illegally from extended quiescent state!
> 2 locks held by swapper/0/0:
> #0: (>hwmod_key#
h:59 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> RCU used illegally from extended quiescent state!
> 2 locks held by swapper/0/0:
> #0: (>hwmod_key#
+ Lokesh Vutla
+ linux-o...@vger.kernel.org
On Thu, Dec 10, 2015 at 6:06 PM, Semen Protsenko
wrote:
>
> From: Sam Protsenko
>
> When using DES module the next bug appears:
>
> BUG: scheduling while atomic: kworker/0:1/63/0x0102
>
> W
Hi!
We're facing this issue from 2014 on UBIFS:
http://www.spinics.net/lists/linux-fsdevel/msg79941.html
So sum up:
UBIFS does not allow pages directly marked as dirty. It want's everyone to do
it via UBIFS's
->wirte_end() and ->page_mkwirte() functions.
This assumption *seems* to be vi
ing so long to get back to you. Can you confirm you had
> lockdep turned on.
Yes, this is from the config I used:
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_LOCKDEP=y
# CONFIG_DEBUG_LOCKDEP is not set
Best regards,
Bartosz Golaszewski
> Thanks
> Andrew
>
>>
>> # echo 24c32
-by: kernel test robot
All errors (new ones prefixed by >>):
In file included from include/linux/spinlock.h:312,
from include/linux/wait.h:9,
from include/linux/pid.h:6,
from include/linux/sched.h:14,
from i
Are any of these worth fixing?
WARNING: vmlinux - Section mismatch: reference to
.init.data:boot_params from .text between '_text' (at offset
0xc0100036) and 'checkCPUtype'
WARNING: vmlinux - Section mismatch: reference to
.init.data:boot_params from .text between '_text' (at offset
0xc0100044
see
> > >
> > > crash> bt
> > > PID: 72 TASK: e1f48640 CPU: 0 COMMAND: "mmcqd/1"
> > > #0 [] (__crash_kexec) from []
> > > #1 [] (panic) from []
> > > #2 [] (svcerr_panic) from []
> > > #3 [] (_SvcErr_) from []
pear
>> > > that someone is changing that member without taking the lock. In my
>> > > setup, I see
>> > >
>> > > crash> bt
>> > > PID: 72 TASK: e1f48640 CPU: 0 COMMAND: "mmcqd/1"
>> > > #0 [] (__crash_kex
Are any of these worth fixing?
WARNING: vmlinux - Section mismatch: reference to
.init.data:boot_params from .text between '_text' (at offset
0xc0100036) and 'checkCPUtype'
WARNING: vmlinux - Section mismatch: reference to
.init.data:boot_params from .text between '_text' (at offset
0xc0100044
see
> > >
> > > crash> bt
> > > PID: 72 TASK: e1f48640 CPU: 0 COMMAND: "mmcqd/1"
> > > #0 [] (__crash_kexec) from []
> > > #1 [] (panic) from []
> > > #2 [] (svcerr_panic) from []
> > > #3 [] (_SvcErr_) from []
> > that someone is changing that member without taking the lock. In my
>> > > setup, I see
>> > >
>> > > crash> bt
>> > > PID: 72 TASK: e1f48640 CPU: 0 COMMAND: "mmcqd/1"
>> > > #0 [] (__crash_kexec) from []
>>
0x2a0
> > > [CRTC:46:crtc-0] vblank wait timed out
> > > Modules linked in:
> > > CPU: 0 PID: 31 Comm: kworker/0:1 Tainted: GW
> > > 5.1.0-next-20190514-00025-gf928bc7cc146 #15
> > > Hardware name: Allwinner sun8i Family
> > > Work
The signal code for ILP32 uses one extra function from signal32.c; it does not
make sense to enable the whole signal32.c code so we move the function which
was being used to signal.c.
Signed-off-by: Andrew Pinski apin...@cavium.com
---
arch/arm64/kernel/signal.c | 85
leds_lp55xx_common video_bus_switch videodev media twl4030_vibra ff_memless
tsc2005(+) omap_sham twl4030_wdt omap_wdt
[ 55.242828] CPU: 0 PID: 528 Comm: kworker/0:3 Tainted: G D W
4.2.0-rc2+ #364
[ 55.251556] Hardware name: Nokia RX-51 board
[ 55.260070] Workqueue: events power_supply_
ive this a try. What board was Subodh using?
>>
>> Any news on trying the above settings?
>
> Sorry, haven't had the chance to try it yet due to the impending merge
> window opening. Once things settle down I'll give it a try -- or maybe
> someone else can test it in
.
Regards,
Tony
8< ---
=
WARNING: suspicious RCU usage
4.12.0-next-20170713+ #118 Tainted: GW
-
./include/linux/rcupdate.h:611 rcu_read_lock() used illegally while idle!
[2.928802]
other info that might help us debug this:
[2.928802]
[2.946777]
RCU used
.
Regards,
Tony
8< ---
=
WARNING: suspicious RCU usage
4.12.0-next-20170713+ #118 Tainted: GW
-
./include/linux/rcupdate.h:611 rcu_read_lock() used illegally while idle!
[2.928802]
other info that might help us debug this:
[2.928802]
[2.946777]
RCU used
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
from /usr/include/asm-generic/int-ll64.h:11,
from /usr/include/powerpc64le-linux-gnu
was never done
for them (opposite of devm_regulator_bulk_get()), the kernel WARNs at
WARN_ON(rdev->open_count);
And eventually it crashes from debugfs_remove_recursive().
x--x
wm8994 3-001a: Device is not a WM8994, ID is 0
--
ring failures, the children are removed first and the core eventually
> calls regulator_unregister() for them. As regulator_put() was never done
> for them (opposite of devm_regulator_bulk_get()), the kernel WARNs at
>
> WARN_ON(rdev->open_count);
>
> And eventually it crashes
On Wed 19-04-17 10:09:12, Geert Uytterhoeven wrote:
> Hi Michal, Tetsuo,
>
> On Wed, Apr 19, 2017 at 9:57 AM, Michal Hocko <mho...@kernel.org> wrote:
> > From f3c6e287042259d6ae9916f1ff66392c46ce2a3c Mon Sep 17 00:00:00 2001
> > From: Michal Hocko <mho...@suse.com&
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All warnings (new ones prefixed by >>):
In file included from include/linux/byteorder/big_endian.h:4:0,
from arch/xtensa/include/uapi/asm/byteorder.h:7,
fro
Hi Bjorn,
As I am rebasing my patches and testing them for submission, I am seeing
kernel crashes with my error recovery tests with TI remoteprocs that use
the virtio_rpmsg transport. This should be a common problem for all
remoteprocs using virtio devices from resource table. Bisecting it led
f --git a/kernel/signal.c b/kernel/signal.c
index d4ccea599692..d56f4d496c89 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2850,89 +2850,9 @@ enum siginfo_layout siginfo_layout(int sig, int si_code)
int copy_siginfo_to_user(siginfo_t __user *to, const siginfo_t *from)
{
f --git a/kernel/signal.c b/kernel/signal.c
index d4ccea599692..d56f4d496c89 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2850,89 +2850,9 @@ enum siginfo_layout siginfo_layout(int sig, int si_code)
int copy_siginfo_to_user(siginfo_t __user *to, const siginfo_t *from)
{
Hi Bjorn,
As I am rebasing my patches and testing them for submission, I am seeing
kernel crashes with my error recovery tests with TI remoteprocs that use
the virtio_rpmsg transport. This should be a common problem for all
remoteprocs using virtio devices from resource table. Bisecting it led
c b/kernel/signal.c
index d4ccea599692..d56f4d496c89 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2850,89 +2850,9 @@ enum siginfo_layout siginfo_layout(int sig, int si_code)
int copy_siginfo_to_user(siginfo_t __user *to, const siginfo_t *from)
{
- int err;
-
- if (!access_ok (VE
l/signal.c
index d4ccea599692..d56f4d496c89 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2850,89 +2850,9 @@ enum siginfo_layout siginfo_layout(int sig, int si_code)
int copy_siginfo_to_user(siginfo_t __user *to, const siginfo_t *from)
{
- int err;
-
- if (!access_ok (VE
On Wed 19-04-17 10:09:12, Geert Uytterhoeven wrote:
> Hi Michal, Tetsuo,
>
> On Wed, Apr 19, 2017 at 9:57 AM, Michal Hocko wrote:
> > From f3c6e287042259d6ae9916f1ff66392c46ce2a3c Mon Sep 17 00:00:00 2001
> > From: Michal Hocko
> > Date: Wed, 19 Apr 2017 09:52:46 +0
was never done
for them (opposite of devm_regulator_bulk_get()), the kernel WARNs at
WARN_ON(rdev->open_count);
And eventually it crashes from debugfs_remove_recursive().
x--x
wm8994 3-001a: Device is not a WM8994, ID is 0
--
ring failures, the children are removed first and the core eventually
> calls regulator_unregister() for them. As regulator_put() was never done
> for them (opposite of devm_regulator_bulk_get()), the kernel WARNs at
>
> WARN_ON(rdev->open_count);
>
> And eventually it crashes
# save the attached .config to linux build tree
make.cross ARCH=xtensa
All warnings (new ones prefixed by >>):
In file included from include/linux/byteorder/big_endian.h:4:0,
from arch/xtensa/include/uapi/asm/byteorder.h:7,
fro
Hi all,
After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
In file included from tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
from /usr/include/asm-generic/int-ll64.h:11,
from /usr/include/powerpc64le-linux-gnu
:/ INFO: rcu_preempt detected stalls on CPUs/tasks: { 0}
(detected by 1, t=29545 jiffies)
[c0014710] (unwind_backtrace+0x0/0xf8) from [c00686fc]
(rcu_check_callbacks+0x6e0/0x76c)
[c00686fc] (rcu_check_callbacks+0x6e0/0x76c) from [c0029cbc]
(update_process_times+0x38/0x4c)
[c0029cbc] (update_process_times
On Mon, Apr 13, 2015 at 07:37:20PM +1000, Stephen Rothwell wrote:
Hi all,
After merging the char-misc tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
In file included from include/trace/define_trace.h:90:0,
from drivers/misc/mei/mei-trace.h
On 23-07-15, 14:32, Viresh Kumar wrote:
This file isn't getting removed while we unbind a device from thermal
zone. And this causes following messages when the device is registered
again:
WARNING: CPU: 0 PID: 2228 at /home/viresh/linux/fs/sysfs/dir.c:31
sysfs_warn_dup+0x60/0x70()
sysfs
On Thu, Jul 23, 2015 at 10:02:32AM +0100, Viresh Kumar wrote:
This file isn't getting removed while we unbind a device from thermal
zone. And this causes following messages when the device is registered
again:
WARNING: CPU: 0 PID: 2228 at /home/viresh/linux/fs/sysfs/dir.c:31
sysfs_warn_dup
This file isn't getting removed while we unbind a device from thermal
zone. And this causes following messages when the device is registered
again:
WARNING: CPU: 0 PID: 2228 at /home/viresh/linux/fs/sysfs/dir.c:31
sysfs_warn_dup+0x60/0x70()
sysfs: cannot create duplicate filename
'/devices
] CPU: 0 PID: 137 Comm: sh Not tainted
4.1.10-rt8-01700-g2c38702-dirty #55
[ 57.767555] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 57.767568] [] (unwind_backtrace) from []
(show_stack+0x20/0x24)
[ 57.767579] [] (show_stack) from []
(dump_stack+0x84/0xa0)
[ 57.767593
From: Al Viro <v...@zeniv.linux.org.uk>
commit eb47e0293baaa3044022059f1fa9ff474bfe35cb upstream.
* copy_from_user() on access_ok() failure ought to zero the destination
* none of those primitives should skip the access_ok() check in case of
small constant size.
Acked-by: Jesper N
From: Al Viro <v...@zeniv.linux.org.uk>
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit eb47e0293baaa3044022059f1fa9ff474bfe35cb upstream.
* copy_from_user() on access_ok() failure ought to zero the destination
* none of those prim
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Niklas Cassel
[ Upstream commit 379521462e4add27f3514da8e4ab1fd7a54fe1c7 ]
Fixes the following splat during boot:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Niklas Cassel
[ Upstream commit 379521462e4add27f3514da8e4ab1fd7a54fe1c7 ]
Fixes the following splat during boot:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c
From: Niklas Cassel
[ Upstream commit 379521462e4add27f3514da8e4ab1fd7a54fe1c7 ]
Fixes the following splat during boot:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
in_atomic(): 1, irqs_disabled(): 128, pid: 77, name: kworker/2:1
4 locks held by kworker/2:1
From: Niklas Cassel
[ Upstream commit 379521462e4add27f3514da8e4ab1fd7a54fe1c7 ]
Fixes the following splat during boot:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
in_atomic(): 1, irqs_disabled(): 128, pid: 77, name: kworker/2:1
4 locks held by kworker/2:1
@ME:/
root@ME:/ INFO: rcu_preempt detected stalls on CPUs/tasks: { 0}
(detected by 1, t=29545 jiffies)
[] (unwind_backtrace+0x0/0xf8) from []
(rcu_check_callbacks+0x6e0/0x76c)
[] (rcu_check_callbacks+0x6e0/0x76c) from []
(update_process_times+0x38/0x4c)
[] (update_process_times+0x38/0x4c) fr
ot@ME:/ INFO: rcu_preempt detected stalls on CPUs/tasks: { 0}
> (detected by 1, t=29545 jiffies)
> [] (unwind_backtrace+0x0/0xf8) from []
> (rcu_check_callbacks+0x6e0/0x76c)
> [] (rcu_check_callbacks+0x6e0/0x76c) from []
> (update_process_times+0x38/0x4c)
> [] (upda
4.18-stable review patch. If anyone has any objections, please let me know.
--
From: Niklas Cassel
[ Upstream commit 379521462e4add27f3514da8e4ab1fd7a54fe1c7 ]
Fixes the following splat during boot:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Niklas Cassel
[ Upstream commit 379521462e4add27f3514da8e4ab1fd7a54fe1c7 ]
Fixes the following splat during boot:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c
From: Niklas Cassel
[ Upstream commit 379521462e4add27f3514da8e4ab1fd7a54fe1c7 ]
Fixes the following splat during boot:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
in_atomic(): 1, irqs_disabled(): 128, pid: 77, name: kworker/2:1
4 locks held by kworker/2:1
From: Niklas Cassel
[ Upstream commit 379521462e4add27f3514da8e4ab1fd7a54fe1c7 ]
Fixes the following splat during boot:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:747
in_atomic(): 1, irqs_disabled(): 128, pid: 77, name: kworker/2:1
4 locks held by kworker/2:1
On Mon, Apr 13, 2015 at 07:37:20PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the char-misc tree, today's linux-next build (x86_64
> allmodconfig) produced these warnings:
>
> In file included from include/trace/define_trace.h:90:0,
> from
[2.593796] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[2.599892] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[2.607612] [] (show_stack) from []
(dump_stack+0x70/0xbc)
[2.614822] [] (dump_stack) from []
(warn_slowpath_common+0x74/0xb0)
[2.622885
0 PID: 1 Comm: swapper/0 Tainted: GW
> 3.18.0-next-20141216-2-g4ff197fc1902-dirty #1318
> [2.593796] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [2.599892] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [2.607612] [] (show_stack) f
From: Al Viro
commit eb47e0293baaa3044022059f1fa9ff474bfe35cb upstream.
* copy_from_user() on access_ok() failure ought to zero the destination
* none of those primitives should skip the access_ok() check in case of
small constant size.
Acked-by: Jesper Nilsson
Signed-off-by: Al Viro
Signed
From: Al Viro
3.12-stable review patch. If anyone has any objections, please let me know.
===
commit eb47e0293baaa3044022059f1fa9ff474bfe35cb upstream.
* copy_from_user() on access_ok() failure ought to zero the destination
* none of those primitives should skip the access_ok
] CPU: 0 PID: 137 Comm: sh Not tainted
4.1.10-rt8-01700-g2c38702-dirty #55
[ 57.767555] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 57.767568] [] (unwind_backtrace) from []
(show_stack+0x20/0x24)
[ 57.767579] [] (show_stack) from []
(dump_stack+0x84/0xa0)
[ 57.767593
Commit 6e3f62f0793e (mfd: core: Fix platform-device id generation)
changed the way platform device ids are generated from mfd id base and
cell ids in mfd_add_device(). Unfortunately the change in question
breaks mfd drivers which are using mfd_add_devices() with mfd id base
equal to -1 and non
Commit 6e3f62f0793e (mfd: core: Fix platform-device id generation)
changed the way platform device ids are generated from mfd id base and
cell ids in mfd_add_device(). Unfortunately the change in question
breaks mfd drivers which are using mfd_add_devices() with mfd id base
equal to -1 and non
Commit 6e3f62f0793e (mfd: core: Fix platform-device id generation)
changed the way platform device ids are generated from mfd id base and
cell ids in mfd_add_device(). Unfortunately the change in question
breaks mfd drivers which are using mfd_add_devices() with mfd id base
equal to -1 and non
The signal code for ILP32 uses one extra function from signal32.c; it does not
make sense to enable the whole signal32.c code so we move the function which
was being used to signal.c.
Signed-off-by: Andrew Pinski
---
arch/arm64/kernel/signal.c | 85
Commit 6e3f62f0793e ("mfd: core: Fix platform-device id generation")
changed the way platform device ids are generated from mfd id base and
cell ids in mfd_add_device(). Unfortunately the change in question
breaks mfd drivers which are using mfd_add_devices() with mfd id base
equal to
Commit 6e3f62f0793e ("mfd: core: Fix platform-device id generation")
changed the way platform device ids are generated from mfd id base and
cell ids in mfd_add_device(). Unfortunately the change in question
breaks mfd drivers which are using mfd_add_devices() with mfd id base
equal to
Commit 6e3f62f0793e ("mfd: core: Fix platform-device id generation")
changed the way platform device ids are generated from mfd id base and
cell ids in mfd_add_device(). Unfortunately the change in question
breaks mfd drivers which are using mfd_add_devices() with mfd id base
equal to
On 02/08/07, Jesper Juhl [EMAIL PROTECTED] wrote:
I get this build error with the current mainline git tree.
When I say current mainline git tree I mean that HEAD is at
370504cf7c68b953de55c41d5e0be97d30f3cf00
Let me know if further details are needed...
...
In file included from include
Kernel built with extcon and charger-manager.
After connecting the USB cable sleeping function was called from atomic
context:
[ 63.328648] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:586
[]
[ 63.388743] Workqueue: events max14577_muic_irq_work
Not tainted
4.3.0-rc4-00030-gca978c0-dirty #335
[ 30.154174] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
[ 30.160827] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 30.168975] [] (show_stack) from []
(dump_stack+0x80/0x9c)
[ 30.176635] [] (dump_stack) from
c AM33XX (Flattened Device Tree)
> [3.806920] [] (unwind_backtrace) from []
> (show_stack+0x10/0x14)
> [3.817762] [] (show_stack) from []
> (dump_stack+0x84/0x9c)
> [3.828071] [] (dump_stack) from []
> (warn_slowpath_common+0x7c/0xb8)
> [3.839284] [] (warn_slo
d3-dirty #68
Hardware name: Generic DRA74X (Flattened Device Tree)
task: eb1ee800 ti: ec962000 task.ti: ec962000
PC is at omap_device_enable+0x10/0x90
LR is at _od_runtime_resume+0x10/0x24
[...]
[] (omap_device_enable) from []
(_od_runtime_resume+0x10/0x24)
[] (_od_runtime_resume) from [] (__r
4.10.0-rc3-next-20170111+ #148
[ 33.421182] Hardware name: Rockchip (Device Tree)
[ 33.425905] [] (unwind_backtrace) from []
(show_stack+0x20/0x24)
[ 33.433652] [] (show_stack) from []
(dump_stack+0x8c/0xa0)
[ 33.440881] [] (dump_stack) from []
(__warn+0xf8/0x110)
[ 33.447839] [] (
[ 33.421182] Hardware name: Rockchip (Device Tree)
[ 33.425905] [] (unwind_backtrace) from []
(show_stack+0x20/0x24)
[ 33.433652] [] (show_stack) from []
(dump_stack+0x8c/0xa0)
[ 33.440881] [] (dump_stack) from []
(__warn+0xf8/0x110)
[ 33.447839] [] (__warn) from []
(warn_slowpath_null+0x30/0x38
n
> issue with memcpy on 64bit with CONFIG_KMEMCHECK=y and with
> memset/__memset on 32bit:
>
> $ cat init/test.c
> #include
> $ make -s init/test.o
> $ make -s init/test.o
> In file included from ./arch/x86/include/asm/string.h:4:0,
>
I do not know if this is old or new, just noticed it scrolling by while
compiling current 4.12+git on 32-bit x86.
CC [M] fs/fat/namei_vfat.o
In file included from ./arch/x86/include/asm/string.h:2:0,
from ./include/linux/string.h:18,
from ./include/linux
Debian
unstable, up to date.
> Well, latest change of namei_vfat.c is Sep, 2016. And I can't reproduce
> it by "gcc version 6.3.0 20170516 (Debian 6.3.0-18)".
>
> > CC [M] fs/fat/namei_vfat.o
> > In file included from ./arch/x86/include/asm/string.h
on 6.3.0 20170516 (Debian 6.3.0-18)".
> CC [M] fs/fat/namei_vfat.o
> In file included from ./arch/x86/include/asm/string.h:2:0,
> from ./include/linux/string.h:18,
> from ./include/linux/bitmap.h:8,
> from ./include/linux/cpumask
Hi all,
After merging the rdma tree, today's linux-next build (x86_64
allmodconfig) produced these warnings:
In file included from include/linux/printk.h:336:0,
from include/linux/kernel.h:14,
from arch/x86/include/asm/percpu.h:45,
from arch/x86
From: Marek Szyprowski <m.szyprow...@samsung.com>
[ Upstream commit 0c4c5860e9983eb3da7a3d73ca987643c3ed034b ]
Initialize data->config_lock mutex before it is used by the driver code.
This fixes following warning on Odroid XU3 boards:
INFO: trying to register non-static key.
the cod
4.15-stable review patch. If anyone has any objections, please let me know.
--
From: Marek Szyprowski <m.szyprow...@samsung.com>
commit 0c4c5860e9983eb3da7a3d73ca987643c3ed034b upstream.
Initialize data->config_lock mutex before it is used by the driver code.
T
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marek Szyprowski <m.szyprow...@samsung.com>
commit 0c4c5860e9983eb3da7a3d73ca987643c3ed034b upstream.
Initialize data->config_lock mutex before it is used by the driver code.
T
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Marek Szyprowski <m.szyprow...@samsung.com>
commit 0c4c5860e9983eb3da7a3d73ca987643c3ed034b upstream.
Initialize data->config_lock mutex before it is used by the driver code.
T
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Marek Szyprowski <m.szyprow...@samsung.com>
commit 0c4c5860e9983eb3da7a3d73ca987643c3ed034b upstream.
Initialize data->config_lock mutex before it is used by the driver code.
T
On 02/08/07, Jesper Juhl <[EMAIL PROTECTED]> wrote:
> I get this build error with the current mainline git tree.
When I say "current mainline git tree" I mean that HEAD is at
370504cf7c68b953de55c41d5e0be97d30f3cf00
> Let me know if further details are needed...
>
>
3] #0: (>cred_guard_mutex){+.+.+.}, at: []
> prepare_bprm_creds+0x28/0x64
> [5.712326] #1: (>i_mutex_dir_key){+.+.+.}, at: []
> lookup_slow+0x2c/0xa0
> [5.720966]
> [5.720966] stack backtrace:
> [5.725528] [] (unwind_backtrace+0x0/0xf0) from []
>> prepare_bprm_creds+0x28/0x64
>> [5.712326] #1: (>i_mutex_dir_key){+.+.+.}, at: []
>> lookup_slow+0x2c/0xa0
>> [5.720966]
>> [5.720966] stack backtrace:
>> [5.725528] [] (unwind_backtrace+0x0/0xf0) from []
>> (rpc_wait_bit_killable+
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Marek Szyprowski
commit 0c4c5860e9983eb3da7a3d73ca987643c3ed034b upstream.
Initialize data->config_lock mutex before it is used by the driver code.
This fixes following warning on Odroid
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Marek Szyprowski
commit 0c4c5860e9983eb3da7a3d73ca987643c3ed034b upstream.
Initialize data->config_lock mutex before it is used by the driver code.
This fixes following warning on Odroid
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Marek Szyprowski
commit 0c4c5860e9983eb3da7a3d73ca987643c3ed034b upstream.
Initialize data->config_lock mutex before it is used by the driver code.
This fixes following warning on Odroid
4.15-stable review patch. If anyone has any objections, please let me know.
--
From: Marek Szyprowski
commit 0c4c5860e9983eb3da7a3d73ca987643c3ed034b upstream.
Initialize data->config_lock mutex before it is used by the driver code.
This fixes following warning on Odroid
From: Marek Szyprowski
[ Upstream commit 0c4c5860e9983eb3da7a3d73ca987643c3ed034b ]
Initialize data->config_lock mutex before it is used by the driver code.
This fixes following warning on Odroid XU3 boards:
INFO: trying to register non-static key.
the code is fine but needs lock
601 - 700 of 3269157 matches
Mail list logo
