Re: [PATCH] mnt: Fix a memory stomp in umount

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Al Viro <viro@xxxxxxxxxxxxxxxxxx> writes:

> On Fri, Jan 02, 2015 at 03:06:06PM -0600, Eric W. Biederman wrote:
>
>> - It requires keeping track of the tail of the list which is half of the
>>   error prone complexity.
>
> Er...  In umount_tree() it comes pretty much for free, actually.

The runtime complexity is basically free.  The conceptual complexity is
not.  It is yet another detail to pay attention to.  Having gotten it
wrong my first round while trying to do something similar while
developing my patches I can attest to this.  The hlist version is more
error prone to use and develop against. (Even if appropriate helpers are
available).

>> - I have a fix for a bad interaction between MNT_LOCKED and MNT_DETACH
>>   where I need to leave mounts on the mount hash, until the final
>>   mntput.  For that I need not to reuse the the mnt_hash lists.
>
> Details, please.

The code doing that has been sent out for review.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux