[git pull] vfs pile 1

[git pull] vfs pile 1

[Al Viro]

	Contains: d_op series on top of Nick's pile, a few other patches
from various folks.  More tomorrow; there's a huge pending pile here.

git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ for-linus

Note: d_set_d_op() is still there, but most of the callers are gone.
FWIW, there are only 3 non-trivial bunches:
	* procfs - as expected, we have shitloads of ->d_op there
	* autofs4 - tomorrow will be fun; automount series needs to be
dealt with to sort that out
	* ceph - I'd rather deal with that on top of ceph tree.

	Shortlog:
Al Viro (31):
      per-superblock default ->d_op
      fix isofs d_op handling
      switch fat to ->s_d_op, close exportfs races there
      switch jfs to ->s_d_op, close exportfs races
      pohmelfs: double-free and leak
      switch fuse
      switch sysv
      minixfs: kill dead code
      switch hfs
      switch hfsplus
      switch adfs
      switch nfs to ->s_d_op
      switch cifs
      switch gfs2, close races
      switch ocfs2, close races
      switch btrfs, close races
      switch cgroup
      switch hpfs
      convert smbfs
      switch coda
      take coda-private headers out of include/linux
      switch configfs
      switch affs
      switch hostfs
      pass default dentry_operations to mount_pseudo()
      switch 9p
      switch ncpfs
      move internal-only parts of ncpfs headers to fs/ncpfs
      switch afs
      sanitize ecryptfs ->mount()
      fix signedness mess in rw_verify_area() on 64bit architectures

