All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: yangerkun <yangerkun@huawei.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	yi.zhang@huawei.com, houtao1@huawei.com, miaoxie@huawei.com
Subject: Re: system panic while dentry reference count overflow
Date: Tue, 7 May 2019 20:16:13 +0100	[thread overview]
Message-ID: <20190507191613.GI23075@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAHk-=wiQ-SdFKP_7TpM3qzNR85S8mxhpzMG0U-H-t4+KRiP35g@mail.gmail.com>

On Tue, May 07, 2019 at 08:26:06AM -0700, Linus Torvalds wrote:
> On Mon, May 6, 2019 at 9:15 PM Al Viro <viro@zeniv.linux.org.uk> wrote:
> >
> > Umm...  Where would you put the cutoff for try_dget()?  1G?  Because
> > 2G-<something relatively small> is risky - have it reached, then
> > get the rest of the way to 2G by normal dget() and you've got trouble.
> 
> I'd make the limit be 2G exactly like the page count. Negative counts
> are fine - they work exactly like large integers. It's only 0 that is
> special.

Negative ->d_lockref.count are used for "lockref is dead"...

>  - add the "limit negative dentries" patches that were already written
> for other reasons by Waiman Long.

Irrelevant here, IMO - negative or not (and evictable or pinned, for that
matter) it's easier solved by having d_alloc() fail on parent's ->d_count
overflow.  And I'm pretty sure we can hit that crap without creating any
negative dentries.

  reply	other threads:[~2019-05-07 19:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-06  3:36 system panic while dentry reference count overflow yangerkun
2019-05-07  0:40 ` Al Viro
2019-05-07  1:50   ` Linus Torvalds
2019-05-07  4:15     ` Al Viro
2019-05-07 15:26       ` Linus Torvalds
2019-05-07 19:16         ` Al Viro [this message]
2019-05-07 19:23           ` Linus Torvalds
2019-05-07 19:55             ` Al Viro
2019-05-07 20:47               ` Linus Torvalds
2019-05-07 21:14                 ` Al Viro

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=20190507191613.GI23075@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=houtao1@huawei.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=miaoxie@huawei.com \
    --cc=torvalds@linux-foundation.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.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.