Re: [dm-devel] Sleeping function called from invalid context

From: Mike Snitzer <snitzer@kernel.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: Joe Thornber <ejt@redhat.com>,
	dm-devel@redhat.com, Alasdair Kergon <agk@redhat.com>
Subject: Re: [dm-devel] Sleeping function called from invalid context
Date: Wed, 27 Sep 2023 11:57:01 -0400	[thread overview]
Message-ID: <ZRRQzWHeTajRZGko@redhat.com> (raw)
In-Reply-To: <ZROyqtbB6OuMOqci@casper.infradead.org>

On Wed, Sep 27 2023 at 12:42P -0400,
Matthew Wilcox <willy@infradead.org> wrote:

> On Tue, Sep 26, 2023 at 11:53:33PM +0100, Matthew Wilcox wrote:
> > I'm going to sleep now instead of running the last 10 steps of the
> > bisect.  If nobody's found this when I wake up, I'll finish it then.
> 
> Bisection found it.  I confirmed by hand; checking out this commit
> yields a failed test, and then reverting it leads to a success.
> 
> commit 026e4728c276cdf3ec618a71a38181864596027b
> Author: Joe Thornber <ejt@redhat.com>
> Date:   Wed Sep 13 10:39:09 2023 +0100
> 
>     dm thin: Use the extent allocator for data blocks
> 
>     The thin_pool object now contains an extent-allocator, and each thin
>     device contains an allocation-context from this.  The allocation
>     context is used to guide data block allocations.  The actual
>     allocation book-keeping is still done by the space-map.
> 
>     2 new specific unit tests were added to dm-unit:
> 
>        /thinp/fragmentation/thins
>        /thinp/fragmentation/snapshots
> 
>        https://github.com/jthornber/dm-unit/blob/main/src/tests/thinp.rs
> 
>     Signed-off-by: Joe Thornber <ejt@redhat.com>
>     Signed-off-by: Mike Snitzer <snitzer@kernel.org>
> 
> Joe, in case you missed the earlier splat:

...

> 
> This seems fairly clear to me; there's a spin_lock() around the call to
> __alloc() in dm_ea_context_alloc(), which then calls all the way down
> that stack until you get to cache_get(), which takes a semaphore and
> the locking validation quite reasonably says "You can't do that".
> 
> I'm sure you don't need my help coming up with a fix.  Although I might
> ask that you turn on at least some basic locking checks in future while
> developing your code, even if not full lockdep.  I think this particular
> warning comes out of CONFIG_DEBUG_ATOMIC_SLEEP=y.

Thanks for the report and bisecting -- wish I caught you earlier to
save you the hassle (was immediately clear which commit caused it when
I saw the trace).

Joe is looking at how best to fix and also updating dmtest-python [1]
to scrape the kernel log to pickup such bugs (as-is the kernel will
carry on despite the splat, so far anyway).

But I've dropped the related code from linux-next until this is all
fixed properly.

Mike

[1] https://github.com/jthornber/dmtest-python.git

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel