Al Viro writes:
> On Tue, Aug 12, 2014 at 03:17:10AM -0700, Eric W. Biederman wrote:
>> I have rebased my changes against vfs.git#for-eric and my changes work
>> just fine on top of the base you have built. The changes are avaiable
>> in user-namespace.git#vfs-detach-mounts10 so you just be able
On Tue, Aug 12, 2014 at 03:17:10AM -0700, Eric W. Biederman wrote:
> I have rebased my changes against vfs.git#for-eric and my changes work
> just fine on top of the base you have built. The changes are avaiable
> in user-namespace.git#vfs-detach-mounts10 so you just be able to just
> pull the cha
Al Viro writes:
> On Sun, May 11, 2014 at 05:45:30PM +0100, Al Viro wrote:
>> Sigh... It's really messy.
>> All versions since lazy fput introduction have acct_auto_close()
>> doing the wrong thing on r/o remount of superblock; we want the damn file
>> closed *before* we go further than acc
Al Viro writes:
> On Sun, May 11, 2014 at 05:45:30PM +0100, Al Viro wrote:
>> Sigh... It's really messy.
>> All versions since lazy fput introduction have acct_auto_close()
>> doing the wrong thing on r/o remount of superblock; we want the damn file
>> closed *before* we go further than acc
On Sun, May 11, 2014 at 05:45:30PM +0100, Al Viro wrote:
> Sigh... It's really messy.
> All versions since lazy fput introduction have acct_auto_close()
> doing the wrong thing on r/o remount of superblock; we want the damn file
> closed *before* we go further than acct_auto_close(). Worse,
On Sun, May 11, 2014 at 05:45:30PM +0100, Al Viro wrote:
> hits acct_auto_close(), so even if we wait there, we still have a window
^
after
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
On Sun, Apr 20, 2014 at 06:41:08AM +0100, Al Viro wrote:
>
> right in the end of mntput_no_expire(). OK, now I have something that
> looks like a complete solution. The last missing bit is to take all
> filp_close() of acct->file to kernel thread, and have them done via
> __fput_sync() the
On Thu, Apr 17, 2014 at 11:12:03PM +0100, Al Viro wrote:
> I'd probably turn mntput_no_expire() into something like
> static struct mount *__mntput(struct mount *m)
> that would return NULL if nothing needs to be killed and returned m
> if m really needs killing. Leaving the caller to decide what
On Sat, Apr 19, 2014 at 03:16:46AM +0100, Al Viro wrote:
> On Sat, Apr 19, 2014 at 02:35:26AM +0100, Al Viro wrote:
>
> > My apologies for confusion - I have not looked at your last commit.
> > I *really* don't like that solution, but it probably does close that
> > particular problem. Consider t
On Sat, Apr 19, 2014 at 02:35:26AM +0100, Al Viro wrote:
> My apologies for confusion - I have not looked at your last commit.
> I *really* don't like that solution, but it probably does close that
> particular problem. Consider that objection withdrawn (modulo "you
> have created a bisect hazard
On Fri, Apr 18, 2014 at 01:37:26AM +0100, Al Viro wrote:
> FWIW, the tricky part around auto-close of acct is that we really want to
> preserve the following property:
>
> In usual setups, umount(2) will not return until fs has been
> shut down.
>
> fput() being async is not a problem - it
On Fri, Apr 18, 2014 at 01:37:26AM +0100, Al Viro wrote:
> IOW, workqueue is not the right tool here. OTOH, it looks like we do have
> a problem with kernel/acct.c vs. umount; it just requires a race between
> auto-closing and acct_process_in_ns(). It's narrow, so it doesn't bite
> us all the tim
On Thu, Apr 17, 2014 at 11:12:03PM +0100, Al Viro wrote:
> That's all. And yes, I believe that such series would make sense on its
> own and once it survives beating (see above about docker - that bastard has
> surprised me quite a bit re stressing namespace-related codepaths), I would
> be quite
On Thu, Apr 17, 2014 at 11:12:03PM +0100, Al Viro wrote:
> * *KERNEL* vfsmounts; anything without MNT_INTERNAL is fair game
> as far as ordering of fs shutdown is concerned. If it wasn't MNT_INTERNAL,
> and we'd done mntput() before destroying some data structures needed for
s/before/just b
On Thu, Apr 17, 2014 at 02:23:27PM -0700, Eric W. Biederman wrote:
> The typically system has about 12 mounts and no mount namespaces.
> Making umount of any kind a rare case.
The typical system has no userns either. Take a look at e.g. docker
setups (and unless I'm mistaken, they are going to b
Al Viro writes:
> Have you tried to profile something like umount -l on a large mount tree?
> You variant causes a shitstorm of
> schedule work
> switch to workqueue
> do actual fs shutdown
> wake umount(8) up
> get through wait_for_completion()
> for every bleeding
Have you tried to profile something like umount -l on a large mount tree?
You variant causes a shitstorm of
schedule work
switch to workqueue
do actual fs shutdown
wake umount(8) up
get through wait_for_completion()
for every bleeding vfsmount in there. And
Linus,
Please pull the for-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
for-linus
HEAD: 3efe1ac78e996da8e141b86667cc15758aad4366 vfs: Block intuitively in the
case of BSD accounting files
This branch contains 3 significant fi
Al Viro writes:
> On Wed, Apr 09, 2014 at 06:53:23PM +0100, Al Viro wrote:
>
>> For starters, put that ext4 on top of dm-raid or dm-multipath. That alone
>> will very likely push you over the top.
>>
>> Keep in mind, BTW, that you do not have full 8K to play with - there's
>> struct thread_info
On Wed, Apr 09, 2014 at 10:32:14AM -0700, Eric W. Biederman wrote:
> Al Viro writes:
>
> > On Wed, Apr 09, 2014 at 03:30:27AM +0100, Al Viro wrote:
> >
> >> > When renaming or unlinking directory entries that are not mountpoints
> >> > no additional locks are taken so no performance differences c
On Wed, Apr 09, 2014 at 06:53:23PM +0100, Al Viro wrote:
> For starters, put that ext4 on top of dm-raid or dm-multipath. That alone
> will very likely push you over the top.
>
> Keep in mind, BTW, that you do not have full 8K to play with - there's
> struct thread_info that should not be steppe
On Wed, Apr 09, 2014 at 10:32:14AM -0700, Eric W. Biederman wrote:
> For resolving a deeply nested symlink that hits the limit of 8 nested
> symlinks, I find 4688 bytes left on the stack. Which means we use
> roughly 3504 bytes of stack when stating a deeply nested symlink.
>
> For umount I had
Al Viro writes:
> On Wed, Apr 09, 2014 at 03:30:27AM +0100, Al Viro wrote:
>
>> > When renaming or unlinking directory entries that are not mountpoints
>> > no additional locks are taken so no performance differences can result,
>> > and my benchmark reflected that.
>>
>> It also means that d_in
Al Viro writes:
> On Wed, Apr 09, 2014 at 03:30:27AM +0100, Al Viro wrote:
>
>> > When renaming or unlinking directory entries that are not mountpoints
>> > no additional locks are taken so no performance differences can result,
>> > and my benchmark reflected that.
>>
>> It also means that d_in
On Wed, Apr 09, 2014 at 03:30:27AM +0100, Al Viro wrote:
> > When renaming or unlinking directory entries that are not mountpoints
> > no additional locks are taken so no performance differences can result,
> > and my benchmark reflected that.
>
> It also means that d_invalidate() now might trigg
On Tue, Apr 08, 2014 at 05:21:32PM -0700, Eric W. Biederman wrote:
> This set of changes has been reviewed and been sitting idle for the last
> 6 weeks. In that time the vfs has slightly shifted under me the new
> version of rename and the mount hash list becoming a hlist. None of
> those change
Linus,
Please pull the for-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
for-linus
HEAD: 0d7d90f86f83f29a442b37c78172870f8ee28c58 proc: Update
proc_flush_task_mnt to use d_invalidate
My apologies for sending this pull request
27 matches
Mail list logo
