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
| ||
|
Date: Fri, 06 Feb 2009 19:10:57 -0500 From: Chris Mason <chris.mason@...cle.com> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: linux-kernel@...r.kernel.org Subject: Re: [GIT PULL] Btrfs updates for 2.6.29-rc On Fri, 2009-02-06 at 13:59 -0800, Linus Torvalds wrote: > > On Fri, 6 Feb 2009, Chris Mason wrote: > > > > 18 files changed, 996 insertions(+), 134 deletions(-) > > This is not at all what I get. I get > > 27 files changed, 1421 insertions(+), 451 deletions(-) > > so there is some confusion there. Crud, the confusion would be me. I missed the cleanups and bug fixes between 2.6.29-rc1 and rc3. The correct diffstat and short log are below, and the only non-btrfs change is to the MAINTAINERS file. MAINTAINERS | 8 fs/btrfs/Kconfig | 13 + fs/btrfs/async-thread.c | 61 +++++- fs/btrfs/compression.c | 1 fs/btrfs/ctree.c | 276 ++++++++++++++++++++++++++---- fs/btrfs/ctree.h | 28 +-- fs/btrfs/disk-io.c | 120 +++++++++---- fs/btrfs/disk-io.h | 2 fs/btrfs/extent-tree.c | 438 ++++++++++++++++++++++++++++++++++++++++-------- fs/btrfs/extent_io.c | 132 +++++++++++--- fs/btrfs/extent_io.h | 18 + fs/btrfs/extent_map.c | 1 fs/btrfs/file.c | 5 fs/btrfs/inode.c | 84 +++++++-- fs/btrfs/ioctl.c | 1 fs/btrfs/locking.c | 208 ++++++++++++++++++++-- fs/btrfs/locking.h | 6 fs/btrfs/ordered-data.c | 4 fs/btrfs/ref-cache.c | 1 fs/btrfs/ref-cache.h | 1 fs/btrfs/super.c | 6 fs/btrfs/transaction.c | 4 fs/btrfs/tree-defrag.c | 1 fs/btrfs/tree-log.c | 354 ++++++++++++++++++-------------------- fs/btrfs/volumes.c | 49 ++--- fs/btrfs/xattr.c | 48 ++++- fs/btrfs/xattr.h | 2 27 files changed, 1421 insertions(+), 451 deletions(-) Chris Ball (1): Btrfs: Handle SGID bit when creating inodes Chris Mason (19): Btrfs: stop providing a bmap operation to avoid swapfile corruptions Btrfs: do less aggressive btree readahead Merge branch 'master' of git://git.kernel.org/.../mason/btrfs-unstable Btrfs: fix readdir on 32 bit machines Btrfs: Catch missed bios in the async bio submission thread Btrfs: async threads should try harder to find work Btrfs: sort references by byte number during btrfs_inc_ref Btrfs: disable leak debugging checks in extent_io.c Btrfs: hash_lock is no longer needed Btrfs: Change btree locking to use explicit blocking points Btrfs: Make btrfs_drop_snapshot work in larger and more efficient chunks Btrfs: Don't try to compress pages past i_size Btrfs: Change btrfs_truncate_inode_items to stop when it hits the inode Btrfs: change btrfs_del_leaf to drop locks earlier Btrfs: fix btrfs_unlock_up_safe to walk the entire path Btrfs: Only prep for btree deletion balances when nodes are mostly empty Btrfs: don't return congestion in write_cache_pages as often Btrfs: Fix memory leak in cache_drop_leaf_ref Btrfs: Make sure dir is non-null before doing S_ISGID checks Christian Hesse (1): Btrfs: make btrfs acls selectable Huang Weiyi (2): Btrfs: removed unused #include <version.h>'s Btrfs: remove duplicated #include Jan Engelhardt (1): Btrfs: change/remove typedef Jim Owens (1): Btrfs: selinux support Joe Perches (1): Btrfs: MAINTAINERS entry Josef Bacik (2): Btrfs: cleanup xattr code Btrfs: join the transaction in __btrfs_setxattr Qinghuang Feng (3): Btrfs: check return value for kthread_run() correctly Btrfs: simplify iteration codes Btrfs: open_ctree() error handling can oops on fs_info Roland Dreier (1): Btrfs: Remove extra KERN_INFO in the middle of a line Wang Cong (1): Btrfs: cleanup fs/btrfs/super.c::btrfs_control_ioctl() Yan Zheng (4): Btrfs: fix locking issue in btrfs_remove_block_group Btrfs: Fix infinite loop in btrfs_extent_post_op Btrfs: fix stop searching test in replace_one_extent Btrfs: fix tree logs parallel sync Yehuda Sadeh (1): Btrfs: fiemap support -- 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/
Powered by blists - more mailing lists