[lkml]   [2005]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] namespace.c: cleanup in mark_mounts_for_expiry()
> > Looks sane.  However, we still have a problem here - just what would
> > happen if vfsmount is detached while we were grabbing namespace
> > semaphore? Refcount alone is not useful here - we might be held by
> > whoever had detached the vfsmount. IOW, we should check that it's
> > still attached (i.e. that mnt->mnt_parent != mnt). If it's not -
> > just leave it alone, do mntput() and let whoever holds it deal with
> > the sucker. No need to put it back on lists.
> Right. I'll fix that too.
> On a bit unrelated node, in do_unmount() why is that
> DQUOT_OFF()/acct_auto_close() thing only called for the base of a tree
> being detached, and not for any submounts? Is that how it's supposed
> to work?
I guess the code is there since the good old times when each
filesystem could be mounted at most once and you had to call umount on
it directly ;). I see two possibilites there:
1) Call DQUOT_OFF() when the last reference to the superblock should
be dropped. This has a problem that currently quota code holds the
reference to the vfsmount of the mountpoint it was called on (to
protect itself against umount). So if you try something like
mount /home, quotaon /home, mount --bind /home /home2, umount /home,
it will fail with EBUSY.
2) Make quota code protect against umount in a different way without
holding the vfsmount references (any ideas?). Then the above described
use will work. But I'm not sure it's worth the problems especially
with userspace tools not being able to see the proper mount options
and so on.

So personally I'd prefer 1). For the namespace code it means only that
it should call DQUOT_OFF() whenever it intends to drop the last
reference to the superblock (and check for business only after quota
has been turned off).

Jan Kara <>
SuSE CR Labs
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-05-24 11:00    [W:0.038 / U:2.112 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site