Jann Horn | 25 Jun 01:51 2016
Picon

[PATCH] orangefs: fix namespace handling

In orangefs_inode_getxattr(), an fsuid is written to dmesg. The kuid is
converted to a userspace uid via from_kuid(current_user_ns(), [...]), but
since dmesg is global, init_user_ns should be used here instead.

In copy_attributes_from_inode(), op_alloc() and fill_default_sys_attrs(),
upcall structures are populated with uids/gids that have been mapped into
the caller's namespace. However, those upcall structures are read by
another process (the userspace filesystem driver), and that process might
be running in another namespace. This effectively lets any user spoof its
uid and gid as seen by the userspace filesystem driver.

To fix the second issue, I just construct the opcall structures with
init_user_ns uids/gids and require the filesystem server to run in the
init namespace. Since orangefs is full of global state anyway (as the error
message in DUMP_DEVICE_ERROR explains, there can only be one userspace
orangefs filesystem driver at once), that shouldn't be a problem.

[
Why does orangefs even exist in the kernel if everything does upcalls into
userspace? What does orangefs do that couldn't be done with the FUSE
interface? If there is no good answer to those questions, I'd prefer to see
orangefs kicked out of the kernel. Can that be done for something that
shipped in a release?

According to commit f7ab093f74bf ("Orangefs: kernel client part 1"), they
even already have a FUSE daemon, and the only rational reason (apart from
"but most of our users report preferring to use our kernel module instead")
given for not wanting to use FUSE is one "in-the-works" feature that could
probably be integated into FUSE instead.
]
(Continue reading)

Zheng Lv | 24 Jun 10:58 2016
Picon

[PATCH] fat: check whether fs size exceeds device size

The original code did not check for size of device. A truncated device
would mount, I/O failures would occur when "attempt to access beyond end
of device", leading to data lost.

Fix this by comparing total-sectors field in BPB with size of device.

This commit also prints a KERN_INFO message if there are extra sectors
at end of device (ie. total sectors < device sectors).

