ask to TASK_INTERRUPTIBLE, before doing the condition check. This
means that we will try to acquire the mutex while already in a
sleeping state. The scheduler warns us by giving the following
warning:
[ 4050.264464] [ cut here ]
[ 4050.264508] do not call blocking ops w
ask to TASK_INTERRUPTIBLE, before doing the condition check. This
means that we will try to acquire the mutex while already in a
sleeping state. The scheduler warns us by giving the following
warning:
[ 4050.264464] [ cut here ]
[ 4050.264508] do not call blocking ops w
ask to TASK_INTERRUPTIBLE, before doing the condition check. This
means that we will try to acquire the mutex while already in a
sleeping state. The scheduler warns us by giving the following
warning:
[ 4050.264464] [ cut here ]
[ 4050.264508] do not call blocking ops w
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Ian Abbott
commit cef988642cdac44e910a27cb6e8166c96f86a0df upstream.
Comedi's read and write file operation handlers (`comedi_read()` and
`comedi_write()`) currently call `copy_to_user()` or `c
4.12-stable review patch. If anyone has any objections, please let me know.
--
From: Ian Abbott
commit cef988642cdac44e910a27cb6e8166c96f86a0df upstream.
Comedi's read and write file operation handlers (`comedi_read()` and
`comedi_write()`) currently call `copy_to_user()` or `
On Fri, Jul 28, 2017 at 04:22:31PM +0100, Ian Abbott wrote:
> Comedi's read and write file operation handlers (`comedi_read()` and
> `comedi_write()`) currently call `copy_to_user()` or `copy_from_user()`
> whilst in the `TASK_INTERRUPTIBLE` state, which falls foul of the
> `might_fault()` checks w
Comedi's read and write file operation handlers (`comedi_read()` and
`comedi_write()`) currently call `copy_to_user()` or `copy_from_user()`
whilst in the `TASK_INTERRUPTIBLE` state, which falls foul of the
`might_fault()` checks when enabled. Fix it by setting the current task
state back to `TASK
ul 13 08:42:02 BST 2017 x86_64
GNU/Linux
[ 80.542018] NOHZ: local_softirq_pending 80
[ 125.175471] [ cut here ]
[ 125.175491] WARNING: CPU: 0 PID: 1497 at kernel/sched/core.c:7833
__might_sleep+0x9f/0xb0()
[ 125.175728] do not call blocking ops when !TASK_RUNNING; st
02 BST 2017
> >x86_64 GNU/Linux
> >
> >[ 80.542018] NOHZ: local_softirq_pending 80
> >[ 125.175471] [ cut here ]
> >[ 125.175491] WARNING: CPU: 0 PID: 1497 at kernel/sched/core.c:7833
> >__might_sleep+0x9f/0xb0()
> >[ 125.175728] do not call bloc
]
[ 125.175491] WARNING: CPU: 0 PID: 1497 at kernel/sched/core.c:7833
__might_sleep+0x9f/0xb0()
[ 125.175728] do not call blocking ops when !TASK_RUNNING; state=1 set at
[] comedi_read+0x1a1/0x610 [comedi]
[ 125.175735] Modules linked in: cpufreq_conservative cpufreq_powersave
cpufreq_userspace cfg80211
/sched/core.c:7833
__might_sleep+0x9f/0xb0()
[ 125.175728] do not call blocking ops when !TASK_RUNNING; state=1 set at
[] comedi_read+0x1a1/0x610 [comedi]
[ 125.175735] Modules linked in: cpufreq_conservative cpufreq_powersave
cpufreq_userspace cfg80211 nfsd auth_rpcgss oid_registry nfs_acl nfs
0 RSI: ae80 RDI:
> 0011
> [ 101.899172] RBP: 7fd36eb5f000 R08: R09:
> 00000000
> [ 101.899172] R10: 0000 R11: 0246 R12:
> 0001
> [ 101.899173] R13: 0004 R14:
2 PID: 4265 at kernel/sched/core.c:7840
__might_sleep+0x80/0x90
[ 101.959144] do not call blocking ops when !TASK_RUNNING; state=1 set at
[] prepare_to_swait+0x40/0xd0
[ 101.959146] Modules linked in: tun(E) ebtable_filter(E) ebtables(E) fuse(E)
nf_log_ipv6(E) xt_pkttype(E) xt_physdev(E)
n the wait_event loop, which
means we might clobber the task state:
[ 10.831289] do not call blocking ops when !TASK_RUNNING; state=1 set at
[]
[ 10.845531] [ cut here ]
[ 10.850161] WARNING: at kernel/sched/core.c:7630
...
[ 12.164333] ---[ end trace 45409966a9a
n the wait_event loop, which
means we might clobber the task state:
[ 10.831289] do not call blocking ops when !TASK_RUNNING; state=1 set at
[]
[ 10.845531] [ cut here ]
[ 10.850161] WARNING: at kernel/sched/core.c:7630
...
[ 12.164333] ---[ end trace 45409966a9a
On 21/08/16 13:26, Lars-Peter Clausen wrote:
> On 08/21/2016 01:21 PM, Jonathan Cameron wrote:
> [...]
>> I've applied to this to the fixes-togreg branch of iio.git
>>
>> For now I haven't marked it for stable, purely because I'm not sure
>> when the first 'problem' usage was introduced. I'm happy
On 08/21/2016 01:21 PM, Jonathan Cameron wrote:
[...]
> I've applied to this to the fixes-togreg branch of iio.git
>
> For now I haven't marked it for stable, purely because I'm not sure
> when the first 'problem' usage was introduced. I'm happy to explicitly
> send a request for stable inclusion
wait_event loop, which
>>> means we might clobber the task state:
>>>
>>> [ 10.831289] do not call blocking ops when !TASK_RUNNING; state=1 set at
>>> []
>>> [ 10.845531] [ cut here ]
>>> [ 10.850161] WARNING:
ght clobber the task state:
>>
>> [ 10.831289] do not call blocking ops when !TASK_RUNNING; state=1 set at
>> []
>> [ 10.845531] [ cut here ]
>> [ 10.850161] WARNING: at kernel/sched/core.c:7630
>> ...
>> [ 12.164333] ---[ end trace
On 09/08/16 01:19, Brian Norris wrote:
> When using CONFIG_DEBUG_ATOMIC_SLEEP, the scheduler nicely points out
> that we're calling sleeping primitives within the wait_event loop, which
> means we might clobber the task state:
>
> [ 10.831289] do not call blocking ops when
On 08/09/2016 12:23 AM, Brian Norris wrote:
> Hi Lars,
>
> On Thu, Aug 04, 2016 at 12:21:08PM +0200, Lars-Peter Clausen wrote:
>> And then also drop the if (!indio_dev->info) at the beginning of the
>> function.
>
> I was poking through the usage of this ->info field, and it looks like
> it's su
When using CONFIG_DEBUG_ATOMIC_SLEEP, the scheduler nicely points out
that we're calling sleeping primitives within the wait_event loop, which
means we might clobber the task state:
[ 10.831289] do not call blocking ops when !TASK_RUNNING; state=1 set at
[]
[ 10.845531]
Hi Lars,
On Thu, Aug 04, 2016 at 12:21:08PM +0200, Lars-Peter Clausen wrote:
> And then also drop the if (!indio_dev->info) at the beginning of the function.
I was poking through the usage of this ->info field, and it looks like
it's supposed to be protected by the 'info_exist_lock' lock, but tha
On 08/04/2016 11:41 AM, Brian Norris wrote:
> On Thu, Aug 04, 2016 at 10:45:39AM +0200, Lars-Peter Clausen wrote:
>>> @@ -132,10 +133,13 @@ ssize_t iio_buffer_read_first_n_outer(struct file
>>> *filp, char __user *buf,
>>> to_wait = min_t(size_t, n / datum_size, rb->watermark);
>>>
>
On Thu, Aug 04, 2016 at 10:45:39AM +0200, Lars-Peter Clausen wrote:
> > @@ -132,10 +133,13 @@ ssize_t iio_buffer_read_first_n_outer(struct file
> > *filp, char __user *buf,
> > to_wait = min_t(size_t, n / datum_size, rb->watermark);
> >
> > do {
> > - ret = wait_event_i
On 08/04/2016 10:26 AM, Brian Norris wrote:
> When using CONFIG_DEBUG_ATOMIC_SLEEP, the scheduler nicely points out
> that we're calling sleeping primitives within the wait_event loop, which
> means we might clobber the task state:
>
> [ 10.831289] do not call blocking op
When using CONFIG_DEBUG_ATOMIC_SLEEP, the scheduler nicely points out
that we're calling sleeping primitives within the wait_event loop, which
means we might clobber the task state:
[ 10.831289] do not call blocking ops when !TASK_RUNNING; state=1 set at
[]
[ 10.845531]
Hi Lars,
On Tue, Aug 02, 2016 at 03:06:39PM +0200, Lars-Peter Clausen wrote:
> On 08/02/2016 03:12 AM, Brian Norris wrote:
> > I'm seeing the following warnings when I read from an IIO char device,
> > with CONFIG_DEBUG_ATOMIC_SLEEP=y. I'm testing a v4.4 kernel, but AFAICT,
> > nothing too relevan
On 08/02/2016 06:57 PM, Brian Norris wrote:
> Hi Lars,
>
> On Tue, Aug 02, 2016 at 03:06:39PM +0200, Lars-Peter Clausen wrote:
>> On 08/02/2016 03:12 AM, Brian Norris wrote:
>>> I'm seeing the following warnings when I read from an IIO char device,
>>> with CONFIG_DEBUG_ATOMIC_SLEEP=y. I'm testing
On 08/02/2016 03:12 AM, Brian Norris wrote:
> Hi all,
>
> I'm seeing the following warnings when I read from an IIO char device,
> with CONFIG_DEBUG_ATOMIC_SLEEP=y. I'm testing a v4.4 kernel, but AFAICT,
> nothing too relevant has changed between that and v4.7:
[...]
> Have any of you seen this ki
Hi all,
I'm seeing the following warnings when I read from an IIO char device,
with CONFIG_DEBUG_ATOMIC_SLEEP=y. I'm testing a v4.4 kernel, but AFAICT,
nothing too relevant has changed between that and v4.7:
[ 10.831289] do not call blocking ops when !TASK_RUNNING; stat
[ 19.381055] [ cut here ]
[ 19.381225] WARNING: CPU: 3 PID: 487 at kernel/sched/core.c:7291
__might_sleep+0x87/0x90()
[ 19.381373] do not call blocking ops when !TASK_RUNNING; state=2 set at
[] wait_for_completion_io+0xe5/0x140
...
[ 19.387265] Call Trace
Thomas Huth writes:
> On Wed, 25 Feb 2015 16:11:27 +0100
> Cornelia Huck wrote:
>
>> On Wed, 25 Feb 2015 15:36:02 +0100
>> "Michael S. Tsirkin" wrote:
>>
>> > virtio balloon has this code:
>> > wait_event_interruptible(vb->config_change,
>> > (diff = tow
On Wed, 25 Feb 2015 16:11:27 +0100
Cornelia Huck wrote:
> On Wed, 25 Feb 2015 15:36:02 +0100
> "Michael S. Tsirkin" wrote:
>
> > virtio balloon has this code:
> > wait_event_interruptible(vb->config_change,
> > (diff = towards_target(vb)) != 0
> >
On Wed, 25 Feb 2015 15:36:02 +0100
"Michael S. Tsirkin" wrote:
> virtio balloon has this code:
> wait_event_interruptible(vb->config_change,
> (diff = towards_target(vb)) != 0
> || vb->need_stats_update
>
On Wed, Feb 25, 2015 at 03:32:08PM +0100, Cornelia Huck wrote:
> On Wed, 25 Feb 2015 15:14:36 +0100
> "Michael S. Tsirkin" wrote:
>
> > virtio balloon has this code:
> > wait_event_interruptible(vb->config_change,
> > (diff = towards_target(vb)) != 0
> >
virtio balloon has this code:
wait_event_interruptible(vb->config_change,
(diff = towards_target(vb)) != 0
|| vb->need_stats_update
|| kthread_should_stop()
||
On Wed, 25 Feb 2015 15:14:36 +0100
"Michael S. Tsirkin" wrote:
> virtio balloon has this code:
> wait_event_interruptible(vb->config_change,
> (diff = towards_target(vb)) != 0
> || vb->need_stats_update
>
virtio balloon has this code:
wait_event_interruptible(vb->config_change,
(diff = towards_target(vb)) != 0
|| vb->need_stats_update
|| kthread_should_stop()
||
On Wed, Dec 24, 2014 at 02:50:02PM +0800, Fam Zheng wrote:
> Could you trace down to the source code context of this io_getevents call in
> mysqld? The change merely made io_getevents return a lot more quickly than
> before, so it seems like that a polling loop is spinning too fast as a result.
T
On Mon, 12/22 13:12, Bjørn Mork wrote:
> Hello,
>
> I got this warning on v3.19-rc1:
>
> [ 16.325814] [ cut here ]
> [ 16.325832] WARNING: CPU: 0 PID: 3368 at kernel/sched/core.c:7303
> __might_sleep+0x55/0x94()
> [ 16.325839] do no
Hello,
I got this warning on v3.19-rc1:
[ 16.325814] [ cut here ]
[ 16.325832] WARNING: CPU: 0 PID: 3368 at kernel/sched/core.c:7303
__might_sleep+0x55/0x94()
[ 16.325839] do not call blocking ops when !TASK_RUNNING; state=1 set at
[] prepare_to_wait_event+0x8c
42 matches
Mail list logo
