linux-kernel - Re: [PATCH] iio: buffer: Silence lock nesting splat

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20220820120800.519b5eb5@jic23-huawei>
Date:   Sat, 20 Aug 2022 12:08:00 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Vincent Whitchurch <vincent.whitchurch@...s.com>, kernel@...s.com,
        Lars-Peter Clausen <lars@...afoo.de>,
        linux-iio <linux-iio@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] iio: buffer: Silence lock nesting splat

On Fri, 19 Aug 2022 11:03:55 +0300
Andy Shevchenko <andy.shevchenko@...il.com> wrote:

> On Tue, Aug 16, 2022 at 1:30 PM Vincent Whitchurch
> <vincent.whitchurch@...s.com> wrote:
> >
> > If an IIO driver uses callbacks from another IIO driver and calls
> > iio_channel_start_all_cb() from one of its buffer setup ops, then
> > lockdep complains due to the lock nesting, as in the below example with
> > lmp91000.  Since the locks are being taken on different IIO devices,
> > there is no actual deadlock, so add lock nesting annotation to silence
> > the spurious warning.
> >
> >  ============================================
> >  WARNING: possible recursive locking detected
> >  6.0.0-rc1+ #10 Not tainted
> >  --------------------------------------------
> >  python3/23 is trying to acquire lock:
> >  0000000064c944c0 (&indio_dev->mlock){+.+.}-{3:3}, at: iio_update_buffers+0x62/0x180
> >
> >  but task is already holding lock:
> >  00000000636b64c0 (&indio_dev->mlock){+.+.}-{3:3}, at: enable_store+0x4d/0x100
> >
> >  other info that might help us debug this:
> >   Possible unsafe locking scenario:
> >
> >         CPU0
> >         ----
> >    lock(&indio_dev->mlock);
> >    lock(&indio_dev->mlock);
> >
> >   *** DEADLOCK ***
> >
> >   May be due to missing lock nesting notation
> >
> >  5 locks held by python3/23:
> >   #0: 00000000636b5420 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x67/0x100
> >   #1: 0000000064c19280 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x13a/0x270
> >   #2: 0000000064c3d9e0 (kn->active#14){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x149/0x270
> >   #3: 00000000636b64c0 (&indio_dev->mlock){+.+.}-{3:3}, at: enable_store+0x4d/0x100
> >   #4: 0000000064c945c8 (&iio_dev_opaque->info_exist_lock){+.+.}-{3:3}, at: iio_update_buffers+0x4f/0x180
> >
> >  stack backtrace:
> >  CPU: 0 PID: 23 Comm: python3 Not tainted 6.0.0-rc1+ #10
> >  Call Trace:
> >   dump_stack+0x1a/0x1c
> >   __lock_acquire.cold+0x407/0x42d
> >   lock_acquire+0x1ed/0x310
> >   __mutex_lock+0x72/0xde0
> >   mutex_lock_nested+0x1d/0x20
> >   iio_update_buffers+0x62/0x180
> >   iio_channel_start_all_cb+0x1c/0x20 [industrialio_buffer_cb]
> >   lmp91000_buffer_postenable+0x1b/0x20 [lmp91000]
> >   __iio_update_buffers+0x50b/0xd80
> >   enable_store+0x81/0x100
> >   dev_attr_store+0xf/0x20
> >   sysfs_kf_write+0x4c/0x70
> >   kernfs_fop_write_iter+0x179/0x270
> >   new_sync_write+0x99/0x120
> >   vfs_write+0x2c1/0x470
> >   ksys_write+0x67/0x100
> >   sys_write+0x10/0x20  
> 
> https://www.kernel.org/doc/html/latest/process/submitting-patches.html#backtraces-in-commit-mesages
> 
> On top of that, Fixes tag?
It's going to be tricky to identify - the interface predates usecases that were IIO
drivers by a long way.  I guess introduction of first IIO driver that used
a callback buffer? No idea which one that was :(

> 
> > Signed-off-by: Vincent Whitchurch <vincent.whitchurch@...s.com>  
> 
> 
> --
> With Best Regards,
> Andy Shevchenko