On Mon, Jun 23, 2014 at 06:27:16PM +0200, David Sterba wrote: > Hi stable folks, > > please add the following patches to the 3.15.x queue. The notable > highlight is "btrfs: allocate raid type kobjects dynamically" that fixes > a use-after-free but is not a short patch. It's been extensively tested > and verified. The rest are few-liners that fix potential crashes or have > user-visible impact. > > Thanks. > > Subjects: > Btrfs: read inode size after acquiring the mutex when punching a hole > btrfs: Add ctime/mtime update for btrfs device add/remove. > Btrfs: output warning instead of error when loading free space cache failed > Btrfs: send, account for orphan directories when building path strings > Btrfs: make sure there are not any read requests before stopping workers > Btrfs: fix NULL pointer crash of deleting a seed device > Btrfs: mark mapping with error flag to report errors to userspace > Btrfs: set right total device count for seeding support > Btrfs: fix double free in find_lock_delalloc_range > Btrfs: send, don't error in the presence of subvols/snapshots > Btrfs: send, use the right limits for xattr names and values > btrfs: allocate raid type kobjects dynamically > fs: btrfs: volumes.c: Fix for possible null pointer dereference > Btrfs: don't check nodes for extent items > Btrfs: use right type to get real comparison > Btrfs: fix scrub_print_warning to handle skinny metadata extents > btrfs: fix use of uninit "ret" in end_extent_writepage() > Commits: > a1a50f60a6bf4f861eb94793420274bc1ccd409a > 5a1972bd9fd4b2fb1bac8b7a0b636d633d8717e3 > 32d6b47fe6fc1714d5f1bba1b9f38e0ab0ad58a8 > c992ec94f24c3e7135d6c23860615f269f0b1d87 > de348ee022175401e77d7662b7ca6e231a94e3fd > 29cc83f69c8338ff8fd1383c9be263d4bdf52d73 > 5dca6eea91653e9949ce6eb9e9acab6277e2f2c4 > 298658414a2f0bea1f05a81876a45c1cd96aa2e0 > 7d78874273463a784759916fc3e0b4e2eb141c70 > 1af56070e3ef9477dbc7eba3b9ad7446979c7974 > 7e3ae33efad1490d01040f552ef50e58ed6376ca > c1895442be01c58449e3bf9272f22062a670e08f > 8321cf2596d283821acc466377c2b85bcd3422b7 > 8a56457f5f8fa7c2698ffae8545214c5b96a2cb5 > cd857dd6bc2ae9ecea14e75a34e8a8fdc158e307 > 6eda71d0c030af0fc2f68aaa676e6d445600855b > 3e2426bd0eb980648449e7a2f5a23e3cd3c7725c That's the order to apply them in, right? Also, any of these relevant to any older stable kernels? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html