public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Hillf Danton <hdanton@sina.com>
Cc: Helge Deller <deller@gmx.de>,
	John David Anglin <dave.anglin@bell.net>,
	linux-kernel@vger.kernel.org, linux-parisc@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: WARNING: CPU: 1 PID: 14735 at fs/dcache.c:365 dentry_free+0x100/0x128
Date: Wed, 20 Jul 2022 18:06:16 +0100	[thread overview]
Message-ID: <Ytg2CDLzLo+FKbTZ@ZenIV> (raw)
In-Reply-To: <20220720110032.1787-1-hdanton@sina.com>

On Wed, Jul 20, 2022 at 07:00:32PM +0800, Hillf Danton wrote:

> To help debug it, de-union d_in_lookup_hash with d_alias and add debug
> info after dentry is killed. If any warning hits, we know where to add
> something like
> 
> 	WARN_ON(dentry->d_flags & DCACHE_DENTRY_KILLED);
> 
> before hlist_bl_add or hlist_add.

IDGI.  That clearly has nothing to do with in-lookup stuff - no
DCACHE_PAR_LOOKUP in reported flags, so it either never had it set,
or it went through __d_lookup_done() already.

If anything, it might have already been through d_free(), with
d_rcu being confused for d_alias.

I'd do something like
	WARN_ON(dentry->d_flags & (1U<<31));
	dentry->d_flags |= 1U << 31;
in the begining of d_free() (possibly with dumping dentry state if we
hit that, not that there would be much to report; d_name.name might
be informative, though).

Again, in-lookup looks like a red herring - DCACHE_PAR_LOOKUP is set
only in d_alloc_parallel(), right next to the insertion into the list
and removed only in __d_lookup_free(), right next to the removal from
the same.  No DCACHE_PAR_LOOKUP in ->d_flags (it's 0x8008 in reported
cases, i.e. DCACHE_OP_REVALIDATE | DCACHE_DENTRY_KILLED).

What's more, take a look at retain_dentry(); WARN_ON(d_in_lookup(dentry))
right at the top and it had not triggered in any of the reports I've
seen in that thread.  Granted, it's not called on each path to
__dentry_kill(), but it is on the call chains I've seen reported...

Another thing that might be interesting to know is ->d_sb, along with
->d_sb->s_type->name and ->d_sb->s_id.  That should tell which fs it's
on...

I wonder if anyone had seen anything similar outside of parisc...
I don't know if I have any chance to reproduce it here - the only
parisc box I've got is a 715/100 (assuming the disk is still alive)
and it's 32bit, unlike the reported setups and, er, not fast.
qemu seems to have some parisc support, but it's 32bit-only at the
moment...

PS: please, Cc fsdevel on anything VFS-related.  Very few people are
still subscribed to l-k these days - I am, but it's impossible to read
through and postings can easily get missed.

  parent reply	other threads:[~2022-07-20 17:06 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20220709090756.2384-1-hdanton@sina.com>
2022-07-15  8:18 ` WARNING: CPU: 1 PID: 14735 at fs/dcache.c:365 dentry_free+0x100/0x128 Helge Deller
     [not found] ` <20220715133300.1297-1-hdanton@sina.com>
2022-07-16  5:27   ` Helge Deller
2022-07-17  9:42     ` Helge Deller
     [not found]     ` <20220717113634.1552-1-hdanton@sina.com>
2022-07-19 16:32       ` Helge Deller
2022-07-19 20:59         ` John David Anglin
2022-07-19 21:25           ` Helge Deller
2022-07-20  2:00             ` Al Viro
2022-07-20  2:22         ` Al Viro
2022-07-20  2:31     ` Al Viro
2022-07-20  2:33       ` Al Viro
2022-07-20  3:29     ` Al Viro
2022-07-20  6:53       ` Helge Deller
2022-07-20  7:07         ` Al Viro
2022-07-20  9:21           ` Helge Deller
     [not found]           ` <20220720110032.1787-1-hdanton@sina.com>
2022-07-20 17:06             ` Al Viro [this message]
2022-07-20 23:15               ` Sam James
2022-07-21  3:54                 ` Helge Deller
2022-07-30 20:21                   ` Helge Deller
2022-07-09  5:33 Helge Deller

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=Ytg2CDLzLo+FKbTZ@ZenIV \
    --to=viro@zeniv.linux.org.uk \
    --cc=dave.anglin@bell.net \
    --cc=deller@gmx.de \
    --cc=hdanton@sina.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox