{"push_id":1017804085,"size":92,"distinct_size":92,"ref":"refs/heads/linux-4.4.y-dddvb","head":"f8b230ce69402ada8a28de0dd2042c18ae677a43","before":"ec89e0f89698b460fd3c4014f14a05f9bb12475b","commits":[{"sha":"53729dbbd20a517c4ecb994cfe994bc832b30523","author":{"email":"de609eb4d5d70b1d38ec6642adbfc33a2781f63c@zeniv.linux.org.uk","name":"Al Viro"},"message":"use ->d_seq to get coherency between ->d_inode and ->d_flags\n\ncommit a528aca7f359f4b0b1d72ae406097e491a5ba9ea upstream.\n\nGames with ordering and barriers are way too brittle.  Just\nbump ->d_seq before and after updating ->d_inode and ->d_flags\ntype bits, so that verifying ->d_seq would guarantee they are\ncoherent.\n\nSigned-off-by: Al Viro <viro@zeniv.linux.org.uk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/53729dbbd20a517c4ecb994cfe994bc832b30523"},{"sha":"ad1d8666ae4b68f5417afb4d990aef597e14206b","author":{"email":"a1ff81395f7e6bf5b509fe9aab06bf3419493e1d@glider.be","name":"Geert Uytterhoeven"},"message":"drivers: sh: Restore legacy clock domain on SuperH platforms\n\ncommit 0378ba4899d5fbd8494ed6580cbc81d7b44dbac6 upstream.\n\nCONFIG_ARCH_SHMOBILE is not only enabled for Renesas ARM platforms\n(which are DT based and multi-platform), but also on a select set of\nRenesas SuperH platforms (SH7722/SH7723/SH7724/SH7343/SH7366). Hence\nsince commit 0ba58de231066e47 (\"drivers: sh: Get rid of\nCONFIG_ARCH_SHMOBILE_MULTI\"), the legacy clock domain is no longer\ninstalled on these SuperH platforms, and module clocks may not be\nenabled when needed, leading to driver failures.\n\nTo fix this, add an additional check for CONFIG_OF.\n\nFixes: 0ba58de231066e47 (\"drivers: sh: Get rid of CONFIG_ARCH_SHMOBILE_MULTI\").\nSigned-off-by: Geert Uytterhoeven <geert+renesas@glider.be>\nSigned-off-by: Simon Horman <horms+renesas@verge.net.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/ad1d8666ae4b68f5417afb4d990aef597e14206b"},{"sha":"2232d6dc0017502b02157000afea6815a6810c2a","author":{"email":"e0fcd583df77ec6c08e6d1257619cc1216ddc994@suse.com","name":"Filipe Manana"},"message":"Btrfs: fix deadlock running delayed iputs at transaction commit time\n\ncommit c2d6cb1636d235257086f939a8194ef0bf93af6e upstream.\n\nWhile running a stress test I ran into a deadlock when running the delayed\niputs at transaction time, which produced the following report and trace:\n\n[  886.399989] =============================================\n[  886.400871] [ INFO: possible recursive locking detected ]\n[  886.401663] 4.4.0-rc6-btrfs-next-18+ #1 Not tainted\n[  886.402384] ---------------------------------------------\n[  886.403182] fio/8277 is trying to acquire lock:\n[  886.403568]  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]\n[  886.403568]\n[  886.403568] but task is already holding lock:\n[  886.403568]  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]\n[  886.403568]\n[  886.403568] other info that might help us debug this:\n[  886.403568]  Possible unsafe locking scenario:\n[  886.403568]\n[  886.403568]        CPU0\n[  886.403568]        ----\n[  886.403568]   lock(&fs_info->delayed_iput_sem);\n[  886.403568]   lock(&fs_info->delayed_iput_sem);\n[  886.403568]\n[  886.403568]  *** DEADLOCK ***\n[  886.403568]\n[  886.403568]  May be due to missing lock nesting notation\n[  886.403568]\n[  886.403568] 3 locks held by fio/8277:\n[  886.403568]  #0:  (sb_writers#11){.+.+.+}, at: [<ffffffff81174c4c>] __sb_start_write+0x5f/0xb0\n[  886.403568]  #1:  (&sb->s_type->i_mutex_key#15){+.+.+.}, at: [<ffffffffa054620d>] btrfs_file_write_iter+0x73/0x408 [btrfs]\n[  886.403568]  #2:  (&fs_info->delayed_iput_sem){++++..}, at: [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]\n[  886.403568]\n[  886.403568] stack backtrace:\n[  886.403568] CPU: 6 PID: 8277 Comm: fio Not tainted 4.4.0-rc6-btrfs-next-18+ #1\n[  886.403568] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014\n[  886.403568]  0000000000000000 ffff88009f80f770 ffffffff8125d4fd ffffffff82af1fc0\n[  886.403568]  ffff88009f80f830 ffffffff8108e5f9 0000000200000000 ffff88009fd92290\n[  886.403568]  0000000000000000 ffffffff82af1fc0 ffffffff829cfb01 00042b216d008804\n[  886.403568] Call Trace:\n[  886.403568]  [<ffffffff8125d4fd>] dump_stack+0x4e/0x79\n[  886.403568]  [<ffffffff8108e5f9>] __lock_acquire+0xd42/0xf0b\n[  886.403568]  [<ffffffff810c22db>] ? __module_address+0xdf/0x108\n[  886.403568]  [<ffffffff8108eb77>] lock_acquire+0x10d/0x194\n[  886.403568]  [<ffffffff8108eb77>] ? lock_acquire+0x10d/0x194\n[  886.403568]  [<ffffffffa0538823>] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs]\n[  886.489542]  [<ffffffff8148556b>] down_read+0x3e/0x4d\n[  886.489542]  [<ffffffffa0538823>] ? btrfs_run_delayed_iputs+0x36/0xbf [btrfs]\n[  886.489542]  [<ffffffffa0538823>] btrfs_run_delayed_iputs+0x36/0xbf [btrfs]\n[  886.489542]  [<ffffffffa0533953>] btrfs_commit_transaction+0x8f5/0x96e [btrfs]\n[  886.489542]  [<ffffffffa0521d7a>] flush_space+0x435/0x44a [btrfs]\n[  886.489542]  [<ffffffffa052218b>] ? reserve_metadata_bytes+0x26a/0x384 [btrfs]\n[  886.489542]  [<ffffffffa05221ae>] reserve_metadata_bytes+0x28d/0x384 [btrfs]\n[  886.489542]  [<ffffffffa052256c>] ? btrfs_block_rsv_refill+0x58/0x96 [btrfs]\n[  886.489542]  [<ffffffffa0522584>] btrfs_block_rsv_refill+0x70/0x96 [btrfs]\n[  886.489542]  [<ffffffffa053d747>] btrfs_evict_inode+0x394/0x55a [btrfs]\n[  886.489542]  [<ffffffff81188e31>] evict+0xa7/0x15c\n[  886.489542]  [<ffffffff81189878>] iput+0x1d3/0x266\n[  886.489542]  [<ffffffffa053887c>] btrfs_run_delayed_iputs+0x8f/0xbf [btrfs]\n[  886.489542]  [<ffffffffa0533953>] btrfs_commit_transaction+0x8f5/0x96e [btrfs]\n[  886.489542]  [<ffffffff81085096>] ? signal_pending_state+0x31/0x31\n[  886.489542]  [<ffffffffa0521191>] btrfs_alloc_data_chunk_ondemand+0x1d7/0x288 [btrfs]\n[  886.489542]  [<ffffffffa0521282>] btrfs_check_data_free_space+0x40/0x59 [btrfs]\n[  886.489542]  [<ffffffffa05228f5>] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs]\n[  886.489542]  [<ffffffffa053620a>] btrfs_direct_IO+0x10c/0x27e [btrfs]\n[  886.489542]  [<ffffffff8111d9a1>] generic_file_direct_write+0xb3/0x128\n[  886.489542]  [<ffffffffa05463c3>] btrfs_file_write_iter+0x229/0x408 [btrfs]\n[  886.489542]  [<ffffffff8108ae38>] ? __lock_is_held+0x38/0x50\n[  886.489542]  [<ffffffff8117279e>] __vfs_write+0x7c/0xa5\n[  886.489542]  [<ffffffff81172cda>] vfs_write+0xa0/0xe4\n[  886.489542]  [<ffffffff811734cc>] SyS_write+0x50/0x7e\n[  886.489542]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f\n[ 1081.852335] INFO: task fio:8244 blocked for more than 120 seconds.\n[ 1081.854348]       Not tainted 4.4.0-rc6-btrfs-next-18+ #1\n[ 1081.857560] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 1081.863227] fio        D ffff880213f9bb28     0  8244   8240 0x00000000\n[ 1081.868719]  ffff880213f9bb28 00ffffff810fc6b0 ffffffff0000000a ffff88023ed55240\n[ 1081.872499]  ffff880206b5d400 ffff880213f9c000 ffff88020a4d5318 ffff880206b5d400\n[ 1081.876834]  ffffffff00000001 ffff880206b5d400 ffff880213f9bb40 ffffffff81482ba4\n[ 1081.880782] Call Trace:\n[ 1081.881793]  [<ffffffff81482ba4>] schedule+0x7f/0x97\n[ 1081.883340]  [<ffffffff81485eb5>] rwsem_down_write_failed+0x2d5/0x325\n[ 1081.895525]  [<ffffffff8108d48d>] ? trace_hardirqs_on_caller+0x16/0x1ab\n[ 1081.897419]  [<ffffffff81269723>] call_rwsem_down_write_failed+0x13/0x20\n[ 1081.899251]  [<ffffffff81269723>] ? call_rwsem_down_write_failed+0x13/0x20\n[ 1081.901063]  [<ffffffff81089fae>] ? __down_write_nested.isra.0+0x1f/0x21\n[ 1081.902365]  [<ffffffff814855bd>] down_write+0x43/0x57\n[ 1081.903846]  [<ffffffffa05211b0>] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]\n[ 1081.906078]  [<ffffffffa05211b0>] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]\n[ 1081.908846]  [<ffffffff8108d461>] ? mark_held_locks+0x56/0x6c\n[ 1081.910409]  [<ffffffffa0521282>] btrfs_check_data_free_space+0x40/0x59 [btrfs]\n[ 1081.912482]  [<ffffffffa05228f5>] btrfs_delalloc_reserve_space+0x1e/0x4e [btrfs]\n[ 1081.914597]  [<ffffffffa053620a>] btrfs_direct_IO+0x10c/0x27e [btrfs]\n[ 1081.919037]  [<ffffffff8111d9a1>] generic_file_direct_write+0xb3/0x128\n[ 1081.920754]  [<ffffffffa05463c3>] btrfs_file_write_iter+0x229/0x408 [btrfs]\n[ 1081.922496]  [<ffffffff8108ae38>] ? __lock_is_held+0x38/0x50\n[ 1081.923922]  [<ffffffff8117279e>] __vfs_write+0x7c/0xa5\n[ 1081.925275]  [<ffffffff81172cda>] vfs_write+0xa0/0xe4\n[ 1081.926584]  [<ffffffff811734cc>] SyS_write+0x50/0x7e\n[ 1081.927968]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f\n[ 1081.985293] INFO: lockdep is turned off.\n[ 1081.986132] INFO: task fio:8249 blocked for more than 120 seconds.\n[ 1081.987434]       Not tainted 4.4.0-rc6-btrfs-next-18+ #1\n[ 1081.988534] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 1081.990147] fio        D ffff880218febbb8     0  8249   8240 0x00000000\n[ 1081.991626]  ffff880218febbb8 00ffffff81486b8e ffff88020000000b ffff88023ed75240\n[ 1081.993258]  ffff8802120a9a00 ffff880218fec000 ffff88020a4d5318 ffff8802120a9a00\n[ 1081.994850]  ffffffff00000001 ffff8802120a9a00 ffff880218febbd0 ffffffff81482ba4\n[ 1081.996485] Call Trace:\n[ 1081.997037]  [<ffffffff81482ba4>] schedule+0x7f/0x97\n[ 1081.998017]  [<ffffffff81485eb5>] rwsem_down_write_failed+0x2d5/0x325\n[ 1081.999241]  [<ffffffff810852a5>] ? finish_wait+0x6d/0x76\n[ 1082.000306]  [<ffffffff81269723>] call_rwsem_down_write_failed+0x13/0x20\n[ 1082.001533]  [<ffffffff81269723>] ? call_rwsem_down_write_failed+0x13/0x20\n[ 1082.002776]  [<ffffffff81089fae>] ? __down_write_nested.isra.0+0x1f/0x21\n[ 1082.003995]  [<ffffffff814855bd>] down_write+0x43/0x57\n[ 1082.005000]  [<ffffffffa05211b0>] ? btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]\n[ 1082.007403]  [<ffffffffa05211b0>] btrfs_alloc_data_chunk_ondemand+0x1f6/0x288 [btrfs]\n[ 1082.008988]  [<ffffffffa0545064>] btrfs_fallocate+0x7c1/0xc2f [btrfs]\n[ 1082.010193]  [<ffffffff8108a1ba>] ? percpu_down_read+0x4e/0x77\n[ 1082.011280]  [<ffffffff81174c4c>] ? __sb_start_write+0x5f/0xb0\n[ 1082.012265]  [<ffffffff81174c4c>] ? __sb_start_write+0x5f/0xb0\n[ 1082.013021]  [<ffffffff811712e4>] vfs_fallocate+0x170/0x1ff\n[ 1082.013738]  [<ffffffff81181ebb>] ioctl_preallocate+0x89/0x9b\n[ 1082.014778]  [<ffffffff811822d7>] do_vfs_ioctl+0x40a/0x4ea\n[ 1082.015778]  [<ffffffff81176ea7>] ? SYSC_newfstat+0x25/0x2e\n[ 1082.016806]  [<ffffffff8118b4de>] ? __fget_light+0x4d/0x71\n[ 1082.017789]  [<ffffffff8118240e>] SyS_ioctl+0x57/0x79\n[ 1082.018706]  [<ffffffff814872d7>] entry_SYSCALL_64_fastpath+0x12/0x6f\n\nThis happens because we can recursively acquire the semaphore\nfs_info->delayed_iput_sem when attempting to allocate space to satisfy\na file write request as shown in the first trace above - when committing\na transaction we acquire (down_read) the semaphore before running the\ndelayed iputs, and when running a delayed iput() we can end up calling\nan inode's eviction handler, which in turn commits another transaction\nand attempts to acquire (down_read) again the semaphore to run more\ndelayed iput operations.\nThis results in a deadlock because if a task acquires multiple times a\nsemaphore it should invoke down_read_nested() with a different lockdep\nclass for each level of recursion.\n\nFix this by simplifying the implementation and use a mutex instead that\nis acquired by the cleaner kthread before it runs the delayed iputs\ninstead of always acquiring a semaphore before delayed references are\nrun from anywhere.\n\nFixes: d7c151717a1e (btrfs: Fix NO_SPACE bug caused by delayed-iput)\nSigned-off-by: Filipe Manana <fdmanana@suse.com>\nSigned-off-by: Chris Mason <clm@fb.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/2232d6dc0017502b02157000afea6815a6810c2a"},{"sha":"08acfd9dd845dc052c5eae33e6c3976338070069","author":{"email":"aacdd228f50c574b28b524b23f12fb9d52d6e0e3@cn.fujitsu.com","name":"Zhao Lei"},"message":"btrfs: Fix no_space in write and rm loop\n\ncommit e1746e8381cd2af421f75557b5cae3604fc18b35 upstream.\n\nI see no_space in v4.4-rc1 again in xfstests generic/102.\nIt happened randomly in some node only.\n(one of 4 phy-node, and a kvm with non-virtio block driver)\n\nBy bisect, we can found the first-bad is:\n commit bdced438acd8 (\"block: setup bi_phys_segments after splitting\")'\nBut above patch only triggered the bug by making bio operation\nfaster(or slower).\n\nMain reason is in our space_allocating code, we need to commit\npage writeback before wait it complish, this patch fixed above\nbug.\n\nBTW, there is another reason for generic/102 fail, caused by\ndisable default mixed-blockgroup, I'll fix it in xfstests.\n\nSigned-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>\nSigned-off-by: Chris Mason <clm@fb.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/08acfd9dd845dc052c5eae33e6c3976338070069"},{"sha":"d60a37490744e8dfc2dbd31319a658da7bd601c7","author":{"email":"f41a7033a6382ce00d6b717e37d942dbe3c9a107@cn.fujitsu.com","name":"Qu Wenruo"},"message":"btrfs: async-thread: Fix a use-after-free error for trace\n\ncommit 0a95b851370b84a4b9d92ee6d1fa0926901d0454 upstream.\n\nParameter of trace_btrfs_work_queued() can be freed in its workqueue.\nSo no one use use that pointer after queue_work().\n\nFix the user-after-free bug by move the trace line before queue_work().\n\nReported-by: Dave Jones <davej@codemonkey.org.uk>\nSigned-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>\nReviewed-by: David Sterba <dsterba@suse.com>\nSigned-off-by: Chris Mason <clm@fb.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/d60a37490744e8dfc2dbd31319a658da7bd601c7"},{"sha":"3b26135a8834b726d773e56cd37dd9ff6e43eb6b","author":{"email":"c2fce4493a16d94b58efb315151c29911fc5d347@gmail.com","name":"Oded Gabbay"},"message":"drm/amdgpu: mask out WC from BO on unsupported arches\n\ncommit a187f17f0e15a046aa5d7263b35df55230d92779 upstream.\n\nReviewed-by: Christian König <christian.koenig@amd.com>\nReviewed-by: Michel Dänzer <michel.daenzer@amd.com>\nSigned-off-by: Oded Gabbay <oded.gabbay@gmail.com>\nSigned-off-by: Alex Deucher <alexander.deucher@amd.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/3b26135a8834b726d773e56cd37dd9ff6e43eb6b"},{"sha":"9ec190906d22e7d8bbe3234f37e31b3ce743a71b","author":{"email":"695e2a2c1e39535baaa147c5eb4e5da14054d59f@intel.com","name":"Keith Busch"},"message":"block: Initialize max_dev_sectors to 0\n\ncommit 5f009d3f8e6685fe8c6215082c1696a08b411220 upstream.\n\nThe new queue limit is not used by the majority of block drivers, and\nshould be initialized to 0 for the driver's requested settings to be used.\n\nSigned-off-by: Keith Busch <keith.busch@intel.com>\nAcked-by: Martin K. Petersen <martin.petersen@oracle.com>\nReviewed-by: Sagi Grimberg <sagig@mellanox.com>\nReviewed-by: Christoph Hellwig <hch@lst.de>\nSigned-off-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/9ec190906d22e7d8bbe3234f37e31b3ce743a71b"},{"sha":"5bbc2b412a22acbf614e71f74e327a7a63a754ac","author":{"email":"a2c63438f6716dbcdea754ffda544d5f766e6579@ti.com","name":"Murali Karicheri"},"message":"PCI: keystone: Fix MSI code that retrieves struct pcie_port pointer\n\ncommit 79e3f4a853ed161cd4c06d84b50beebf961a47c6 upstream.\n\nCommit cbce7900598c (\"PCI: designware: Make driver arch-agnostic\") changed\nthe host bridge sysdata pointer from the ARM pci_sys_data to the DesignWare\npcie_port structure, and changed pcie-designware.c to reflect that.  But it\ndid not change the corresponding code in pci-keystone-dw.c, so it caused\ncrashes on Keystone:\n\n  Unable to handle kernel NULL pointer dereference at virtual address 00000030\n  pgd = c0003000\n  [00000030] *pgd=80000800004003, *pmd=00000000\n  Internal error: Oops: 206 [#1] PREEMPT SMP ARM\n  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.2-00139-gb74f926 #2\n  Hardware name: Keystone\n  PC is at ks_dw_pcie_msi_irq_unmask+0x24/0x58\n\nChange pci-keystone-dw.c to expect sysdata to be the struct pcie_port\npointer.\n\n[bhelgaas: changelog]\nFixes: cbce7900598c (\"PCI: designware: Make driver arch-agnostic\")\nSigned-off-by: Murali Karicheri <m-karicheri2@ti.com>\nSigned-off-by: Bjorn Helgaas <bhelgaas@google.com>\nCC: Zhou Wang <wangzhou1@hisilicon.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/5bbc2b412a22acbf614e71f74e327a7a63a754ac"},{"sha":"59dc7ab2e8ab1a0fd0ff104a67f7827436435a46","author":{"email":"5b1e7895819cf7d6bc77091b09bbfd6d330a4e74@gmx.de","name":"Helge Deller"},"message":"parisc: Fix ptrace syscall number and return value modification\n\ncommit 98e8b6c9ac9d1b1e9d1122dfa6783d5d566bb8f7 upstream.\n\nMike Frysinger reported that his ptrace testcase showed strange\nbehaviour on parisc: It was not possible to avoid a syscall and the\nreturn value of a syscall couldn't be changed.\n\nTo modify a syscall number, we were missing to save the new syscall\nnumber to gr20 which is then picked up later in assembly again.\n\nThe effect that the return value couldn't be changed is a side-effect of\nanother bug in the assembly code. When a process is ptraced, userspace\nexpects each syscall to report entrance and exit of a syscall.  If a\nsyscall number was given which doesn't exist, we jumped to the normal\nsyscall exit code instead of informing userspace that the (non-existant)\nsyscall exits. This unexpected behaviour confuses userspace and thus the\nbug was misinterpreted as if we can't change the return value.\n\nThis patch fixes both problems and was tested on 64bit kernel with\n32bit userspace.\n\nSigned-off-by: Helge Deller <deller@gmx.de>\nCc: Mike Frysinger <vapier@gentoo.org>\nTested-by: Mike Frysinger <vapier@gentoo.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/59dc7ab2e8ab1a0fd0ff104a67f7827436435a46"},{"sha":"ce16d9cf0481aa71cf31fac9cd5826022c9f12fb","author":{"email":"255103e50249e3d658441816e0597170ebfc16ef@redhat.com","name":"Michael S. Tsirkin"},"message":"mips/kvm: fix ioctl error handling\n\ncommit 0178fd7dcc4451fcb90bec5e91226586962478d2 upstream.\n\nReturning directly whatever copy_to_user(...) or copy_from_user(...)\nreturns may not do the right thing if there's a pagefault:\ncopy_to_user/copy_from_user return the number of bytes not copied in\nthis case, but ioctls need to return -EFAULT instead.\n\nFix up kvm on mips to do\n\treturn copy_to_user(...)) ?  -EFAULT : 0;\nand\n\treturn copy_from_user(...)) ?  -EFAULT : 0;\n\neverywhere.\n\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/ce16d9cf0481aa71cf31fac9cd5826022c9f12fb"},{"sha":"8cedd1c0796f849760ddd46fb45355c92e913c84","author":{"email":"bf843bd8c284060de73249a47283a98d07f1b82f@google.com","name":"Owen Hofmann"},"message":"kvm: x86: Update tsc multiplier on change.\n\ncommit 2680d6da455b636dd006636780c0f235c6561d70 upstream.\n\nvmx.c writes the TSC_MULTIPLIER field in vmx_vcpu_load, but only when a\nvcpu has migrated physical cpus. Record the last value written and\nupdate in vmx_vcpu_load on any change, otherwise a cpu migration must\noccur for TSC frequency scaling to take effect.\n\nFixes: ff2c3a1803775cc72dc6f624b59554956396b0ee\nSigned-off-by: Owen Hofmann <osh@google.com>\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/8cedd1c0796f849760ddd46fb45355c92e913c84"},{"sha":"2f553b9b6fe7ef636353d80e22d45dbe76c61fb9","author":{"email":"cd827698b6b0b149223c6bff0eb26f50ff43865f@arm.com","name":"Jean-Philippe Brucker"},"message":"fbcon: set a default value to blink interval\n\ncommit a1e533ec07d583d01349ef13c0c965b8633e1b91 upstream.\n\nSince commit 27a4c827c34ac4256a190cc9d24607f953c1c459\n\tfbcon: use the cursor blink interval provided by vt\n\ntwo attempts have been made at fixing a possible hang caused by\ncursor_timer_handler. That function registers a timer to be triggered at\n\"jiffies + fbcon_ops.cur_blink_jiffies\".\n\nA new case had been encountered during initialisation of clcd-pl11x:\n\n    fbcon_fb_registered\n    do_fbcon_takeover\n\n    ->  do_register_con_driver\n        fbcon_startup\n    (A) add_cursor_timer (with cur_blink_jiffies = 0)\n\n    ->  do_bind_con_driver\n        visual_init\n        fbcon_init\n    (B) cur_blink_jiffies = msecs_to_jiffies(vc->vc_cur_blink_ms);\n\nIf we take an softirq anywhere between A and B (and we do),\ncursor_timer_handler executes indefinitely.\n\nInstead of patching all possible paths that lead to this case one at a\ntime, fix the issue at the source and initialise cur_blink_jiffies to\n200ms when allocating fbcon_ops. This was its default value before\naforesaid commit. fbcon_cursor or fbcon_init will refine this value\ndownstream.\n\nSigned-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>\nTested-by: Scot Doyle <lkml14@scotdoyle.com>\nSigned-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/2f553b9b6fe7ef636353d80e22d45dbe76c61fb9"},{"sha":"77f0cc0e5e9cd79f93acb3e7baae425638b8f293","author":{"email":"ee937cfcc16cf790ab2b37c6354b6c3019afbce8@gmail.com","name":"Justin Maggard"},"message":"cifs: fix out-of-bounds access in lease parsing\n\ncommit deb7deff2f00bdbbcb3d560dad2a89ef37df837d upstream.\n\nWhen opening a file, SMB2_open() attempts to parse the lease state from the\nSMB2 CREATE Response.  However, the parsing code was not careful to ensure\nthat the create contexts are not empty or invalid, which can lead to out-\nof-bounds memory access.  This can be seen easily by trying\nto read a file from a OSX 10.11 SMB3 server.  Here is sample crash output:\n\nBUG: unable to handle kernel paging request at ffff8800a1a77cc6\nIP: [<ffffffff8828a734>] SMB2_open+0x804/0x960\nPGD 8f77067 PUD 0\nOops: 0000 [#1] SMP\nModules linked in:\nCPU: 3 PID: 2876 Comm: cp Not tainted 4.5.0-rc3.x86_64.1+ #14\nHardware name: NETGEAR ReadyNAS 314          /ReadyNAS 314          , BIOS 4.6.5 10/11/2012\ntask: ffff880073cdc080 ti: ffff88005b31c000 task.ti: ffff88005b31c000\nRIP: 0010:[<ffffffff8828a734>]  [<ffffffff8828a734>] SMB2_open+0x804/0x960\nRSP: 0018:ffff88005b31fa08  EFLAGS: 00010282\nRAX: 0000000000000015 RBX: 0000000000000000 RCX: 0000000000000006\nRDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff88007eb8c8b0\nRBP: ffff88005b31fad8 R08: 666666203d206363 R09: 6131613030383866\nR10: 3030383866666666 R11: 00000000000002b0 R12: ffff8800660fd800\nR13: ffff8800a1a77cc2 R14: 00000000424d53fe R15: ffff88005f5a28c0\nFS:  00007f7c8a2897c0(0000) GS:ffff88007eb80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b\nCR2: ffff8800a1a77cc6 CR3: 000000005b281000 CR4: 00000000000006e0\nStack:\n ffff88005b31fa70 ffffffff88278789 00000000000001d3 ffff88005f5a2a80\n ffffffff00000003 ffff88005d029d00 ffff88006fde05a0 0000000000000000\n ffff88005b31fc78 ffff88006fde0780 ffff88005b31fb2f 0000000100000fe0\nCall Trace:\n [<ffffffff88278789>] ? cifsConvertToUTF16+0x159/0x2d0\n [<ffffffff8828cf68>] smb2_open_file+0x98/0x210\n [<ffffffff8811e80c>] ? __kmalloc+0x1c/0xe0\n [<ffffffff882685f4>] cifs_open+0x2a4/0x720\n [<ffffffff88122cef>] do_dentry_open+0x1ff/0x310\n [<ffffffff88268350>] ? cifsFileInfo_get+0x30/0x30\n [<ffffffff88123d92>] vfs_open+0x52/0x60\n [<ffffffff88131dd0>] path_openat+0x170/0xf70\n [<ffffffff88097d48>] ? remove_wait_queue+0x48/0x50\n [<ffffffff88133a29>] do_filp_open+0x79/0xd0\n [<ffffffff8813f2ca>] ? __alloc_fd+0x3a/0x170\n [<ffffffff881240c4>] do_sys_open+0x114/0x1e0\n [<ffffffff881241a9>] SyS_open+0x19/0x20\n [<ffffffff8896e257>] entry_SYSCALL_64_fastpath+0x12/0x6a\nCode: 4d 8d 6c 07 04 31 c0 4c 89 ee e8 47 6f e5 ff 31 c9 41 89 ce 44 89 f1 48 c7 c7 28 b1 bd 88 31 c0 49 01 cd 4c 89 ee e8 2b 6f e5 ff <45> 0f b7 75 04 48 c7 c7 31 b1 bd 88 31 c0 4d 01 ee 4c 89 f6 e8\nRIP  [<ffffffff8828a734>] SMB2_open+0x804/0x960\n RSP <ffff88005b31fa08>\nCR2: ffff8800a1a77cc6\n---[ end trace d9f69ba64feee469 ]---\n\nSigned-off-by: Justin Maggard <jmaggard@netgear.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/77f0cc0e5e9cd79f93acb3e7baae425638b8f293"},{"sha":"b52a395883fa5b793137d57d90e1fd980e42748f","author":{"email":"2df99ca89f9c8ed215655495d7ee4ffaa8e47d30@samba.org","name":"Pavel Shilovsky"},"message":"CIFS: Fix SMB2+ interim response processing for read requests\n\ncommit 6cc3b24235929b54acd5ecc987ef11a425bd209e upstream.\n\nFor interim responses we only need to parse a header and update\na number credits. Now it is done for all SMB2+ command except\nSMB2_READ which is wrong. Fix this by adding such processing.\n\nSigned-off-by: Pavel Shilovsky <pshilovsky@samba.org>\nTested-by: Shirish Pargaonkar <shirishpargaonkar@gmail.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/b52a395883fa5b793137d57d90e1fd980e42748f"},{"sha":"bbb3c5076be5c932609524db605e7911ecb95b47","author":{"email":"e1633b7b3267a50e658c251c85c22f5e8697b2aa@novell.com","name":"Yadan Fan"},"message":"Fix cifs_uniqueid_to_ino_t() function for s390x\n\ncommit 1ee9f4bd1a97026a7b2d7ae9f1f74b45680d0003 upstream.\n\nThis issue is caused by commit 02323db17e3a7 (\"cifs: fix\ncifs_uniqueid_to_ino_t not to ever return 0\"), when BITS_PER_LONG\nis 64 on s390x, the corresponding cifs_uniqueid_to_ino_t()\nfunction will cast 64-bit fileid to 32-bit by using (ino_t)fileid,\nbecause ino_t (typdefed __kernel_ino_t) is int type.\n\nIt's defined in arch/s390/include/uapi/asm/posix_types.h\n\n    #ifndef __s390x__\n\n    typedef unsigned long   __kernel_ino_t;\n    ...\n    #else /* __s390x__ */\n\n    typedef unsigned int    __kernel_ino_t;\n\nSo the #ifdef condition is wrong for s390x, we can just still use\none cifs_uniqueid_to_ino_t() function with comparing sizeof(ino_t)\nand sizeof(u64) to choose the correct execution accordingly.\n\nSigned-off-by: Yadan Fan <ydfan@suse.com>\nSigned-off-by: Steve French <smfrench@gmail.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/bbb3c5076be5c932609524db605e7911ecb95b47"},{"sha":"7931825da8fd57ceb8bae86d3dbe555a506a7edd","author":{"email":"255103e50249e3d658441816e0597170ebfc16ef@redhat.com","name":"Michael S. Tsirkin"},"message":"vfio: fix ioctl error handling\n\ncommit 8160c4e455820d5008a1116d2dca35f0363bb062 upstream.\n\nCalling return copy_to_user(...) in an ioctl will not\ndo the right thing if there's a pagefault:\ncopy_to_user returns the number of bytes not copied\nin this case.\n\nFix up vfio to do\n\treturn copy_to_user(...)) ?\n\t\t-EFAULT : 0;\n\neverywhere.\n\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Alex Williamson <alex.williamson@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/7931825da8fd57ceb8bae86d3dbe555a506a7edd"},{"sha":"25e8618619a5a46aae253e1cc68eeaa0d44d2f52","author":{"email":"69d3ebcf5ee4e7f05a50dc23cd96655b730804b4@redhat.com","name":"Paolo Bonzini"},"message":"KVM: x86: fix root cause for missed hardware breakpoints\n\ncommit 70e4da7a8ff62f2775337b705f45c804bb450454 upstream.\n\nCommit 172b2386ed16 (\"KVM: x86: fix missed hardware breakpoints\",\n2016-02-10) worked around a case where the debug registers are not loaded\ncorrectly on preemption and on the first entry to KVM_RUN.\n\nHowever, Xiao Guangrong pointed out that the root cause must be that\nKVM_DEBUGREG_BP_ENABLED is not being set correctly.  This can indeed\nhappen due to the lazy debug exit mechanism, which does not call\nkvm_update_dr7.  Fix it by replacing the existing loop (more or less\nequivalent to kvm_update_dr0123) with calls to all the kvm_update_dr*\nfunctions.\n\nFixes: 172b2386ed16a9143d9a456aae5ec87275c61489\nReviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>\nSigned-off-by: Paolo Bonzini <pbonzini@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/25e8618619a5a46aae253e1cc68eeaa0d44d2f52"},{"sha":"d1c623c9c264c6cb045015900f8ce1e60b4d2c7d","author":{"email":"255103e50249e3d658441816e0597170ebfc16ef@redhat.com","name":"Michael S. Tsirkin"},"message":"arm/arm64: KVM: Fix ioctl error handling\n\ncommit 4cad67fca3fc952d6f2ed9e799621f07666a560f upstream.\n\nCalling return copy_to_user(...) in an ioctl will not\ndo the right thing if there's a pagefault:\ncopy_to_user returns the number of bytes not copied\nin this case.\n\nFix up kvm to do\n\treturn copy_to_user(...)) ?  -EFAULT : 0;\n\neverywhere.\n\nAcked-by: Christoffer Dall <christoffer.dall@linaro.org>\nSigned-off-by: Michael S. Tsirkin <mst@redhat.com>\nSigned-off-by: Marc Zyngier <marc.zyngier@arm.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/d1c623c9c264c6cb045015900f8ce1e60b4d2c7d"},{"sha":"ad0f9dade9912224326fcac1e09ed4846b41f7c9","author":{"email":"8bfd13cad0bc4b2ac41d9e235951e72c9b62c2aa@jcornwall.me","name":"Jay Cornwall"},"message":"iommu/amd: Apply workaround for ATS write permission check\n\ncommit 358875fd52ab8f00f66328cbf1a1d2486f265829 upstream.\n\nThe AMD Family 15h Models 30h-3Fh (Kaveri) BIOS and Kernel Developer's\nGuide omitted part of the BIOS IOMMU L2 register setup specification.\nWithout this setup the IOMMU L2 does not fully respect write permissions\nwhen handling an ATS translation request.\n\nThe IOMMU L2 will set PTE dirty bit when handling an ATS translation with\nwrite permission request, even when PTE RW bit is clear. This may occur by\ndirect translation (which would cause a PPR) or by prefetch request from\nthe ATC.\n\nThis is observed in practice when the IOMMU L2 modifies a PTE which maps a\npagecache page. The ext4 filesystem driver BUGs when asked to writeback\nthese (non-modified) pages.\n\nEnable ATS write permission check in the Kaveri IOMMU L2 if BIOS has not.\n\nSigned-off-by: Jay Cornwall <jay@jcornwall.me>\nSigned-off-by: Joerg Roedel <jroedel@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/ad0f9dade9912224326fcac1e09ed4846b41f7c9"},{"sha":"44792d5c907c9afa03ac1f6a8ace7df4db500d85","author":{"email":"ed04488ebbbd0c8ebb072b7ab25add9fa816eb84@amd.com","name":"Suravee Suthikulpanit"},"message":"iommu/amd: Fix boot warning when device 00:00.0 is not iommu covered\n\ncommit 38e45d02ea9f194b89d6bf41e52ccafc8e2c2b47 upstream.\n\nThe setup code for the performance counters in the AMD IOMMU driver\ntests whether the counters can be written. It tests to setup a counter\nfor device 00:00.0, which fails on systems where this particular device\nis not covered by the IOMMU.\n\nFix this by not relying on device 00:00.0 but only on the IOMMU being\npresent.\n\nSigned-off-by: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>\nSigned-off-by: Joerg Roedel <jroedel@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/herrnst/dddvb-linux-kernel/commits/44792d5c907c9afa03ac1f6a8ace7df4db500d85"}]}