From: Vincent Whitchurch <vincent.whitchurch@axis.com>
To: Shyam Prasad N <nspmangalore@gmail.com>
Cc: Steve French <smfrench@gmail.com>,
ronnie sahlberg <ronniesahlberg@gmail.com>,
Paulo Alcantara <pc@cjr.nz>, CIFS <linux-cifs@vger.kernel.org>
Subject: Re: lockdep deadlock warning
Date: Mon, 30 May 2022 15:34:48 +0200 [thread overview]
Message-ID: <20220530133443.GA3563@axis.com> (raw)
In-Reply-To: <20220523123755.GA13668@axis.com>
On Mon, May 23, 2022 at 02:38:02PM +0200, Vincent Whitchurch wrote:
> On Mon, Feb 14, 2022 at 10:19:30PM +0530, Shyam Prasad N wrote:
> > It's about a circular dependency locking fs_reclaim lock with srv_mutex held.
> > Does someone here understand this dependency?
>
> The crypto shash allocation does allocations with GFP_KERNEL (i.e.,
> GFP_NOFS is not set and so fs reclaim can be triggered) and this is
> called under the CIFS srv_mutex. However, the CIFS srv_mutex is also
> used in the reclaim path as the splat shows. This is the dependency
> which lockdep is complaining about.
>
> A way to remove this particular dependency is to make CIFS do a
> memalloc_nofs_save/restore() around the places it takes the srv_mutex.
> However, doing this does not solve the lockdep splats completely since
> there is another dependency via some internal locks in crypto, see the
> log below.
I have now sent out a patch to use memalloc_nofs_*. There are other
GFP_KERNEL allocations in CIFS done under the srv_mutex (such as the one
in SMB2_sess_auth_rawntlmssp_negotiate()) besides the shash allocations,
so that patch is needed even if something is done later to move the
crypto shash allocations out of that mutex.
https://lore.kernel.org/linux-cifs/20220530132155.4019006-1-vincent.whitchurch@axis.com/
prev parent reply other threads:[~2022-05-30 13:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-14 16:49 lockdep deadlock warning Shyam Prasad N
2022-05-23 12:38 ` Vincent Whitchurch
2022-05-30 13:34 ` Vincent Whitchurch [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220530133443.GA3563@axis.com \
--to=vincent.whitchurch@axis.com \
--cc=linux-cifs@vger.kernel.org \
--cc=nspmangalore@gmail.com \
--cc=pc@cjr.nz \
--cc=ronniesahlberg@gmail.com \
--cc=smfrench@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.