{"push_id":985742132,"size":202,"distinct_size":0,"ref":"refs/heads/4.3/upstream-updates","head":"49f9ae92af54217fd9821a7613342178893a72af","before":"849a2d3d9be31368559e6852cf64d749e6903818","commits":[{"sha":"7333f7d64093432c7653ec8c3b226c7c34e9b2fb","author":{"email":"55afd0fb1f1ce5f067f0822840bbfc35c48fdecb@m4x.org","name":"Nicolas Iooss"},"message":"crypto: crc32c-pclmul - use .rodata instead of .rotata\n\ncommit 97bce7e0b58dfc7d159ded329f57961868fb060b upstream.\n\nModule crc32c-intel uses a special read-only data section named .rotata.\nThis section is defined for K_table, and its name seems to be a spelling\nmistake for .rodata.\n\nFixes: 473946e674eb (\"crypto: crc32c-pclmul - Shrink K_table to 32-bit words\")\nSigned-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/7333f7d64093432c7653ec8c3b226c7c34e9b2fb"},{"sha":"c084696ae6b8a9f42007043b944ff0b845c797d2","author":{"email":"f6aa0246ff943bfa8602cdf60d40c481b38ed232@arm.linux.org.uk","name":"Russell King"},"message":"crypto: caam - fix non-block aligned hash calculation\n\ncommit c7556ff7e3e4f2747583bcc787f12ec9460ec3a6 upstream.\n\ncaam does not properly calculate the size of the retained state\nwhen non-block aligned hashes are requested - it uses the wrong\nbuffer sizes, which results in errors such as:\n\ncaam_jr 2102000.jr1: 40000501: DECO: desc idx 5: SGT Length Error. The descriptor is trying to read more data than is contained in the SGT table.\n\nWe end up here with:\n\nin_len 0x46 blocksize 0x40 last_bufsize 0x0 next_bufsize 0x6\nto_hash 0x40 ctx_len 0x28 nbytes 0x20\n\nwhich results in a job descriptor of:\n\njobdesc@889: ed03d918: b0861c08 3daa0080 f1400000 3d03d938\njobdesc@889: ed03d928: 00000068 f8400000 3cde2a40 00000028\n\nwhere the word at 0xed03d928 is the expected data size (0x68), and a\nscatterlist containing:\n\nsg@892: ed03d938: 00000000 3cde2a40 00000028 00000000\nsg@892: ed03d948: 00000000 3d03d100 00000006 00000000\nsg@892: ed03d958: 00000000 7e8aa700 40000020 00000000\n\n0x68 comes from 0x28 (the context size) plus the \"in_len\" rounded down\nto a block size (0x40).  in_len comes from 0x26 bytes of unhashed data\nfrom the previous operation, plus the 0x20 bytes from the latest\noperation.\n\nThe fixed version would create:\n\nsg@892: ed03d938: 00000000 3cde2a40 00000028 00000000\nsg@892: ed03d948: 00000000 3d03d100 00000026 00000000\nsg@892: ed03d958: 00000000 7e8aa700 40000020 00000000\n\nwhich replaces the 0x06 length with the correct 0x26 bytes of previously\nunhashed data.\n\nThis fixes a previous commit which erroneously \"fixed\" this due to a\nDMA-API bug report; that commit indicates that the bug was caused via a\ntest_ahash_pnum() function in the tcrypt module.  No such function has\never existed in the mainline kernel.  Given that the change in this\ncommit has been tested with DMA API debug enabled and shows no issue,\nI can only conclude that test_ahash_pnum() was triggering that bad\nbehaviour by CAAM.\n\nFixes: 7d5196aba3c8 (\"crypto: caam - Correct DMA unmap size in ahash_update_ctx()\")\nSigned-off-by: Russell King <rmk+kernel@arm.linux.org.uk>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/c084696ae6b8a9f42007043b944ff0b845c797d2"},{"sha":"a349da65d72708d63cd8a0c1303549ac98c3a957","author":{"email":"71255387a32c360dfbe6dfb7aaeb123bf1dc8cb6@kernel.org","name":"Jaegeuk Kim"},"message":"f2fs crypto: allocate buffer for decrypting filename\n\ncommit 569cf1876a32e574ba8a7fb825cd91bafd003882 upstream.\n\nWe got dentry pages from high_mem, and its address space directly goes into the\ndecryption path via f2fs_fname_disk_to_usr.\nBut, sg_init_one assumes the address is not from high_mem, so we can get this\npanic since it doesn't call kmap_high but kunmap_high is triggered at the end.\n\nkernel BUG at ../../../../../../kernel/mm/highmem.c:290!\nInternal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM\n...\n (kunmap_high+0xb0/0xb8) from [<c0114534>] (__kunmap_atomic+0xa0/0xa4)\n (__kunmap_atomic+0xa0/0xa4) from [<c035f028>] (blkcipher_walk_done+0x128/0x1ec)\n (blkcipher_walk_done+0x128/0x1ec) from [<c0366c24>] (crypto_cbc_decrypt+0xc0/0x170)\n (crypto_cbc_decrypt+0xc0/0x170) from [<c0367148>] (crypto_cts_decrypt+0xc0/0x114)\n (crypto_cts_decrypt+0xc0/0x114) from [<c035ea98>] (async_decrypt+0x40/0x48)\n (async_decrypt+0x40/0x48) from [<c032ca34>] (f2fs_fname_disk_to_usr+0x124/0x304)\n (f2fs_fname_disk_to_usr+0x124/0x304) from [<c03056fc>] (f2fs_fill_dentries+0xac/0x188)\n (f2fs_fill_dentries+0xac/0x188) from [<c03059c8>] (f2fs_readdir+0x1f0/0x300)\n (f2fs_readdir+0x1f0/0x300) from [<c0218054>] (vfs_readdir+0x90/0xb4)\n (vfs_readdir+0x90/0xb4) from [<c0218418>] (SyS_getdents64+0x64/0xcc)\n (SyS_getdents64+0x64/0xcc) from [<c0105ba0>] (ret_fast_syscall+0x0/0x30)\n\nReviewed-by: Chao Yu <chao2.yu@samsung.com>\nSigned-off-by: Jaegeuk Kim <jaegeuk@kernel.org>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/a349da65d72708d63cd8a0c1303549ac98c3a957"},{"sha":"d4f9756c6ad78cbb728549e1e0dd7afafd8069a6","author":{"email":"ef65de1c7be0aa837fe7b25ba9a7739905af6a55@gondor.apana.org.au","name":"Herbert Xu"},"message":"crypto: algif_hash - Only export and import on sockets with data\n\ncommit 4afa5f9617927453ac04b24b584f6c718dfb4f45 upstream.\n\nThe hash_accept call fails to work on sockets that have not received\nany data.  For some algorithm implementations it may cause crashes.\n\nThis patch fixes this by ensuring that we only export and import on\nsockets that have received data.\n\nReported-by: Harsh Jain <harshjain.prof@gmail.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nTested-by: Stephan Mueller <smueller@chronox.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/d4f9756c6ad78cbb728549e1e0dd7afafd8069a6"},{"sha":"08b8fa6165d4bbd4a0b2b330677974748eb8fc55","author":{"email":"ac7da5bc34fbda078ba4af5ef710d2a59a2316f5@intel.com","name":"Tadeusz Struk"},"message":"crypto: qat - don't use userspace pointer\n\ncommit 176155dac13f528e0a58c14dc322623219365d91 upstream.\n\nBugfix - don't dereference userspace pointer.\n\nSigned-off-by: Tadeusz Struk <tadeusz.struk@intel.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/08b8fa6165d4bbd4a0b2b330677974748eb8fc55"},{"sha":"9af08bfec330b387f7432aacfa2c189e5c3e8d1d","author":{"email":"aa743a0aaec8f7d7a1f01442503957f4d7a2d634@sigma-star.at","name":"David Gstir"},"message":"crypto: nx - Fix timing leak in GCM and CCM decryption\n\ncommit cb8affb55c7e64816f3effcd9b2fc3268c016fac upstream.\n\nUsing non-constant time memcmp() makes the verification of the authentication\ntag in the decrypt path vulnerable to timing attacks. Fix this by using\ncrypto_memneq() instead.\n\nSigned-off-by: David Gstir <david@sigma-star.at>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/9af08bfec330b387f7432aacfa2c189e5c3e8d1d"},{"sha":"1f8b52002e010be989eb2e02bd0c90b65bdb3683","author":{"email":"aa743a0aaec8f7d7a1f01442503957f4d7a2d634@sigma-star.at","name":"David Gstir"},"message":"crypto: talitos - Fix timing leak in ESP ICV verification\n\ncommit 79960943fdc114fd4583c9ab164b5c89da7aa601 upstream.\n\nUsing non-constant time memcmp() makes the verification of the authentication\ntag in the decrypt path vulnerable to timing attacks. Fix this by using\ncrypto_memneq() instead.\n\nSigned-off-by: David Gstir <david@sigma-star.at>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/1f8b52002e010be989eb2e02bd0c90b65bdb3683"},{"sha":"f15e5364441e892de6b3090c357b6947513b7a7a","author":{"email":"e7e312fea4c2c1aad2bb075d739111890e1ce08b@zx2c4.com","name":"Jason A. Donenfeld"},"message":"crypto: skcipher - Copy iv from desc even for 0-len walks\n\ncommit 70d906bc17500edfa9bdd8c8b7e59618c7911613 upstream.\n\nSome ciphers actually support encrypting zero length plaintexts. For\nexample, many AEAD modes support this. The resulting ciphertext for\nthose winds up being only the authentication tag, which is a result of\nthe key, the iv, the additional data, and the fact that the plaintext\nhad zero length. The blkcipher constructors won't copy the IV to the\nright place, however, when using a zero length input, resulting in\nsome significant problems when ciphers call their initialization\nroutines, only to find that the ->iv parameter is uninitialized. One\nsuch example of this would be using chacha20poly1305 with a zero length\ninput, which then calls chacha20, which calls the key setup routine,\nwhich eventually OOPSes due to the uninitialized ->iv member.\n\nSigned-off-by: Jason A. Donenfeld <Jason@zx2c4.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/f15e5364441e892de6b3090c357b6947513b7a7a"},{"sha":"e3d57c5b7136a657d46cca666ffedf1f0d4f7880","author":{"email":"ef65de1c7be0aa837fe7b25ba9a7739905af6a55@gondor.apana.org.au","name":"Herbert Xu"},"message":"crypto: algif_skcipher - Use new skcipher interface\n\ncommit 0d96e4bab2855a030077cc695a3563fd7cb0e7d8 upstream.\n\nThis patch replaces uses of ablkcipher with the new skcipher\ninterface.\n\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nTested-by: <smueller@chronox.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/e3d57c5b7136a657d46cca666ffedf1f0d4f7880"},{"sha":"f7b03cd741dc1f87936b58e841a2555c6a7deb00","author":{"email":"4df73f6d53a690d105cd8130f057950f3b2f7aac@gmail.com","name":"LABBE Corentin"},"message":"crypto: sun4i-ss - add missing statesize\n\ncommit 4f9ea86604e3ba64edd2817795798168fbb3c1a6 upstream.\n\nsun4i-ss implementaton of md5/sha1 is via ahash algorithms.\nCommit 8996eafdcbad (\"crypto: ahash - ensure statesize is non-zero\")\nmade impossible to load them without giving statesize. This patch\nspecifiy statesize for sha1 and md5.\n\nFixes: 6298e948215f (\"crypto: sunxi-ss - Add Allwinner Security System crypto accelerator\")\nTested-by: Chen-Yu Tsai <wens@csie.org>\nSigned-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>\nSigned-off-by: Herbert Xu <herbert@gondor.apana.org.au>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/f7b03cd741dc1f87936b58e841a2555c6a7deb00"},{"sha":"f6d45a66d0c5a4c5747df0b8a6eebaaa1126b56e","author":{"email":"b0d1e9e4a4e27620745ff49be9000da3174a4cc6@suse.de","name":"Hannes Reinecke"},"message":"block: Always check queue limits for cloned requests\n\ncommit bf4e6b4e757488dee1b6a581f49c7ac34cd217f8 upstream.\n\nWhen a cloned request is retried on other queues it always needs\nto be checked against the queue limits of that queue.\nOtherwise the calculations for nr_phys_segments might be wrong,\nleading to a crash in scsi_init_sgtable().\n\nTo clarify this the patch renames blk_rq_check_limits()\nto blk_cloned_rq_check_limits() and removes the symbol\nexport, as the new function should only be used for\ncloned requests and never exported.\n\nCc: Mike Snitzer <snitzer@redhat.com>\nCc: Ewan Milne <emilne@redhat.com>\nCc: Jeff Moyer <jmoyer@redhat.com>\nSigned-off-by: Hannes Reinecke <hare@suse.de>\nFixes: e2a60da74 (\"block: Clean up special command handling logic\")\nAcked-by: Mike Snitzer <snitzer@redhat.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/f6d45a66d0c5a4c5747df0b8a6eebaaa1126b56e"},{"sha":"7435c303d7e85e47738282becc3c8e15b4b02c06","author":{"email":"85e533f2e78486213c4d69f71462342ec0c62734@redhat.com","name":"Mike Snitzer"},"message":"dm btree: fix leak of bufio-backed block in btree_split_sibling error path\n\ncommit 30ce6e1cc5a0f781d60227e9096c86e188d2c2bd upstream.\n\nThe block allocated at the start of btree_split_sibling() is never\nreleased if later insert_at() fails.\n\nFix this by releasing the previously allocated bufio block using\nunlock_block().\n\nReported-by: Mikulas Patocka <mpatocka@redhat.com>\nSigned-off-by: Mike Snitzer <snitzer@redhat.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/7435c303d7e85e47738282becc3c8e15b4b02c06"},{"sha":"c854fc16ba94297c971fc93aebdfded3f543259e","author":{"email":"74ca843d8fa59bb3c472e2551935d3d1dafb5aea@variantweb.net","name":"Seth Jennings"},"message":"drivers/base/memory.c: prohibit offlining of memory blocks with missing sections\n\ncommit 26bbe7ef6d5cdc7ec08cba6d433fca4060f258f3 upstream.\n\nCommit bdee237c0343 (\"x86: mm: Use 2GB memory block size on large-memory\nx86-64 systems\") and 982792c782ef (\"x86, mm: probe memory block size for\ngeneric x86 64bit\") introduced large block sizes for x86.  This made it\npossible to have multiple sections per memory block where previously,\nthere was a only every one section per block.\n\nSince blocks consist of contiguous ranges of section, there can be holes\nin the blocks where sections are not present.  If one attempts to\noffline such a block, a crash occurs since the code is not designed to\ndeal with this.\n\nThis patch is a quick fix to gaurd against the crash by not allowing\nblocks with non-present sections to be offlined.\n\nAddresses https://bugzilla.kernel.org/show_bug.cgi?id=107781\n\nSigned-off-by: Seth Jennings <sjennings@variantweb.net>\nReported-by: Andrew Banman <abanman@sgi.com>\nCc: Daniel J Blueman <daniel@numascale.com>\nCc: Yinghai Lu <yinghai@kernel.org>\nCc: Greg KH <greg@kroah.com>\nCc: Russ Anderson <rja@sgi.com>\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":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/c854fc16ba94297c971fc93aebdfded3f543259e"},{"sha":"ecf177df3b63d88f6fb5e10683004f50b6dfe116","author":{"email":"3576fcbd7ffa3776a92ac17fc90ba38e23f75e95@ce.jp.nec.com","name":"Junichi Nomura"},"message":"block: ensure to split after potentially bouncing a bio\n\ncommit 23688bf4f830a89866fd0ed3501e342a7360fe4f upstream.\n\nblk_queue_bio() does split then bounce, which makes the segment\ncounting based on pages before bouncing and could go wrong. Move\nthe split to after bouncing, like we do for blk-mq, and the we\nfix the issue of having the bio count for segments be wrong.\n\nFixes: 54efd50bfd87 (\"block: make generic_make_request handle arbitrarily sized bios\")\nTested-by: Artem S. Tashkinov <t.artem@lycos.com>\nSigned-off-by: Jens Axboe <axboe@fb.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/ecf177df3b63d88f6fb5e10683004f50b6dfe116"},{"sha":"368f974ce05b21eae9b5bf8edaf6940079d3dc91","author":{"email":"cc958843532c615cbd4920e868f78c7985331a5a@primarydata.com","name":"Trond Myklebust"},"message":"NFSv4.1/pnfs: Fixup an lo->plh_block_lgets imbalance in layoutreturn\n\ncommit 1a093ceb053832c25b92f3cf26b957543c7baf9b upstream.\n\nSince commit 2d8ae84fbc32, nothing is bumping lo->plh_block_lgets in the\nlayoutreturn path, so it should not be touched in nfs4_layoutreturn_release\neither.\n\nFixes: 2d8ae84fbc32 (\"NFSv4.1/pnfs: Remove redundant lo->plh_block_lgets...\")\nSigned-off-by: Trond Myklebust <trond.myklebust@primarydata.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/368f974ce05b21eae9b5bf8edaf6940079d3dc91"},{"sha":"5b419b909db57ce8bc06e1504086067484fef90e","author":{"email":"a00ab39bde3bb6a3a96371eaec927260697da3a5@oracle.com","name":"Tariq Saeed"},"message":"ocfs2: NFS hangs in __ocfs2_cluster_lock due to race with ocfs2_unblock_lock\n\ncommit b1b1e15ef6b80facf76d6757649dfd7295eda29f upstream.\n\nNFS on a 2 node ocfs2 cluster each node exporting dir.  The lock causing\nthe hang is the global bit map inode lock.  Node 1 is master, has the\nlock granted in PR mode; Node 2 is in the converting list (PR -> EX).\nThere are no holders of the lock on the master node so it should\ndownconvert to NL and grant EX to node 2 but that does not happen.\nBLOCKED + QUEUED in lock res are set and it is on osb blocked list.\nThreads are waiting in __ocfs2_cluster_lock on BLOCKED.  One thread\nwants EX, rest want PR.  So it is as though the downconvert thread needs\nto be kicked to complete the conv.\n\nThe hang is caused by an EX req coming into __ocfs2_cluster_lock on the\nheels of a PR req after it sets BUSY (drops l_lock, releasing EX\nthread), forcing the incoming EX to wait on BUSY without doing anything.\nPR has called ocfs2_dlm_lock, which sets the node 1 lock from NL -> PR,\nqueues ast.\n\nAt this time, upconvert (PR ->EX) arrives from node 2, finds conflict\nwith node 1 lock in PR, so the lock res is put on dlm thread's dirty\nlistt.\n\nAfter ret from ocf2_dlm_lock, PR thread now waits behind EX on BUSY till\nawoken by ast.\n\nNow it is dlm_thread that serially runs dlm_shuffle_lists, ast, bast, in\nthat order.  dlm_shuffle_lists ques a bast on behalf of node 2 (which\nwill be run by dlm_thread right after the ast).  ast does its part, sets\nUPCONVERT_FINISHING, clears BUSY and wakes its waiters.  Next,\ndlm_thread runs bast.  It sets BLOCKED and kicks dc thread.  dc thread\nruns ocfs2_unblock_lock, but since UPCONVERT_FINISHING set, skips doing\nanything and reques.\n\nInside of __ocfs2_cluster_lock, since EX has been waiting on BUSY ahead\nof PR, it wakes up first, finds BLOCKED set and skips doing anything but\nclearing UPCONVERT_FINISHING (which was actually \"meant\" for the PR\nthread), and this time waits on BLOCKED.  Next, the PR thread comes out\nof wait but since UPCONVERT_FINISHING is not set, it skips updating the\nl_ro_holders and goes straight to wait on BLOCKED.  So there, we have a\nhang! Threads in __ocfs2_cluster_lock wait on BLOCKED, lock res in osb\nblocked list.  Only when dc thread is awoken, it will run\nocfs2_unblock_lock and things will unhang.\n\nOne way to fix this is to wake the dc thread on the flag after clearing\nUPCONVERT_FINISHING\n\nOrabug: 20933419\nSigned-off-by: Tariq Saeed <tariq.x.saeed@oracle.com>\nSigned-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>\nReviewed-by: Wengang Wang <wen.gang.wang@oracle.com>\nReviewed-by: Mark Fasheh <mfasheh@suse.de>\nCc: Joel Becker <jlbec@evilplan.org>\nCc: Junxiao Bi <junxiao.bi@oracle.com>\nReviewed-by: Joseph Qi <joseph.qi@huawei.com>\nCc: Eric Ren <zren@suse.com>\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":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/5b419b909db57ce8bc06e1504086067484fef90e"},{"sha":"e52edae1fe3b60307d460a5ccb9a3403e14d8bc9","author":{"email":"b3e8ff7ac1c7e75661e16152a5dce1ff36a3e140@adirat.com","name":"Ioan-Adrian Ratiu"},"message":"HID: usbhid: fix recursive deadlock\n\ncommit e470127e9606b1fa151c4184243e61296d1e0c0f upstream.\n\nThe critical section protected by usbhid->lock in hid_ctrl() is too\nbig and because of this it causes a recursive deadlock. \"Too big\" means\nthe case statement and the call to hid_input_report() do not need to be\nprotected by the spinlock (no URB operations are done inside them).\n\nThe deadlock happens because in certain rare cases drivers try to grab\nthe lock while handling the ctrl irq which grabs the lock before them\nas described above. For example newer wacom tablets like 056a:033c try\nto reschedule proximity reads from wacom_intuos_schedule_prox_event()\ncalling hid_hw_request() -> usbhid_request() -> usbhid_submit_report()\nwhich tries to grab the usbhid lock already held by hid_ctrl().\n\nThere are two ways to get out of this deadlock:\n    1. Make the drivers work \"around\" the ctrl critical region, in the\n    wacom case for ex. by delaying the scheduling of the proximity read\n    request itself to a workqueue.\n    2. Shrink the critical region so the usbhid lock protects only the\n    instructions which modify usbhid state, calling hid_input_report()\n    with the spinlock unlocked, allowing the device driver to grab the\n    lock first, finish and then grab the lock afterwards in hid_ctrl().\n\nThis patch implements the 2nd solution.\n\nSigned-off-by: Ioan-Adrian Ratiu <adi@adirat.com>\nSigned-off-by: Jiri Kosina <jkosina@suse.cz>\nSigned-off-by: Jason Gerecke <jason.gerecke@wacom.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/e52edae1fe3b60307d460a5ccb9a3403e14d8bc9"},{"sha":"788e6ddf4d9816185d857c34b763d26945bdcd4b","author":{"email":"4596b3305151c7ee743192a95d394341e3d3b644@suse.de","name":"Takashi Iwai"},"message":"ALSA: hda - Implement loopback control switch for Realtek and other codecs\n\ncommit e7fdd52779a6c2b49d457f452296a77c8cffef6a upstream.\n\nMany codecs, typically found on Realtek codecs, have the analog\nloopback path merged to the secondary input of the middle of the\noutput paths.  Currently, we don't offer the dynamic switching in such\nconfiguration but let each loopback path mute by itself.\n\nThis should work well in theory, but in reality, we often see that\nsuch a dead loopback path causes some background noises even if all\nthe elements get muted.  Such a problem has been fixed by adding the\nquirk accordingly to disable aamix, and it's the right fix, per se.\nThe only problem is that it's not so trivial to achieve it; user needs\nto pass a hint string via patch module option or sysfs.\n\nThis patch gives a bit improvement on the situation: it adds \"Loopback\nMixing\" control element for such codecs like other codecs (e.g. IDT or\nVIA codecs) with the individual loopback paths.  User can turn on/off\nthe loopback path simply via a mixer app.\n\nFor keeping the compatibility, the loopback is still enabled on these\ncodecs.  But user can try to turn it off if experiencing a suspicious\nbackground or click noise on the fly, then build a static fixup later\nonce after the problem is addressed.\n\nOther than the addition of the loopback enable/disablement control,\nthere should be no changes.\n\nSigned-off-by: Takashi Iwai <tiwai@suse.de>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/788e6ddf4d9816185d857c34b763d26945bdcd4b"},{"sha":"a793d2b5bc0b1d6dcac2e2ad1d5f39bd47a6a234","author":{"email":"20b70f0af00562e63758b9ee42012ecc96c58590@redhat.com","name":"Oleg Nesterov"},"message":"proc: actually make proc_fd_permission() thread-friendly\n\ncommit 54708d2858e79a2bdda10bf8a20c80eb96c20613 upstream.\n\nThe commit 96d0df79f264 (\"proc: make proc_fd_permission() thread-friendly\")\nfixed the access to /proc/self/fd from sub-threads, but introduced another\nproblem: a sub-thread can't access /proc/<tid>/fd/ or /proc/thread-self/fd\nif generic_permission() fails.\n\nChange proc_fd_permission() to check same_thread_group(pid_task(), current).\n\nFixes: 96d0df79f264 (\"proc: make proc_fd_permission() thread-friendly\")\nReported-by: \"Jin, Yihua\" <yihua.jin@intel.com>\nSigned-off-by: Oleg Nesterov <oleg@redhat.com>\nCc: \"Eric W. Biederman\" <ebiederm@xmission.com>\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":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/a793d2b5bc0b1d6dcac2e2ad1d5f39bd47a6a234"},{"sha":"bffecd3844604aa095ed473d75f26028de5202f5","author":{"email":"f2c659f01951776204a6c5b902787d9019fbeebd@arndb.de","name":"Arnd Bergmann"},"message":"remoteproc: avoid stack overflow in debugfs file\n\ncommit 92792e48e2ae6051af30468a87994b5432da2f06 upstream.\n\nRecent gcc versions warn about reading from a negative offset of\nan on-stack array:\n\ndrivers/remoteproc/remoteproc_debugfs.c: In function 'rproc_recovery_write':\ndrivers/remoteproc/remoteproc_debugfs.c:167:9: warning: 'buf[4294967295u]' may be used uninitialized in this function [-Wmaybe-uninitialized]\n\nI don't see anything in sys_write() that prevents us from\nbeing called with a zero 'count' argument, so we should\nadd an extra check in rproc_recovery_write() to prevent the\naccess and avoid the warning.\n\nSigned-off-by: Arnd Bergmann <arnd@arndb.de>\nFixes: 2e37abb89a2e (\"remoteproc: create a 'recovery' debugfs entry\")\nSigned-off-by: Ohad Ben-Cohen <ohad@wizery.com>\nSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>","distinct":false,"url":"https://api.github.com/repos/zen-kernel/zen-kernel/commits/bffecd3844604aa095ed473d75f26028de5202f5"}]}