public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chiluk <chiluk@canonical.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Petr Vandrovec <petr@vandrovec.name>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] ncpfs: fix rmdir returns Device or resource busy
Date: Thu, 13 Jun 2013 23:19:26 -0500	[thread overview]
Message-ID: <51BA99CE.8000902@canonical.com> (raw)
In-Reply-To: <20130613064235.GK4165@ZenIV.linux.org.uk>

On 06/13/2013 01:42 AM, Al Viro wrote:
> On Thu, Jun 13, 2013 at 03:01:22AM +0100, Al Viro wrote:
>> On Fri, Jun 07, 2013 at 05:14:52PM +0100, Al Viro wrote:
>>> On Fri, Jun 07, 2013 at 11:09:05AM -0500, Dave Chiluk wrote:
>>>> Can't you just use the patch from my original e-mail?  Anyhow I attached
>>>> it an already signed-off patch.
>>>>
>>>> Al Viro Can you integrate it now?
>>>
>>> Applied...  FWIW, patch directly in mail body is more convenient to deal with.
>>
>> Actually, looking at that stuff...  Why are we bothering with -EBUSY for
>> removal of busy directories on ncpfs, anyway?  It's not just rmdir(), it's
>> overwriting rename() as well.  IS_DEADDIR checks in fs/namei.c and fs/readdir.c
>> mean that the only method of ncpfs directories that might get called after
>> successful removal is ->setattr() and it would be trivial to add the check
>> in ncp_notify_change() that would make it fail for dead directories without
>> bothering the server at all...
>>
>> Related question: what happens if you open / unlink / fchmod on ncpfs?
> 
> Speaking of crap used only by ncpfs: I think we can use ->d_iput() to get rid
> of d_validate() for good.  The only remaining user is ncpfs; what happens there
> is that we use the page cache of directory to cache the references to dentries
> made by readdir.  We could do the following trick:
> 	* have ->d_fsdata for these dentries a pointer into the cache page where
> the reference back to dentry is stored
> 	* ->freepage() for those pages consisting of
> 		grab global spinlock
> 		go through all dentries still pointed to by pointers in that
> page, zeroing ->d_fsdata
> 		drop the spinlock
> 	* ->d_iput() for those dentries consisting of
> 		grab the same spinlock
> 		if ->d_fsdata is non-zero, store NULL at the address pointed
> to by it
> 		drop the spinlock
> 	* ncp_dget_fpos() would
> 		grab that spinlock
> 		check if the reference to dentry in the position we are
> interested in is non-NULL
> 			grab ->d_lock
> 			if DCACHE_DENTRY_KILLED is not set
> 				bump ->d_count
> 				drop ->d_lock
> 				drop the spinlock
> 				return dentry
> 			// dentry is doomed
> 			clear the reference
> 			drop ->d_lock
> 		drop the spinlock
> 		return NULL
> 	* ncp_fill_cache() would insert the sucker into cache and set
> ->d_fsdata under the same spinlock.
> 
> IOW, instead of wanking with untrusted pointers to dentries, we simply make
> sure we clean the pointer when dentry is going away and clean the reference
> from dentry to the location of that pointer when the page is going away.
> 
> Objections?  I can do a patch along those lines, but I've nothing to test it
> on.  Had that been cifs, I could at least use samba to test the fucker, but
> I've no idea how to do that with ncpfs and I'm not too fond of checking how
> much bitrot has mars_nwe suffered...
> 
I'm afraid you are way beyond my current vfs experience level on this
one.  While you're getting rid of things you might consider
dentry_unhash as well, as only hpfs_unlink, ncp_rmdir, and ncp_rename
call that.

If you get a patch together, I'll do my best to test it.  Looks like
only ncp_readdir calls that, so afaik, a few varying ls commands should
be all that's needed for a test.

Dave.
p.s. are you sure you don't just want to just deprecate all of ncpfs?

  reply	other threads:[~2013-06-14  4:19 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-28 22:50 [PATCH] ncpfs: fix rmdir returns Device or resource busy Dave Chiluk
2013-05-31 21:40 ` Dave Chiluk
     [not found]   ` <CA+i2_De5HHw2H9SvZ=W+QAOcy0M7jFac88OK6aeYdJVCGL6b+A@mail.gmail.com>
2013-06-05 20:20     ` Dave Chiluk
2013-06-07  6:43       ` Petr Vandrovec
2013-06-07 16:09         ` Dave Chiluk
2013-06-07 16:14           ` Al Viro
2013-06-13  2:01             ` Al Viro
2013-06-13  6:42               ` Al Viro
2013-06-14  4:19                 ` Dave Chiluk [this message]
2013-06-15  5:09                   ` Al Viro
2013-06-15  5:26                     ` Al Viro
2013-06-14  4:02               ` Dave Chiluk
2013-06-19  9:30 ` Luis Henriques
2013-06-26  1:05   ` Ben Hutchings

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=51BA99CE.8000902@canonical.com \
    --to=chiluk@canonical.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=petr@vandrovec.name \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    /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