- 14 Mar, 2019 40 commits
-
-
Finn Thain authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 296dcc40 ] When the block device is opened with FMODE_EXCL, ref_count is set to -1. This value doesn't get reset when the device is closed which means the device cannot be opened again. Fix this by checking for refcount <= 0 in the release method. Reported-and-tested-by:
Stan Johnson <userm57@yahoo.com> Fixes: 1da177e4 ("Linux-2.6.12-rc2") Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Wenwen Wang authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 093c4821 ] In probe_gdrom(), the buffer pointed by 'gd.cd_info' is allocated through kzalloc() and is used to hold the information of the gdrom device. To register and unregister the device, the pointer 'gd.cd_info' is passed to the functions register_cdrom() and unregister_cdrom(), respectively. However, this buffer is not freed after it is used, which can cause a memory leak bug. This patch simply frees the buffer 'gd.cd_info' in exit_gdrom() to fix the above issue. Signed-off-by:
Wenwen Wang <wang6495@umn.edu> Signed-off-by:
-
Jia-Ju Bai authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 7418e652 ] In drivers/isdn/hisax/hfc_pci.c, the functions hfcpci_interrupt() and HFCPCI_l1hw() may be concurrently executed. HFCPCI_l1hw() line 1173: if (!cs->tx_skb) hfcpci_interrupt() line 942: spin_lock_irqsave(); line 1066: dev_kfree_skb_irq(cs->tx_skb); Thus, a possible concurrency use-after-free bug may occur in HFCPCI_l1hw(). To fix these bugs, the calls to spin_lock_irqsave() and spin_unlock_irqrestore() are added in HFCPCI_l1hw(), to protect the access to cs->tx_skb. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Junxiao Bi authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 70306d9d ] For sync io read in ocfs2_read_blocks_sync(), first clear bh uptodate flag and submit the io, second wait io done, last check whether bh uptodate, if not return io error. If two sync io for the same bh were issued, it could be the first io done and set uptodate flag, but just before check that flag, the second io came in and cleared uptodate, then ocfs2_read_blocks_sync() for the first io will return IO error. Indeed it's not necessary to clear uptodate flag, as the io end handler end_buffer_read_sync() will set or clear it based on io succeed or failed. The following message was found from a nfs server but the underlying storage returned no error. [4106438.567376] (nfsd,7146,3):ocfs2_get_suballoc_slot_bit:2780 ERROR: read block 1238823695 failed -5 [4106438.567569] (nfsd,7146,3):ocfs2_get_suballoc_slot_bit:2812 ERROR: status = -5 [4106438.567611] (nfsd,7146,3):ocfs2_test_inode_bit:2894 ERROR: get alloc slot and bit failed -5 [4106438.567643] (nfsd,7146,3):ocfs2_test_inode_bit:2932 ERROR: status = -5 [4106438.567675] (nfsd,7146,3):ocfs2_get_dentry:94 ERROR: test inode bit failed -5 Same issue in non sync read ocfs2_read_blocks(), fixed it as well. Link: http://lkml.kernel.org/r/20181121020023.3034-4-junxiao.bi@oracle.comSigned-off-by:
Junxiao Bi <junxiao.bi@oracle.com> Reviewed-by:
Changwei Ge <ge.changwei@h3c.com> Reviewed-by:
Yiwen Jiang <jiangyiwen@huawei.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Joseph Qi <jiangqi903@gmail.com> Cc: Jun Piao <piaojun@huawei.com> Cc: Mark Fasheh <mfasheh@versity.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Marc Zyngier authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 67a28de4 ] Running something like: decodecode vmlinux . leads to interested results where not only the leading "." gets stripped from the displayed paths, but also anywhere in the string, displaying something like: kvm_vcpu_check_block (arch/arm64/kvm/virt/kvm/kvm_mainc:2141) which doesn't help further processing. Fix it by only stripping the base path if it is a prefix of the path. Link: http://lkml.kernel.org/r/20181210174659.31054-3-marc.zyngier@arm.comSigned-off-by:
Marc Zyngier <marc.zyngier@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Kangjie Lu authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 26fd962b ] niu_pci_eeprom_read() may fail, so we should check its return value before using the read data. Signed-off-by:
Kangjie Lu <kjlu@umn.edu> Acked-by:
Shannon Nelson <shannon.lee.nelson@gmail.com> Signed-off-by:
-
Anton Ivanov authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 8892d854 ] Changing protection is a very high cost operation in UML because in addition to an extra syscall it also interrupts mmap merge sequences generated by the tlb. While the condition is not particularly common it is worth avoiding. Signed-off-by:
Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Ronnie Sahlberg authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 59a63e47 ] RHBZ: 1021460 There is an issue where when multiple threads open/close the same directory ntwrk_buf_start might end up being NULL, causing the call to smbCalcSize later to oops with a NULL deref. The real bug is why this happens and why this can become NULL for an open cfile, which should not be allowed. This patch tries to avoid a oops until the time when we fix the underlying issue. Signed-off-by:
Ronnie Sahlberg <lsahlber@redhat.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 5ac93f80 ] Clang warns when one enumerated type is implicitly converted to another: drivers/crypto/ux500/hash/hash_core.c:169:4: warning: implicit conversion from enumeration type 'enum dma_data_direction' to different enumeration type 'enum dma_transfer_direction' [-Wenum-conversion] direction, DMA_CTRL_ACK | DMA_PREP_INTERRUPT); ^~~~~~~~~ 1 warning generated. dmaengine_prep_slave_sg expects an enum from dma_transfer_direction. We know that the only direction supported by this function is DMA_TO_DEVICE because of the check at the top of this function so we can just use the equivalent value from dma_transfer_direction. DMA_TO_DEVICE = DMA_MEM_TO_DEV = 1 Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 9d880c59 ] Clang warns when one enumerated type is implicitly converted to another: drivers/crypto/ux500/cryp/cryp_core.c:559:5: warning: implicit conversion from enumeration type 'enum dma_data_direction' to different enumeration type 'enum dma_transfer_direction' [-Wenum-conversion] direction, DMA_CTRL_ACK); ^~~~~~~~~ drivers/crypto/ux500/cryp/cryp_core.c:583:5: warning: implicit conversion from enumeration type 'enum dma_data_direction' to different enumeration type 'enum dma_transfer_direction' [-Wenum-conversion] direction, ^~~~~~~~~ 2 warnings generated. dmaengine_prep_slave_sg expects an enum from dma_transfer_direction. Because we know the value of the dma_data_direction enum from the switch statement, we can just use the proper value from dma_transfer_direction so there is no more conversion. DMA_TO_DEVICE = DMA_MEM_TO_DEV = 1 DMA_FROM_DEVICE = DMA_DEV_TO_MEM = 2 Signed-off-by:
-
Michael Ellerman authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 0464ed24 ] Currently seq_buf_puts() will happily create a non null-terminated string for you in the buffer. This is particularly dangerous if the buffer is on the stack. For example: char buf[8]; char secret = "secret"; struct seq_buf s; seq_buf_init(&s, buf, sizeof(buf)); seq_buf_puts(&s, "foo"); printk("Message is %s\n", buf); Can result in: Message is fooªªªªªsecret We could require all users to memset() their buffer to zero before use. But that seems likely to be forgotten and lead to bugs. Instead we can change seq_buf_puts() to always leave the buffer in a null-terminated state. The only downside is that this makes the buffer 1 character smaller for seq_buf_puts(), but that seems like a good trade off. Link: http://lkml.kernel.org/r/20181019042109.8064-1-mpe@ellerman.id.auAcked-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Kangjie Lu authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 9aa3aa15 ] In lm80_probe(), if lm80_read_value() fails, it returns a negative error number which is stored to data->fan[f_min] and will be further used. We should avoid using the data if the read fails. The fix checks if lm80_read_value() fails, and if so, returns with the error number. Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Kangjie Lu authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit c9c63915 ] If lm80_read_value() fails, it returns a negative number instead of the correct read data. Therefore, we should avoid using the data if it fails. The fix checks if lm80_read_value() fails, and if so, returns with the error number. Signed-off-by:
-
Chris Perl authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 594d1644 ] This patch removes the check from nfs_compare_mount_options to see if a `sec' option was passed for the current mount before comparing auth flavors and instead just always compares auth flavors. Consider the following scenario: You have a server with the address 192.168.1.1 and two exports /export/a and /export/b. The first export supports `sys' and `krb5' security, the second just `sys'. Assume you start with no mounts from the server. The following results in EIOs being returned as the kernel nfs client incorrectly thinks it can share the underlying `struct nfs_server's: $ mkdir /tmp/{a,b} $ sudo mount -t nfs -o vers=3,sec=krb5 192.168.1.1:/export/a /tmp/a $ sudo mount -t nfs -o vers=3 192.168.1.1:/export/b /tmp/b $ df >/dev/null df: ‘/tmp/b’: Input/output error Signed-off-by:
Chris Perl <cperl@janestreet.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit e87555e5 ] AMD doesn't seem to implement MSR_IA32_MCG_EXT_CTL and svm code in kvm knows nothing about it, however, this MSR is among emulated_msrs and thus returned with KVM_GET_MSR_INDEX_LIST. The consequent KVM_GET_MSRS, of course, fails. Report the MSR as unsupported to not confuse userspace. Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
Radim Krčmář <rkrcmar@redhat.com> Signed-off-by:
-
Noralf Trønnes authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 2122b405 ] When unregistering fbdev using unregister_framebuffer(), any bound console will unbind automatically. This is working fine if this is the only framebuffer, resulting in a switch to the dummy console. However if there is a fb0 and I unregister fb1 having a bound console, I eventually get a crash. The fastest way for me to trigger the crash is to do a reboot, resulting in this splat: [ 76.478825] WARNING: CPU: 0 PID: 527 at linux/kernel/workqueue.c:1442 __queue_work+0x2d4/0x41c [ 76.478849] Modules linked in: raspberrypi_hwmon gpio_backlight backlight bcm2835_rng rng_core [last unloaded: tinydrm] [ 76.478916] CPU: 0 PID: 527 Comm: systemd-udevd Not tainted 4.20.0-rc4+ #4 [ 76.478933] Hardware name: BCM2835 [ 76.478949] Backtrace: [ 76.478995] [<c010d388>] (dump_backtrace) from [<c010d670>] (show_stack+0x20/0x24) [ 76.479022] r6:00000000 r5:c0bc73be r4:00000000 r3:6fb5bf81 [ 76.479060] [<c010d650>] (show_stack) from [<c08e82f4>] (dump_stack+0x20/0x28) [ 76.479102] [<c08e82d4>] (dump_stack) from [<c0120070>] (__warn+0xec/0x12c) [ 76.479134] [<c011ff84>] (__warn) from [<c01201e4>] (warn_slowpath_null+0x4c/0x58) [ 76.479165] r9:c0eb6944 r8:00000001 r7:c0e927f8 r6:c0bc73be r5:000005a2 r4:c0139e84 [ 76.479197] [<c0120198>] (warn_slowpath_null) from [<c0139e84>] (__queue_work+0x2d4/0x41c) [ 76.479222] r6:d7666a00 r5:c0e918ee r4:dbc4e700 [ 76.479251] [<c0139bb0>] (__queue_work) from [<c013a02c>] (queue_work_on+0x60/0x88) [ 76.479281] r10:c0496bf8 r9:00000100 r8:c0e92ae0 r7:00000001 r6:d9403700 r5:d7666a00 [ 76.479298] r4:20000113 [ 76.479348] [<c0139fcc>] (queue_work_on) from [<c0496c28>] (cursor_timer_handler+0x30/0x54) [ 76.479374] r7:d8a8fabc r6:c0e08088 r5:d8afdc5c r4:d8a8fabc [ 76.479413] [<c0496bf8>] (cursor_timer_handler) from [<c0178744>] (call_timer_fn+0x100/0x230) [ 76.479435] r4:c0e9192f r3:d758a340 [ 76.479465] [<c0178644>] (call_timer_fn) from [<c0178980>] (expire_timers+0x10c/0x12c) [ 76.479495] r10:40000000 r9:c0e9192f r8:c0e92ae0 r7:d8afdccc r6:c0e19280 r5:c0496bf8 [ 76.479513] r4:d8a8fabc [ 76.479541] [<c0178874>] (expire_timers) from [<c0179630>] (run_timer_softirq+0xa8/0x184) [ 76.479570] r9:00000001 r8:c0e19280 r7:00000000 r6:c0e08088 r5:c0e1a3e0 r4:c0e19280 [ 76.479603] [<c0179588>] (run_timer_softirq) from [<c0102404>] (__do_softirq+0x1ac/0x3fc) [ 76.479632] r10:c0e91680 r9:d8afc020 r8:0000000a r7:00000100 r6:00000001 r5:00000002 [ 76.479650] r4:c0eb65ec [ 76.479686] [<c0102258>] (__do_softirq) from [<c0124d10>] (irq_exit+0xe8/0x168) [ 76.479716] r10:d8d1a9b0 r9:d8afc000 r8:00000001 r7:d949c000 r6:00000000 r5:c0e8b3f0 [ 76.479734] r4:00000000 [ 76.479764] [<c0124c28>] (irq_exit) from [<c016b72c>] (__handle_domain_irq+0x94/0xb0) [ 76.479793] [<c016b698>] (__handle_domain_irq) from [<c01021dc>] (bcm2835_handle_irq+0x3c/0x48) [ 76.479823] r8:d8afdebc r7:d8afddfc r6:ffffffff r5:c0e089f8 r4:d8afddc8 r3:d8afddc8 [ 76.479851] [<c01021a0>] (bcm2835_handle_irq) from [<c01019f0>] (__irq_svc+0x70/0x98) The problem is in the console rebinding in fbcon_fb_unbind(). It uses the virtual console index as the new framebuffer index to bind the console(s) to. The correct way is to use the con2fb_map lookup table to find the framebuffer index. Fixes: cfafca80 ("fbdev: fbcon: console unregistration from unregister_framebuffer") Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Mikulas Patocka <mpatocka@redhat.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Peter Rosin authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit f75df8d4 ] Blitting an image with "negative" offsets is not working since there is no clipping. It hopefully just crashes. For the bootup logo, there is protection so that blitting does not happen as the image is drawn further and further to the right (ROTATE_UR) or further and further down (ROTATE_CW). There is however no protection when drawing in the opposite directions (ROTATE_UD and ROTATE_CCW). Add back this protection. The regression is 20-odd years old but the mindless warning-killing mentality displayed in commit 34bdb666 ("fbdev: fbmem: remove positive test on unsigned values") is also to blame, methinks. Fixes: 448d4797 ("fbdev: fb_do_show_logo() updates") Signed-off-by:
Peter Rosin <peda@axentia.se> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Fabian Frederick <ffrederick@users.sourceforge.net> Cc: Geert Uytterhoeven <geert+renesas@glider.be> cc: Geoff Levand <geoff@infradead.org> Cc: James Simmons <jsimmons@users.sf.net> Signed-off-by:
-
Alexey Khoroshilov authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit fdac7513 ] clps711x_fb_probe() increments refcnt of disp device node by of_parse_phandle() and leaves it undecremented on both successful and error paths. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Cc: Alexander Shiyan <shc_work@mail.ru> Signed-off-by:
-
Nathan Chancellor authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit a52c5a16 ] There are several warnings from Clang about no case statement matching the constant 0: In file included from drivers/block/drbd/drbd_receiver.c:48: In file included from drivers/block/drbd/drbd_int.h:48: In file included from ./include/linux/drbd_genl_api.h:54: In file included from ./include/linux/genl_magic_struct.h:236: ./include/linux/drbd_genl.h:321:1: warning: no case matching constant switch condition '0' GENL_struct(DRBD_NLA_HELPER, 24, drbd_helper_info, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/genl_magic_struct.h:220:10: note: expanded from macro 'GENL_struct' switch (0) { ^ Silence this warning by adding a 'case 0:' statement. Additionally, adjust the alignment of the statements in the ct_assert_unique macro to avoid a checkpatch warning. This solution was originally sent by Arnd Bergmann with a default case statement: https://lore.kernel.org/patchwork/patch/756723/ Link: https://github.com/ClangBuiltLinux/linux/issues/43Suggested-by:
Lars Ellenberg <lars.ellenberg@linbit.com> Signed-off-by:
-
Lars Ellenberg authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 9848b6dd ] If you try to promote a Secondary while connected to a Primary and allow-two-primaries is NOT set, we will wait for "ping-timeout" to give this node a chance to detect a dead primary, in case the cluster manager noticed faster than we did. But if we then are *still* connected to a Primary, we fail (after an additional timeout of ping-timout). This change skips the spurious second timeout. Most people won't notice really, since "ping-timeout" by default is half a second. But in some installations, ping-timeout may be 10 or 20 seconds or more, and spuriously delaying the error return becomes annoying. Signed-off-by:
-
Lars Ellenberg authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit b17b5960 ] With "on-no-data-accessible suspend-io", DRBD requires the next attach or connect to be to the very same data generation uuid tag it lost last. If we first lost connection to the peer, then later lost connection to our own disk, we would usually refuse to re-connect to the peer, because it presents the wrong data set. However, if the peer first connects without a disk, and then attached its disk, we accepted that same wrong data set, which would be "unexpected" by any user of that DRBD and cause "undefined results" (read: very likely data corruption). The fix is to forcefully disconnect as soon as we notice that the peer attached to the "wrong" dataset. Signed-off-by:
-
Roland Kammerer authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit d29e89e3 ] So far there was the possibility that we called genlmsg_new(GFP_NOIO)/mutex_lock() while holding an rcu_read_lock(). This included cases like: drbd_sync_handshake (acquire the RCU lock) drbd_asb_recover_1p drbd_khelper drbd_bcast_event genlmsg_new(GFP_NOIO) --> may sleep drbd_sync_handshake (acquire the RCU lock) drbd_asb_recover_1p drbd_khelper notify_helper genlmsg_new(GFP_NOIO) --> may sleep drbd_sync_handshake (acquire the RCU lock) drbd_asb_recover_1p drbd_khelper notify_helper mutex_lock --> may sleep While using GFP_ATOMIC whould have been possible in the first two cases, the real fix is to narrow the rcu_read_lock. Reported-by:
Jia-Ju Bai <baijiaju1990@163.com> Reviewed-by:
Roland Kammerer <roland.kammerer@linbit.com> Signed-off-by:
-
Jia-Ju Bai authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 4f68ef64 ] The function cw1200_bss_info_changed() and cw1200_hw_scan() can be concurrently executed. The two functions both access a possible shared variable "frame.skb". This shared variable is freed by dev_kfree_skb() in cw1200_upload_beacon(), which is called by cw1200_bss_info_changed(). The free operation is protected by a mutex lock "priv->conf_mutex" in cw1200_bss_info_changed(). In cw1200_hw_scan(), this shared variable is accessed without the protection of the mutex lock "priv->conf_mutex". Thus, concurrency use-after-free bugs may occur. To fix these bugs, the original calls to mutex_lock(&priv->conf_mutex) and mutex_unlock(&priv->conf_mutex) are moved to the places, which can protect the accesses to the shared variable. Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Johan Hedberg authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 1629db9c ] In case a command which completes in Command Status was sent using the hci_cmd_send-family of APIs there would be a misleading error in the hci_get_cmd_complete function, since the code would be trying to fetch the Command Complete parameters when there are none. Avoid the misleading error and silently bail out from the function in case the received event is a command status. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Acked-by:
Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
YueHaibing authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit fa89a459 ] gcc warn this: net/ipv6/xfrm6_tunnel.c:143 __xfrm6_tunnel_alloc_spi() warn: always true condition '(spi <= 4294967295) => (0-u32max <= u32max)' 'spi' is u32, which always not greater than XFRM6_TUNNEL_SPI_MAX because of wrap around. So the second forloop will never reach. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Johannes Berg authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit efc38dd7 ] Due to the alignment handling, it actually matters where in the code we add the 4 bytes for the presence bitmap to the length; the first field is the timestamp with 8 byte alignment so we need to add the space for the extra vendor namespace presence bitmap *before* we do any alignment for the fields. Move the presence bitmap length accounting to the right place to fix the alignment for the data properly. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
-
Christophe Leroy authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 05a4ab82 ] With the following piece of code, the following compilation warning is encountered: if (_IOC_DIR(ioc) != _IOC_NONE) { int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE : VERIFY_READ; if (!access_ok(verify, ioarg, _IOC_SIZE(ioc))) { drivers/platform/test/dev.c: In function 'my_ioctl': drivers/platform/test/dev.c:219:7: warning: unused variable 'verify' [-Wunused-variable] int verify = _IOC_DIR(ioc) & _IOC_READ ? VERIFY_WRITE : VERIFY_READ; This patch fixes it by referencing 'type' in the macro allthough doing nothing with it. Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
-
Mark Rutland authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 0d640732 ] When we emulate an MMIO instruction, we advance the CPU state within decode_hsr(), before emulating the instruction effects. Having this logic in decode_hsr() is opaque, and advancing the state before emulation is problematic. It gets in the way of applying consistent single-step logic, and it prevents us from being able to fail an MMIO instruction with a synchronous exception. Clean this up by only advancing the CPU state *after* the effects of the instruction are emulated. Cc: Peter Maydell <peter.maydell@linaro.org> Reviewed-by:
Alex Bennée <alex.bennee@linaro.org> Reviewed-by:
Christoffer Dall <christoffer.dall@arm.com> Signed-off-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
-
Beomho Seo authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 31e93364 ] Commit 391f93f2 ("serial: core: Rework hw-assited flow control support") has changed the way the autoCTS mode is handled. According to that change, serial drivers which enable H/W autoCTS mode must set UPSTAT_AUTOCTS to prevent the serial core from inadvertently disabling TX. This patch adds proper handling of UPSTAT_AUTOCTS flag. Signed-off-by:
Beomho Seo <beomho.seo@samsung.com> [mszyprow: rephrased commit message] Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Kai-Heng Feng authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit e03e303e ] We can use MEMSTICK_POWER_{ON,OFF} along with pm_runtime_{get,put} helpers to let memstick host support runtime pm. The rpm count may go down to zero before the memstick host powers on, so the host can be runtime suspended. So before doing card detection, increment the rpm count to avoid the host gets runtime suspended. Balance the rpm count after card detection is done. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by:
Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Fabio Estevam authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit add68836 ] eukrea-tlv320.c machine driver runs on non-DT platforms and include <asm/mach-types.h> header file in order to be able to use some machine_is_eukrea_xxx() macros. Building it for ARM64 causes the following build error: sound/soc/fsl/eukrea-tlv320.c:28:10: fatal error: asm/mach-types.h: No such file or directory Avoid this error by not allowing to build the SND_SOC_EUKREA_TLV320 driver when ARM64 is selected. This is needed in preparation for the i.MX8M support. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Fabio Estevam <festevam@gmail.com> Acked-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 88af3209 ] WARNING: vmlinux.o(.text+0x19f90): Section mismatch in reference from the function littleton_init_lcd() to the function .init.text:pxa_set_fb_info() The function littleton_init_lcd() references the function __init pxa_set_fb_info(). This is often because littleton_init_lcd lacks a __init annotation or the annotation of pxa_set_fb_info is wrong. WARNING: vmlinux.o(.text+0xf824): Section mismatch in reference from the function zeus_register_ohci() to the function .init.text:pxa_set_ohci_info() The function zeus_register_ohci() references the function __init pxa_set_ohci_info(). This is often because zeus_register_ohci lacks a __init annotation or the annotation of pxa_set_ohci_info is wrong. WARNING: vmlinux.o(.text+0xf95c): Section mismatch in reference from the function cm_x300_init_u2d() to the function .init.text:pxa3xx_set_u2d_info() The function cm_x300_init_u2d() references the function __init pxa3xx_set_u2d_info(). This is often because cm_x300_init_u2d lacks a __init annotation or the annotation of pxa3xx_set_u2d_info is wrong. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Jan Kara authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit d288d958 ] When inode is corrupted so that extent type is invalid, some functions (such as udf_truncate_extents()) will just BUG. Check that extent type is valid when loading the inode to memory. Reported-by:
Anatoly Trosinenko <anatoly.trosinenko@gmail.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 4f5c85fe ] It was observed that when using seqentional mode contrary to the documentation, the SS bit (which is supposed to only be set if automatic/sequence command completed normally), is sometimes set together with NA (NAK in address phase) causing transfer to falsely be considered successful. My assumption is that this does not happen during manual mode since the controller is stopping its work the moment it sets NA/ND bit in status register. This is not the case in Automatic/Sequentional mode where it is still working to send STOP condition and the actual status we get depends on the time when the ISR is run. This patch changes the order of checking status bits in ISR - error conditions are checked first and only if none of them occurred, the transfer may be considered successful. This is required to introduce using of sequentional mode in next patch. Signed-off-by:
Krzysztof Adamski <krzysztof.adamski@nokia.com> Reviewed-by:
Alexander Sverdlin <alexander.sverdlin@nokia.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Yangtao Li authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 9456823c ] of_find_node_by_path() acquires a reference to the node returned by it and that reference needs to be dropped by its caller. bl_idle_init() doesn't do that, so fix it. Signed-off-by:
Yangtao Li <tiny.windzz@gmail.com> Acked-by:
Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Anson Huang authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 0efcc2c0 ] Same as other i.MX6 SoCs, ensure unused MMDC channel's handshake is bypassed, this is to make sure no request signal will be generated when periphe_clk_sel is changed or SRC warm reset is triggered. Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Sergei Shtylyov authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 9f83cfdb ] The driver overrides the error codes returned by platform_get_irq() to -EINVAL, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Switch to propagating the error code upstream, still checking/overriding IRQ0 as libata regards it as "no IRQ" (thus polling) anyway... Fixes: 9ec36caf ("of/irq: do irq resolution in platform_get_irq") Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by:
-
Will Deacon authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit a868e853 ] After removing an entry from a queue (e.g. reading an event in arm_smmu_evtq_thread()) it is necessary to advance the MMIO consumer pointer to free the queue slot back to the SMMU. A memory barrier is required here so that all reads targetting the queue entry have completed before the consumer pointer is updated. The implementation of queue_inc_cons() relies on a writel() to complete the previous reads, but this is incorrect because writel() is only guaranteed to complete prior writes. This patch replaces the call to writel() with an mb(); writel_relaxed() sequence, which gives us the read->write ordering which we require. Cc: Robin Murphy <robin.murphy@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Jiong Wang authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 17f6c83f ] For micro-mips, srlv inside POOL32A encoding space should use 0x50 sub-opcode, NOT 0x90. Some early version ISA doc describes the encoding as 0x90 for both srlv and srav, this looks to me was a typo. I checked Binutils libopcode implementation which is using 0x50 for srlv and 0x90 for srav. v1->v2: - Keep mm_srlv32_op sorted by value. Fixes: f31318fd ("MIPS: uasm: Add srlv uasm instruction") Cc: Markos Chandras <markos.chandras@imgtec.com> Cc: Paul Burton <paul.burton@mips.com> Cc: linux-mips@vger.kernel.org Acked-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by:
Song Liu <songliubraving@fb.com> Signed-off-by:
Jiong Wang <jiong.wang@netronome.com> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Russell King - ARM Linux authored
BugLink: https://bugs.launchpad.net/bugs/1818813 [ Upstream commit 84fb6c7f ] It was noticed that unbinding and rebinding the KSZ8851 ethernet resulted in the driver reporting "failed to read device ID" at probe. Probing the reset line with a 'scope while repeatedly attempting to bind the driver in a shell loop revealed that the KSZ8851 RSTN pin is constantly held at zero, meaning the device is held in reset, and does not respond on the SPI bus. Experimentation with the startup delay on the regulator set to 50ms shows that the reset is positively released after 20ms. Schematics for this board are not available, and the traces are buried in the inner layers of the board which makes tracing where the RSTN pin extremely difficult. We can only guess that the RSTN pin is wired to a reset generator chip driven off the ethernet supply, which fits the observed behaviour. Include this delay in the regulator startup delay - effectively treating the reset as a "supply stable" indicator. This can not be modelled as a delay in the KSZ8851 driver since the reset generation is board specific - if the RSTN pin had been wired to a GPIO, reset could be released earlier via the already provided support in the KSZ8851 driver. This also got confirmed by Peter Ujfalusi <peter.ujfalusi@ti.com> based on Blaze schematics that should be very close to SDP4430: TPS22902YFPR is used as the regulator switch (gpio48 controlled): Convert arm boot_lock to raw The VOUT is routed to TPS3808G01DBV. (SCH Note: Threshold set at 90%. Vsense: 0.405V). According to the TPS3808 data sheet the RESET delay time when Ct is open (this is the case in the schema): MIN/TYP/MAX: 12/20/28 ms. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Reviewed-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> [tony@atomide.com: updated with notes from schematics from Peter] Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
