All of lore.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 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.