linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: linux-cifs-client@lists.samba.org
Cc: linux-fsdevel@vger.kernel.org
Subject: [PATCH 0/4] cifs: fix "Busy inodes after umount" issues (RFC)
Date: Fri, 21 May 2010 14:25:13 -0400	[thread overview]
Message-ID: <1274466317-28231-1-git-send-email-jlayton@redhat.com> (raw)

We've had a spate of "Busy inodes after umount" problems in recent
kernels. With the help of a reproducer that Suresh provided, I tracked
down the cause of one of these and wrote it up here:

    https://bugzilla.samba.org/show_bug.cgi?id=7433

The main problem is that CIFS opens files during create operations,
puts these files on a list and then expects that a subsequent open
operation will find those on the list and make them full, productive
members of society.

This expectation is wrong however. There's no guarantee that cifs_open
will be called at all after a create. There are several scenarios that
can prevent it from occuring. When this happens, these entries get left
dangling on the list and nothing will ever clean them up. Recent changes
have made it so that cifsFileInfo structs hold an inode reference as
well, which is what actually leads to the busy inodes after umount
problems.

This patch is intended to fix this in the right way. It has the create
operations properly use lookup_instantiate_filp to create an open file
during the operation that does the actual create. With this, there's
no need to have cifs_open scrape these entries off the list.

This fixes the busy inodes problem I was able to reproduce. It's not
very well tested yet however, and I could stand for someone else to
review it and help test it.

Jeff Layton (4):
  cifs: make cifs_lookup return a dentry
  cifs: don't leave open files dangling
  cifs: move cifs_new_fileinfo call out of cifs_posix_open
  cifs: pass instantiated filp back after open call

 fs/cifs/cifsproto.h |    1 -
 fs/cifs/dir.c       |   88 ++++++++++++++++++++++++++++++---------------------
 fs/cifs/file.c      |   59 +++++++--------------------------
 3 files changed, 65 insertions(+), 83 deletions(-)


             reply	other threads:[~2010-05-21 18:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-21 18:25 Jeff Layton [this message]
2010-05-21 18:25 ` [PATCH 1/4] cifs: make cifs_lookup return a dentry Jeff Layton
2010-05-21 18:45   ` Josef Bacik
2010-05-21 18:42     ` Jeff Layton
2010-05-22 13:30   ` Al Viro
2010-05-22 14:08     ` Jeff Layton
2010-05-22 14:46       ` Al Viro
2010-05-22 15:23         ` Jeff Layton
2010-05-21 18:25 ` [PATCH 2/4] cifs: don't leave open files dangling Jeff Layton
2010-05-24  6:50   ` [linux-cifs-client] " Suresh Jayaraman
2010-05-24 10:49     ` Jeff Layton
2010-05-21 18:25 ` [PATCH 3/4] cifs: move cifs_new_fileinfo call out of cifs_posix_open Jeff Layton
2010-05-24  6:50   ` [linux-cifs-client] " Suresh Jayaraman
2010-05-24 10:48     ` Jeff Layton
2010-05-21 18:25 ` [PATCH 4/4] cifs: pass instantiated filp back after open call Jeff Layton
2010-05-24  7:13 ` [PATCH 0/4] cifs: fix "Busy inodes after umount" issues (RFC) Suresh Jayaraman
2010-05-24 10:52   ` [linux-cifs-client] " Jeff Layton

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=1274466317-28231-1-git-send-email-jlayton@redhat.com \
    --to=jlayton@redhat.com \
    --cc=linux-cifs-client@lists.samba.org \
    --cc=linux-fsdevel@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;
as well as URLs for NNTP newsgroup(s).