Jeff Layton (1):
      vfs: pass struct file to do_truncate on O_TRUNC opens (try #2)

Josef Bacik (7):
      fs: add hole punching to fallocate
      XFS: handle hole punching via fallocate properly
      Ocfs2: handle hole punching via fallocate properly
      Ext4: fail if we try to use hole punch
      Btrfs: fail if we try to use hole punch
      Gfs2: fail if we try to use hole punch
      fs: add documentation on fallocate hole punching

Randy Dunlap (2):
      fs: fix kernel-doc for dcache::d_validate
      fs: fix kernel-doc for dcache::prepend_path

Diffstat:
 Documentation/filesystems/porting       |    9 ++
 Documentation/magic-number.txt          |    2 +-
 arch/ia64/kernel/perfmon.c              |    6 +-
 drivers/mtd/mtdchar.c                   |    2 +-
 drivers/staging/pohmelfs/net.c          |    2 +-
 drivers/staging/smbfs/dir.c             |   13 ---
 drivers/staging/smbfs/inode.c           |    4 +
 drivers/staging/smbfs/proto.h           |    2 +
 fs/9p/v9fs_vfs.h                        |    1 -
 fs/9p/vfs_dentry.c                      |    2 +-
 fs/9p/vfs_inode.c                       |    5 -
 fs/9p/vfs_super.c                       |    8 +-
 fs/adfs/dir.c                           |    1 -
 fs/adfs/super.c                         |    4 +-
 fs/affs/affs.h                          |    1 +
 fs/affs/namei.c                         |    3 +-
 fs/affs/super.c                         |    6 +-
 fs/afs/dir.c                            |    4 +-
 fs/afs/internal.h                       |    1 +
 fs/afs/super.c                          |    1 +
 fs/anon_inodes.c                        |   21 ++--
 fs/block_dev.c                          |    2 +-
 fs/btrfs/export.c                       |   12 +--
 fs/btrfs/inode.c                        |    6 +-
 fs/btrfs/super.c                        |    1 +
 fs/cifs/cifsfs.c                        |    6 +
 fs/cifs/dir.c                           |   25 +-----
 fs/cifs/inode.c                         |    8 --
 fs/cifs/link.c                          |    4 -
 fs/cifs/readdir.c                       |    5 -
 fs/coda/cache.c                         |    5 +-
 fs/coda/cnode.c                         |    3 +-
 {include/linux => fs/coda}/coda_cache.h |    0 
 {include/linux => fs/coda}/coda_fs_i.h  |    0 
 fs/coda/coda_linux.c                    |    3 +-
 {include/linux => fs/coda}/coda_linux.h |    4 +-
 fs/coda/dir.c                           |    9 +-
 fs/coda/file.c                          |    3 +-
 fs/coda/inode.c                         |    6 +-
 fs/coda/pioctl.c                        |    4 +-
 fs/coda/psdev.c                         |    4 +-
 fs/coda/symlink.c                       |    4 +-
 fs/coda/upcall.c                        |    5 +-
 fs/configfs/configfs_internal.h         |    1 +
 fs/configfs/dir.c                       |    6 +-
 fs/configfs/mount.c                     |    1 +
 fs/dcache.c                             |    9 +-
 fs/ecryptfs/inode.c                     |    1 -
 fs/ecryptfs/main.c                      |  155 ++++++++++++++-----------------
 fs/ext4/extents.c                       |    4 +
 fs/fat/fat.h                            |    3 +-
 fs/fat/inode.c                          |   13 +--
 fs/fat/namei_msdos.c                    |   27 ++----
 fs/fat/namei_vfat.c                     |   27 ++----
 fs/fuse/dir.c                           |    1 -
 fs/fuse/inode.c                         |   10 +-
 fs/gfs2/export.c                        |   13 +--
 fs/gfs2/ops_fstype.c                    |    2 +-
 fs/gfs2/ops_inode.c                     |    6 +-
 fs/hfs/dir.c                            |    2 -
 fs/hfs/super.c                          |    3 +-
 fs/hfsplus/dir.c                        |    1 -
 fs/hfsplus/super.c                      |    2 +-
 fs/hostfs/hostfs_kern.c                 |    2 +-
 fs/hpfs/dentry.c                        |    7 +-
 fs/hpfs/dir.c                           |    1 -
 fs/hpfs/hpfs_fn.h                       |    2 +-
 fs/hpfs/super.c                         |    2 +-
 fs/isofs/inode.c                        |   13 ++-
 fs/isofs/namei.c                        |    2 -
 fs/jfs/namei.c                          |   10 +--
 fs/jfs/super.c                          |    6 +-
 fs/libfs.c                              |    4 +-
 fs/minix/namei.c                        |    2 -
 fs/namei.c                              |    7 +-
 fs/ncpfs/dir.c                          |   19 +---
 fs/ncpfs/file.c                         |    3 +-
 fs/ncpfs/inode.c                        |    6 +-
 fs/ncpfs/ioctl.c                        |    4 +-
 fs/ncpfs/mmap.c                         |    4 +-
 fs/ncpfs/ncp_fs.h                       |   98 +++++++++++++++++++
 {include/linux => fs/ncpfs}/ncp_fs_i.h  |    0 
 {include/linux => fs/ncpfs}/ncp_fs_sb.h |   24 ++++-
 fs/ncpfs/ncplib_kernel.c                |    2 +-
 fs/ncpfs/ncplib_kernel.h                |    2 -
 fs/ncpfs/ncpsign_kernel.c               |    1 +
 fs/ncpfs/ncpsign_kernel.h               |    2 -
 fs/ncpfs/sock.c                         |    2 +-
 fs/ncpfs/symlink.c                      |    4 +-
 fs/nfs/dir.c                            |    4 -
 fs/nfs/getroot.c                        |    6 -
 fs/nfs/super.c                          |    1 +
 fs/ocfs2/export.c                       |    6 +-
 fs/ocfs2/file.c                         |    8 +-
 fs/ocfs2/namei.c                        |    5 -
 fs/ocfs2/super.c                        |    1 +
 fs/open.c                               |    7 +-
 fs/pipe.c                               |    4 +-
 fs/read_write.c                         |   27 ++---
 fs/sysv/namei.c                         |    1 -
 fs/sysv/super.c                         |    8 +-
 fs/xfs/linux-2.6/xfs_iops.c             |    7 +-
 include/linux/falloc.h                  |    1 +
 include/linux/fs.h                      |    5 +-
 include/linux/ncp_fs.h                  |  100 --------------------
 include/linux/ncp_mount.h               |   22 -----
 kernel/cgroup.c                         |   30 ++-----
 net/socket.c                            |   30 +++---
 108 files changed, 424 insertions(+), 582 deletions(-)

Re: [git pull] vfs pile 1

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 804 bytes --]

