public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frank Schruefer <kernel@man-made.de>
To: linux-kernel@vger.kernel.org
Subject: PROBLEM: No dentry alias for page host in writepage.
Date: Thu, 30 Jun 2005 05:29:21 +0200	[thread overview]
Message-ID: <42C36711.6020306@man-made.de> (raw)

Hy,

There is some rare case which hits me aprox. once in a million writepage calls
where for the page handed over there can not be get a connected dentry of its
inode host (via i_dentry).

Unluckily I'm absolutely depending on at least one alias at that point and I'm
not able to implement the export filesystem functions because for implementing
the get_name etc... functions I'd already need the dentry to contain the valid
name. Hence reconnecting is out of the question.

It seems not to be possible to circumvent that situation by just making the
d_delete dentry operations function returning 0 if the inode is dirty or has
dirty pages (mapping_tagged ... PAGECACHE_TAG_DIRTY).

I programmed a really ugly workaround dget'ing an alias as soon as I dirty an
inode and dput it as soon as the last page is writepage'd - that works for now -
but I really hate it and it seems to be memory leak prone (why I'd still have
to find out) and having possible side effects with rename and unlink ...

My question is why are the dentries/aliases dropped/disconnected if the inode is
still dirty or it's pages are under writeout and why am I not asked via d_delete
or have any other option to deny dropping/disconnecting the dentry/aliases?
Is this a bug?
What could I do?

Until now I just have that ugly workaround - please make my day, someone, please ;-)

-- 

Thanks,
    Frank Schruefer
    SITEFORUM Software Europe GmbH
    Germany (Thuringia)


                 reply	other threads:[~2005-06-30  3:29 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=42C36711.6020306@man-made.de \
    --to=kernel@man-made.de \
    --cc=linux-kernel@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