Hi Al,
Do you plan to put a VFS tree together for 3.17? To me the various
renameat2 bits from Miklos are something I'd really prefer to not miss,
but there might be other bits waiting for attention as well.
On Wed, Jul 16, 2014 at 04:41:36AM -0700, Christoph Hellwig wrote:
> Hi Al,
>
> Do you plan to put a VFS tree together for 3.17? To me the various
> renameat2 bits from Miklos are something I'd really prefer to not miss,
> but there might be other bits waiting for attention as well.
Another weeks has passed and I'd really like to make sure we don't
let the VFS leap.
I'll try to put together a tree over the next days so we can at least
get a minium amount of linux-next exposure. Candidates are:
- the direct-io.c warning fix from Boaz (really should 3.16 actually)
- the unmount on symlink reference count fix
- the rename/rename2 patches from Mikilos. These are a bit older
and could use a respin.
Anything else I've missed?
On Tue, Jul 22, 2014 at 6:24 PM, Christoph Hellwig <[email protected]> wrote:
> On Wed, Jul 16, 2014 at 04:41:36AM -0700, Christoph Hellwig wrote:
>> Hi Al,
>>
>> Do you plan to put a VFS tree together for 3.17? To me the various
>> renameat2 bits from Miklos are something I'd really prefer to not miss,
>> but there might be other bits waiting for attention as well.
>
> Another weeks has passed and I'd really like to make sure we don't
> let the VFS leap.
>
> I'll try to put together a tree over the next days so we can at least
> get a minium amount of linux-next exposure. Candidates are:
>
> - the direct-io.c warning fix from Boaz (really should 3.16 actually)
> - the unmount on symlink reference count fix
This fix is also stable material.
The issue as introduced in 3.12 by 8033426e6b
(vfs: allow umount to handle mountpoints without revalidating them)
> - the rename/rename2 patches from Mikilos. These are a bit older
> and could use a respin.
>
> Anything else I've missed?
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks,
//richard
I've pushed out the current queue to:
git://git.infradead.org/users/hch/vfs.git vfs-for-3.17
Stephen, can you include this in linux-next for testing? I plan to
send the first two patches to Linus on Saturday as they seems worth
to fix for this release still, between a user triggered refcount one off
and a fix for a just introduced warning.
If there's anything else for 3.17 please send it my way.
On Thu, Jul 24, 2014 at 5:30 PM, Christoph Hellwig <[email protected]> wrote:
> If there's anything else for 3.17 please send it my way.
(linux-unionfs CC-d)
overlayfs? I think it's mature enough, but I thought that a year ago,
and there's been a format change since then... So how do people feel?
Thanks,
Miklos
Hi Christoph,
On Thu, 24 Jul 2014 08:30:57 -0700 Christoph Hellwig <[email protected]> wrote:
>
> I've pushed out the current queue to:
>
> git://git.infradead.org/users/hch/vfs.git vfs-for-3.17
>
> Stephen, can you include this in linux-next for testing? I plan to
> send the first two patches to Linus on Saturday as they seems worth
> to fix for this release still, between a user triggered refcount one off
> and a fix for a just introduced warning.
Added from today (called "hch-vfs").
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
[email protected]
Hi Linus,
here's a userspace triggered vfsmount leak fix, and a compile warning
fix for 3.16:
The following changes since commit 82e13c71bc655b6dc7110da4e164079dadb44892:
Merge branch 'for-3.16' of git://linux-nfs.org/~bfields/linux (2014-07-23 17:55:11 -0700)
are available in the git repository at:
git://git.infradead.org/users/hch/vfs.git vfs-for-3.16
for you to fetch changes up to 295dc39d941dc2ae53d5c170365af4c9d5c16212:
fs: umount on symlink leaks mnt count (2014-07-24 06:18:12 -0400)
----------------------------------------------------------------
Boaz Harrosh (1):
direct-io: fix uninitialized warning in do_direct_IO()
Vasily Averin (1):
fs: umount on symlink leaks mnt count
fs/direct-io.c | 14 +++++++-------
fs/namei.c | 3 ++-
2 files changed, 9 insertions(+), 8 deletions(-)
On Thu, Jul 24, 2014 at 06:35:24PM +0200, Miklos Szeredi wrote:
> overlayfs? I think it's mature enough, but I thought that a year ago,
> and there's been a format change since then... So how do people feel?
Even if I had reviewed it recently I wouldn't pull in something that
large without wainting for Al to reappear.
On Thu, Jul 24, 2014 at 08:30:57AM -0700, Christoph Hellwig wrote:
> I've pushed out the current queue to:
>
> git://git.infradead.org/users/hch/vfs.git vfs-for-3.17
>
> Stephen, can you include this in linux-next for testing? I plan to
> send the first two patches to Linus on Saturday as they seems worth
> to fix for this release still, between a user triggered refcount one off
> and a fix for a just introduced warning.
>
> If there's anything else for 3.17 please send it my way.
There's these fixes to d_splice_alias and related code:
git://linux-nfs.org/~bfields/linux-topics.git for-viro
(last posted in June).
The project isn't really finished but I think those patches are
justifiable on their own.
Happy to repost.
--b.
On Wed, Jul 30, 2014 at 01:20:09PM -0400, J. Bruce Fields wrote:
> There's these fixes to d_splice_alias and related code:
>
> git://linux-nfs.org/~bfields/linux-topics.git for-viro
>
> (last posted in June).
>
> The project isn't really finished but I think those patches are
> justifiable on their own.
I've pulled in all the actual code changes. I've skipped the export
change as I'm not going to pull in anything to make life easier for
leacher and cheaters.