Hi Al,

On Thu, 13 Jan 2011 05:35:54 +0000 Al Viro <viro@ZenIV.linux.org.uk> wrote:
>
> 	Contains: d_op series on top of Nick's pile, a few other patches
> from various folks.  More tomorrow; there's a huge pending pile here.
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6.git/ for-linus

None of this has been in linux-next.  Some of it seems to date back into
early December and even November ...

Merging it into today's linux-next produces conflicts against the
ecryptfs and cleancache trees.

It would be good in the future (as I have asked in the past) if vfs-wide
changes like these could spend some time in linux-next so people know
what is coming ...

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

Re: [git pull] vfs pile 1

[Christoph Hellwig]

On Thu, Jan 13, 2011 at 05:25:57PM +1100, Stephen Rothwell wrote:
> Merging it into today's linux-next produces conflicts against the
> ecryptfs and cleancache trees.

How did cleancache end up in linux-next again?

clearcache (Was: Re: [git pull] vfs pile 1)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

Hi Christoph,

On Thu, 13 Jan 2011 03:55:47 -0500 Christoph Hellwig <hch@infradead.org> wrote:
>
> How did cleancache end up in linux-next again?

Um, I asked after the last merge window (on November 17, cc'ing you, Al
and Linus) and the only reply I got was from Dan saying that he was
hoping to work more on it with some chance of being ready for 2.6.38 ...

So, let me ask again:

"I didn't really follow the discussion at Kernel Summit, but there seemed
to be some question as to whether the cleancache stuff will be merged or
not.  It missed 2.6.37 (obviously), but my question now is do I keep in
in linux-next in the hope that it will be merged in 2.6.38?  Or is that
not going to happen?"

(The cleancache tree has not changed since October 9 last year.)
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

RE: clearcache (Was: Re: [git pull] vfs pile 1)

[Dan Magenheimer]

> On Thu, 13 Jan 2011 03:55:47 -0500 Christoph Hellwig
> <hch@infradead.org> wrote:
> >
> > How did cleancache end up in linux-next again?
> 
> Um, I asked after the last merge window (on November 17, cc'ing you, Al
> and Linus) and the only reply I got was from Dan saying that he was
> hoping to work more on it with some chance of being ready for 2.6.38
> ...
> 
> So, let me ask again:
> 
> "I didn't really follow the discussion at Kernel Summit, but there
> seemed
> to be some question as to whether the cleancache stuff will be merged
> or
> not.  It missed 2.6.37 (obviously), but my question now is do I keep in
> in linux-next in the hope that it will be merged in 2.6.38?  Or is that
> not going to happen?"
> 
> (The cleancache tree has not changed since October 9 last year.)

Hi Stephen --

Today or tomorrow, I will post a fully-functional in-kernel non-virtualization
user for cleancache (and frontswap), called kztmem, which is proposed
initially as a staging driver.  It will be up to Linus, Andrew, and
GregKH to determine if this is acceptable and a sufficient second user
of cleancache.  Assuming it is, because of the dependency (staging driver
dependent on as-yet-unmerged core kernel functionality), I'm not clear
yet if/how cleancache should go through linux-next.  (Linus's last
email on the topic indicated he thought cleancache should go through Andrew.)

So please stay tuned for the next episode in this continuing drama. ;-)

Thanks,
Dan

Re: clearcache (Was: Re: [git pull] vfs pile 1)

