linux-kernel - [RFC 0/2] vfs / btrfs: add support for ustat()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Jul 2014 16:07:03 -0700
From:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
To:	viro@...iv.linux.org.uk, clm@...com, jbacik@...com
Cc:	linux-fsdevel@...r.kernel.org, linux-btrfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, jeffm@...e.com, fdmanana@...e.com,
	"Luis R. Rodriguez" <mcgrof@...e.com>
Subject: [RFC 0/2] vfs / btrfs: add support for ustat()

From: "Luis R. Rodriguez" <mcgrof@...e.com>

ustat() does not work for btrfs, the reason is the VFS layer
cannot get to the super block from the anonymous bdevs. The
way these are used within btrfs though are to actually use a
series of them per superblock. This modifies the way the
VFS exposes these bdevs by pegging them onto the super
block on a linked list. This should also allow us to grow
the subdevices on the super block with any other information
that might be better suited underneath so that the VFS
layer is aware. If this approach is reasonable then perhaps
we should next remove the exported symbol for get_anon_bdev()
as btrfs was the only user.

Luis R. Rodriguez (2):
  fs/super.c: add new super block sub devices super_block_dev
  btrfs: use the new VFS super_block_dev

 fs/btrfs/ctree.h   |  7 ++---
 fs/btrfs/disk-io.c | 10 +++---
 fs/btrfs/inode.c   |  2 +-
 fs/super.c         | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
 include/linux/fs.h | 10 ++++++
 5 files changed, 106 insertions(+), 13 deletions(-)

-- 
2.0.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/