linux.git/fs/romfs, branch v3.18.72

fs/romfs/super.c: add blank line after declarations

2014-08-08T22:57:25+00:00

Fix checkpatch warning:

  WARNING: Missing a blank line after declarations

Signed-off-by: Fabian Frederick 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs/romfs/super.c: use pr_fmt in logging

2014-08-08T22:57:25+00:00

- Remove "Error" in format logging (already in pr_ level)

- Use modulename in pr_fmt instead of ROMFS: in each pr_ callsites.

Signed-off-by: Fabian Frederick 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs/romfs/super.c: convert printk to pr_foo()

2014-08-08T22:57:25+00:00

Use current logging functions. Coalesce formats.

Signed-off-by: Fabian Frederick 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

switch simple generic_file_aio_read() users to ->read_iter()

2014-05-06T21:37:55+00:00

Signed-off-by: Al Viro

fs: push sync_filesystem() down to the file system's remount_fs()

2014-03-13T14:14:33+00:00

Previously, the no-op "mount -o mount /dev/xxx" operation when the
file system is already mounted read-write causes an implied,
unconditional syncfs().  This seems pretty stupid, and it's certainly
documented or guaraunteed to do this, nor is it particularly useful,
except in the case where the file system was mounted rw and is getting
remounted read-only.

However, it's possible that there might be some file systems that are
actually depending on this behavior.  In most file systems, it's
probably fine to only call sync_filesystem() when transitioning from
read-write to read-only, and there are some file systems where this is
not needed at all (for example, for a pseudo-filesystem or something
like romfs).

Signed-off-by: "Theodore Ts'o" 
Cc: linux-fsdevel@vger.kernel.org
Cc: Christoph Hellwig 
Cc: Artem Bityutskiy 
Cc: Adrian Hunter 
Cc: Evgeniy Dushistov 
Cc: Jan Kara 
Cc: OGAWA Hirofumi 
Cc: Anders Larsen 
Cc: Phillip Lougher 
Cc: Kees Cook 
Cc: Mikulas Patocka 
Cc: Petr Vandrovec 
Cc: xfs@oss.sgi.com
Cc: linux-btrfs@vger.kernel.org
Cc: linux-cifs@vger.kernel.org
Cc: samba-technical@lists.samba.org
Cc: codalist@coda.cs.cmu.edu
Cc: linux-ext4@vger.kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net
Cc: fuse-devel@lists.sourceforge.net
Cc: cluster-devel@redhat.com
Cc: linux-mtd@lists.infradead.org
Cc: jfs-discussion@lists.sourceforge.net
Cc: linux-nfs@vger.kernel.org
Cc: linux-nilfs@vger.kernel.org
Cc: linux-ntfs-dev@lists.sourceforge.net
Cc: ocfs2-devel@oss.oracle.com
Cc: reiserfs-devel@vger.kernel.org

romfs: fix returm err while getting inode in fill_super

2014-01-24T00:37:04+00:00

Getting an inode by romfs_iget may lead to an err in fill_super, and the
err value should be return.

And it should return -ENOMEM instead while d_make_root fails, fix it too.

Signed-off-by: Rui Xiang 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[readdir] convert romfs

2013-06-29T08:56:29+00:00

Signed-off-by: Al Viro

romfs: fix nommu map length to keep inside filesystem

2013-04-28T23:17:57+00:00

Checks introduced in commit 4991e7251 ("romfs: do not use
mtd->get_unmapped_area directly") re-introduce problems fixed in the earlier
commit 2b4b2482e ("romfs: fix romfs_get_unmapped_area() argument check").

If a flat binary app is located at the end of a romfs, its page aligned
length may be outside of the romfs filesystem. The flat binary loader, via
nommu do_mmap_pgoff(), page aligns the length it is mmaping. So simple
offset+size checks will fail - returning EINVAL.

We can truncate the length to keep it inside the romfs filesystem, and that
also keeps the call to mtd_get_unmapped_area() happy.

Are there any side effects to truncating the size here though?

Signed-off-by: Greg Ungerer

fs: Limit sys_mount to only request filesystem modules.

2013-03-04T03:36:31+00:00

Modify the request_module to prefix the file system type with "fs-"
and add aliases to all of the filesystems that can be built as modules
to match.

A common practice is to build all of the kernel code and leave code
that is not commonly needed as modules, with the result that many
users are exposed to any bug anywhere in the kernel.

Looking for filesystems with a fs- prefix limits the pool of possible
modules that can be loaded by mount to just filesystems trivially
making things safer with no real cost.

Using aliases means user space can control the policy of which
filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
with blacklist and alias directives.  Allowing simple, safe,
well understood work-arounds to known problematic software.

This also addresses a rare but unfortunate problem where the filesystem
name is not the same as it's module name and module auto-loading
would not work.  While writing this patch I saw a handful of such
cases.  The most significant being autofs that lives in the module
autofs4.

This is relevant to user namespaces because we can reach the request
module in get_fs_type() without having any special permissions, and
people get uncomfortable when a user specified string (in this case
the filesystem type) goes all of the way to request_module.

After having looked at this issue I don't think there is any
particular reason to perform any filtering or permission checks beyond
making it clear in the module request that we want a filesystem
module.  The common pattern in the kernel is to call request_module()
without regards to the users permissions.  In general all a filesystem
module does once loaded is call register_filesystem() and go to sleep.
Which means there is not much attack surface exposed by loading a
filesytem module unless the filesystem is mounted.  In a user
namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
which most filesystems do not set today.

Acked-by: Serge Hallyn 
Acked-by: Kees Cook 
Reported-by: Kees Cook 
Signed-off-by: "Eric W. Biederman"

new helper: file_inode(file)

2013-02-23T04:31:31+00:00

Signed-off-by: Al Viro