[Ted Ts'o]

On Thu, Jan 13, 2011 at 09:42:39PM +1100, Stephen Rothwell wrote:
> 
> "I didn't really follow the discussion at Kernel Summit, but there seemed
> to be some question as to whether the cleancache stuff will be merged or
> not.  It missed 2.6.37 (obviously), but my question now is do I keep in
> in linux-next in the hope that it will be merged in 2.6.38?  Or is that
> not going to happen?"

The real problem is I don't think anyone is really paying attention to
cleancache.

Dan, something that might be useful to drive interest would be a
demonstration of this improves performance on, say, a netbook using
cleancache and zram, and how it is better than just using zram
directly as a swap device.  With maybe some numbers?  That might get
some interest from the community desktop distributions...

     	      	       		 	 - Ted

RE: clearcache (Was: Re: [git pull] vfs pile 1)

[Dan Magenheimer]

Hi Ted --

Thanks for taking the time to reply.

> The real problem is I don't think anyone is really paying attention to
> cleancache.

It's a bit more complicated than that.  There ARE a lot of people
interested in it, but there is a bit of a deadlock.  I've heard from
many people that would love to use Xen transcendent memory as
a great solution for memory overcommitment in the cloud, but they
get skittish when I tell them it requires kernel changes that haven't
been accepted upstream.  But key Linux maintainers don't consider
the Xen base interesting enough to allow merging of cleancache
(and frontswap), despite its simplicity and negligible impact,
without at least a second (and preferably in-kernel) user.

> Dan, something that might be useful to drive interest would be a
> demonstration of this improves performance on, say, a netbook using
> cleancache and zram, and how it is better than just using zram
> directly as a swap device.  With maybe some numbers?  That might get
> some interest from the community desktop distributions...

Indeed.  I was hoping that Nitin's work on zcache (the page cache
version of zram) would serve that purpose but GregKH declined to
merge it because it was dependent on unmerged cleancache... thus a
chicken-and-egg problem; and Nitin has apparently now moved on to
other (non-Linux-kernel) things.  As a result, I've spent most of my
free time over the last three months working on kztmem, which will
hopefully serve the purpose.  (I had hoped to post V1 of kztmem
by today but ran into a problem in an overnight test run.  So
stay tuned.)

Dan

P.S. The numbers look pretty good.
P.P.S. kztmem should also be easily adaptable to KVM, but I haven't
 the KVM expertise to make it happen

Re: clearcache (Was: Re: [git pull] vfs pile 1)

[Ted Ts'o]

On Fri, Jan 14, 2011 at 01:11:02PM -0800, Dan Magenheimer wrote:
> As a result, I've spent most of my
> free time over the last three months working on kztmem, which will
> hopefully serve the purpose.

You'll have to forgive me, but I have absolutely no idea what kztmem
is or what it does.  Is it just compressed tmem, and hence, something
that is only of interest to people using Xen?  If so, it's not clear
to me how it will help non-Xen people become interested in these
patches.

Regards,

					- Ted

RE: clearcache (Was: Re: [git pull] vfs pile 1)

[Dan Magenheimer]

> > As a result, I've spent most of my
> > free time over the last three months working on kztmem, which will
> > hopefully serve the purpose.
> 
> You'll have to forgive me, but I have absolutely no idea what kztmem
> is or what it does.  Is it just compressed tmem, and hence, something
> that is only of interest to people using Xen?  If so, it's not clear
> to me how it will help non-Xen people become interested in these
> patches.

Ah, sorry, processing too much email backlog and left out some context...

Kztmem is entirely in-kernel, no virtualization required (neither
Xen nor KVM).  I'll cc you when I post V1 soon but, yes, it is
compressed *in-kernel* tmem, a more flexible/dynamic replacement for
zcache and possibly also for zram as well, architected and designed
to more easily (than zcache/zram) exploit some other directions
I plan to take with tmem concepts, including (but not limited to)
page-addressable memory (http://marc.info/?l=linux-mm&m=127811271605009).
Kztmem is coded (at least for now) as a staging driver, but uses
exactly the proposed cleancache (and frontswap) patches.

Hope that helps!
Dan