Signed-off-by: Zheng Lv <lv.zheng.2015 <at> gmail.com>
---
 fs/fat/inode.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 3bcf579..211f7bb 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
 <at>  <at>  -1583,6 +1583,7  <at>  <at>  int fat_fill_super(struct super_block *sb, void *data, int silent, int isvfat,
 	struct msdos_sb_info *sbi;
 	u16 logical_sector_size;
 	u32 total_sectors, total_clusters, fat_clusters, rootdir_sectors;
+	u64 device_sectors;
 	int debug;
 	long error;
 	char buf[50];
 <at>  <at>  -1738,6 +1739,17  <at>  <at>  int fat_fill_super(struct super_block *sb, void *data, int silent, int isvfat,
 	if (total_sectors == 0)
 		total_sectors = bpb.fat_total_sect;

(Continue reading)

Zheng Lv | 24 Jun 07:31 2016
Picon

[PATCH] fat: fix error message for bogus number of directory entries

"bogus directory-entries per block" was reported for what was instead
bogus number of directory entries. The message also mismatched the
argument passed to printk(), which was sbi->dir_entries.

Fix this by replacing the message with "bogus number of directory
entries". printk() argument was kept unchanged.

Signed-off-by: Zheng Lv <lv.zheng.2015 <at> gmail.com>
Cc: trivial <at> kernel.org
---
Note that this patch would possibly confuse users who receive the error message from an old kernel but grep
in the patched source tree. However, I think this case is rare enough to be ignored.

 fs/fat/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 3bcf579..d26a5ce 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
 <at>  <at>  -1726,7 +1726,7  <at>  <at>  int fat_fill_super(struct super_block *sb, void *data, int silent, int isvfat,
 	sbi->dir_entries = bpb.fat_dir_entries;
 	if (sbi->dir_entries & (sbi->dir_per_block - 1)) {
 		if (!silent)
-			fat_msg(sb, KERN_ERR, "bogus directory-entries per block"
+			fat_msg(sb, KERN_ERR, "bogus number of directory entries"
 			       " (%u)", sbi->dir_entries);
 		goto out_invalid;
 	}
--

-- 
(Continue reading)

Al Viro | 24 Jun 06:36 2016
Picon

[RFC] weirdness in ext4_sync_file()

Could somebody explain when would the second part of that test _not_ be true?

                if (!ret && !hlist_empty(&inode->i_dentry))
                        ret = ext4_sync_parent(inode);

inode is that of an opened file; how could it possibly _not_ have a dentry
alias?  Is that code actually supposed to check if the sucker is not
unlinked?  If so, it's not what we are actually checking - pinned dentry
remains positive (and unhashed) after unlink(2).  What's more, the loop
in ext4_sync_parent() is vulnerable to races with rmdir(2) - if you
get unlink and rmdir of ancestors between
                next = igrab(d_inode(dentry->d_parent));
and
                inode = next;
                ret = sync_mapping_buffers(inode->i_mapping);
                if (ret)
                        break;
                ret = sync_inode_metadata(inode, 1);
                if (ret)
                        break;
you are risking interesting things done in the middle of rmdir and/or
unlink; that might be actually safe, but in that case it's worth a comment
explaining that.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Eric Sandeen | 23 Jun 23:54 2016
Picon
Gravatar

[PATCH] dax: fix offset overflow in dax_io

This isn't functionally apparent for some reason, but
when we test io at extreme offsets at the end of the loff_t
rang, such as in fstests xfs/071, the calculation of
"max" in dax_io() can be wrong due to pos + size overflowing.

For example,

# xfs_io -c "pwrite 9223372036854771712 512" /mnt/test/file

enters dax_io with:

start 0x7ffffffffffff000
end   0x7ffffffffffff200

and the rounded up "size" variable is 0x1000.  This yields:

pos + size 0x8000000000000000 (overflows loff_t)
       end 0x7ffffffffffff200

Due to the overflow, the min() function picks the wrong
value for the "max" variable, and when we send (max - pos)
into i.e. copy_from_iter_pmem() it is also the wrong value.

This somehow(tm) gets magically absorbed without incident,
probably because iter->count is correct.  But it seems best
to fix it up properly by comparing the two values as
unsigned.

Signed-off-by: Eric Sandeen <sandeen <at> redhat.com>
---
(Continue reading)

Miklos Szeredi | 22 Jun 16:35 2016
Picon

[PATCH 0/8] remove d_time from dentry

dentry->d_time is not used by the VFS anymore, it's essentially a fs-private
data.  And it just wastes space in the dentry for the vast majority of
filesystems.

This series moves the few uses to ->d_fsdata.  Introduce ->d_allocate() method
to make it easier to allocate fs specific structure together with the dentry.

---
Miklos Szeredi (8):
  vfs: new d_allocate method
  ceph: don't use ->d_time
  cifs: don't use ->d_time
  vfat: don't use ->d_time
  fuse: don't use ->d_time
  nfs: don't use ->d_time
  ncpfs: don't use ->d_time
  vfs: remove ->d_time

 Documentation/filesystems/Locking |  2 ++
 Documentation/filesystems/vfs.txt |  3 +++
 fs/ceph/dir.c                     |  6 +++---
 fs/ceph/inode.c                   |  4 ++--
 fs/ceph/mds_client.c              |  4 ++--
 fs/ceph/super.h                   |  2 +-
 fs/cifs/cifsfs.h                  | 10 ++++++++++
 fs/cifs/dir.c                     |  6 +++---
 fs/cifs/inode.c                   |  2 +-
 fs/dcache.c                       | 11 +++++++++++
 fs/fat/namei_vfat.c               | 19 +++++++++++++++----
 fs/fuse/dir.c                     | 36 ++++++++++++++++--------------------
(Continue reading)

Dave Chinner | 22 Jun 02:29 2016

[ANNOUNCE] xfs: for-next branch updated to f477ced

Hi folks,

The for-next branch of the xfs kernel repository at

git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git

has just been updated. This update includes the long-awaited
iomap-based IO path infrastructure changes that Christoph has
finished off, along with a few bug fixes and the first handful of
miscellaneous changes from Darrick's mega-rmap patchset.

The iomap infrastructure patches are in their own separate branch -
fs-4.8-iomap-infrastructure - so it can be considered a stable
branch and hence can be merged into other fs trees so they can start
adding their own iomap-based work.  It will be included in the
linux-next build by the merge into the XFS tree's for-next branch.
Any bug fixes that are needed will be appended to this branch, so
please cc me on bug reports so I see them quickly.

Cheers,

Dave.

The new head of the for-next branch is commit:

f477ced Merge branch 'xfs-4.8-misc-fixes-2' into for-next

New Commits:

Brian Foster (2):
(Continue reading)

Zheng Lv | 21 Jun 05:51 2016
Picon

[PATCH] fat: fix typo s/supeblock/superblock/

Signed-off-by: Zheng Lv <lv.zheng.2015 <at> gmail.com>
Cc: trivial <at> kernel.org
---
 fs/fat/inode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/fat/inode.c b/fs/fat/inode.c
index 3bcf579..b902c89 100644
--- a/fs/fat/inode.c
+++ b/fs/fat/inode.c
 <at>  <at>  -1589,7 +1589,7  <at>  <at>  int fat_fill_super(struct super_block *sb, void *data, int silent, int isvfat,

 	/*
 	 * GFP_KERNEL is ok here, because while we do hold the
-	 * supeblock lock, memory pressure can't call back into
+	 * superblock lock, memory pressure can't call back into
 	 * the filesystem, since we're only just about to mount
 	 * it and have no inodes etc active!
 	 */
--

-- 
2.7.4

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

Holger Hoffstätte | 20 Jun 15:46 2016

What happened to the sb writeback list (aka sync efficiency) fix?


Once upon a time there was this fine patch set called
"improve sync efficiency with sb inode wb list" [1]
by Brian Foster, who fixed up the original version by Josef Bacik.

I've been running with this since then and it seems to work flawlessly,
yet it doesn't seem that this ever got merged..does anybody know why?

Waiman Long has been working on something similar with his per-CPU
lists, but those patches naturally collide a bit, so I'm wondering
what's what.

Fwiw the effect of the wb list on systems with many cached inodes is
phenomal; it would be a shame if this went unmerged.

thanks,
Holger

[1] http://thread.gmane.org/gmane.linux.file-systems/103940

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

Wang Xiaoguang | 20 Jun 12:47 2016

[RFC PATCH] btrfs: fix free space calculation in dump_space_info()

Signed-off-by: Wang Xiaoguang <wangxg.fnst <at> cn.fujitsu.com>
---
 fs/btrfs/extent-tree.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index f3e6666..13a87fe 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
 <at>  <at>  -7736,8 +7736,8  <at>  <at>  static void dump_space_info(struct btrfs_space_info *info, u64 bytes,
 	printk(KERN_INFO "BTRFS: space_info %llu has %llu free, is %sfull\n",
 	       info->flags,
 	       info->total_bytes - info->bytes_used - info->bytes_pinned -
-	       info->bytes_reserved - info->bytes_readonly,
-	       (info->full) ? "" : "not ");
+	       info->bytes_reserved - info->bytes_readonly -
+	       info->bytes_may_use, (info->full) ? "" : "not ");
 	printk(KERN_INFO "BTRFS: space_info total=%llu, used=%llu, pinned=%llu, "
 	       "reserved=%llu, may_use=%llu, readonly=%llu\n",
 	       info->total_bytes, info->bytes_used, info->bytes_pinned,
--

-- 
1.8.3.1

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

zhangaihua1 | 20 Jun 04:51 2016

[PATCH] fix error: a bin file can truncate itself while running at overlayfs.

From: Aihua Zhang <zhangaihua1 <at> huawei.com>

I wrote a testcase to truncate a bin file while it is running at overlayfs.
the result as below:

Bus error (core dumped)

I think it's not appropriate for filesystem, and fixed it by this patch.
after the patch, result as below:

status:-1
errno:26
ETXTBSY:26
PASS

This is because the inode is not correct ,it should point to overlayfs rather
than the upper filesystem.

Signed-off-by: Aihua Zhang <zhangaihua1 <at> huawei.com>
---
 include/linux/fs.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index dd28814..54fdbf9 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
 <at>  <at>  -2589,7 +2589,7  <at>  <at>  static inline int get_write_access(struct inode *inode)
 }
 static inline int deny_write_access(struct file *file)
(Continue reading)


Gmane