{"push_id":3704619256,"size":246,"distinct_size":246,"ref":"refs/heads/pie-clang","head":"518d99fd57ca792c5585dc3af10202fd8b8a529c","before":"856438a225b95a2987b2ab4e72cf3bb033ef05ec","commits":[{"sha":"4d68e2bf383458e08f33c9995c4252e11367a7bf","author":{"name":"Andy Lutomirski","email":"2cc0d0d76de2e6f37b92deeb83c85cb306fc5dc1@kernel.org"},"message":"x86/speculation/mds: Revert CPU buffer clear on double fault exit\n\ncommit 88640e1dcd089879530a49a8d212d1814678dfe7 upstream.\n\nThe double fault ESPFIX path doesn't return to user mode at all --\nit returns back to the kernel by simulating a #GP fault.\nprepare_exit_to_usermode() will run on the way out of\ngeneral_protection before running user code.\n\nSigned-off-by: Andy Lutomirski <luto@kernel.org>\nCc: Borislav Petkov <bp@suse.de>\nCc: Frederic Weisbecker <frederic@kernel.org>\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCc: Jon Masters <jcm@redhat.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: stable@vger.kernel.org\nFixes: 04dcbdb80578 (\"x86/speculation/mds: Clear CPU buffers on exit to user\")\nLink: http://lkml.kernel.org/r/ac97612445c0a44ee10374f6ea79c222fe22a5c4.1557865329.git.luto@kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/4d68e2bf383458e08f33c9995c4252e11367a7bf"},{"sha":"ce814dc7e8110c5ea6da1ba49a27d099c937824b","author":{"name":"Andy Lutomirski","email":"2cc0d0d76de2e6f37b92deeb83c85cb306fc5dc1@kernel.org"},"message":"x86/speculation/mds: Improve CPU buffer clear documentation\n\ncommit 9d8d0294e78a164d407133dea05caf4b84247d6a upstream.\n\nOn x86_64, all returns to usermode go through\nprepare_exit_to_usermode(), with the sole exception of do_nmi().\nThis even includes machine checks -- this was added several years\nago to support MCE recovery.  Update the documentation.\n\nSigned-off-by: Andy Lutomirski <luto@kernel.org>\nCc: Borislav Petkov <bp@suse.de>\nCc: Frederic Weisbecker <frederic@kernel.org>\nCc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCc: Jon Masters <jcm@redhat.com>\nCc: Linus Torvalds <torvalds@linux-foundation.org>\nCc: Peter Zijlstra <peterz@infradead.org>\nCc: Thomas Gleixner <tglx@linutronix.de>\nCc: stable@vger.kernel.org\nFixes: 04dcbdb80578 (\"x86/speculation/mds: Clear CPU buffers on exit to user\")\nLink: http://lkml.kernel.org/r/999fa9e126ba6a48e9d214d2f18dbde5c62ac55c.1557865329.git.luto@kernel.org\nSigned-off-by: Ingo Molnar <mingo@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/ce814dc7e8110c5ea6da1ba49a27d099c937824b"},{"sha":"f7dee0816e5d71cfdf924e21f4a21f51fd109b89","author":{"name":"Wen Yang","email":"afd840760ae056f12d268e4e37e2fa284568e0a9@zte.com.cn"},"message":"ARM: exynos: Fix a leaked reference by adding missing of_node_put\n\ncommit 629266bf7229cd6a550075f5961f95607b823b59 upstream.\n\nThe call to of_get_next_child returns a node pointer with refcount\nincremented thus it must be explicitly decremented after the last\nusage.\n\nDetected by coccinelle with warnings like:\n    arch/arm/mach-exynos/firmware.c:201:2-8: ERROR: missing of_node_put;\n        acquired a node pointer with refcount incremented on line 193,\n        but without a corresponding object release within this function.\n\nCc: stable@vger.kernel.org\nSigned-off-by: Wen Yang <wen.yang99@zte.com.cn>\nSigned-off-by: Krzysztof Kozlowski <krzk@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/f7dee0816e5d71cfdf924e21f4a21f51fd109b89"},{"sha":"2ee0dd38a0a0bcd066791363147ab58dbaac39fd","author":{"name":"Daniel Axtens","email":"cf1af486034ab0119a20f38a060e40da25f4cea3@axtens.net"},"message":"crypto: vmx - fix copy-paste error in CTR mode\n\ncommit dcf7b48212c0fab7df69e84fab22d6cb7c8c0fb9 upstream.\n\nThe original assembly imported from OpenSSL has two copy-paste\nerrors in handling CTR mode. When dealing with a 2 or 3 block tail,\nthe code branches to the CBC decryption exit path, rather than to\nthe CTR exit path.\n\nThis leads to corruption of the IV, which leads to subsequent blocks\nbeing corrupted.\n\nThis can be detected with libkcapi test suite, which is available at\nhttps://github.com/smuellerDD/libkcapi\n\nReported-by: Ondrej Mosnáček <omosnacek@gmail.com>\nFixes: 5c380d623ed3 (\"crypto: vmx - Add support for VMS instructions by ASM\")\nCc: stable@vger.kernel.org\nSigned-off-by: Daniel Axtens <dja@axtens.net>\nTested-by: Michael Ellerman <mpe@ellerman.id.au>\nTested-by: Ondrej Mosnacek <omosnacek@gmail.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/2ee0dd38a0a0bcd066791363147ab58dbaac39fd"},{"sha":"2ee7c2310cd075268be8bf02d966b76ac3824cdb","author":{"name":"Eric Biggers","email":"6f6115196800bbe9712b3f04c7e40093bb382fc5@google.com"},"message":"crypto: crct10dif-generic - fix use via crypto_shash_digest()\n\ncommit 307508d1072979f4435416f87936f87eaeb82054 upstream.\n\nThe ->digest() method of crct10dif-generic reads the current CRC value\nfrom the shash_desc context.  But this value is uninitialized, causing\ncrypto_shash_digest() to compute the wrong result.  Fix it.\n\nProbably this wasn't noticed before because lib/crc-t10dif.c only uses\ncrypto_shash_update(), not crypto_shash_digest().  Likewise,\ncrypto_shash_digest() is not yet tested by the crypto self-tests because\nthose only test the ahash API which only uses shash init/update/final.\n\nThis bug was detected by my patches that improve testmgr to fuzz\nalgorithms against their generic implementation.\n\nFixes: 2d31e518a428 (\"crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform framework\")\nCc: <stable@vger.kernel.org> # v3.11+\nCc: Tim Chen <tim.c.chen@linux.intel.com>\nSigned-off-by: Eric Biggers <ebiggers@google.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/2ee7c2310cd075268be8bf02d966b76ac3824cdb"},{"sha":"b1c1888ad6c930ee7cdc7ca01069027462dfb37f","author":{"name":"Eric Biggers","email":"6f6115196800bbe9712b3f04c7e40093bb382fc5@google.com"},"message":"crypto: x86/crct10dif-pcl - fix use via crypto_shash_digest()\n\ncommit dec3d0b1071a0f3194e66a83d26ecf4aa8c5910e upstream.\n\nThe ->digest() method of crct10dif-pclmul reads the current CRC value\nfrom the shash_desc context.  But this value is uninitialized, causing\ncrypto_shash_digest() to compute the wrong result.  Fix it.\n\nProbably this wasn't noticed before because lib/crc-t10dif.c only uses\ncrypto_shash_update(), not crypto_shash_digest().  Likewise,\ncrypto_shash_digest() is not yet tested by the crypto self-tests because\nthose only test the ahash API which only uses shash init/update/final.\n\nFixes: 0b95a7f85718 (\"crypto: crct10dif - Glue code to cast accelerated CRCT10DIF assembly as a crypto transform\")\nCc: <stable@vger.kernel.org> # v3.11+\nCc: Tim Chen <tim.c.chen@linux.intel.com>\nSigned-off-by: Eric Biggers <ebiggers@google.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/b1c1888ad6c930ee7cdc7ca01069027462dfb37f"},{"sha":"2d8956305ae8529b15e492029c1b50bbfdf30ba5","author":{"name":"Wenwen Wang","email":"bafc5a1ee344249d3957e4d34f33647904b567dc@umn.edu"},"message":"ALSA: usb-audio: Fix a memory leak bug\n\ncommit cb5173594d50c72b7bfa14113dfc5084b4d2f726 upstream.\n\nIn parse_audio_selector_unit(), the string array 'namelist' is allocated\nthrough kmalloc_array(), and each string pointer in this array, i.e.,\n'namelist[]', is allocated through kmalloc() in the following for loop.\nThen, a control instance 'kctl' is created by invoking snd_ctl_new1(). If\nan error occurs during the creation process, the string array 'namelist',\nincluding all string pointers in the array 'namelist[]', should be freed,\nbefore the error code ENOMEM is returned. However, the current code does\nnot free 'namelist[]', resulting in memory leaks.\n\nTo fix the above issue, free all string pointers 'namelist[]' in a loop.\n\nSigned-off-by: Wenwen Wang <wang6495@umn.edu>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/2d8956305ae8529b15e492029c1b50bbfdf30ba5"},{"sha":"1bbb08c8ab6a7bd4a08a8a19cfceba57812efc18","author":{"name":"Hui Wang","email":"51909cde9c974b33f1f2fb15bb7fd44a1b667281@canonical.com"},"message":"ALSA: hda/hdmi - Consider eld_valid when reporting jack event\n\ncommit 7f641e26a6df9269cb25dd7a4b0a91d6586ed441 upstream.\n\nOn the machines with AMD GPU or Nvidia GPU, we often meet this issue:\nafter s3, there are 4 HDMI/DP audio devices in the gnome-sound-setting\neven there is no any monitors plugged.\n\nWhen this problem happens, we check the /proc/asound/cardX/eld#N.M, we\nwill find the monitor_present=1, eld_valid=0.\n\nThe root cause is BIOS or GPU driver makes the PRESENCE valid even no\nmonitor plugged, and of course the driver will not get the valid\neld_data subsequently.\n\nIn this situation, we should not report the jack_plugged event, to do\nso, let us change the function hdmi_present_sense_via_verbs(). In this\nfunction, it reads the pin_sense via snd_hda_pin_sense(), after\ncalling this function, the jack_dirty is 0, and before exiting\nvia_verbs(), we change the shadow pin_sense according to both\nmonitor_present and eld_valid, then in the snd_hda_jack_report_sync(),\nsince the jack_dirty is still 0, it will report jack event according\nto this modified shadow pin_sense.\n\nAfter this change, the driver will not report Jack_is_plugged event\nthrough hdmi_present_sense_via_verbs() if monitor_present is 1 and\neld_valid is 0.\n\nSigned-off-by: Hui Wang <hui.wang@canonical.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/1bbb08c8ab6a7bd4a08a8a19cfceba57812efc18"},{"sha":"2a8188c68e0a83b34d53ece586cd6372ef21425a","author":{"name":"Kailang Yang","email":"f9c437feeb6aa4c634d1401f9d6bbc3a81a20705@realtek.com"},"message":"ALSA: hda/realtek - EAPD turn on later\n\ncommit 607ca3bd220f4022e6f5356026b19dafc363863a upstream.\n\nLet EAPD turn on after set pin output.\n\n[ NOTE: This change is supposed to reduce the possible click noises at\n  (runtime) PM resume.  The functionality should be same (i.e. the\n  verbs are executed correctly) no matter which order is, so this\n  should be safe to apply for all codecs -- tiwai ]\n\nSigned-off-by: Kailang Yang <kailang@realtek.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/2a8188c68e0a83b34d53ece586cd6372ef21425a"},{"sha":"e6bf706cee3f8164baf74d78e0fcca839fe1c486","author":{"name":"Jon Hunter","email":"cbbc2a491dd609dc667a5c30620606c73351583d@nvidia.com"},"message":"ASoC: max98090: Fix restore of DAPM Muxes\n\ncommit ecb2795c08bc825ebd604997e5be440b060c5b18 upstream.\n\nThe max98090 driver defines 3 DAPM muxes; one for the right line output\n(LINMOD Mux), one for the left headphone mixer source (MIXHPLSEL Mux)\nand one for the right headphone mixer source (MIXHPRSEL Mux). The same\nbit is used for the mux as well as the DAPM enable, and although the mux\ncan be correctly configured, after playback has completed, the mux will\nbe reset during the disable phase. This is preventing the state of these\nmuxes from being saved and restored correctly on system reboot. Fix this\nby marking these muxes as SND_SOC_NOPM.\n\nNote this has been verified this on the Tegra124 Nyan Big which features\nthe MAX98090 codec.\n\nSigned-off-by: Jon Hunter <jonathanh@nvidia.com>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nCc: stable@vger.kernel.org\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/e6bf706cee3f8164baf74d78e0fcca839fe1c486"},{"sha":"80cc516ed7830eca17f437c9a21431e5cd731715","author":{"name":"Curtis Malainey","email":"9427d954bf16a65878c953cc565cfe9ab51a3885@chromium.org"},"message":"ASoC: RT5677-SPI: Disable 16Bit SPI Transfers\n\ncommit a46eb523220e242affb9a6bc9bb8efc05f4f7459 upstream.\n\nThe current algorithm allows 3 types of transfers, 16bit, 32bit and\nburst. According to Realtek, 16bit transfers have a special restriction\nin that it is restricted to the memory region of\n0x18020000 ~ 0x18021000. This region is the memory location of the I2C\nregisters. The current algorithm does not uphold this restriction and\ntherefore fails to complete writes.\n\nSince this has been broken for some time it likely no one is using it.\nBetter to simply disable the 16 bit writes. This will allow users to\nproperly load firmware over SPI without data corruption.\n\nSigned-off-by: Curtis Malainey <cujomalainey@chromium.org>\nReviewed-by: Ben Zhang <benzh@chromium.org>\nSigned-off-by: Mark Brown <broonie@kernel.org>\nCc: stable@vger.kernel.org\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/80cc516ed7830eca17f437c9a21431e5cd731715"},{"sha":"b614485b6b93dbb2f6202341c60594fcdc110d5c","author":{"name":"Jiri Kosina","email":"ed58f755cc8caaf10c3e8c731a8b86fb8f13d6cb@suse.cz"},"message":"mm/mincore.c: make mincore() more conservative\n\ncommit 134fca9063ad4851de767d1768180e5dede9a881 upstream.\n\nThe semantics of what mincore() considers to be resident is not\ncompletely clear, but Linux has always (since 2.3.52, which is when\nmincore() was initially done) treated it as \"page is available in page\ncache\".\n\nThat's potentially a problem, as that [in]directly exposes\nmeta-information about pagecache / memory mapping state even about\nmemory not strictly belonging to the process executing the syscall,\nopening possibilities for sidechannel attacks.\n\nChange the semantics of mincore() so that it only reveals pagecache\ninformation for non-anonymous mappings that belog to files that the\ncalling process could (if it tried to) successfully open for writing;\notherwise we'd be including shared non-exclusive mappings, which\n\n - is the sidechannel\n\n - is not the usecase for mincore(), as that's primarily used for data,\n   not (shared) text\n\n[jkosina@suse.cz: v2]\n  Link: http://lkml.kernel.org/r/20190312141708.6652-2-vbabka@suse.cz\n[mhocko@suse.com: restructure can_do_mincore() conditions]\nLink: http://lkml.kernel.org/r/nycvar.YFH.7.76.1903062342020.19912@cbobk.fhfr.pm\nSigned-off-by: Jiri Kosina <jkosina@suse.cz>\nSigned-off-by: Vlastimil Babka <vbabka@suse.cz>\nAcked-by: Josh Snyder <joshs@netflix.com>\nAcked-by: Michal Hocko <mhocko@suse.com>\nOriginally-by: Linus Torvalds <torvalds@linux-foundation.org>\nOriginally-by: Dominique Martinet <asmadeus@codewreck.org>\nCc: Andy Lutomirski <luto@amacapital.net>\nCc: Dave Chinner <david@fromorbit.com>\nCc: Kevin Easton <kevin@guarana.org>\nCc: Matthew Wilcox <willy@infradead.org>\nCc: Cyril Hrubis <chrubis@suse.cz>\nCc: Tejun Heo <tj@kernel.org>\nCc: Kirill A. Shutemov <kirill@shutemov.name>\nCc: Daniel Gruss <daniel@gruss.cc>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/b614485b6b93dbb2f6202341c60594fcdc110d5c"},{"sha":"e3a74fbc42cad54d7e6f406a6f393357458e6499","author":{"name":"Shuning Zhang","email":"0796dd720dee3bb6fd517aebe50d561b12bd2e82@oracle.com"},"message":"ocfs2: fix ocfs2 read inode data panic in ocfs2_iget\n\ncommit e091eab028f9253eac5c04f9141bbc9d170acab3 upstream.\n\nIn some cases, ocfs2_iget() reads the data of inode, which has been\ndeleted for some reason.  That will make the system panic.  So We should\njudge whether this inode has been deleted, and tell the caller that the\ninode is a bad inode.\n\nFor example, the ocfs2 is used as the backed of nfs, and the client is\nnfsv3.  This issue can be reproduced by the following steps.\n\non the nfs server side,\n..../patha/pathb\n\nStep 1: The process A was scheduled before calling the function fh_verify.\n\nStep 2: The process B is removing the 'pathb', and just completed the call\nto function dput.  Then the dentry of 'pathb' has been deleted from the\ndcache, and all ancestors have been deleted also.  The relationship of\ndentry and inode was deleted through the function hlist_del_init.  The\nfollowing is the call stack.\ndentry_iput->hlist_del_init(&dentry->d_u.d_alias)\n\nAt this time, the inode is still in the dcache.\n\nStep 3: The process A call the function ocfs2_get_dentry, which get the\ninode from dcache.  Then the refcount of inode is 1.  The following is the\ncall stack.\nnfsd3_proc_getacl->fh_verify->exportfs_decode_fh->fh_to_dentry(ocfs2_get_dentry)\n\nStep 4: Dirty pages are flushed by bdi threads.  So the inode of 'patha'\nis evicted, and this directory was deleted.  But the inode of 'pathb'\ncan't be evicted, because the refcount of the inode was 1.\n\nStep 5: The process A keep running, and call the function\nreconnect_path(in exportfs_decode_fh), which call function\nocfs2_get_parent of ocfs2.  Get the block number of parent\ndirectory(patha) by the name of ...  Then read the data from disk by the\nblock number.  But this inode has been deleted, so the system panic.\n\nProcess A                                             Process B\n1. in nfsd3_proc_getacl                   |\n2.                                        |        dput\n3. fh_to_dentry(ocfs2_get_dentry)         |\n4. bdi flush dirty cache                  |\n5. ocfs2_iget                             |\n\n[283465.542049] OCFS2: ERROR (device sdp): ocfs2_validate_inode_block:\nInvalid dinode #580640: OCFS2_VALID_FL not set\n\n[283465.545490] Kernel panic - not syncing: OCFS2: (device sdp): panic forced\nafter error\n\n[283465.546889] CPU: 5 PID: 12416 Comm: nfsd Tainted: G        W\n4.1.12-124.18.6.el6uek.bug28762940v3.x86_64 #2\n[283465.548382] Hardware name: VMware, Inc. VMware Virtual Platform/440BX\nDesktop Reference Platform, BIOS 6.00 09/21/2015\n[283465.549657]  0000000000000000 ffff8800a56fb7b8 ffffffff816e839c\nffffffffa0514758\n[283465.550392]  000000000008dc20 ffff8800a56fb838 ffffffff816e62d3\n0000000000000008\n[283465.551056]  ffff880000000010 ffff8800a56fb848 ffff8800a56fb7e8\nffff88005df9f000\n[283465.551710] Call Trace:\n[283465.552516]  [<ffffffff816e839c>] dump_stack+0x63/0x81\n[283465.553291]  [<ffffffff816e62d3>] panic+0xcb/0x21b\n[283465.554037]  [<ffffffffa04e66b0>] ocfs2_handle_error+0xf0/0xf0 [ocfs2]\n[283465.554882]  [<ffffffffa04e7737>] __ocfs2_error+0x67/0x70 [ocfs2]\n[283465.555768]  [<ffffffffa049c0f9>] ocfs2_validate_inode_block+0x229/0x230\n[ocfs2]\n[283465.556683]  [<ffffffffa047bcbc>] ocfs2_read_blocks+0x46c/0x7b0 [ocfs2]\n[283465.557408]  [<ffffffffa049bed0>] ? ocfs2_inode_cache_io_unlock+0x20/0x20\n[ocfs2]\n[283465.557973]  [<ffffffffa049f0eb>] ocfs2_read_inode_block_full+0x3b/0x60\n[ocfs2]\n[283465.558525]  [<ffffffffa049f5ba>] ocfs2_iget+0x4aa/0x880 [ocfs2]\n[283465.559082]  [<ffffffffa049146e>] ocfs2_get_parent+0x9e/0x220 [ocfs2]\n[283465.559622]  [<ffffffff81297c05>] reconnect_path+0xb5/0x300\n[283465.560156]  [<ffffffff81297f46>] exportfs_decode_fh+0xf6/0x2b0\n[283465.560708]  [<ffffffffa062faf0>] ? nfsd_proc_getattr+0xa0/0xa0 [nfsd]\n[283465.561262]  [<ffffffff810a8196>] ? prepare_creds+0x26/0x110\n[283465.561932]  [<ffffffffa0630860>] fh_verify+0x350/0x660 [nfsd]\n[283465.562862]  [<ffffffffa0637804>] ? nfsd_cache_lookup+0x44/0x630 [nfsd]\n[283465.563697]  [<ffffffffa063a8b9>] nfsd3_proc_getattr+0x69/0xf0 [nfsd]\n[283465.564510]  [<ffffffffa062cf60>] nfsd_dispatch+0xe0/0x290 [nfsd]\n[283465.565358]  [<ffffffffa05eb892>] ? svc_tcp_adjust_wspace+0x12/0x30\n[sunrpc]\n[283465.566272]  [<ffffffffa05ea652>] svc_process_common+0x412/0x6a0 [sunrpc]\n[283465.567155]  [<ffffffffa05eaa03>] svc_process+0x123/0x210 [sunrpc]\n[283465.568020]  [<ffffffffa062c90f>] nfsd+0xff/0x170 [nfsd]\n[283465.568962]  [<ffffffffa062c810>] ? nfsd_destroy+0x80/0x80 [nfsd]\n[283465.570112]  [<ffffffff810a622b>] kthread+0xcb/0xf0\n[283465.571099]  [<ffffffff810a6160>] ? kthread_create_on_node+0x180/0x180\n[283465.572114]  [<ffffffff816f11b8>] ret_from_fork+0x58/0x90\n[283465.573156]  [<ffffffff810a6160>] ? kthread_create_on_node+0x180/0x180\n\nLink: http://lkml.kernel.org/r/1554185919-3010-1-git-send-email-sunny.s.zhang@oracle.com\nSigned-off-by: Shuning Zhang <sunny.s.zhang@oracle.com>\nReviewed-by: Joseph Qi <jiangqi903@gmail.com>\nCc: Mark Fasheh <mark@fasheh.com>\nCc: Joel Becker <jlbec@evilplan.org>\nCc: Junxiao Bi <junxiao.bi@oracle.com>\nCc: Changwei Ge <gechangwei@live.cn>\nCc: piaojun <piaojun@huawei.com>\nCc: \"Gang He\" <ghe@suse.com>\nCc: <stable@vger.kernel.org>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/e3a74fbc42cad54d7e6f406a6f393357458e6499"},{"sha":"592a36c59f4cce88daee1423a973b4b215cfd8aa","author":{"name":"Steve Twiss","email":"fe2d2d2e9cbc66a66e33b8e3c46609d5cf898468@diasemi.com"},"message":"mfd: da9063: Fix OTP control register names to match datasheets for DA9063/63L\n\ncommit 6b4814a9451add06d457e198be418bf6a3e6a990 upstream.\n\nMismatch between what is found in the Datasheets for DA9063 and DA9063L\nprovided by Dialog Semiconductor, and the register names provided in the\nMFD registers file. The changes are for the OTP (one-time-programming)\ncontrol registers. The two naming errors are OPT instead of OTP, and\nCOUNT instead of CONT (i.e. control).\n\nCc: Stable <stable@vger.kernel.org>\nSigned-off-by: Steve Twiss <stwiss.opensource@diasemi.com>\nSigned-off-by: Lee Jones <lee.jones@linaro.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/592a36c59f4cce88daee1423a973b4b215cfd8aa"},{"sha":"e5100e7fa78e44dd0365df53003947b16197943a","author":{"name":"Sergei Trofimovich","email":"110fdadc76b6bce16977f568bdb4723eaed6fb3f@gentoo.org"},"message":"tty/vt: fix write/write race in ioctl(KDSKBSENT) handler\n\ncommit 46ca3f735f345c9d87383dd3a09fa5d43870770e upstream.\n\nThe bug manifests as an attempt to access deallocated memory:\n\n    BUG: unable to handle kernel paging request at ffff9c8735448000\n    #PF error: [PROT] [WRITE]\n    PGD 288a05067 P4D 288a05067 PUD 288a07067 PMD 7f60c2063 PTE 80000007f5448161\n    Oops: 0003 [#1] PREEMPT SMP\n    CPU: 6 PID: 388 Comm: loadkeys Tainted: G         C        5.0.0-rc6-00153-g5ded5871030e #91\n    Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77M-D3H, BIOS F12 11/14/2013\n    RIP: 0010:__memmove+0x81/0x1a0\n    Code: 4c 89 4f 10 4c 89 47 18 48 8d 7f 20 73 d4 48 83 c2 20 e9 a2 00 00 00 66 90 48 89 d1 4c 8b 5c 16 f8 4c 8d 54 17 f8 48 c1 e9 03 <f3> 48 a5 4d 89 1a e9 0c 01 00 00 0f 1f 40 00 48 89 d1 4c 8b 1e 49\n    RSP: 0018:ffffa1b9002d7d08 EFLAGS: 00010203\n    RAX: ffff9c873541af43 RBX: ffff9c873541af43 RCX: 00000c6f105cd6bf\n    RDX: 0000637882e986b6 RSI: ffff9c8735447ffb RDI: ffff9c8735447ffb\n    RBP: ffff9c8739cd3800 R08: ffff9c873b802f00 R09: 00000000fffff73b\n    R10: ffffffffb82b35f1 R11: 00505b1b004d5b1b R12: 0000000000000000\n    R13: ffff9c873541af3d R14: 000000000000000b R15: 000000000000000c\n    FS:  00007f450c390580(0000) GS:ffff9c873f180000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: ffff9c8735448000 CR3: 00000007e213c002 CR4: 00000000000606e0\n    Call Trace:\n     vt_do_kdgkb_ioctl+0x34d/0x440\n     vt_ioctl+0xba3/0x1190\n     ? __bpf_prog_run32+0x39/0x60\n     ? mem_cgroup_commit_charge+0x7b/0x4e0\n     tty_ioctl+0x23f/0x920\n     ? preempt_count_sub+0x98/0xe0\n     ? __seccomp_filter+0x67/0x600\n     do_vfs_ioctl+0xa2/0x6a0\n     ? syscall_trace_enter+0x192/0x2d0\n     ksys_ioctl+0x3a/0x70\n     __x64_sys_ioctl+0x16/0x20\n     do_syscall_64+0x54/0xe0\n     entry_SYSCALL_64_after_hwframe+0x49/0xbe\n\nThe bug manifests on systemd systems with multiple vtcon devices:\n  # cat /sys/devices/virtual/vtconsole/vtcon0/name\n  (S) dummy device\n  # cat /sys/devices/virtual/vtconsole/vtcon1/name\n  (M) frame buffer device\n\nThere systemd runs 'loadkeys' tool in tapallel for each vtcon\ninstance. This causes two parallel ioctl(KDSKBSENT) calls to\nrace into adding the same entry into 'func_table' array at:\n\n    drivers/tty/vt/keyboard.c:vt_do_kdgkb_ioctl()\n\nThe function has no locking around writes to 'func_table'.\n\nThe simplest reproducer is to have initrams with the following\ninit on a 8-CPU machine x86_64:\n\n    #!/bin/sh\n\n    loadkeys -q windowkeys ru4 &\n    loadkeys -q windowkeys ru4 &\n    loadkeys -q windowkeys ru4 &\n    loadkeys -q windowkeys ru4 &\n\n    loadkeys -q windowkeys ru4 &\n    loadkeys -q windowkeys ru4 &\n    loadkeys -q windowkeys ru4 &\n    loadkeys -q windowkeys ru4 &\n    wait\n\nThe change adds lock on write path only. Reads are still racy.\n\nCC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nCC: Jiri Slaby <jslaby@suse.com>\nLink: https://lkml.org/lkml/2019/2/17/256\nSigned-off-by: Sergei Trofimovich <slyfox@gentoo.org>\nCc: stable <stable@vger.kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/e5100e7fa78e44dd0365df53003947b16197943a"},{"sha":"f3b9c26f191b435c31a9ae3a14d5cd3e96e3badc","author":{"name":"Kirill Tkhai","email":"e5b39230c99b4d3ebd6aa54f6d823f95134bc39d@virtuozzo.com"},"message":"ext4: actually request zeroing of inode table after grow\n\ncommit 310a997fd74de778b9a4848a64be9cda9f18764a upstream.\n\nIt is never possible, that number of block groups decreases,\nsince only online grow is supported.\n\nBut after a growing occured, we have to zero inode tables\nfor just created new block groups.\n\nFixes: 19c5246d2516 (\"ext4: add new online resize interface\")\nSigned-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nReviewed-by: Jan Kara <jack@suse.cz>\nCc: stable@kernel.org\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/f3b9c26f191b435c31a9ae3a14d5cd3e96e3badc"},{"sha":"b268b6e501ed91638ed2effa3e790abe0359b6fc","author":{"name":"Debabrata Banerjee","email":"8416239a43cab9c6f46deec338e1a206a5c77021@akamai.com"},"message":"ext4: fix ext4_show_options for file systems w/o journal\n\ncommit 50b29d8f033a7c88c5bc011abc2068b1691ab755 upstream.\n\nInstead of removing EXT4_MOUNT_JOURNAL_CHECKSUM from s_def_mount_opt as\nI assume was intended, all other options were blown away leading to\n_ext4_show_options() output being incorrect.\n\nFixes: 1e381f60dad9 (\"ext4: do not allow journal_opts for fs w/o journal\")\nSigned-off-by: Debabrata Banerjee <dbanerje@akamai.com>\nSigned-off-by: Theodore Ts'o <tytso@mit.edu>\nReviewed-by: Jan Kara <jack@suse.cz>\nCc: stable@kernel.org\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/b268b6e501ed91638ed2effa3e790abe0359b6fc"},{"sha":"686e4352e3d8ad58bfa0b7fc0243d7ef503e32c7","author":{"name":"Filipe Manana","email":"e0fcd583df77ec6c08e6d1257619cc1216ddc994@suse.com"},"message":"Btrfs: do not start a transaction at iterate_extent_inodes()\n\ncommit bfc61c36260ca990937539cd648ede3cd749bc10 upstream.\n\nWhen finding out which inodes have references on a particular extent, done\nby backref.c:iterate_extent_inodes(), from the BTRFS_IOC_LOGICAL_INO (both\nv1 and v2) ioctl and from scrub we use the transaction join API to grab a\nreference on the currently running transaction, since in order to give\naccurate results we need to inspect the delayed references of the currently\nrunning transaction.\n\nHowever, if there is currently no running transaction, the join operation\nwill create a new transaction. This is inefficient as the transaction will\neventually be committed, doing unnecessary IO and introducing a potential\npoint of failure that will lead to a transaction abort due to -ENOSPC, as\nrecently reported [1].\n\nThat's because the join, creates the transaction but does not reserve any\nspace, so when attempting to update the root item of the root passed to\nbtrfs_join_transaction(), during the transaction commit, we can end up\nfailling with -ENOSPC. Users of a join operation are supposed to actually\ndo some filesystem changes and reserve space by some means, which is not\nthe case of iterate_extent_inodes(), it is a read-only operation for all\ncontextes from which it is called.\n\nThe reported [1] -ENOSPC failure stack trace is the following:\n\n heisenberg kernel: ------------[ cut here ]------------\n heisenberg kernel: BTRFS: Transaction aborted (error -28)\n heisenberg kernel: WARNING: CPU: 0 PID: 7137 at fs/btrfs/root-tree.c:136 btrfs_update_root+0x22b/0x320 [btrfs]\n(...)\n heisenberg kernel: CPU: 0 PID: 7137 Comm: btrfs-transacti Not tainted 4.19.0-4-amd64 #1 Debian 4.19.28-2\n heisenberg kernel: Hardware name: FUJITSU LIFEBOOK U757/FJNB2A5, BIOS Version 1.21 03/19/2018\n heisenberg kernel: RIP: 0010:btrfs_update_root+0x22b/0x320 [btrfs]\n(...)\n heisenberg kernel: RSP: 0018:ffffb5448828bd40 EFLAGS: 00010286\n heisenberg kernel: RAX: 0000000000000000 RBX: ffff8ed56bccef50 RCX: 0000000000000006\n heisenberg kernel: RDX: 0000000000000007 RSI: 0000000000000092 RDI: ffff8ed6bda166a0\n heisenberg kernel: RBP: 00000000ffffffe4 R08: 00000000000003df R09: 0000000000000007\n heisenberg kernel: R10: 0000000000000000 R11: 0000000000000001 R12: ffff8ed63396a078\n heisenberg kernel: R13: ffff8ed092d7c800 R14: ffff8ed64f5db028 R15: ffff8ed6bd03d068\n heisenberg kernel: FS:  0000000000000000(0000) GS:ffff8ed6bda00000(0000) knlGS:0000000000000000\n heisenberg kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n heisenberg kernel: CR2: 00007f46f75f8000 CR3: 0000000310a0a002 CR4: 00000000003606f0\n heisenberg kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n heisenberg kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n heisenberg kernel: Call Trace:\n heisenberg kernel:  commit_fs_roots+0x166/0x1d0 [btrfs]\n heisenberg kernel:  ? _cond_resched+0x15/0x30\n heisenberg kernel:  ? btrfs_run_delayed_refs+0xac/0x180 [btrfs]\n heisenberg kernel:  btrfs_commit_transaction+0x2bd/0x870 [btrfs]\n heisenberg kernel:  ? start_transaction+0x9d/0x3f0 [btrfs]\n heisenberg kernel:  transaction_kthread+0x147/0x180 [btrfs]\n heisenberg kernel:  ? btrfs_cleanup_transaction+0x530/0x530 [btrfs]\n heisenberg kernel:  kthread+0x112/0x130\n heisenberg kernel:  ? kthread_bind+0x30/0x30\n heisenberg kernel:  ret_from_fork+0x35/0x40\n heisenberg kernel: ---[ end trace 05de912e30e012d9 ]---\n\nSo fix that by using the attach API, which does not create a transaction\nwhen there is currently no running transaction.\n\n[1] https://lore.kernel.org/linux-btrfs/b2a668d7124f1d3e410367f587926f622b3f03a4.camel@scientia.net/\n\nReported-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>\nCC: stable@vger.kernel.org # 4.4+\nSigned-off-by: Filipe Manana <fdmanana@suse.com>\nReviewed-by: David Sterba <dsterba@suse.com>\nSigned-off-by: David Sterba <dsterba@suse.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/686e4352e3d8ad58bfa0b7fc0243d7ef503e32c7"},{"sha":"5651075a1ce3ccc59690f72f32dac469f3e2e52c","author":{"name":"Liang Chen","email":"31657768478aac2ec9d18b8c37d622da3ab83e75@gmail.com"},"message":"bcache: fix a race between cache register and cacheset unregister\n\ncommit a4b732a248d12cbdb46999daf0bf288c011335eb upstream.\n\nThere is a race between cache device register and cache set unregister.\nFor an already registered cache device, register_bcache will call\nbch_is_open to iterate through all cachesets and check every cache\nthere. The race occurs if cache_set_free executes at the same time and\nclears the caches right before ca is dereferenced in bch_is_open_cache.\nTo close the race, let's make sure the clean up work is protected by\nthe bch_register_lock as well.\n\nThis issue can be reproduced as follows,\nwhile true; do echo /dev/XXX> /sys/fs/bcache/register ; done&\nwhile true; do echo 1> /sys/block/XXX/bcache/set/unregister ; done &\n\nand results in the following oops,\n\n[  +0.000053] BUG: unable to handle kernel NULL pointer dereference at 0000000000000998\n[  +0.000457] #PF error: [normal kernel read fault]\n[  +0.000464] PGD 800000003ca9d067 P4D 800000003ca9d067 PUD 3ca9c067 PMD 0\n[  +0.000388] Oops: 0000 [#1] SMP PTI\n[  +0.000269] CPU: 1 PID: 3266 Comm: bash Not tainted 5.0.0+ #6\n[  +0.000346] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.fc28 04/01/2014\n[  +0.000472] RIP: 0010:register_bcache+0x1829/0x1990 [bcache]\n[  +0.000344] Code: b0 48 83 e8 50 48 81 fa e0 e1 10 c0 0f 84 a9 00 00 00 48 89 c6 48 89 ca 0f b7 ba 54 04 00 00 4c 8b 82 60 0c 00 00 85 ff 74 2f <49> 3b a8 98 09 00 00 74 4e 44 8d 47 ff 31 ff 49 c1 e0 03 eb 0d\n[  +0.000839] RSP: 0018:ffff92ee804cbd88 EFLAGS: 00010202\n[  +0.000328] RAX: ffffffffc010e190 RBX: ffff918b5c6b5000 RCX: ffff918b7d8e0000\n[  +0.000399] RDX: ffff918b7d8e0000 RSI: ffffffffc010e190 RDI: 0000000000000001\n[  +0.000398] RBP: ffff918b7d318340 R08: 0000000000000000 R09: ffffffffb9bd2d7a\n[  +0.000385] R10: ffff918b7eb253c0 R11: ffffb95980f51200 R12: ffffffffc010e1a0\n[  +0.000411] R13: fffffffffffffff2 R14: 000000000000000b R15: ffff918b7e232620\n[  +0.000384] FS:  00007f955bec2740(0000) GS:ffff918b7eb00000(0000) knlGS:0000000000000000\n[  +0.000420] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  +0.000801] CR2: 0000000000000998 CR3: 000000003cad6000 CR4: 00000000001406e0\n[  +0.000837] Call Trace:\n[  +0.000682]  ? _cond_resched+0x10/0x20\n[  +0.000691]  ? __kmalloc+0x131/0x1b0\n[  +0.000710]  kernfs_fop_write+0xfa/0x170\n[  +0.000733]  __vfs_write+0x2e/0x190\n[  +0.000688]  ? inode_security+0x10/0x30\n[  +0.000698]  ? selinux_file_permission+0xd2/0x120\n[  +0.000752]  ? security_file_permission+0x2b/0x100\n[  +0.000753]  vfs_write+0xa8/0x1a0\n[  +0.000676]  ksys_write+0x4d/0xb0\n[  +0.000699]  do_syscall_64+0x3a/0xf0\n[  +0.000692]  entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nSigned-off-by: Liang Chen <liangchen.linux@gmail.com>\nCc: stable@vger.kernel.org\nSigned-off-by: Coly Li <colyli@suse.de>\nSigned-off-by: Jens Axboe <axboe@kernel.dk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/5651075a1ce3ccc59690f72f32dac469f3e2e52c"},{"sha":"bef039b2419ea35f5acede56820b42e818cdcdcb","author":{"name":"Coly Li","email":"f873d2e1ca1a16c3419d71461d4bbaa0a7678f5d@suse.de"},"message":"bcache: never set KEY_PTRS of journal key to 0 in journal_reclaim()\n\ncommit 1bee2addc0c8470c8aaa65ef0599eeae96dd88bc upstream.\n\nIn journal_reclaim() ja->cur_idx of each cache will be update to\nreclaim available journal buckets. Variable 'int n' is used to count how\nmany cache is successfully reclaimed, then n is set to c->journal.key\nby SET_KEY_PTRS(). Later in journal_write_unlocked(), a for_each_cache()\nloop will write the jset data onto each cache.\n\nThe problem is, if all jouranl buckets on each cache is full, the\nfollowing code in journal_reclaim(),\n\n529 for_each_cache(ca, c, iter) {\n530       struct journal_device *ja = &ca->journal;\n531       unsigned int next = (ja->cur_idx + 1) % ca->sb.njournal_buckets;\n532\n533       /* No space available on this device */\n534       if (next == ja->discard_idx)\n535               continue;\n536\n537       ja->cur_idx = next;\n538       k->ptr[n++] = MAKE_PTR(0,\n539                         bucket_to_sector(c, ca->sb.d[ja->cur_idx]),\n540                         ca->sb.nr_this_dev);\n541 }\n542\n543 bkey_init(k);\n544 SET_KEY_PTRS(k, n);\n\nIf there is no available bucket to reclaim, the if() condition at line\n534 will always true, and n remains 0. Then at line 544, SET_KEY_PTRS()\nwill set KEY_PTRS field of c->journal.key to 0.\n\nSetting KEY_PTRS field of c->journal.key to 0 is wrong. Because in\njournal_write_unlocked() the journal data is written in following loop,\n\n649\tfor (i = 0; i < KEY_PTRS(k); i++) {\n650-671\t\tsubmit journal data to cache device\n672\t}\n\nIf KEY_PTRS field is set to 0 in jouranl_reclaim(), the journal data\nwon't be written to cache device here. If system crahed or rebooted\nbefore bkeys of the lost journal entries written into btree nodes, data\ncorruption will be reported during bcache reload after rebooting the\nsystem.\n\nIndeed there is only one cache in a cache set, there is no need to set\nKEY_PTRS field in journal_reclaim() at all. But in order to keep the\nfor_each_cache() logic consistent for now, this patch fixes the above\nproblem by not setting 0 KEY_PTRS of journal key, if there is no bucket\navailable to reclaim.\n\nSigned-off-by: Coly Li <colyli@suse.de>\nReviewed-by: Hannes Reinecke <hare@suse.com>\nCc: stable@vger.kernel.org\nSigned-off-by: Jens Axboe <axboe@kernel.dk>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":true,"url":"https://api.github.com/repos/BeastRoms-Devices/kernel_xiaomi_lavender/commits/bef039b2419ea35f5acede56820b42e818cdcdcb"}]}
{"actor":{"display_login":"mdeejay"}}