Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1455022

Re: iio: WARNING at kernel/sched/core.c:7630: do not call blocking ops when !TASK_RUNNING

From Brian Norris <briannorris@chromium.org>
Newsgroups linux.kernel
Subject Re: iio: WARNING at kernel/sched/core.c:7630: do not call blocking ops when !TASK_RUNNING
Date 2016-08-02 19:00 +0200
Message-ID <s1LcW-77c-5@gated-at.bofh.it> (permalink)
References <s1wGW-5Vm-11@gated-at.bofh.it> <s1If1-589-73@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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 relevant has changed between that and v4.7:
> [...]
> > Have any of you seen this kind of issue before (perhaps most IIO users
> > are not using CONFIG_DEBUG_ATOMIC_SLEEP)? If the WARNING is really
> > correct, then this problem has really been around a while. It looks like
> > we have a wait_event_interruptible() called, with this call chain in the
> > 'condition' path:
> > 
> >   iio_buffer_ready()
> >     -> iio_buffer_data_available() (i.e., iio_kfifo_buf_data_available())
> >       -> mutex_lock()
> > 
> > Calling mutex_lock() means we clobber the TASK_INTERRUPTIBLE state with
> > TASK_RUNNING -- hence, the WARNING. Should this be using a spinlock
> > instead? Or is there some way to refactor this to avoid calling these
> > sleeping functions in the wait_event*() condition?
> 
> Hi,
> 
> Yes, this is an issue, thanks for pointing this out. It has been there for a
> while, my fault, sorry for that. We need a solution like pointed out in this
> article (https://lwn.net/Articles/628628/).

Ah, thanks for the pointer. I thought this problem seemed familiar, but
I couldn't find a canonical solution. The wait_woken() solution looks
like a good starting point, although it's definitely got more
boilerplate... It also requires a 'timeout'; I guess we'd want
MAX_SCHEDULE_TIMEOUT for this case?

Do you want to cook a patch, or should I?

Brian

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

iio: WARNING at kernel/sched/core.c:7630: do not call blocking ops  when !TASK_RUNNING Brian Norris <briannorris@chromium.org> - 2016-08-02 03:30 +0200
  Re: iio: WARNING at kernel/sched/core.c:7630: do not call blocking  ops when !TASK_RUNNING Lars-Peter Clausen <lars@metafoo.de> - 2016-08-02 15:50 +0200
    Re: iio: WARNING at kernel/sched/core.c:7630: do not call blocking  ops when !TASK_RUNNING Brian Norris <briannorris@chromium.org> - 2016-08-02 19:00 +0200
      Re: iio: WARNING at kernel/sched/core.c:7630: do not call blocking  ops when !TASK_RUNNING Lars-Peter Clausen <lars@metafoo.de> - 2016-08-02 19:10 +0200
        [PATCH] iio: fix sched WARNING "do not call blocking ops when  !TASK_RUNNING" Brian Norris <briannorris@chromium.org> - 2016-08-04 10:30 +0200
          Re: [PATCH] iio: fix sched WARNING "do not call blocking ops when  !TASK_RUNNING" Lars-Peter Clausen <lars@metafoo.de> - 2016-08-04 10:50 +0200
            Re: [PATCH] iio: fix sched WARNING "do not call blocking ops when  !TASK_RUNNING" Brian Norris <briannorris@chromium.org> - 2016-08-04 11:50 +0200
              Re: [PATCH] iio: fix sched WARNING "do not call blocking ops when  !TASK_RUNNING" Lars-Peter Clausen <lars@metafoo.de> - 2016-08-04 13:20 +0200
                Re: [PATCH] iio: fix sched WARNING "do not call blocking ops when  !TASK_RUNNING" Brian Norris <briannorris@chromium.org> - 2016-08-09 00:30 +0200
                Re: [PATCH] iio: fix sched WARNING "do not call blocking ops when  !TASK_RUNNING" Lars-Peter Clausen <lars@metafoo.de> - 2016-08-09 10:30 +0200
          [PATCH v2] iio: fix sched WARNING "do not call blocking ops when  !TASK_RUNNING" Brian Norris <briannorris@chromium.org> - 2016-08-09 02:20 +0200

csiph-web