payload: {"push_id":4110865448,"size":18,"distinct_size":18,"ref":"refs/heads/misc-next","head":"fbca8f6eaaac64d8fac812782bb33b87e40b2ced","before":"d9f02963e536c4072f9787938f0ea74fca35d406","commits":[{"sha":"d7fa9125fe5b57462831eba5ff44d4db40d8506d","author":{"name":"David Sterba","email":"a2ce9d316ca04d17b520237d2846a218b8284e52@suse.com"},"message":"btrfs: make locking assertion helpers static inline\n\nI've noticed that none of the btrfs_assert_*lock* debugging helpers is\ninlined, despite they're short and mostly a value update. Making them\ninline shaves 67 from the text size, reduces stack consumption and\nperhaps also slightly improves the performance due to avoiding\nunnecessary calls.\n\nReviewed-by: Josef Bacik <josef@toxicpanda.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/d7fa9125fe5b57462831eba5ff44d4db40d8506d"},{"sha":"edf45753af899c360dbcf44edf1613056389f94f","author":{"name":"David Sterba","email":"a2ce9d316ca04d17b520237d2846a218b8284e52@suse.com"},"message":"btrfs: make btrfs_assert_tree_locked static inline\n\nThe function btrfs_assert_tree_locked is used outside of the locking\ncode so it is exported, however we can make it static inine as it's\nfairly trivial.\n\nThis is the only locking assertion used in release builds, inlining\nimproves the text size by 174 bytes and reduces stack consumption in the\ncallers.\n\nReviewed-by: Josef Bacik <josef@toxicpanda.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/edf45753af899c360dbcf44edf1613056389f94f"},{"sha":"bfd3bc82d1aa2c10550e8bb51fccfcbf82d96264","author":{"name":"David Sterba","email":"a2ce9d316ca04d17b520237d2846a218b8284e52@suse.com"},"message":"btrfs: move btrfs_set_path_blocking to other locking functions\n\nThe function belongs to the family of locking functions, so move it\nthere. The 'noinline' keyword is dropped as it's now an exported\nfunction that does not need it.\n\nReviewed-by: Josef Bacik <josef@toxicpanda.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/bfd3bc82d1aa2c10550e8bb51fccfcbf82d96264"},{"sha":"af1d9726a652ec70c6646e12257e2e9d74aa2b63","author":{"name":"David Sterba","email":"a2ce9d316ca04d17b520237d2846a218b8284e52@suse.com"},"message":"btrfs: move btrfs_unlock_up_safe to other locking functions\n\nThe function belongs to the family of locking functions, so move it\nthere. The 'noinline' keyword is dropped as it's now an exported\nfunction that does not need it.\n\nReviewed-by: Josef Bacik <josef@toxicpanda.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/af1d9726a652ec70c6646e12257e2e9d74aa2b63"},{"sha":"43963926eebaf8e50844b2c2d75ee80fb5229abd","author":{"name":"Anand Jain","email":"81069a49b521acf79f562d472ec8c4e0d6a88433@oracle.com"},"message":"btrfs: balance: use term redundancy instead of integrity in message\n\nWhen balance reduces the number of copies of metadata, it reduces the\nredundancy, use the term redundancy instead of integrity.\n\nSigned-off-by: Anand Jain <anand.jain@oracle.com>\nReviewed-by: David Sterba <dsterba@suse.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/43963926eebaf8e50844b2c2d75ee80fb5229abd"},{"sha":"3131f8200151cd9ce9bec3ae6be9f6a600b78b12","author":{"name":"Filipe Manana","email":"e0fcd583df77ec6c08e6d1257619cc1216ddc994@suse.com"},"message":"Btrfs: fix memory leak due to concurrent append writes with fiemap\n\nWhen we have a buffered write that starts at an offset greater than or\nequals to the file's size happening concurrently with a full ranged\nfiemap, we can end up leaking an extent state structure.\n\nSuppose we have a file with a size of 1Mb, and before the buffered write\nand fiemap are performed, it has a single extent state in its io tree\nrepresenting the range from 0 to 1Mb, with the EXTENT_DELALLOC bit set.\n\nThe following sequence diagram shows how the memory leak happens if a\nfiemap a buffered write, starting at offset 1Mb and with a length of\n4Kb, are performed concurrently.\n\n          CPU 1                                                  CPU 2\n\n  extent_fiemap()\n    --> it's a full ranged fiemap\n        range from 0 to LLONG_MAX - 1\n        (9223372036854775807)\n\n    --> locks range in the inode's\n        io tree\n      --> after this we have 2 extent\n          states in the io tree:\n          --> 1 for range [0, 1Mb[ with\n              the bits EXTENT_LOCKED and\n              EXTENT_DELALLOC_BITS set\n          --> 1 for the range\n              [1Mb, LLONG_MAX[ with\n              the EXTENT_LOCKED bit set\n\n                                                  --> start buffered write at offset\n                                                      1Mb with a length of 4Kb\n\n                                                  btrfs_file_write_iter()\n\n                                                    btrfs_buffered_write()\n                                                      --> cached_state is NULL\n\n                                                      lock_and_cleanup_extent_if_need()\n                                                        --> returns 0 and does not lock\n                                                            range because it starts\n                                                            at current i_size / eof\n\n                                                      --> cached_state remains NULL\n\n                                                      btrfs_dirty_pages()\n                                                        btrfs_set_extent_delalloc()\n                                                          (...)\n                                                          __set_extent_bit()\n\n                                                            --> splits extent state for range\n                                                                [1Mb, LLONG_MAX[ and now we\n                                                                have 2 extent states:\n\n                                                                --> one for the range\n                                                                    [1Mb, 1Mb + 4Kb[ with\n                                                                    EXTENT_LOCKED set\n                                                                --> another one for the range\n                                                                    [1Mb + 4Kb, LLONG_MAX[ with\n                                                                    EXTENT_LOCKED set as well\n\n                                                            --> sets EXTENT_DELALLOC on the\n                                                                extent state for the range\n                                                                [1Mb, 1Mb + 4Kb[\n                                                            --> caches extent state\n                                                                [1Mb, 1Mb + 4Kb[ into\n                                                                @cached_state because it has\n                                                                the bit EXTENT_LOCKED set\n\n                                                    --> btrfs_buffered_write() ends up\n                                                        with a non-NULL cached_state and\n                                                        never calls anything to release its\n                                                        reference on it, resulting in a\n                                                        memory leak\n\nFix this by calling free_extent_state() on cached_state if the range was\nnot locked by lock_and_cleanup_extent_if_need().\n\nThe same issue can happen if anything else other than fiemap locks a range\nthat covers eof and beyond.\n\nThis could be triggered, sporadically, by test case generic/561 from the\nfstests suite, which makes duperemove run concurrently with fsstress, and\nduperemove does plenty of calls to fiemap. When CONFIG_BTRFS_DEBUG is set\nthe leak is reported in dmesg/syslog when removing the btrfs module with\na message like the following:\n\n  [77100.039461] BTRFS: state leak: start 6574080 end 6582271 state 16402 in tree 0 refs 1\n\nOtherwise (CONFIG_BTRFS_DEBUG not set) detectable with kmemleak.\n\nCC: stable@vger.kernel.org # 4.16+\nReviewed-by: Josef Bacik <josef@toxicpanda.com>\nSigned-off-by: Filipe Manana <fdmanana@suse.com>\nReviewed-by: David Sterba <dsterba@suse.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/3131f8200151cd9ce9bec3ae6be9f6a600b78b12"},{"sha":"d052e5448104d30ba56f300f8bbf4ee63be3ce5d","author":{"name":"Josef Bacik","email":"78b342861d821967b29f951b7366f5a0267e0c38@toxicpanda.com"},"message":"btrfs: fix incorrect updating of log root tree\n\nWe've historically had reports of being unable to mount file systems\nbecause the tree log root couldn't be read.  Usually this is the \"parent\ntransid failure\", but could be any of the related errors, including\n\"fsid mismatch\" or \"bad tree block\", depending on which block got\nallocated.\n\nThe modification of the individual log root items are serialized on the\nper-log root root_mutex.  This means that any modification to the\nper-subvol log root_item is completely protected.\n\nHowever we update the root item in the log root tree outside of the log\nroot tree log_mutex.  We do this in order to allow multiple subvolumes\nto be updated in each log transaction.\n\nThis is problematic however because when we are writing the log root\ntree out we update the super block with the _current_ log root node\ninformation.  Since these two operations happen independently of each\nother, you can end up updating the log root tree in between writing out\nthe dirty blocks and setting the super block to point at the current\nroot.\n\nThis means we'll point at the new root node that hasn't been written\nout, instead of the one we should be pointing at.  Thus whatever garbage\nor old block we end up pointing at complains when we mount the file\nsystem later and try to replay the log.\n\nFix this by copying the log's root item into a local root item copy.\nThen once we're safely under the log_root_tree->log_mutex we update the\nroot item in the log_root_tree.  This way we do not modify the\nlog_root_tree while we're committing it, fixing the problem.\n\nCC: stable@vger.kernel.org # 4.4+\nReviewed-by: Chris Mason <clm@fb.com>\nReviewed-by: Filipe Manana <fdmanana@suse.com>\nSigned-off-by: Josef Bacik <josef@toxicpanda.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/d052e5448104d30ba56f300f8bbf4ee63be3ce5d"},{"sha":"73fae0e67dd0619f1bee43a3f8b62843d25e1880","author":{"name":"Zygo Blaxell","email":"fdeb914dd8066ef55b6bb37d701a850e78332d12@umail.furryterror.org"},"message":"btrfs: fix balance convert to single on 32-bit host CPUs\n\nCurrently, the command:\n\n\tbtrfs balance start -dconvert=single,soft .\n\non a Raspberry Pi produces the following kernel message:\n\n\tBTRFS error (device mmcblk0p2): balance: invalid convert data profile single\n\nThis fails because we use is_power_of_2(unsigned long) to validate\nthe new data profile, the constant for 'single' profile uses bit 48,\nand there are only 32 bits in a long on ARM.\n\nFix by open-coding the check using u64 variables.\n\nTested by completing the original balance command on several Raspberry\nPis.\n\nFixes: 818255feece6 (\"btrfs: use common helper instead of open coding a bit test\")\nCC: stable@vger.kernel.org # 4.20+\nSigned-off-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>\nReviewed-by: David Sterba <dsterba@suse.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/73fae0e67dd0619f1bee43a3f8b62843d25e1880"},{"sha":"f255633a49c0a13e6e3d5fb1b3a112dd3f0ef5bc","author":{"name":"David Sterba","email":"a2ce9d316ca04d17b520237d2846a218b8284e52@suse.com"},"message":"btrfs: add 64bit safe helper for power of two checks\n\nAs is_power_of_two takes unsigned long, it's not safe on 32bit\narchitectures, but we could pass any u64 value in seveal places. Add a\nseparate helper and also an alias that better expresses the purpose for\nwhich the helper is used.\n\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/f255633a49c0a13e6e3d5fb1b3a112dd3f0ef5bc"},{"sha":"4c1d7f2e10c1755cb20d64effd7e0b90a52d7f18","author":{"name":"David Sterba","email":"a2ce9d316ca04d17b520237d2846a218b8284e52@suse.com"},"message":"btrfs: use has_single_bit_set for clarity\n\nReplace is_power_of_2 with the helper that is self-documenting and\nremove the open coded call in alloc_profile_is_valid.\n\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/4c1d7f2e10c1755cb20d64effd7e0b90a52d7f18"},{"sha":"1534adeb2b6655806b4aeb1defc97ca0559b9fb5","author":{"name":"Josef Bacik","email":"78b342861d821967b29f951b7366f5a0267e0c38@toxicpanda.com"},"message":"btrfs: allocate new inode in NOFS context\n\nA user reported a lockdep splat\n\n ======================================================\n WARNING: possible circular locking dependency detected\n 5.2.11-gentoo #2 Not tainted\n ------------------------------------------------------\n kswapd0/711 is trying to acquire lock:\n 000000007777a663 (sb_internal){.+.+}, at: start_transaction+0x3a8/0x500\n\nbut task is already holding lock:\n 000000000ba86300 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x30\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-> #1 (fs_reclaim){+.+.}:\n kmem_cache_alloc+0x1f/0x1c0\n btrfs_alloc_inode+0x1f/0x260\n alloc_inode+0x16/0xa0\n new_inode+0xe/0xb0\n btrfs_new_inode+0x70/0x610\n btrfs_symlink+0xd0/0x420\n vfs_symlink+0x9c/0x100\n do_symlinkat+0x66/0xe0\n do_syscall_64+0x55/0x1c0\n entry_SYSCALL_64_after_hwframe+0x49/0xbe\n\n-> #0 (sb_internal){.+.+}:\n __sb_start_write+0xf6/0x150\n start_transaction+0x3a8/0x500\n btrfs_commit_inode_delayed_inode+0x59/0x110\n btrfs_evict_inode+0x19e/0x4c0\n evict+0xbc/0x1f0\n inode_lru_isolate+0x113/0x190\n __list_lru_walk_one.isra.4+0x5c/0x100\n list_lru_walk_one+0x32/0x50\n prune_icache_sb+0x36/0x80\n super_cache_scan+0x14a/0x1d0\n do_shrink_slab+0x131/0x320\n shrink_node+0xf7/0x380\n balance_pgdat+0x2d5/0x640\n kswapd+0x2ba/0x5e0\n kthread+0x147/0x160\n ret_from_fork+0x24/0x30\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n lock(fs_reclaim);\n lock(sb_internal);\n lock(fs_reclaim);\n lock(sb_internal);\n*** DEADLOCK ***\n\n 3 locks held by kswapd0/711:\n #0: 000000000ba86300 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x30\n #1: 000000004a5100f8 (shrinker_rwsem){++++}, at: shrink_node+0x9a/0x380\n #2: 00000000f956fa46 (&type->s_umount_key#30){++++}, at: super_cache_scan+0x35/0x1d0\n\nstack backtrace:\n CPU: 7 PID: 711 Comm: kswapd0 Not tainted 5.2.11-gentoo #2\n Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.4.2 09/29/2017\n Call Trace:\n dump_stack+0x85/0xc7\n print_circular_bug.cold.40+0x1d9/0x235\n __lock_acquire+0x18b1/0x1f00\n lock_acquire+0xa6/0x170\n ? start_transaction+0x3a8/0x500\n __sb_start_write+0xf6/0x150\n ? start_transaction+0x3a8/0x500\n start_transaction+0x3a8/0x500\n btrfs_commit_inode_delayed_inode+0x59/0x110\n btrfs_evict_inode+0x19e/0x4c0\n ? var_wake_function+0x20/0x20\n evict+0xbc/0x1f0\n inode_lru_isolate+0x113/0x190\n ? discard_new_inode+0xc0/0xc0\n __list_lru_walk_one.isra.4+0x5c/0x100\n ? discard_new_inode+0xc0/0xc0\n list_lru_walk_one+0x32/0x50\n prune_icache_sb+0x36/0x80\n super_cache_scan+0x14a/0x1d0\n do_shrink_slab+0x131/0x320\n shrink_node+0xf7/0x380\n balance_pgdat+0x2d5/0x640\n kswapd+0x2ba/0x5e0\n ? __wake_up_common_lock+0x90/0x90\n kthread+0x147/0x160\n ? balance_pgdat+0x640/0x640\n ? __kthread_create_on_node+0x160/0x160\n ret_from_fork+0x24/0x30\n\nThis is because btrfs_new_inode() calls new_inode() under the\ntransaction.  We could probably move the new_inode() outside of this but\nfor now just wrap it in memalloc_nofs_save().\n\nReported-by: Zdenek Sojka <zsojka@seznam.cz>\nFixes: 712e36c5f2a7 (\"btrfs: use GFP_KERNEL in btrfs_alloc_inode\")\nCC: stable@vger.kernel.org # 4.16+\nReviewed-by: Filipe Manana <fdmanana@suse.com>\nSigned-off-by: Josef Bacik <josef@toxicpanda.com>\nReviewed-by: David Sterba <dsterba@suse.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/1534adeb2b6655806b4aeb1defc97ca0559b9fb5"},{"sha":"a2bca4e0365c916262331adfdcd72e2e1ff6ab22","author":{"name":"Qu Wenruo","email":"668a4a6da3341b25f8dc67d6a1b3c7eba3092599@suse.com"},"message":"btrfs: transaction: describe transaction states and transitions\n\nAdd an overview of the basic btrfs transaction transitions, including\nthe following states:\n\n- No transaction states\n- Transaction N [[TRANS_STATE_RUNNING]]\n- Transaction N [[TRANS_STATE_COMMIT_START]]\n- Transaction N [[TRANS_STATE_COMMIT_DOING]]\n- Transaction N [[TRANS_STATE_UNBLOCKED]]\n- Transaction N [[TRANS_STATE_COMPLETED]]\n\nFor each state, the comment will include:\n\n- Basic explaination about current state\n- How to go next stage\n- What will happen if we call various start_transaction() functions\n- Relationship to transaction N+1\n\nThis doesn't provide tech details, but serves as a cheat sheet for\nreader to get into the code a little easier.\n\nSigned-off-by: Qu Wenruo <wqu@suse.com>\nReviewed-by: David Sterba <dsterba@suse.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/a2bca4e0365c916262331adfdcd72e2e1ff6ab22"},{"sha":"71cb65a4872d15803b7df8d99ebe8c028be48146","author":{"name":"Qu Wenruo","email":"668a4a6da3341b25f8dc67d6a1b3c7eba3092599@suse.com"},"message":"btrfs: transaction: Cleanup unused TRANS_STATE_BLOCKED\n\nThe state was introduced in commit 4a9d8bdee368 (\"Btrfs: make the state\nof the transaction more readable\"), then in commit 302167c50b32\n(\"btrfs: don't end the transaction for delayed refs in throttle\") the\nstate is completely removed.\n\nSo we can just clean up the state since it's only compared but never\nset.\n\nSigned-off-by: Qu Wenruo <wqu@suse.com>\nReviewed-by: David Sterba <dsterba@suse.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/71cb65a4872d15803b7df8d99ebe8c028be48146"},{"sha":"05652305b887b3e2b7f530f56952507b400d2636","author":{"name":"Josef Bacik","email":"78b342861d821967b29f951b7366f5a0267e0c38@toxicpanda.com"},"message":"btrfs: fix uninitialized ret in ref-verify\n\nCoverity caught a case where we could return with a uninitialized value\nin ret in process_leaf.  This is actually pretty likely because we could\nvery easily run into a block group item key and have a garbage value in\nret and think there was an errror.  Fix this by initializing ret to 0.\n\nReported-by: Colin Ian King <colin.king@canonical.com>\nFixes: fd708b81d972 (\"Btrfs: add a extent ref verify tool\")\nCC: stable@vger.kernel.org # 4.19+\nSigned-off-by: Josef Bacik <josef@toxicpanda.com>\nReviewed-by: David Sterba <dsterba@suse.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/05652305b887b3e2b7f530f56952507b400d2636"},{"sha":"8ac9c0638276783f72f3c2359078f825f81859c7","author":{"name":"Nikolay Borisov","email":"142453373c3b88d8ff81b1a9e73f7ad113f58c91@suse.com"},"message":"btrfs: Don't opencode btrfs_find_name_in_backref in backref_in_log\n\nDirect replacement, though note that the inside of the loop in\nbtrfs_find_name_in_backref is organized in a slightly different way but\nis equvalent.\n\nSigned-off-by: Nikolay Borisov <nborisov@suse.com>\nReviewed-by: David Sterba <dsterba@suse.com>\n[ add changelog ]\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/8ac9c0638276783f72f3c2359078f825f81859c7"},{"sha":"ff683fd16d768468ab745a41360ebc6bee40f549","author":{"name":"Nikolay Borisov","email":"142453373c3b88d8ff81b1a9e73f7ad113f58c91@suse.com"},"message":"btrfs: Properly handle backref_in_log retval\n\nThis function can return a negative error value if btrfs_search_slot\nerrors for whatever reason or if btrfs_alloc_path runs out of memory.\nThis is currently problemattic because backref_in_log is treated by its\ncallers as if it returns boolean.\n\nFix this by adding proper error handling in callers. That also enables\nthe function to return the direct error code from btrfs_search_slot.\n\nSigned-off-by: Nikolay Borisov <nborisov@suse.com>\nReviewed-by: David Sterba <dsterba@suse.com>\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/ff683fd16d768468ab745a41360ebc6bee40f549"},{"sha":"b1492da35aacd5027e85642adc4c0211df8cca06","author":{"name":"Nikolay Borisov","email":"142453373c3b88d8ff81b1a9e73f7ad113f58c91@suse.com"},"message":"btrfs: Open-code name_in_log_ref in replay_one_name\n\nThat function adds unnecessary indirection between backref_in_log and\nthe caller. Furthermore it also \"downgrades\" backref_in_log's return\nvalue to a boolean, when in fact it could very well be an error.\n\nRectify the situation by simply opencoding name_in_log_ref in\nreplay_one_name and properly handling possible return codes from\nbackref_in_log.\n\nSigned-off-by: Nikolay Borisov <nborisov@suse.com>\nReviewed-by: David Sterba <dsterba@suse.com>\n[ update comment ]\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/b1492da35aacd5027e85642adc4c0211df8cca06"},{"sha":"fbca8f6eaaac64d8fac812782bb33b87e40b2ced","author":{"name":"Anand Jain","email":"81069a49b521acf79f562d472ec8c4e0d6a88433@oracle.com"},"message":"btrfs: print process name and pid that calls device scanning\n\nIts very helpful if we had logged the device scanner process name to\ndebug the race condition between the systemd-udevd scan and the user\ninitiated device forget command.\n\nThis patch adds process name and pid to the scan message.\n\nSigned-off-by: Anand Jain <anand.jain@oracle.com>\nReviewed-by: David Sterba <dsterba@suse.com>\n[ add pid to the message ]\nSigned-off-by: David Sterba <dsterba@suse.com>","distinct":true,"url":"https://api.github.com/repos/kdave/btrfs-devel/commits/fbca8f6eaaac64d8fac812782bb33b87e40b2ced"}]}
other: {"actor":{"display_login":"kdave"}}